[Eisfair] [e1] Fehle?==?utf-8?Q?r beim update auf eiskernel?==?utf-8?Q?-smp (4.4.1): Your lilo confi?==?utf-8?Q?guration is broken!

[Marcus Roeckrath]

Hallo Hilmar,

Hilix schrieb am Thu, 23 January 2020 15:01
> === START OF INFORMATION SECTION ===
> Model Family:     JMicron based SSDs
> Device Model:     TS64GSSD25-M
> Serial Number:    20110607433335055105
> Firmware Version: 20100603
> User Capacity:    64,105,742,336 bytes [64.1 GB]
> Sector Size:      512 bytes logical/physical
> Rotation Rate:    Solid State Device
> Device is:        In smartctl database [for details use: -P show]
> ATA Version is:   ATA/ATAPI-7 (minor revision not indicated)
> Local Time is:    Thu Jan 23 12:35:48 2020 CET
> SMART support is: Available - device has SMART capability.
> 
> Es handelt sich um eine IDE-SSD von Transcend. Das ist eine SSD mit
> einem IDE/ATA-Interface. Selten, aber absolut zuverlässig, 
> läuft seit Jahren in meinem "bare metal" Eisfair-Server. Diese SSD
> wird folgerichtig als hda-Device erkannt (und nicht als sda 
> SATA-Device)

Ob sie als sd- oder hd-Device erkannt wird, liegt nicht an der Hardware
sondern daran, mit welchem Treiber sie eingebunden wird. Der hd-Devices
erzeugende Treiber ist aber nun verschwunden.

Zitat:
> Wenn man sich die korrekte by-id Bezeichnung einer solchen
> Boot-Platte anschaut, dann ist auch klar, woher dieses "_"-Problem 
> kommt. z.B.:
> ----
> lrwxrwxrwx 1 root root  9 Jan 23 12:43 ata-TS32GSSD25-M_0032261913DB
> -> ../../sda
> ----
> (Zwischenzeitlich wurde offensichtlich die entsprechende udev-Regel
> korrigiert)

Das greift IMHO zu kurz. Im 3er-Installer ist die gleiche Version samt
Regeln aktiv; ein Kernelupdate tauscht hier nichts aus.

udev bekommt Daten zur Hardware vom Kernel übermittelt, aus denen dann
der udev "etwas" macht.

Zitat:
> Ich bin der Meinung, dass man keine Zeit mehr auf die Suche nach dem
> Fehler in der 3er-Umgebung verschwenden sollte.
> 
> Vielmehr sollte man bedenken, dass der Fehler beim Folge-Upgrade des
> (ersten) 4er-Kernels auftritt!

Und deshalb steht das ja auch im Wikiartikel drin bzw. hat es im Kopf,
wenn jemand hier ohne Lektüre des Wiki-Artikels hier nachfragt.

Zitat:
> Denn beim _erstmaligen_ Upgrade auf den 4er-Kernel und der dabei
> erfolgten Ersetzung (in lilo.conf) von "boot = /dev/hda" durch 
> "boot = /dev/disk/by-id/<ata..._>" wird die by-id Bezeichnung der
> Boot-Platte aus der *alten* _3er_ Umgebung mit zu dem 
> Zeitpunkt laufenden 3er-Kernel ermittelt. Das ist der falsche
> Zeitpunkt, wie ich schon mal schrieb! Die Ersetzung muß *nach* den 
> ersten Reboot des neuen 4er-Kernels erfolgen!

Nein das ist falsch; Ein Update vom 3er- auf den 4er-Kernel muss genau
diesen "falschen", weil für den laufenden 3er-Kernel richtigen, Namen
ermitteln, weil die Bootdateien genau in diesem Moment geschrieben
werden. Nur für das Schreiben der Bootdateien ist diese Information
notwendig und die geschieht nunmal unter einem laufenden 3er-Kernel.

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.

-- 
Gruß Marcus