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

[Marcus Röckrath]

Hallo Hilmar,

Hilmar wrote:

> Ich habe noch mal von vorne begonnen mit einer Installation des
> Eisfair-ISOs vom 19.12.19 (B2.8.23, K3.48.0)

Danke.

> 1. nach dem ersten Reboot nach der Installation: ergibt sich folgendes:
> 
> A) /dev/disk/by-id /dev/hda
>  ------------------------------------------------------------------------
> ----
> lrwxrwxrwx 1 root root  9 Jan 12 12:17
> ata-TS64GSSD25-M_20110607433335055105_ -> ../../hda
>  ------------------------------------------------------------------------
> ----
> 
> Also _mit_ Underscore.

So hatte ich es erwartet.

> B) Das ist auch ableitbar aus: "udevadm info -q all /dev/hda"
>  ------------------------------------------------------------------------
> ----
> E: ID_SERIAL=20110607433335055105_
>
> Beachte: Attribut ID_SERIAL enthält den Underscore.

Den bringt also ata_id ins Spiel, denn hier ist ja noch das hda-Device aktiv
(eingebauter IDE-Treiber).

Oder die Platte meldet in der Seriennummer noch ein komisches Zeichen,
welches durch den Underscore ersetzt wird.

> 2. Nach dem Upgrade auf Kernel 4.2.0, aber VOR dem Reboot wird die Disk
> immer noch als hda-Device angesprochen,

Klar, denn die Installation des Kernelupdates ändert noch garnichts am
System, welches weiterhin unter Kernel 3.16er läuft.

> aber im Laufe des 4.2.0-Upgrade 
> ist die lilo.conf geändert worden bzgl. des Boot-Devices ("boot =").
> Der by-id-Name der Disk enthält somit immer noch den Underscore (am
> Ende) und die Disk ist immer noch /dev/_h_da!

Klar, denn es läuft der 3.16er-Kernel und in die lilo.conf wird als boot nun
der unter Kernel 3-16 geltenden by-id-Link eingetragen, der dieses _ am
Ende enthält.

Das muss so, denn die boot-Zeile der lilo.conf muss dem aktuellen Zustand
entsprechen, um die Bootdateien ins richtige Device schreiben zu können; d.
h. der Zustand unter Kernel 3.16. und nicht dem später zu erwartenden
Zustand.

> 3. Nach den 1. Reboot nach dem erfolgten Kernel-Upgrade auf 4.2.0 ergibt
> sich folgendes Bild:
> 
> A) Die Disk ist jetzt /dev/_s_da!

Klar, denn hda-Devices gibt es mit dem Kernel 4 nicht mehr.

> B) "udevadm info -q all /dev/sda zeigt jetzt:
> E: ID_SERIAL=TS64GSSD25-M_20110607433335055105

> Beachte: kein Underscore mehr am Ende UND jetzt inkl. des
> ID_MODEL-Namens der Disk. (das ist neu!)

Und das habe ich immer gesagt: Die Änderung tritt beim Wechsel von Kernel 3
auf Kernel 4 auf und nicht zwischen den Updates des 4er-Kernels.

Da die lilo.conf aber vorher zum Schreiben der Bootdateien mit den unter
Kernel 3 geltenden Bezeichnungen arbeiten musste, die nun aber nach Boot
mit dem 4er-Kernel sich geändert haben, muss nun der Check im Kernelupdate
fehlschlagen.

Nochmal: der boot-Eintrag ist für den eigentlichen Bootvorgang nicht von
Bedeutung.

> 4. Das ist jetzt der Zustand vor dem Kernel-Upgrade zu 4.3.0. Das
> bedeutet, dass
> 
> - lilo.conf bzgl. dev Boot-Devicesnamens immer noch auf dem aktuallen
> Stand ist, also _mit_ Underscore

Weil die lilo.conf unter laufendem 3er-Kernel neu geschreiben wurde und das
völlig korrekt.

> - und dass durch die neue Erkennung der Disk als sda Device durch udev
> KEIN Underscore mehr vorhanden ist.

Wie ich immer gesagt habe: 3er- und 4er-Kernel geben im Zusammenspiel mit
udev dem Device andere Namen.

> 5. Da, wie Tom schreibt, der "lilo -t" Check VOR den eigentlichen 4.3.0
> Upgrade stattfindet und die lilo.conf da auch immer noch im alten
> Zustand ist, ergibt sich das Lilo-Problem.

Nein, wieso haben wir ein lilo-Problem!

Tom testet, ob die lilo.conf schlüssig ist, was man simpel durch ausführen
von lilo -t durchführen kann und bricht konsequenterweise ab.

Die lilo.conf passt nicht zu den aktuell vorhandenen Laufwerklinks in by-id!

Das ist kein Bug und kein fehler sondern konsequent.

Wäre zunächst die Überlegung, ob in diesem Fall das Kernelupdate vielleicht
die problematische boot-Zele und den Inhalt von by-id ausgibt, welche dann
das Problem leichter erkennen läßt.

Ich sehe nicht, dass das Kernelupdate hier eine eigene Reparatur versuchen
sollte, was ist, wenn die falsch liegt?

> Das ist meine m.E. plausible Erklärung für das 4.3.0-Upgradeproblem.
> Falls gewümscht kann ist die o.g. Outputs/Dateien als Tar-Archive zur
> Verfügung stellen.

Unnötig.

Was du machen könntest, wäre, nach der Installation sofort auf den 4.3.0
upzudaten, was IMHO völlig problemlos klappen sollte. Den Fehler bekommst
du dann mit dem nächsten 4.x-Kernelupdate.

> Was mich etwas wundert ist, dass  das bei meinen VIRT-Installation noch
> nocht aufgefallen ist. Es ist auch offensichtlich noch niemand Anderem
> hier aufgefallen...

Weil aus ominösen Gründen der udev unter Kernel 3.16 deiner Platte diesen
Underscore verpasst.

Möglicher Grund:

Die Platte hat am Ende ein nicht druckbares Zeichen, welches durch _ ersetzt
wird, während der 4er-Kernel dies ignoriert.

Man müsste unter Kernel 3.16 den Bennenungsprozess debuggen, um auf die
Schliche dieses _ zu kommen.

Das ist kein generelles Problem des Wechsel vom hda zum sda Device, denn ich
habe das in keinem Fall beobachtet, da waren die Link-Namen in beiden
Fällen gleich.

Wenn dies im allgemeinen so gewesen wäre, wäre mit hda-Devices kein
automatischer Umstieg auf den 4er-Kernel durch Umschreiben der
lilo.conf/fstab auf by-id und by-uuid Links möglich gewesen.

IMHO ist es ein Effekt, der ganz speziell mit deiner Hardware zusammenhängt
und natürlich auf anderer Hardware auch auftreten kann.

-- 
Gruß Marcus
[eisfair-Team]