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

[Thomas Bork]

Am 10.01.2020 um 13:48 schrieb Hilmar Böhm:

> Installiert habe ich eine CD-ROM mit
> "eisfair-2.8.23-3.48.0-SMP-cd-image" (19.12.2019), Linux kernel 3.16.74.
> Habe das Netzwerk aufgesetzt, so dass ich an die Eisfair-Repos komme.
> Das erste eisman update/upgrade läuft problemlos durch inkl. einem
> anschliedenden Reboot. Nach dem reboot meldet sich Kernel 4.2.0, Base
> 2.8.23.

Ok.

> Das lilo.conf sieht dann so aus:
> ---------------------
> lba32
> #boot = /dev/hda
> boot = /dev/disk/by-id/ata-TS64GSSD25-M_20110607433335055105_
> read-only
> prompt
> timeout = 50
> vga = normal
> menu-scheme = wr:bw:wr:Yr
> image = /boot/kernel
> #root = /dev/hda3
> root = "UUID=97432f82-f216-4033-9ba5-dd3d05aaa17b"
> label = eis
> initrd = /boot/initrd.gz
> append = "raid=noautodetect"
> image = /boot/old-kernel
> #root = /dev/hda3
> root = "UUID=97432f82-f216-4033-9ba5-dd3d05aaa17b"
> label = oldeis
> initrd = /boot/old-initrd.gz
> append = "raid=noautodetect"
> image = /boot/kernel-3.16.74-SMP
> #root = /dev/hda3
> root = "UUID=97432f82-f216-4033-9ba5-dd3d05aaa17b"
> label = 3.16.74-SMP
> initrd = /boot/initrd-3.16.74-SMP.gz
> append = "raid=noautodetect"
> ----------------------
> 
> Beachte die "boot = " - Zeile.
> "by-id" zeigt folgendes:
> ----------
> lrwxrwxrwx 1 root root  9 Jan  9 22:44
> ata-TS64GSSD25-M_20110607433335055105_ -> ../../sda
> lrwxrwxrwx 1 root root 10 Jan  9 22:44
> ata-TS64GSSD25-M_20110607433335055105_-part1 -> ../../sda1
> lrwxrwxrwx 1 root root 10 Jan  9 22:44
> ata-TS64GSSD25-M_20110607433335055105_-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 Jan  9 22:44
> ata-TS64GSSD25-M_20110607433335055105_-part3 -> ../../sda3
> ---------------

Die Regeln zur Erzeugung der Namen der Links auf die Devices stecken in

/lib/udev/rules.d/60-persistent-storage.rules

Da zu dem Zeitpunkt schon der Kernel 4.9.x läuft, zeigen die Links auf 
sdaX. Es gibt keinen Treiber mehr für hdaX. Die verwendete Regel ist:

# ATA
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi", 
ATTRS{vendor}=="ATA", IMPORT{program}="ata_id --export $devnode"

Diese Regel wird bei Installation eines Kernels nicht verändert, sie 
sollte also immer identische Device-Links erzeugen, gerade bei Kernel 
4.9.x mit identischem Treiber. Es ist deswegen nicht so recht 
einzusehen, warum /dev/disk/by-id einmal so und einmal so aussehen soll.

> "lsblk" Zeigt die IDE-Disk so an:
> -------------------------
> eis 2.8.23 # lsblk --output MODEL,SERIAL /dev/sda
> MODEL        SERIAL
> TS64GSSD25-M 20110607433335055105
> ----------------------------------
> 
> Die "by-id"-Kennzeichnung der IDE-Disk besteht also u.a. aus
> <ata-MODEL_SERIAL_>

Bei laufendem Kernel 4.9.x, also mit dem libata-Treiber und obiger Regel.

> Wie man sieht, wurde beim Kernel 4.2.0 Upgrade die "by-id"Kennzeichnung
> der Disk korrekt in die lilo.conf übernommen

Bevor der Kernel 4.9.x installiert wurde, lief der Kernel 3.16.x mit 
fest eingebautem IDE-Treiber. Der benutzt eine andere Regel:

