Page Comparison

...

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 derzeit größer als zwischen etwa 43 MB und 50 MB groß, wäre ist bei Nutzung auch 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 wäre ist auch für die Fallback-Bootoption vorläufig genügend Platz vorhanden. Es bestände also , 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:

...

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

Benennung von Platten- und Partitions-Devices durch udev und daraus folgende Konsequenzen

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

...

Aktivierung der Festplatten-UUID unter VMWare

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.

Benennung von Platten- und Partitions-Devices durch udev und daraus folgende Konsequenzen

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-WDCATAPI_WD10EFRXDVD-68PJCN0_WD-WCC4J6543210-part1ROM_16XMax -> ../../sda1sr0
lrwxrwxrwx 1 root root 10 9 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part2WCC4J0123456 -> ../../sda2sdb
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210WCC4J0123456-part3part1 -> ../../sda3sdb1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210WCC4J0123456-part4part2 -> ../../sda4sdb2
lrwxrwxrwx 1 root root  910 Oct 15 18:38 ata-WDC_WD5002AALXWD10EFRX-00J37A068PJCN0_WD-WCC4J0123456-WCAYUX987654part3 -> ../../sdcsdb3
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD5002AALXWD10EFRX-00J37A068PJCN0_WD-WCAYUX987654WCC4J0123456-part1part4 -> ../../sdc1sdb4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 md-uuid-135afd76:948553dc:948eeef1:172592f9ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210 -> ../../md2sda
lrwxrwxrwx 1 root root 10 9 Oct 15 18:38 mdata-uuid-203badca:8a80e9c7:8dc76d1d:46951125WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part1 -> ../../md1sda1
lrwxrwxrwx 1 root root  910 Oct 15 18:38 md-uuid-36bc0c98:73b1d447:1ed7b829:58d71fd0ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part2 -> ../../md4sda2
lrwxrwxrwx 1 root root 10 9 Oct 15 18:38 md-uuid-40fd76c9:661c73fe:a10f393a:eaf0a8ddata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part3 -> ../../md3sda3
lrwxrwxrwx 1 root root  910 Oct 15 18:38 wwn-0x50014ee1da2a4aa0ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part4 -> ../../sdcsda4
lrwxrwxrwx 1 root root 10 9 Oct 15 18:38 wwn-0x50014ee1da2a4aa0-part1ata-WDC_WD5002AALX-00J37A0_WD-WCAYUX987654 -> ../../sdc1sdc
lrwxrwxrwx 1 root root  910 Oct 15 18:38 wwn-0x50014ee2093d24c2ata-WDC_WD5002AALX-00J37A0_WD-WCAYUX987654-part1 -> ../../sdbsdc1
lrwxrwxrwx 1 root root 10 9 Oct 15 18:38 wwnmd-0x50014ee2093d24c2-part1uuid-135afd76:948553dc:948eeef1:172592f9 -> ../../sdb1md2
lrwxrwxrwx 1 root root  109 Oct 15 18:38 wwnmd-0x50014ee2093d24c2-part2uuid-203badca:8a80e9c7:8dc76d1d:46951125 -> ../../sdb2md1
lrwxrwxrwx 1 root root 10 9 Oct 15 18:38 wwnmd-0x50014ee2093d24c2-part3uuid-36bc0c98:73b1d447:1ed7b829:58d71fd0 -> ../../sdb3md4
lrwxrwxrwx 1 root root  109 Oct 15 18:38 wwnmd-0x50014ee2093d24c2-part4uuid-40fd76c9:661c73fe:a10f393a:eaf0a8dd -> ../../sdb4md3
lrwxrwxrwx 1 root root  9 Oct 15 18:38 wwn-0x50014ee2095c32c10x50014ee1da2a4aa0 -> ../../sdasdc
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c10x50014ee1da2a4aa0-part1 -> ../../sda1sdc1
lrwxrwxrwx 1 root root  109 Oct 15 18:38 wwn-0x50014ee2095c32c1-part20x50014ee2093d24c2 -> ../../sda2sdb
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c10x50014ee2093d24c2-part3part1 -> ../../sda3sdb1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c10x50014ee2093d24c2-part4part2 -> ../../sda4

# ls -l /dev/disk/by-uuid
total 0
sdb2
lrwxrwxrwx 1 root root 10 Oct 15 18:38 12834961wwn-5ffc-4893-b0d6-06290813633d0x50014ee2093d24c2-part3 -> ../../sdc1sdb3
lrwxrwxrwx 1 root root 10 9 Oct 15 18:38 d1e22432wwn-f054-4de6-b96b-a6fc4a48ff1d0x50014ee2093d24c2-part4 -> ../../md4sdb4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ae8c6c23-60b2-4db6-9b8f-34558604c9d4wwn-0x50014ee2095c32c1 -> ../../md3sda
lrwxrwxrwx 1 root root 10 9 Oct 15 18:38 bfb57216wwn-0e4f-4ba8-b2da-d4c34530cb270x50014ee2095c32c1-part1 -> ../../md1sda1
lrwxrwxrwx 1 root root  910 Oct 15 18:38 f11c5f08wwn-8f4d-49bb-aa19-f909183298870x50014ee2095c32c1-part2 -> ../../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, ...

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 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

...

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.

Mögliche Unterschiede in der Benennung von Plattendevices durch den 3.16er und 4.9er Kernel und deren Konsequenzen

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.

Angabe von Devicenamen in eigenen Skripten

...