Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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. 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 anbschließ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:

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

...