Mit der neuen Kernelserie 4.9 wird es einige grundlegende Änderungen und weitergehende Möglichkeiten geben.

Die Bootdateien des neuen Kernels nutzen schon udev und bringen außerdem alle möglichen Module für Festplatten-Controller mit. Dadurch kann eine Installation ohne Änderung der initrd auf eine neue Hardware übertragen werden und sollte dort problemlos booten.

Dadurch werden allerdings die Bootdateien viel größer als bisher, wodurch der Platz in /boot eng werden kann. Gegebenenfalls muss mittels entsprechender Tools die boot-Partition vergrößert werden.

Es werden prinzipiell nur zwei Varianten der initrd erzeugt, je nachdem, ob das spätere Bootmedium eine interne Platte oder ein USB-Stick ist:

Im ersten Fall werden die Module usb-storage und uas blacklisted, damit sich Devices eventuell angeschlossener USB-Sticks/Platten nicht zwischen die Devices der internen Platten schieben können; insbesondere könnte es sonst passieren, dass sich ein USB-Device zwischen die Platten eines RAIDs drängelt. Die Module usb-storage und uas werden in diesem Fall erst nach der Durchlaufen der initrd im Init-Prozess geladen.

Im zweiten Fall werden die Module usb-storage und uas nicht blacklisted, da sie beim Booten für den Zugriff auf das auf USB installierte System benötigt werden.

Mit dem Base-Update 2.8.18 wurde die fstab derart angepasst, dass die Partitionen der Boot-Platte (boot, swap und root) mittels UUID gemountet werden, so dass der Boot nicht davon abhängt, wie udev die sdX-Devices auf die physikalischen Platten verteilt. Eine entsprechende Konvertierung auf eindeutige Platten- und Partitions-UUIDs der /etc/lilo.conf nehmen die aktuellen Kernelpakete beim Update vor.

Mit dem Kernel 4.9 entfällt das alte fest in den Kernel integrierte IDE-Modul und somit nun auch die hdX-Devices. IDE-Devices werden nun auch von den libata basierten Modulen behandelt, womit diese zu sdX-Devices werden. Dies kann auf Systemen, die bislang hdX- und sdX-Devices hatten, zu Verschiebungen führen.

Für den 4.9er-Kernel werden folgende AVM-Modulpakete zur Verfügung stehen:

• avm_fritz-1_pci
• avm_fritz_usb2x

Da die Boot-Dateien, insbesondere die initrd, die nun alle möglichen Festplattenkontroller-Module mitbringt, deutlich größer sind (Kernel 3.16 ca. 7-8 MB, Kernel 4.9 12-14 MB), wird für die Bootvarianten eis, oldeis und gegebenenfalls auch die Fallback-Option mehr Platz in der Boot-Partition benötigt, als es ältere Installer eingerichtet haben. Zukünftige Installer werden für die Boot-Partition 96 MB vorsehen, wenn das Installationsmedium größer als 1 GB ist.

Ist die Bootpartition zwischen etwa 43 MB und 50 MB groß, ist bei Installation von testing-Kernels eventuell kein Platz zum Anlegen einer Fallback-Bootoption auf den letzten stable Kernel vorhanden, für die beiden Boot-Optionen eis und oldeis als 4.9er-Kernel würde der Platz jedoch ausreichen. Ab etwa 50 MB Größe ist auch für die Fallback-Bootoption vorläufig genügend Platz vorhanden, es bestünde also in diesem Fall derzeit kein dringender Handlungsbedarf, die Boot-Partition zu vergrößern. Die Platzverhältnisse lassen sich mit folgenden Befehlen feststellen:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/md3         16G  2.6G   13G  18% /
tmpfs           4.0G  440K  4.0G   1% /run
devtmpfs        4.0G  4.0K  4.0G   1% /dev
/dev/md1         49M   32M   14M  71% /boot
/dev/md4        442G   25G  395G   6% /data
tmpfs           4.0G     0  4.0G   0% /run/shm

