CF-Bootmedium erstellen
Archivierte Anleitung
Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.
Anmerkung: Im Artikel wird noch Upstart referenziert, Ubuntu 16.04 nutzt aber systemd.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Dieser Artikel erklärt detailliert, wie man eine Compact-Flash-Karte auf einem anderen Computer mit einem fertigen Betriebssystem für Alix-Boards vorbereitet. Die meisten Anleitungen, die sich im Internet finden lassen, erklären, wie eine Installation auf der Maschine selber funktioniert. Dies scheitert aber sehr oft daran, dass gerade, wo man es bräuchte, das Null-Modem-Kabel verschwunden ist, das neue Notebook oder der Computer ja gar keine serielle Schnittstelle mehr hat und zu einer ungünstigen Uhrzeit ein solches auch nicht mal eben schnell aufzutreiben ist.
Die Herausforderung liegt also darin, die Installation vollkommen offline auf einer anderen Maschine vorzubereiten, die daraus resultierende CF-Karte ins Alix-Board einzulegen, den Strom und das Netzwerk anzuschließen und sich nach wenigen Sekunden per SSH einloggen zu können.
Voraussetzungen¶
Um mit der Installation zu beginnen, muss Folgendes vorhanden sein:
Ein funktionierendes Netzwerk, welches Zugriff auf das Internet erlaubt.
Ein Rechner, auf dem ein Ubuntu läuft. Die Version ist prinzipiell egal.
Ein funktionsfähiges Alix-Board. Mit Hilfe des Verfahrens, welches in dieser Anleitung beschrieben wird, wurden Systeme für verschiedene Alix-Boards der Serie 2D.. aufgesetzt. Prinzipiell sollte diese Anleitung für alle Alix-Boards mit nur einer serieller Schnittstelle geeignet sein (um funktionierende Betriebssystems-Images erzeugen zu können).
Eine möglichst schnelle Compact-Flash-Karte, die mindestens 1GB groß sein sollte. Die Gesamtkapazität ist allerdings vom späteren Verwendungszweck abhängig.
ein externer Kartenleser
Sind alle diese Voraussetzungen erfüllt, kann mit der Installation begonnen werden.
Installation¶
Hinweis:
Nahezu alle hier nachfolgend aufgeführten Befehle erfordern Root-Rechte [1]. Um nicht jedem dieser Befehle sudo voranstellen zu müssen, empfiehlt es sich, die Installation in einer Root-Shell auszuführen. Diese kann durch Eingabe des Befehls sudo su erreicht werden.
Im Laufe dieses Artikels werden des öfteren Pakete mit apt-get installiert und deinstalliert. Dieser Befehl stellt nicht die einzige Möglichkeit dar, dies zu erreichen. Es ist zum Beispiel möglich, alternativ den Befehl aptitude zu verwenden, bei dem allerdings unter Umständen dann andere Parameter angegeben werden müssen.
Partitionierung und Formatierung¶
Um die Compact-Flash-Karte benutzen zu können, muss diese zuerst partitioniert und formatiert werden. Nach dem Einlegen im Kartenleser muss zunächst der Gerätename, unter dem die Karte angesprochen werden kann, ermittelt werden. Dies erreicht man, in dem man die Ausgaben des System Log beobachtet. Folgender Befehl, vor dem Einlegen der Karte ausgeführt, zeigt die bisherigen Meldungen:
tail -f /var/log/messages
Nach dem Einlegen der CF-Karte sollten dann neue Meldungen wie diese hier erscheinen:
Nov 25 06:36:10 transpoldo kernel: [58904.010195] sd 2:0:0:1: [sdc] 7847280 512-byte hardware sectors (4018 MB) Nov 25 06:36:10 transpoldo kernel: [58904.016240] sd 2:0:0:1: [sdc] Write Protect is off Nov 25 06:36:10 transpoldo kernel: [58904.026204] sd 2:0:0:1: [sdc] 7847280 512-byte hardware sectors (4018 MB) Nov 25 06:36:10 transpoldo kernel: [58904.032226] sd 2:0:0:1: [sdc] Write Protect is off Nov 25 06:36:10 transpoldo kernel: [58904.037168] sdc: sdc1
Hieran kann man erkennen, dass die CF-Karte den Gerätenamen /dev/sdc bekommen hat und sich darauf eine Partition mit dem Gerätenamen /dev/sdc1 befindet. An diesem Punkt kann das Partitionierungsprogramm aufgerufen werden [9]:
fdisk /dev/sdc
Im Partitionierungsprogramm sollten dann eventuell vorhandene Partitionen gelöscht werden, eine neue primäre Partition vom Typ 83 (Linux) die die ganze Karte umfasst erstellt werden und diese mit einem Boot-Flag versehen werden (Befehl 'a'). Das sieht bei einer 4 GB Karte ungefähr so aus:
Disk /dev/sdc: 4017 MB, 4017807360 bytes 128 heads, 63 sectors/track, 973 cylinders Units = cylinders of 8064 * 512 = 4128768 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdc1 * 1 973 3923104+ 83 Linux
Hinweis:
Ohne das Setzen des Boot-Flags (was man am Sternchen neben dem Gerätenamen der Partition erkennen kann), wird das System nicht von der Partition starten.
Nun kann die Partitionierung beendet werden, um mit der Erstellung des Dateisystems fortzufahren:
mke2fs -t ext2 -L root /dev/sdc1
Wie man hier sehen kann, wurde dem Volumen der Name root gegeben (was das Einhängen nach Namen erlaubt), und als Dateisystem wurde ext2 gewählt, was aufgrund der geringeren Anzahl Schreibzugriffe wegen der fehlenden Implementation des "Journaling", das Flash-RAM der CF-Karte schont. Da heutzutage moderne Flash-Controller über die Fähigkeit verfügen, die Schreibzugriffe gleichmäßig auf die Speicherzellen zu verteilen, wird die Wirksamkeit dieser Maßnahme zur Zeit kontrovers diskutiert. Die Benutzung des Dateisystems ext3 oder gar eines anderen Dateisystems ist durchaus auch möglich.
Hinweis:
Mit Angabe des Parameters -L root wurde dem Volumen der Name root gegeben. Auf Systemen mit udev erlaubt dies, die Partition nicht nur durch ihren Gerätenamen /dev/sdc1 sondern auch durch den Namen /dev/disk/by-label/root anzusprechen (bei gerade erst erstellten Volumen allerdings erst nach Eingabe des Befehls udevtrigger). Damit kann man das Problem mit ständig wechselnden Gerätenamen etwas entschärfen. Legt man z.B. ein USB-Stick ein, kann es beim nächsten Neustart durchaus passieren, dass die Reihenfolge der Gerätenamen sich geändert hat. Das Identifizieren nach Namen funktioniert allerdings nur, solange diese Namen auch eindeutig sind. Besser gelingt hier eine Identifizierung nach UUID. Diese pseudo-eindeutige Identifikationsnummer wird bei Erstellen des Dateisystems erzeugt und die Partition kann dann über /dev/disk/by-id/<UUID> angesprochen werden. Allerdings ist auch hier die Eindeutigkeit nicht wirklich gewährleistet, da einige Formatierungsprogramme wie z.B. mkswap das Angeben einer UUID erlauben. Außerdem kann eine Partition auch geklont werden.
Nach erfolgreicher Erzeugung des Dateisystems kann die neue formatierte CF-Karte ins Dateisystem eingebunden werden, um mit der Installation fortzufahren.
mkdir /mnt/alix mount /dev/sdc1 /mnt/alix
Installation des Basissystems¶
Zu Beginn wird auf der Karte ein minimales Basissystem installiert. Dafür wird das Paket
debootstrap
verwendet. Ist dieses nicht bereits installiert, so muss man es zuerst installieren [2].
Die Installation des Basissystems erfolgt mittels Eingabe des Befehls (entsprechend anpassen!):
Ubuntu 14.04:
debootstrap --arch i386 xenial /mnt/alix http://de.archive.ubuntu.com/ubuntu
Dieser Vorgang dauert je nach Geschwindigkeit der Internetverbindung (falls noch Pakete heruntergeladen werden müssen) und je nach Schreibgeschwindigkeit der CF-Karte unterschiedlich lange.
Wechsel in das Zielsystem¶
Ist dieser Vorgang erfolgreich beendet, ist es Zeit, in das neue Dateisystem zu wechseln[6]:
mount -o bind /dev /mnt/alix/dev mount -o bind /sys /mnt/alix/sys mount -o bind /proc /mnt/alix/proc chroot /mnt/alix /bin/bash
Konfiguration des Basissystems¶
Achtung!
Ab hier ist man per chroot auf dem späteren Zielsystem unterwegs. Alle eingegebenen Befehle im momentanen Terminal wirken sich nur dort aus!
Namensauflösung¶
Nicht jedes System braucht einen Namen, aber mit einem Namen lässt es sich besser leben:
echo alix-router > /etc/hostname
Und damit die ganze Namensauflösung zumindest rudimentär funktioniert, sollte die Datei /etc/hosts folgenden Inhalt haben:
127.0.0.1 localhost 127.0.1.1 alix-router.example.com alix-router # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts
Es lohnt sich auch, einen kurzen Blick in die Datei /etc/resolv.conf zu werfen. debootstrap kopiert hier üblicherweise die Datei des erzeugenden Systems hinein. Da das Alix-System zunächst im selben Netzwerk angeschlossen werden wird, stellt das kein Problem dar. Will man jedoch sicher stellen, dass auch nach einer Umkonfiguration die Namensauflösung höchstwahrscheinlich funktioniert, empfiehlt es sich hier, als Nameserver generell erreichbare wie z.B. die OpenDNS- und Google-Server einzutragen:
nameserver 8.8.8.8 nameserver 208.67.222.222 nameserver 8.8.4.4 nameserver 208.67.220.220
Dateisystem¶
Folgende Dateisystem-Tabelle /etc/fstab [7] stellt sicher, dass das System auch alle seine Dateisysteme korrekt einhängt:
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 # /dev/sda1 LABEL=root / ext2 noatime,errors=remount-ro 0 0 tmpfs /tmp tmpfs defaults,noatime 0 0 tmpfs /var/tmp tmpfs defaults,noatime 0 0
Die Option noatime beim Root-Dateisystem verhindert, dass jeder Dateizugriff (also auch lesende Zugriffe) das sogenannte atime-Attribut (Zeitstempel des letzten Zugriffes) aktualisiert. Dies schont den Flash-Speicher der CF-Karte. Aus diesem Grunde werden hier auch die temporären Verzeichnisse als RAM-Disk ausgelegt. Um den Flash-Speicher noch weiter zu schonen, kann man die Zeit für zeitversetzte Schreibzugriffe verlängern. Dies erfolgt, indem man folgende Zeilen in die Datei /etc/sysctl.conf einfügt:
vm.dirty_writeback_centisecs = 1500
Der Standard-Wert liegt normalerweise bei 500 (5 Sekunden). Der neue Wert 1500 (15 Sekunden) dürfte die Anzahl der tatsächlich stattfindenden Schreibzugriffe im laufenden Betrieb relevant senken.
Netzwerk¶
Innerhalb dieses Artikels wird angenommen, dass das vorhandene Netzwerk den Adressraum 192.168.97.0/24 besitzt und 192.168.97.1 das Standard-Gateway ist. Diese entsprechenden Werte müssen an die lokalen Gegebenheiten angepasst werden. Die Konfiguration der Netzwerkadressen der Adapter erfolgt statisch in der Datei /etc/network/interfaces. Diese wird hier nun mit folgendem Inhalt angelegt:
# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.97.100
netmask 255.255.255.0
gateway 192.168.97.1
# emergency fallback addresses
post-up ip addr add 169.254.19.65/16 dev eth0
pre-down ip addr del 169.254.19.65/16 dev eth0Hinweis:
Unter 16.04 werden ggf. andere Namen für die Geräte verwendet, da Predictable Network Interface Names 🇬🇧 verwendet werden. Daher müssen in der Datei /etc/network/interfaces statt eth0 durchgängig Einträge in der Form enp0sX verwendet werden. Hinweise zu dem verwendeten Namen findet man ggf. in /var/log/syslog oder /var/log/kern.log beispielsweise mit dem Befehl
grep eth0 LOGDATEI
Weitere Hinweise zu ggf. anderen Namen finden sich auch im Forum.
Da das Alix-System blind (ohne Bildschirm) gestartet wird, ist es sehr sinnvoll, eine feste IP-Adresse zu vergeben, da es sonst eher schwierig sein dürfte, die der Netzwerkkarte zugewiesene Adresse zu ermitteln. Die Angabe des Default-Gateways ist zwingend, da später auf dem System noch zusätzliche Pakete installiert werden müssen. Es ist übrigens extrem ratsam, noch zusätzlich eine bekannte APIPA-Adresse zu vergeben (wie z.B.: 169.254.19.65), da man so die Sicherheit hat, jederzeit mit dem Gerät Kontakt aufnehmen zu können, auch wenn die primäre Adresse vergessen wurde oder unbekannt ist. Die APIPA-Adresse sollte auch in Form eines Etiketts am Gerät befestigt werden.
Paketquellen eintragen¶
Die Paketquellen werden - entsprechend der gewünschten Ubuntu-Version - in sources.list eingetragen[5].
Für Ubuntu 16.04 (xenial):
# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to # newer versions of the distribution. ## Primary distribution source deb http://de.archive.ubuntu.com/ubuntu/ xenial main universe #deb-src http://de.archive.ubuntu.com/ubuntu/ xenial main universe ## Major bug fix updates produced after the final release of the ## distribution. deb http://de.archive.ubuntu.com/ubuntu/ xenial-updates main universe #deb-src http://de.archive.ubuntu.com/ubuntu/ xenial-updates main universe ## Security updates deb http://security.ubuntu.com/ubuntu xenial-security main universe #deb-src http://security.ubuntu.com/ubuntu xenial-security main universe
Paketabhängigkeitsmodus optimieren¶
Seit Ubuntu 8.10 ist auch der Paketmanager apt so konfiguriert, dass nicht nur Pakete mit direkter Abhängigkeit mitinstalliert werden, sondern auch Pakete, die sich in der Liste der empfohlenen Zusatzpakete ("Recommends") befinden. Dieses Verhalten ist in diesem spezifischen Falle aus verschiedenen Gründen unerwünscht, da zum einen beabsichtigt wird, ein möglichst schlankes System zu erzeugen, zum anderen aber auch vermieden werden soll, daß einer der vorgeschlagenen Bootmanager (in diesem Fall GRUB 2) automatisch mitinstalliert wird, da dieser in einem derartigen System nicht nur überdimensioniert sondern sogar schädlich sein kann, was im entsprechenden Abschnitt dieses Artikel näher erläutert wird.
Um also den Paketmanager dazu zu bringen, nur die notwendigen Abhängigkeiten zu installieren, wird die Datei /etc/apt/apt.conf.d/00onlydepends mit folgenden Inhalt angelegt:
APT::Install-Recommends "0"; APT::Install-Suggests "0";
Diese Änderung wirkt sich sowohl auf den Paketmanager apt als auch auf dem Paketmanager aptitude aus.
Regionale Einstellungen¶
Regionale Einstellungen und das Konsolensystem installieren [1]:
echo en_US.UTF-8 UTF-8 > /var/lib/locales/supported.d/local locale-gen apt-get update
oder alternativ
dpkg-reconfigure locales
Kernel und Bootloader¶
Nun kann ein geeigneter Kernel installiert werden.
Der Kernel für Ubuntu 14.04 benötigt die Unterstützung der CPU von PAE, welches der AMD-Geode-Prozessor nicht bietet. Phill Whiteside 🇬🇧 hat für 14.04 Kernel ohne PAE erstellt. Für Ubuntu 14.04 erfolgt die Installation des Non-PAE-Kernel mittels Eingabe der Befehle:
apt-get -y install wget wget http://phillw.net/isos/non-pae/14.04/alternate-14.04/linux-firmware-image-3.13.0-non-pae_124_i386.deb wget http://phillw.net/isos/non-pae/14.04/alternate-14.04/linux-headers-3.13.0-non-pae_124_i386.deb wget http://phillw.net/isos/non-pae/14.04/alternate-14.04/linux-image-3.13.0-non-pae_124_i386.deb wget http://phillw.net/isos/non-pae/14.04/alternate-14.04/linux-libc-dev_124_i386.deb dpkg -i *.deb rm *non-pae*.deb
Für Ubuntu 16.04:
apt-get -y install wget wget http://phillw.net/isos/non-pae/16.04/linux-firmware-image-4.4.0-non-pae_4.4.0-non-pae-1_i386.deb wget http://phillw.net/isos/non-pae/16.04/linux-headers-4.4.0-non-pae_4.4.0-non-pae-1_i386.deb wget http://phillw.net/isos/non-pae/16.04/linux-image-4.4.0-non-pae_4.4.0-non-pae-1_i386.deb wget http://phillw.net/isos/non-pae/16.04/linux-libc-dev_4.4.0-non-pae-1_i386.deb dpkg -i *.deb rm *non-pae*.deb
Bootmanager installieren¶
Damit das System starten kann, benötigt es noch einen Bootmanager. In üblichen Ubuntu-Installationen wird der Bootmanager GRUB eingesetzt, der in diesem spezifischen Fall derart konfiguriert wird, dass er seine Ein- und Ausgaben über die serielle Schnittstelle erledigt. Bedauerlicherweise wurde aber auf verschiedenen Alix-Boards beobachtet, daß dies dazu führen kann, daß nach dem Einschalten des Systems, dieses nicht automatisch bootet, sondern im GRUB Menü verweilt. Dies ist vermutlich darauf zurückzuführen, daß anscheinend der Einschaltimpuls nach zufälligem Muster Zeichen im Seriellen Puffer erscheinen lässt, was die automatische Boot-Sequenz unterbricht.
Um den Benutzer die Wahl zwischen den verschiedenen Boot-Managern zu überlassen, folgen nun die Anleitungen für die Installationen sowohl von SYSLINUX als auch von GRUB.
Achtung!
Bitte bei allen nachfolgenden Aktionen darauf achten, dass der angesprochene Gerätename auch tatsächlich der ist, unter dem die CF-Karte im System angesprochen wird. Blindes Ausführen der Befehle kann ansonsten zu unerwünschten Resultaten führen!
Booten mit SYSLINUX¶
Das SYSLINUX-Projekt stellt kompakte Boot-Loader für das Starten von MS-DOS-FAT-Dateisysteme (SYSLINUX), für das Starten über das Netzwerk (PXELINUX), für das Starten von bootbaren "El Torito" CD-ROMs (ISOLINUX) und für das Starten von ext2/ext3 Dateisystemen (EXTLINUX) zur Verfügung.
Installation von SYSLINUX unter Ubuntu 14.04¶
Mit folgenden Befehlen wird SYSLINUX installiert und die CF-Karte bootbar gemacht:
apt-get -y install extlinux mkdir -f /boot/extlinux extlinux --install /boot/extlinux dd if=/usr/lib/extlinux/mbr.bin of=/dev/sdc
Als nächstes wird die Konfiguration des SYSLINUX Bootmanagers angepasst. Dafür muss die Datei /etc/default/extlinux editiert werden:
EXTLINUX_UPDATE="true" EXTLINUX_ALTERNATIVES="default recovery" EXTLINUX_DEFAULT="l0" EXTLINUX_ENTRIES="all" EXTLINUX_MENU_LABEL="Ubuntu GNU/Linux, kernel" EXTLINUX_PARAMETERS="ro reboot=bios console=ttyS0,38400n8" EXTLINUX_ROOT="root=/dev/sda1" EXTLINUX_THEME="none" EXTLINUX_TIMEOUT="50"
Zum Schluss noch ein mal
extlinux-update
aufrufen. Hiermit ist die Installation des Bootmanagers abgeschlossen.
Booten mit GRUB 2¶
Seit Version 9.10 benutzt Ubuntu GRUB 2. Die Installation erfolgt mittels folgenden Befehls:
apt-get -y install grub-pc
Während der Installation werden verschiedene Fragen gestellt, die alle mit der Eingabetaste bestätigt werden können. Wichtig ist hier lediglich, in der Liste der vorhandenen Geräte nur die CF-Karte (in diesem Fall /dev/sdc) auszuwählen. Weiteren Anpassungen erfolgen mittels Eingabe diverser Werte in einigen Konfigurationsdateien.
Als nächstes wird die Konfiguration des GRUB 2[11] angepasst. Dafür muss die Datei /etc/default/grub folgenden Inhalt vorweisen:
# If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. GRUB_DEFAULT=0 GRUB_HIDDEN_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT="3" GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="verbose console=ttyS0,38400n8 reboot=bios" GRUB_CMDLINE_LINUX="" # Konfiguration der seriellen Schnittstelle der Alix-Boards: GRUB_SERIAL_COMMAND="serial --unit=0 --speed=38400" GRUB_TERMINAL=serial # Uncomment to disable graphical terminal (grub-pc only) #GRUB_TERMINAL=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' #GRUB_GFXMODE=640x480 # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux #GRUB_DISABLE_LINUX_UUID=true # Uncomment to disable generation of recovery mode menu entrys #GRUB_DISABLE_LINUX_RECOVERY="true"
Die eingebenen Änderungen bewirken, dass GRUB 2 seine Ein- und Ausgaben über die serielle Schnittstelle entgegen nimmt und ansonsten alle Pausen recht kurz ausfallen.
In nachfolgenden Schritt wird GRUB 2 nun in die CF-Karte installiert. Da diese sich allerdings noch nicht im Zielsystem befindet, gibt es einen Unterschied zwischen den Parametern, wie sie im Boot-Sektor eingetragen werden müssen (z.B. dass sich das Betriebsystem auf dem ersten Datenträger befindet), und der momentanen Realität (und zwar die, dass das künftige Boot-Medium sich als zusätzliches Laufwerk in einem anderen System befindet). Zu diesem Zwecke wird die Zuweisung zwischen dem internen Gerätenamen und dem effektiven Gerätenamen in der Namens-Abgleichstabelle /boot/grub/devices.map von GRUB 2 folgendenmaßen getätigt:
(hd0) /dev/sdc
Hierbei ist es existentiell wichtig, dass der Gerätename der CF-Karte eingegeben wird. Dieser wird sich später im laufenden System verändern. Hier soll jetzt erst mal der Name aus Sicht des installierenden Systems stehen. An diesem Punkt kann GRUB2 anhand der neuen Werte auf die CF-Karte mit folgenden Befehlen installiert und konfiguriert werden:
grub-install /dev/sdc update-grub
Nach der Installation kann nun die Namens-Abgleichstabelle /boot/grub/devices.map mit dem endgültigen Eintrag versehen werden:
(hd0) /dev/sda
Damit auch bei künftigen Kernel-Aktualisierungen GRUB 2 seine Konfiguration anpassen kann, müssen noch folgende Zeilen der Datei /etc/kernel-img.conf hinzugefügt werden:
postinst_hook = update-grub postrm_hook = update-grub
Root-Passwort¶
Damit ein Login über SSH funktioniert, muss noch das Password für den Benutzer root festgelegt werden:
passwd root
Serielle Konsole¶
Eine Standardinstallation konfiguriert eine Bildschirm-Konsolensystem mit sechs Konsolen. Diese werden nicht benötigt und daher entfernt. Dafür ist es lediglich erforderlich, die Event-Handler-Konfigurationsdateien der sechs Bildschirmkonsolen aus dem Event-Handler-Verzeichnis von Archiv/Upstart zu entfernen:
rm /etc/init/tty?.conf
Stattdessen wird nun eine Konfigurationsdatei benötigt, die dafür zuständig ist, eine serielle Konsole einzurichten. Dies erfolgt durch Erstellen der Datei /etc/init/ttyS0.conf mit folgendem Inhalt:
# ttyS0 - getty # # This service maintains a getty on tty1 from the point the system is # started until it is shut down again. start on stopped rc RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /sbin/getty -8 38400 -L ttyS0
Zeitzone¶
Die Zeitzone des Systems wird mit folgendem Befehl festgelegt:
dpkg-reconfigure tzdata
Zugang über SSH¶
Um auf das laufende System zugreifen zu können, muss ein SSH-Server installiert werden [2]:
openssh-server
Ab hier ist das System über das Netz erreichbar.
Achtung!
Der SSH-Server akzeptiert standardmäßig die Authentifiziereung mittels Passwort. Sobald das System in den Regelbetrieb gehen wird, wird empfohlen, diese Möglichkeit abzuschalten, da sie ein erhebliches Sicherheitsrisiko darstellt. Bei abgeschalteter Passwort-Authentifizierung ist es nur noch möglich, sich mittels privatem Schlüssel anzumelden. Zu diesem Zwecke ist dafür Sorge zu tragen, den eigenen öffentlichen Schlüssel in die Datei ~/.ssh/authorized_keys des entsprechenden Benutzers einzutragen. Die Passwort-Authentifizierung kann bei OpenSSH abgeschaltet werden, indem man die Option PasswordAuthentication in der Datei /etc/ssh/sshd_config auf no setzt.
Zusätzlich geladene Module¶
Damit das System beim Start auch die Kernelmodule ("Treiber") für spezielle Hardware-Komponenten der Alix-Boards lädt, werden diese in der Datei /etc/modules eingetragen[10]:
# /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. # Alix Specific: natsemi lm90 scx200_acb base=0x810,0x820 leds-alix ledtrig-default-on ledtrig-heartbeat ledtrig-gpio ledtrig-timer
Installation abschließen und CF-Karte aushängen¶
An diesem Punkt ist die eigentliche Installation abgeschlossen. Vor dem Entfernen der CF-Karte aus dem Kartenleser müssen aber noch folgende Befehle ausgeführt werden:
exit umount /mnt/alix/proc umount /mnt/alix/sys umount /mnt/alix/dev umount /mnt/alix
Sollte der letzte Befehl eine Fehlermeldung ausgeben, ist zu prüfen, ob noch ein Prozess auf das Verzeichnis /mnt/alix oder dessen Unterverzeichnisse zugreift. Erst wenn das Dateisystem ohne Fehlermeldung ausgehängt wurde, kann die Karte entnommen werden.
Achtung!
Nach der Eingabe des Befehls exit wird chroot beendet und man ist nicht mehr auf dem späteren Zielsystem unterwegs. Alle eingebenen Befehle im momentanen Terminal wirken sich wieder auf das reale System aus!
Erster Start¶
Nach dem Einlegen der CF-Karte ins Alix-Board kann nun ein erster Start gewagt werden. Vor dem Einschalten muss das System aber noch ans Netzwerk angeschlossen werden. Bei Alix-Boards mit mehreren Netzwerkkarten ist die erste Netzwerkkarte erfahrungsgemäß jene, die sich direkt neben der Stromversorgungsbuchse befindet. Will man auf Nummer sicher gehen, so kann man alle Netzwerkstecker mit dem Netzwerk verbinden. An diesem Punkt kann das System eingeschaltet werden. Um festzustellen, wann das System hochgefahren ist und im Netzwerk erscheint, kann man vor dem Einschalten auf dem eigenen Rechner schon mal folgenden Befehl eingeben:
ping 192.168.97.100
Nach ca. 10-15 Sekunden sollte sichtbare Aktivität auf beiden LEDs des aktiven Netzwerk-Anschlusses zu sehen sein. Der Erfolg ist dadurch zu erkennen, dass das Alix-System auf die Pings antwortet:
ping 192.168.97.100
PING 192.168.97.100 (192.168.97.100) 56(84) bytes of data. From 192.168.97.249 icmp_seq=1 Destination Host Unreachable [...] From 192.168.97.249 icmp_seq=6 Destination Host Unreachable 64 bytes from 192.168.97.100: icmp_seq=7 ttl=64 time=2001 ms 64 bytes from 192.168.97.100: icmp_seq=8 ttl=64 time=992 ms --- 192.168.97.100 ping statistics --- 11 packets transmitted, 5 received, +6 errors, 54% packet loss, time 10026ms rtt min/avg/max/mdev = 0.389/599.057/2001.498/799.607 ms, pipe 3
Tritt dieser Fall nicht ein, so ist davon auszugehen, dass das System nicht gestartet ist, die Netzwerk-Konfiguration nicht mit dem Netzwerk kompatibel ist oder bei der Ausführung der oben genannten Schritte etwas schiefgegangen ist. Eine genaue Analyse des Inhalts der CF-Karte erlaubt es in der Regel, den Fehler schnell zu finden. Allerdings sollte man auch in Erwägung ziehen, sich mit der passenden Hardware an die serielle Schnittstelle anzuschließen und den Startvorgang des Systems genau zu verfolgen.
Ist hingegen erwartungsgemäß alles gut gegangen, kann man sich nun mit dem System mittels SSH verbinden:
ssh -l root 192.168.97.100
The authenticity of host '192.168.97.100 (192.168.97.100)' can't be established. RSA key fingerprint is ec:38:36:0b:42:9c:c2:ae:17:6d:8f:d5:27:24:9d:f0. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.97.100' (RSA) to the list of known hosts. root@192.168.97.100's password: Linux alix-router 2.6.31-15-386 #50-Ubuntu SMP Tue Nov 10 17:30:14 UTC 2009 i586 To access official Ubuntu documentation, please visit: http://help.ubuntu.com/ root@alix-router:~#
Das System ist nun lauffähig und bereit für den letzten Feinschliff.
Hinweis:
Standardmäßig ist der SSH-Remote-Shell-Zugriff für den Benutzer root gesperrt. Jeglicher Versuch, sich per root auf die Maschine zu schalten, resultiert deshalb in eine Fehlermeldung:
Permission denied, please try again.
Um die entsprechende Berechtigung zu erteilen, muss in /etc/ssh/sshd_config in einem Editor mit Root-Rechten folgende Anpassung vorgenommen werden:
PermitRootLogin prohibit-password
wird in
PermitRootLogin yes
geändert.
Anschließend muss mittels
sudo systemctl restart sshd
der SSH-Daemon neu gestartet werden. Danach kann mit dem Root-User per SSH eine Remote Shell geöffnet werden.
Im tatsächlichen Einsatz ist es allerdings ratsam, einen zweiten User mit eingeschränkten Privilegien anzulegen. Gute Gründe dafür werden auf unix.stackexchange.com 🇬🇧 genannt.
Finale Konfiguration und Optimierung¶
Aktualisierung und Softwareinstallation¶
Zunächst das ganze System aktualisieren und die Standard-Systemkomponenten installieren:
apt-get update apt-get upgrade apt-get -y install ubuntu-standard screen
Damit Screen auch angenehm benutzbar wird, sollte die entsprechende Konfigurationsdatei /etc/screenrc noch etwas verbessert werden. Hier die vollständige geänderte Fassung mit Änderungsvermerken:
# $Id: screenrc,v 1.15 2003/10/08 11:39:03 zal Exp $
#
# /etc/screenrc
#
# This is the system wide screenrc.
#
# You can use this file to change the default behavior of screen system wide
# or copy it to ~/.screenrc and use it as a starting point for your own
# settings.
#
# Commands in this file are used to set options, bind screen functions to
# keys, redefine terminal capabilities, and to automatically establish one or
# more windows at the beginning of your screen session.
#
# This is not a comprehensive list of options, look at the screen manual for
# details on everything that you can put in this file.
#
# ------------------------------------------------------------------------------
# SCREEN SETTINGS
# ------------------------------------------------------------------------------
startup_message off
#nethack on
#defflow on # will force screen to process ^S/^Q
deflogin on
#autodetach off
# turn visual bell on
# vbell on
# vbell_msg " Wuff ---- Wuff!! "
# define a bigger scrollback, default is 100 lines
defscrollback 10240
# ------------------------------------------------------------------------------
# SCREEN KEYBINDINGS
# ------------------------------------------------------------------------------
# Remove some stupid / dangerous key bindings
bind ^k
#bind L
bind ^\
# Make them better
bind \\ quit
bind K kill
bind I login on
bind O login off
bind } history
# An example of a "screen scraper" which will launch urlview on the current
# screen window
#
#bind ^B eval "hardcopy_append off" "hardcopy -h $HOME/.screen-urlview" "screen urlview $HOME/.screen-urlview"
# ------------------------------------------------------------------------------
# TERMINAL SETTINGS
# ------------------------------------------------------------------------------
# The vt100 description does not mention "dl". *sigh*
termcapinfo vt100 dl=5\E[M
# turn sending of screen messages to hardstatus off
hardstatus off
# Set the hardstatus prop on gui terms to set the titlebar/icon title
termcapinfo xterm*|rxvt*|kterm*|Eterm* hs:ts=\E]0;:fs=\007:ds=\E]0;\007
# use this for the hard status string
hardstatus string "%h%? users: %u%?"
# An alternative hardstatus to display a bar at the bottom listing the
# windownames and highlighting the current windowname in blue. (This is only
# enabled if there is no hardstatus setting for your terminal)
#
#hardstatus lastline "%-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%<"
# set these terminals up to be 'optimal' instead of vt100
termcapinfo xterm*|linux*|rxvt*|Eterm* OP
# Change the xterm initialization string from is2=\E[!p\E[?3;4l\E[4l\E>
# (This fixes the "Aborted because of window size change" konsole symptoms found
# in bug #134198)
termcapinfo xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'
# To get screen to add lines to xterm's scrollback buffer, uncomment the
# following termcapinfo line which tells xterm to use the normal screen buffer
# (which has scrollback), not the alternate screen buffer.
#
#termcapinfo xterm|xterms|xs|rxvt ti@:te@
# Enable non-blocking mode to better cope with flaky ssh connections.
defnonblock 5
# ------------------------------------------------------------------------------
# STARTUP SCREENS
# ------------------------------------------------------------------------------
# Example of automatically running some programs in windows on screen startup.
#
# The following will open top in the first window, an ssh session to monkey
# in the next window, and then open mutt and tail in windows 8 and 9
# respectively.
#
# screen top
# screen -t monkey ssh monkey
# screen -t mail 8 mutt
# screen -t daemon 9 tail -f /var/log/daemon.log
hardstatus alwayslastline "%{kw} %{b}%H%{K} < %-w%{Wb} %n %t %{-}%+w >"
# This lets work all functions keys in midnight commander
termcapinfo xterm 'k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~'Ansteuerung der LEDs¶
Zur Ansteuerung der LEDs müß das entsprechende Modul kompiliert und geladen werden. Eine detaillierte Beschreibung dazu findet sich in LEDs ansteuern.
Damit die erste LED nicht einfach nur stur vor sich hin leuchtet, sondern ein wenig Rückmeldung über den Systemstatus und Run Level gibt, hier ein Event-Handler in Form der Datei /etc/init/watchdog-led.conf:
# WatchDog LED Configuration for Alix-Boards
#
# This task configures the watchdog led to resemble the status
# of the system
description "Configuration of the first alix led (Watchdog led)"
author "Leo Moll <leo@yeasoft.com>"
start on runlevel [0123456]
stop on runlevel [!$RUNLEVEL]
export RUNLEVEL
export PREVLEVEL
task
script
case $RUNLEVEL in
1|6) echo timer > /sys/class/leds/alix\:1/trigger
echo 100 > /sys/class/leds/alix\:1/delay_on
echo 100 > /sys/class/leds/alix\:1/delay_off
;;
0) echo 0 > /sys/class/leds/alix\:1/brightness
echo none > /sys/class/leds/alix\:1/trigger
;;
2|3|4|5) echo heartbeat > /sys/class/leds/alix\:1/trigger
;;
*) echo timer > /sys/class/leds/alix\:1/trigger
echo 100 > /sys/class/leds/alix\:1/delay_on
echo 300 > /sys/class/leds/alix\:1/delay_off
;;
esac
end scriptBasierend auf dem entsprechenden Run Level verhält sich nun die erste LED folgendermaßen:
Normaler Betrieb: Herzschlag (Heartbeat)
Reboot: Schnelles blinken
System heruntergefahren: LED aus
Beim Starten: LED an
System gestartet in Run Level 1: schnelles blinken
Anderer Runlevel: Kurzes blinken
Fazit¶
Das System befindet sich nun im Zustand eines gut funktionierenden Basissystems. Dies ist ein hervorragender Startpunkt, um beliebige Spezial-Applikationen wie z.B. Spezialrouter, kleine Netzwerkserver oder Telefonanlagen daraus zu fabrizieren.
Hinweis:
Möchte man das System auf weitere CF-Karten klonen bzw. die CF-Karte in ein anderes Alix-System einsetzen, so darf nicht vergessen werden, die Datei /etc/udev/rules.d/70-persistent-net.rules zu löschen. Tut man dies nicht, werden die Netzwerkadapter neue Namen erhalten (z.B. eth3, eth4 und eth5) und werden nicht initialisiert (da diese ja nicht in der /etc/network/interfaces stehen).
Links¶
LEDs 🇩🇪 - Blogbeitrag 05/2008
The Syslinux Project 🇬🇧 Homepage des SYSLINUX Projektes
Archiv/Alix - Hauptartikel