# syntax for IDE devices, eisfair special for old kernels
# ATA devices with their own "ata" kernel subsystem
KERNEL=="hd*[!0-9]", ATTRS{serial}=="?*", 
ENV{ID_SERIAL}="$attr{serial}", 
SYMLINK+="disk/by-id/ata-$env{ID_MODEL}_$env{ID_SERIAL}", 
IMPORT{program}="ata_id --export $devnode"
KERNEL=="hd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", 
SYMLINK+="disk/by-id/ata-$env{ID_MODEL}_$env{ID_SERIAL}-part%n"

Wenn diese Regeln für den alten IDE-Treiber im 3.16er Kernel andere 
Device-Links erzeugen würden, als die obige Regel für die 
libata-basierenden Treiber, dann hätte schon das Update auf den Kernel 
4.2.0 nicht mehr geklappt.

Und dort sehe ich auch keinen Unterstrich.

> Jetzt kommt der kernel-Upgrade auf 4.3.0 unstable mit dem Abbruch:
> ------------------------------------------
> eis 2.8.23 # eisman upgrade --unstable
> searching...
> 
> The following packages will be installed:
>   
> version  status   name                   source
> ---------------------------------------------------------------------
> 4.3.0    testing  eiskernel-smp          https://www.pack-eis.de
>   
>   package(s) using approx. 10 MB of disk space.
>   
> Continue (y/n) [yes]?
> Downloading required packages ...
> Done!
> Installation of: eiskernel-smp (4.3.0) ...
> 
> 
> Your lilo configuration is broken!
> This is the output from the test with 'lilo -t':
> 
> Fatal: raid_setup:
> stat("/dev/disk/by-id/ata-TS64GSSD25-M_20110607433335055105_")

Zu diesem Zeitpunkt kann in /dev/disk/by-id der Unterstrich am Ende 
schon nicht mehr existiert haben, denn lilo versucht das Device genau 
dort aufzulösen.

> Repair your lilo configuration, cancelling installation.
> 
> 
> Press ENTER to continue
> error: installation of "eiskernel-smp" aborted by /tmp/preinstall.sh!
> Failed to install: eiskernel-smp (4.3.0)!
> error: installation aborted!
> eis 2.8.23 # exit
> -----------------------------------------------
> 
> ==> Lösung: Wenn ich in lilo.conf in der "boot =" Zeile von der
> by-id-Bezeichnung das hintere "_" wegnehme (also ...55105"), läuft ein
> "lilo -t" und das Kernel-Upgrade durch.

Genau.

> Erstaunlich ist auch, das nach dem 430er-Upgrade-Abbruch die wohl
> lilo.conf identisch zur vorherigen ist (also mit dem bewussten "_"),
> aber ein "ls -l /dev/disk/by-id" foldenges zeigt:
> -----------------------------------------
> lrwxrwxrwx 1 root root  9 Jan  9 23:18
> ata-TS64GSSD25-M_20110607433335055105 -> ../../sda
> lrwxrwxrwx 1 root root 10 Jan  9 23:18
> ata-TS64GSSD25-M_20110607433335055105-part1 -> ../../sda1
> lrwxrwxrwx 1 root root 10 Jan  9 23:18
> ata-TS64GSSD25-M_20110607433335055105-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 Jan  9 23:18
> ata-TS64GSSD25-M_20110607433335055105-part3 -> ../../sda3
> lrwxrwxrwx 1 root root  9 Jan  9 23:18 ata-_NEC_DVD_RW_ND-7550A ->
> ./../sr0
> -----------------------------------------
> 
> Was auffällt ist, dass jetzt das bewusste "_" fehlt.

Die Frage ist, wo der Unterstrich herkommt und warum er einmal bei 
laufendem Kernel 4.9.x zu sehen ist und dann wieder nicht mehr. Wurde 
udev zwischenzeitlich aktualisiert?

-- 
der tom
[eisfair-team]