In diesem Beispiel wären in /boot von 49 MB nun 32 MB belegt, wobei dies in diesem Beispiel zwei 4.9er-Kernel (eis und oldeis) und ein Fallback auf den vorigen stable Kernel 3.16.74 sind:

# ls -l /boot          
total 31010
-rw-r--r-- 1 root root     512 May 26  2004 boot.0300
-rw-r--r-- 1 root root     512 Nov  7  2012 boot.0800
-rw-r--r-- 1 root root     512 Nov  7  2012 boot.0810
-rw-r--r-- 1 root root     512 Oct  6 09:28 boot.0820
-rw-r--r-- 1 root root     512 Nov  7  2012 boot.0901
-rw-r--r-- 1 root root    4368 May 26  2004 boot.b
-rw-r--r-- 1 root root 3693026 Oct 15 18:34 initrd-3.16.74-PAE.gz
-rw-r--r-- 1 root root 8735951 Nov 26 06:39 initrd.gz
-rw-r--r-- 1 root root 3583712 Nov 26 06:39 kernel
-rw-r--r-- 1 root root 3055072 Oct 15 18:34 kernel-3.16.74-PAE
drwx------ 2 root root   12288 Nov  7  2012 lost+found
-rw------- 1 root root  328704 Nov 26 06:40 map
-rw-r--r-- 1 root root 8747036 Nov  6 06:59 old-initrd.gz
-rw-r--r-- 1 root root 3583712 Nov  6 06:59 old-kernel

