[Eisfair] [e1] Fehler beim update auf eiskernel-smp (4.4.1): Your lilo configuration is broken!

Marcus Röckrath marcus.roeckrath at gmx.de
Do Jan 23 16:53:23 CET 2020


Hallo Hilmar,

Hilix wrote:

>  > Nach dem Boot des 4er-Kernels ändert sich dieser Link, aber es wäre
>  > "Raterei" aus den in by-id vorhandenen Links nun einen anderen zu
>  > nehmen.
> 
> Das ist keine Raterei, denn in dem lilo.conf nach der 1.
> 4er-Kernel-Upgrade steht eindeutig: ---------
> ...
> #boot = /dev/hda
> boot = /dev/disk/by-id/ata-TS64GSSD25-M_20110607433335055105_

Doch ist es.

In der lilo.conf steht /dev/hda bei noch laufendem Kernel 3.16. Es ist
simpel in /dev/disk/by-id den Link herauszusuchen, der auf /dev/sda zeigt.

Dieser wird nun in die lilo.conf unter dem laufenden Kernel eingetragen,
damit die Bootdateien nun in das richtige Device geschrieben werden.

Nun wird der 4er-Kernel gebootet und das nun in der lilo.conf
stehende /dev/disk/by-id-Device

/dev/disk/by-id/ata-TS64GSSD25-M_20110607433335055105_

ist nun schlicht nicht mehr existent.

Was soll nun aus den exitierenden Links nachträglich in die lilo.conf
eingetragen werden? Jnes, welches dem vorhandenen namen am Ähnlichsten ist?

> Es ist eindeutig zu erkennen: /dev/hda --> wird zu /dev/sda.

Nein, denn beim Boot kann die Bootplatte auch sdb werden!

Das sind die Folgen von udev; das ist ähnlich zu den wechselnden
Netzwerkkartendevices!

Auf einer maschine wurden bei mir - wenn zufällig eine USB-Device
angeschlossen war -  aus dem sda/sdb-RAID ein sda/sdc-RAID.

Zum weiteren wäre es nicht ausgeschlossen, dass jemand bewußt irgendetwas
spezielles als boot in die lilo.conf eingetragen hat, was auch nicht
geändert werden dürfte.

Thomas testet, ob ein lilo-Aufruf fehlerfrei laufen würde und bricht ab.
wenn der einen Error liefert.

> Und aus 
> "blkid /dev/sda" oder aus lsblk ... /dev/sda" kann die richtige
> By-id-Bezeichnung ermittel werden. Wo ist also das Problem.

Das es für das nun fehlende Device kein Ersatz mit absoluter Sicherheit
ermittelt werden kann.

> Ich bleibe dabei: Die boot= Substitution in lilo.conf findet zum falschen
> Zeitpunkt statt und das Problem könnte leicht vermieden werden.

Bitte verstehe, dass der boot-Eintrag nur zum Zeitpunkt des Kernelupdates
überhaupt eine Bewandnis hat.

> So wie es jetzt gehandhabt wird, ist es ein Eifsfair-Problem!

Unser Problem ist, dass wir noch auf lilo statt grub setzen. Aber wir können
nicht alle Baustellen gleichzeitig angehen.

-- 
Gruß Marcus
[eisfair-Team]


Mehr Informationen über die Mailingliste Eisfair