[Eisfair] E1 - Kernel 4.3.0 Upgr / Lilo - Problem?

[Marcus Röckrath]

Hallo Hilmar,

Hilmar wrote:

> Meine Findings bzgl. des Lilo-Fehlers beim 1. Folge-4er-Kernelupgrade,
> sind keine Erfindung meinerseits, sondern sie sind reproduzierbar (inzw.
> 3 Installationen).

Was verstehst du unter lilo-Fehler? Ein Bug in lilo, ...

lilo sagt schlicht, die lilo.conf passt nicht zum System, mehr nicht.

> Dass das Problem von der unterschiedlichen Behandlung von Devicenamen
> (udev) zw. der 3er und 4er Kerne verursacht wird, ist inzwischen auch
> klar.

Es gibt keinen generellen Unterschied zwischen den unter dem 3er- und
4er-Kernel erstellten Devicenamen, sondt wäre das hier schon massenhaft
aufgeschlagen.

> Ich finde, dass, wenn die Entwickler - sicherlich berechtigt - die
> lilo.conf meines Systems bzgl der "boot"-Option verändern, dann müssen
> Sie auch dafür sorgen, dass dort die richtigen Einträge erscheinen,
> die für einen weiteren Betrieb mit dem 4er-Kernel erforderlich sind!

Zum Zeitpunkt, bei dem der boot-Eintrag von hd/sd auf by-id umgestellt wird,
existiert im laufenden System eine eindeutige Zuordnung!

Nach dem Boot des 4er-Kernels existiert keine Zuordnung zwischen dem vom
3er-Kernel gewählten Namen zu dem nun gültigen Namen unter dem 4er-Kernel.

Ich glaube nicht, aber dafür wäre Thomas der Ansprechpartner und nicht ich,
dass Thomas nach Boot des 4er-Kernel heuristisch versucht, zu erraten,
welchen Namen den nun das Plattendevice bekommen hat.

Bootet man wechselseitig einen 3er- und 4er-Kernel würde das ein
Wechselspiel ergeben.

> Wenn also beim Wechsel vom 3er auf den 4er Kernel in der lilo.conf beim
> "boot =" Eintrag von /dev/sdx auf den (für dieses System)
> entsprechenden "by-id" Device-Namen geändert wird, dann muss auch der
> "by-id"-Namen des (neuen) Kernels eingetragen dort werden, der nach dem
> ersten Reboot mit dem neuen Kernel erzeugt wird.

Woher soll man das sicher entnehmen?

Die Risiken, hier gegebenenfalls falsch zu korrigieren, sind IMHO viel zu
hoch.

Durch udev muss die Bootplatte nun z. B. nicht sda sein; es kann weitere
Platten sdb, sdc, ... geben.

Da das Problem bislang exakt einmal aufgetreten ist, ist hier eine manuelle
Korrektur, nach manueller Kontrolle des by-id-Verzeichnisses die wohl
einfachste Lösung.

> Beim Wechsel vom 3er auf das 4er System ist dies die einzige
> Möglichkeit, exakt das /dev/sdx Device mit dem entsprechenden
> Gerätenamen zu ersetzen. Bei ersten Reboot kann zum Beispiel "udevadm
> info -q symlink /dev/sdx" verwendet werden, um die korrekte Bezeichnung
> zu ermitteln.

Wenn es mehrere Platten gibt, kann das so aussehen:

eis # udevadm info -q symlink /dev/sda
disk/by-id/ata-ST3160215A_9RABEDAP
eis # udevadm info -q symlink /dev/sdb
disk/by-id/scsi-SSEAGATE_ST336706LW_3FD0DDE600007227E2UN
disk/by-path/pci-0000:02:0d.0-scsi-0:0:0:0

Was soll nun eingetragen werden? Was der vorhandenen Bezeichnung am nächsten
kommt?

Für mich ist das Kaffeesatzleserei.

Was ist, wenn jemand bewußt die Bootdateien durch lilo über einen
manipulierten boot-Eintrag auf etwas anderes hat schreiben lassen?

Soll nun hier dann auch schlicht nach Ermittlung der Systemplatte eine
Zwangsänderung stattfinden?

Thomas schrieb schon, dass die lilo.conf exakt einmal von hd/sd auf by-id
umgeschrieben wird, nämlich dann, wenn es eine eindeutige im System
ablesbare Verknüpfung zwischen diesen beiden Objekten gibt.

Danach rührt Thomas das in den Kernelupdates nicht mehr an.

Mehr kann ich dazu nicht sagen, denn Thomas kennt sich mit der Logik des
Kernelupdates viel besser aus, weil er das schon seit Urzeiten betreut.

@Thomas:
Sehe ich in meinen Ausführungen zu "schwarz", was die Risiken solcher
Korrekturen der lilo.conf nach dem Boot angeht?

-- 
Gruß Marcus
[eisfair-Team]