Mittels gparted (https://gparted.org/livecd.php) kann boot auf Kosten der anderen Partitionen vergrößert werden. Auf einer Standard eisfair-Installation mit boot (1. Partition), swap (2. Partition) und root (3. Partition) könnte man mittels gparted die swap-Partition am Anfang um einige MB verkleinern und diese dann der boot-Partition zuschlagen. Ohne swap-Partition muss man den notwendigen Platz durch Verkleinern der root-Partition freiräumen. Eine Kurzanleitung zu gparted hat Heise/c't als Tipp und Trick https://www.heise.de/tipps-tricks/Linux-Partition-vergroessern-4164154.html veröffentlicht.

Auch wenn gparted selbst bei richtiger Anwendung perfekt funktioniert, ist ein Image der Platte Pflicht, denn Bedienfehler, Rechnerabstürze oder Stromausfälle kann auch gparted nicht ungeschehen machen! Diese Anleitung gilt nur für normale und nicht für RAID-Systeme, bei denen die Systempartitionen von eisfair auf einem RAID liegen! Thomas Zweifel hat in der Newsgroup eine Anleitung zur Vergrößerung für diesen Fall geschrieben: https://web.nettworks.org/forum/index.php?t=msg&th=10264&goto=75599&#msg_75599
Liegen die Systempartitionen jedoch auf einer einzelnen Platte und das RAID ist zusätzlich z. B. als Datenablage vorhanden, kann diese Anleitung verwendet werden. Den eventuell hinter der letzten Partition befindliche Freiraum ist Absicht, insbesondere wenn er etwa 10 MB groß ist. Diesen niemals der vorhergehenden Partition zuschlagen! Am besten verändert man den rechten Rand der letzten Partition nicht. Jede zu bearbeitende Partition (außer swap) vorher überprüfen (fsck), was in der gparted-Oberfläche als Aktion gemacht werden kann. Auch wenn inzwischen manche Operationen sogar im gemounteten Zustand möglich sind, rate ich dringend dazu, alle Aktionen nur bei ungemounteten Partitionen durchzuführen.

Im folgenden eine Schritt für Schritt Anleitung zur Vergrößerung der boot-Partition (/dev/sdX1) auf Kosten der swap-Partition (/dev/sdX2), natürlich ohne jede Gewähr; sdX bezeichnet hier und im folgenden das Device der Platte, wie es in gparted erscheint:

• Booten des gparted-Livesystem von CD-Rom oder USB-Stick. Nach Aufbau des Desktop startet gparted mit root-Rechten automatisch.
• Wähle aus der Schaltfläche am rechten oberen Bildschirmrand die richtige Platte aus.
• Mit Rechtsklick auf die Partition /dev/sdX1 das Kontextmenü aufrufen, „Überprüfen“ auswählen und mit dem „Anwenden“-Button durchführen.
• Mit Rechtsklick auf die Partition /dev/sdX2 das Kontextmenü aufrufen, „Größe ändern/Verschieben“ auswählen.
• Nun wenden wir uns zunächst der swap-Partition zu und verkleinern diese, so dass vor ihr freier Platz entsteht.
• Im „Größe ändern/Verschieben“-Fenster zunächst die Option „Ausrichten an:“ auf MiB stellen.
• Nun mit der Maus das schwarze Dreieck an der linken Seite anfassen (Rechts-Links-Pfeil erscheint) und wie gewünscht nach rechts verschieben; die Eingabeboxen zeigen die gewählten Werte numerisch an.
• Durch Klick auf „Größe ändern/Verschieben“ wird die eingestellte Operation vorgemerkt.
• Nun wenden wir uns der boot-Partition zu und vergrößern diese bis zum Beginn der swap-Partition.
• Mit Rechtsklick auf die Partition /dev/sdX1 das Kontextmenü aufrufen, „Größe ändern/Verschieben“ auswählen.
• Im „Größe ändern/Verschieben“-Fenster zunächst die Option „Ausrichten an:“ auf MiB stellen.
• Nun mit der Maus das schwarze Dreieck an der rechten Seite anfassen (Rechts-Links-Pfeil erscheint) und bis an den rechten Rand verschieben; die Eingabeboxen zeigen die gewählten Werte numerisch an.
• Durch Klick auf „Größe ändern/Verschieben“ wird die eingestellte Operation vorgemerkt.

Nun sind die gewünschten Operationen vorgemerkt, sie werden im unteren Abschnitt des gparted-Fensters aufgelistet, aber bis auf den Dateisystemcheck der boot-Partition ist noch nichts passiert. Man kann durch Rechtsklick in diesem Operationen-Abschnitt auch „alle Operationen löschen“, mit „letzte Operation rückgängig machen“ der Reihe nach Operationen wieder entfernen oder gparted beenden.

• Zur Durchführung der vorgemerkten Operationen, klickt man nun auf den „Anwenden“-Button. Nun werden alle Operationen in der festgelegten Reihenfolge abgearbeitet. Danach kann gparted beendet, der PC heruntergefahren und eisfair wieder gebootet werden.

Hat man keine swap-Partition, muss man obige Schritte ebenfalls für /dev/sdX2 durchführen, nur das dies dann eben die root-Partition ist. Diese sollte, wie oben für die boot-Partition geschehen, vorher überprüft werden.

Ist es nicht gewollt, eine vorhandene swap-Partition (/dev/sdX2) zu verkleinern, muss der für boot zusätzlich benötigte Platz durch Verkleinern der root-Partition (/dev/sdX3) bereitgestellt werden:

• Nach Überprüfung verkleinern der root-Partition (/dev/sdXa3), so dass vor ihr Freiraum entsteht.
• Verschieben der swap-Partition (/dev/sdX2) bis zum Beginn der root-Partition; im „Größe ändern/Verschieben“-Fenster mit Partition mit der Maus innerhalb des Partitions-Rechtecks anfassen und ganz nach rechts schieben,wodurch nun Freiraum vor der swap-Partition entsteht.
• Wie oben beschrieben nun die boot-Partition (/dev/sdX1) vergrößern.

Befindet sich auf der eisfair-Systemplatte neben den drei Standardpartitionen auch eine vierte Partition (/dev/sdX4), die sogenannte data-Partition, kann auch diese den für die boot-Partition zusätzlich benötigten Platz bereitstellen:

• Nach Überprüfung verkleinern der data-Partition (/dev/sdX4), so dass vor ihr Freiraum entsteht
• Nach Überprüfung verschieben der root-Partition (/dev/sdX3) bis zum Beginn der data-Partition; im „Größe ändern/Verschieben“-Fenster mit Partition mit der Maus innerhalb des Partitions-Rechtecks anfassen und ganz nach rechts schieben, wodurch nun Freiraum vor der root-Partition entsteht.
• Verschieben der swap-Partition (/dev/sdX2) bis zum Beginn der root-Partition; im „Größe ändern/Verschieben“-Fenster mit Partition mit der Maus innerhalb des Partitions-Rechtecks anfassen und ganz nach rechts schieben, wodurch nun Freiraum vor der swap-Partition entsteht.
• Wie oben beschrieben nun die boot-Partition (/dev/sdX1) vergrößern

Empfehlenswert ist es, mit dem gparted-Programm vorher mal an einem in Partitionen unterteilten Stick zu üben.

Die auf 4.9.x basierenden eisfair-Kernel erfordern es, dass Platten und Partitionen eine eindeutige UUID erhalten. Das ist bei Virtualisierern von VMWare nicht immer gegeben. Bei einem Updates eines 3.x basierenden eisfair-Kernels auf einen 4.x basierenden eisfair-Kernel könnte deshalb folgende Fehlermeldung beim Update erscheinen:

Cannot convert boot device /dev/sda to /dev/disk/by-id/!

Um das Problem zu lösen, muss der .vmx-Datei des eisfair-Gastes folgende Option hinzugefügt bzw. diese auf „TRUE“ gesetzt werden: disk.EnableUUID = „TRUE“.

Hierzu sind für VMWare ESXi folgende Schritte zu unternehmen (Quelle: https://sort.veritas.com/public/documents/sfha/6.2/vmwareesx/productguides/html/sfhas_virtualization/ch10s05s01.htm):

1. Gast herunterfahren.
2. Gast auswählen und „Edit Settings“ wählen.
3. „Options“ Tab selektieren.
4. Wähle „General“ unter „Advanced section“.
5. „Configuration Parameters“ auf rechter Seite auswählen.
6. Prüfe, ob der Parameter „disk.EnableUUID“ vorhanden und auf „TRUE“ gesetzt ist. Ist der Parameter nicht sichtbar, wähle „Add Row“, füge ihn hinzu und setze in auf „TRUE“.

Bei VMWare Workstation und sicherlich auch bei VMWare Player ist die .vmx-Datei nach Herunterfahren des Gastes und Erzeugen eines Schnappschusses von Hand zu editieren. Wenn die virtuelle Maschine eisfair heisst, existiert im Home-Verzeichnis des Users oder unter %userprofile%\documents\My Virtual Machines ein Verzeichnis eisfair und darin eine Datei eisfair.vmx, die zu editieren ist (Quelle: https://kb.vmware.com/s/article/2057902):

1. Gast herunterfahren.
2. In der Verzeichnis mit den Dateien der virtuellen Maschine wechseln.
3. Öffnen der Konfigurationsdatei (.vmx) in einem Texteditor.
4. Hinzufügen oder editieren der Zeile disk.EnableUUID = „TRUE“.
5. Abspeichern der Konfiguration und Texteditor beenden.

Jedem Platten- oder Partitions-Device werden durch udev in /dev/disk/by-id und /dev/disk/by-uuid eindeutige Devicenamen zugeordnet:

# ls -l /dev/disk/by-id 
total 0
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ata-ATAPI_DVD-ROM_16XMax -> ../../sr0
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456 -> ../../sdb
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part3 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part4 -> ../../sdb4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part4 -> ../../sda4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ata-WDC_WD5002AALX-00J37A0_WD-WCAYUX987654 -> ../../sdc
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD5002AALX-00J37A0_WD-WCAYUX987654-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 md-uuid-135afd76:948553dc:948eeef1:172592f9 -> ../../md2
lrwxrwxrwx 1 root root  9 Oct 15 18:38 md-uuid-203badca:8a80e9c7:8dc76d1d:46951125 -> ../../md1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 md-uuid-36bc0c98:73b1d447:1ed7b829:58d71fd0 -> ../../md4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 md-uuid-40fd76c9:661c73fe:a10f393a:eaf0a8dd -> ../../md3
lrwxrwxrwx 1 root root  9 Oct 15 18:38 wwn-0x50014ee1da2a4aa0 -> ../../sdc
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee1da2a4aa0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 wwn-0x50014ee2093d24c2 -> ../../sdb
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part3 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part4 -> ../../sdb4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 wwn-0x50014ee2095c32c1 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part4 -> ../../sda4

# ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Oct 15 18:38 12834961-5ffc-4893-b0d6-06290813633d -> ../../sdc1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 d1e22432-f054-4de6-b96b-a6fc4a48ff1d -> ../../md4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ae8c6c23-60b2-4db6-9b8f-34558604c9d4 -> ../../md3
lrwxrwxrwx 1 root root  9 Oct 15 18:38 bfb57216-0e4f-4ba8-b2da-d4c34530cb27 -> ../../md1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 f11c5f08-8f4d-49bb-aa19-f90918329887 -> ../../md2

Wie zu erkennen ist, handelt es sich bei diesen eindeutigen Devicenamen in /dev/disk/by-id und /dev/disk/by-uuid um Links auf die aktuell den Platten und Partitionen zugeordneten /dev/sdXn-Devices, wobei /dev/sdX-Namen die Platte und /dev/sdXn-Namen Partitionen bezeichnen. Für physikalische Platten und Partitionen werden in /dev/disk/by-id sogar deren zwei angelegt, nämlich einmal von Plattenname und Seriennummer abgeleitet und einmal mit dem Prefix wwn (World Wide Number). Die Partitionslinks in /dev/disk/by-id leiten sich von den Links für die ganze Platte und einem angehängten Suffix „-partN“ für die jeweilige Partition ab, die Links in /dev/disk/by-uuid werden aus der UUID des Dateisystems gebildet.

Durch die Verwendung von udev im Bootprozess und/oder das Entfallen des alten kernelintegrierten IDE-Moduls kann es zu Umbennung der Platten- und Partitions-Devices kommen. Deshalb wird zukünftig in der /etc/lilo.conf und auch in der fstab für die Systemplatte mit von by-id und by-uuid abgeleiteten Devicenamen gearbeitet, die eindeutig und fix sind. Jedoch können an anderer Stelle in der Konfiguration diverser Pakete oder eigener Skripte noch hdX- oder sdX-Devices genutzt worden sein, die gegebenenfalls angepasst werden müssen.

Soweit möglich, ist die Verwendung eindeutiger Devicenamen vorzuziehen, für Partitionen vorzugsweise aus /dev/disk/by-uuid, da diese z. B. beim Klonen auf eine neue Platte erhalten bleiben.

Besitzt ein Rechner mehrere verschiedene Festplatten-Controller mit jeweils einer oder mehreren angeschlossenen Festplatten, können die Devicenamen sogar ineinander verwoben sein, z. B.: Controller 1 Platte 1 → /dev/sda, Controller 2 Platte 1 → /dev/sdb, Controller 1 Platte 2 → /dev/sdc, …

Achtung: Skripte und Programme, die zukünftig weiterhin auf die Nutzung von sdX/sdXn-Devices konfiguriert sind, können hierdurch plötzlich auf eine ganz andere Platte schreiben, als dies beabsichtigt ist. Da sich die Device-Zuordnungen sogar zwischen Boots verändern können (Race Conditions bei der Device-Zuordnung durch udev) ist nicht kontrollierbar, welche Platte/Partition durch ein sdX/sdXn-Device angesprochen wird. Dis kann zum Totalverlust der Daten führen.

Im Folgenden sollen verschieden Fälle behandelt werden:

Bisher eine SATA- oder SCSI-Platte als sda-Device

Es sind keine Korrekturen erforderlich.

Bisher eine IDE-Platte als hda-Device

Diese wird nun zu sda; in allen Paketen oder eigenen Skripte ist also eine Referenz von /dev/hda auf /dev/sda bzw. bei Partitionsverweisen von /dev/hdaX auf /dev/sdaX zu ändern oder man benutzt die eindeutigen Devicenamen.

Bisher eine IDE-Platte als hda-Device und eine oder mehrere interne SATA- und/oder SCSI-Platten (sdX-Devices)

Die IDE-Platte wird nun zu einem sdX-Device, wobei vorab nicht vorhersehbar ist, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, … zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden.

Bisher eine IDE-Platte als hda-Device und eine oder mehrere externe USB-Platten (sdX-Devices)

Die IDE-Platte wird nun zu einem sdX-Device. Die Devicenamen der USB-Platten verschieben sich dadurch um eine Position (sda→sdb; sdb→sdc, …). Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden.

Bisher eine IDE-Platte als hda-Device, eine oder mehrere interne SATA- und/oder SCSI-Platten (sdX-Devices) und eine oder mehrere externe USB-Platten (sdX-Devices)

Die IDE-Platte wird nun zu einem sdX-Device, wobei vorab nicht vorhersehbar ist, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, … zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die UUID basierten Devicenamen in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab nutzen kann.

Bisher zwei oder mehr interne SATA- und/oder SCSI-Platten (sdX-Devices)

Es ist vorab nicht vorhersehbar, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, … zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden.

Bisher zwei oder mehr interne SATA- und/oder SCSI-Platten (sdX-Devices) und eine oder mehrere externe USB-Platten (sdX-Devices)

Es ist vorab nicht vorhersehbar, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, … zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die UUID basierten Devicenamen in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab nutzen kann.

Bisher RAID mit 2 oder 3 Platten

RAIDs werden schon bislang über die UUIDs assembliert. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen für die einzelnen Member des RAIDs.

Bisher RAID mit 2 oder 3 Platten und eine oder mehrere weitere SATA- oder SCSI-Platten

RAIDs werden schon bislang über die UUIDs assembliert, die sdX-Devices können sich aber zwischen/vor die Devices des RAIDs schieben. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen bzw. auf die weiteren Platten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen.

Bisher RAID mit 2 oder 3 Platten und eine oder mehrere externe USB-Platten

RAIDs werden schon bislang über die UUIDs assembliert. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die eindeutigen Devicenamen in Paketkonfiguration, eigenen Skripten oder der /etc/fstab nutzen kann.

Bisher RAID mit 2 oder 3 Platten, eine oder mehrere weitere SATA- oder SCSI-Platten und eine oder mehrere externe USB-Platten

RAIDs werden schon bislang über die UUIDs assembliert, die sdX-Devices können sich aber zwischen/vor die Devices des RAIDs schieben. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen bzw. auf die weiteren Platten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die eindeutigen Devicenamen in Paketkonfiguration, eigenen Skripten oder der /etc/fstab nutzen kann.

In einem Fall ist bislang das Problem aufgetreten, dass sich die Links in /dev/disk/by-id zwischen dem 3.16er und dem 4.9er-Kernel unterschieden haben. Die Links enthielten unter dem 3-16er-Kernel ein abschließendes „_“, welcher unter dem Kernel 4.9 fehlt.

Wird ein solches System auf einen 4.9er-Kernel upgedatet, läuft der Kernelupdateprozess durch und das System ist auch problemlos mit dem 4.9er-Kernel bootbar. Ein nächstes Kernelupdate wird aber wegen fehlerhafter /etc/lilo.conf abgebrochen:

Installation of: eiskernel-smp (4.3.0) ...


Your lilo configuration is broken!
This is the output from the test with 'lilo -t':

Fatal: raid_setup: stat("/dev/disk/by-id/ata-AB12CDEF34-G_1234567890_")

Repair your lilo configuration, cancelling installation.


Press ENTER to continue
error: installation of "eiskernel-smp" aborted by /tmp/preinstall.sh!
Failed to install: eiskernel-smp (4.3.0)!
error: installation aborted!

Da das erstmalige Update auf den 4.9er-Kernel bei laufendem 3.16er-Kernel durchgeführt wurde, enthält die /etc/lilo.conf korrekterweise den Eintrag „boot = /dev/disk/by-id/ata-AB12CDEF34-G_1234567890_“, da diese Zeile immer den Zustand zum Zeitpunkt der Durchführung des Updates und nicht den Zustand nach einem Reboot widerspiegeln muss, um während des Kernelupdates die Bootdateien an den richtigen Ort zu schreiben. Für den Bootvorgang hat diese Zeile keinerlei Bedeutung. Wird aber nun unter einem laufenden Kernel 4.9 erneut ein Kernelupdate durchgeführt, wird das Kernelupdate abgebrochen.

Das Problem läßt sich dadurch lösen, dass in der /etc/lilo.conf der abschließende „_“ in der boot-Zeile entfernt wird.

Eine eindeutige fixe Zuordnung erhält man durch Verwendung von eindeutigen Devicenamen. Im Falle von wechselnden externen USB-Platten z. B. für Backupzwecke kann es jedoch sinnvoll sein, wie bisher mit einem sdX-Device bzw. sdXn-Device zu arbeiten. Aufgrund des Wegfalls der hdX-Devices werden hdX-Devices zu sdX-Devices und es kommt zu Verschiebungen, die in eigenen Skripten zu berücksichtigen sind.

Eine eindeutige fixe Zuordnung erhält man durch Verwendung von eindeutigen Devicenamen, sofern der Konfigurationscheck eines Paketes dies zuläßt . Aufgrund des Wegfalls der hdX-Devices werden hdX-Devices zu sdX-Devices und es kommt zu Verschiebungen, die in den Paketkonfigurationen zu berücksichtigen sind.

hddtemp: Änderung von hdX-Devices in sdX-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-id. Es ist zu beachten, dass andere Pakete neu zu konfigurieren sind, wenn sie Werte des hddtemp-Daemons auslesen.

monitoring: Änderung von hdX-Devices in sdX-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-id (Platten) und /dev/disk/by-uuid (Partitionen).

smartmon: Änderung von hdX-Devices in sdX-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-id.

backup-zip, rsnapshot: Änderung von hdXn-Devices in sdXn-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-uuid.

Der Kernel 4.9 erfordert einen größeren Entropiepool (Pool für Zufallszahlen) als unsere bisherigen Kernelserien. Auf einem System ohne Benutzerinteraktion stehen nicht genügend Quellen für zufällige Ereignisse zur Verfügung, so dass dieser Entropiepool oftmals nicht genügend Daten enthält und dieses dann zu stark verzögerter Ausführung bestimmter Vorgänge wie z. B. dem Aufbau von ssh-Verbindungen führt. Daher wird das haveged-Paket zwangsweise installiert und aktiviert, welches dem Entropiepool ausreichend zufällige Daten zuführt. Das haveged-Paket sollte daher weder deaktiviert noch deinstalliert werden.

Startet eine Anwendung unter dem neuen Kernel mit Verweis auf Speichermangel nicht mehr, sollte überprüft werden, ob für diese Anwendung eine Speicherlimit z. B. mittel „ulimit -u 100000 (entspricht 100000 KB) in der Startdatei dieser Anwendung in /etc/init.d festgelegt wurde. Setzt man dieses höher, sollte auch diese Anwendung wieder starten. So startet der Datenbankserver firebird mit vorgenannten ulimit von 100000 unter dem Kernel 3.16 neue Threads auf eine Connectanfrage, mit dem Kernel 4.9 ist das Limit jedoch auf mindestens 130000 zu setzen.