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

[Hilix]

Am 23.01.20 um 11:59 schrieb W. Loefstedt:
> === START OF INFORMATION SECTION ===
> Model Family:     Transcend CompactFlash Cards
> Device Model:     TS4GCF133
> Serial Number:    B27850A50663030002D0
> Firmware Version: 20110407
> User Capacity:    4,009,549,824 bytes [4.00 GB]
> Sector Size:      512 bytes logical/physical
> 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 11:58:21 2020 CET
> SMART support is: Available - device has SMART capability.
> SMART support is: Disabled

=== 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)
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)

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!

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! Denn dann ist offensichtlich auch ein aktuelles udev aktiv, das den by-id Namen 
der Boot-Disk korrekt ermittelt.
So wäre es erst gar nicht zu diesem Problem gekommen.

Zur Vermeidung des Problems könnte man z.B eine korrekte Substitution der "boot=" Zeile in einem geeigneten Init-Script einbauen.


Ich hoffe, dass ich mich jetzt verständlicher ausgedrückt habe? =:-|

Grüße. / Hilmar.