Update auf eiskernel 4.1.2 - auf einem USB-Datenträger

[Stefan Puschek]

Hallo Mitlesende,

ich mache mal einen neuen Thread auf, damit es nicht zu unübersichtlich
wird - hoffentlich mache ich mich nicht unbeliebt damit...

Ausgangspunkt:
ein Minimal-e1 auf einem USB-Datenträger (egal ob Stick oder HDD - beide
getestet) mit dem letzten 3er Kernel. Die erste Partition (für /boot)
ist bereits vergrössert auf 130MB.

lilo meckert zwar über den BIOS-Bug (den ich übersehen hatte) - aber das
soll mich nicht stören.

ich mache das Update auf Kernel 4.9 und reboote.

grob die Hälfte aller Reboots lande ich in der Busybox! ich habe jetzt
die letzten 3 Stunden laut Strichliste 51 Reboots gemacht, 28 Mal nur
busybox.

ich sitze einfach nur vor dem Notebook und starte von USB; er wählt dann
automatisch 'eis', und wenn der Boot durchläuft sehe ich die Meldung vom
4er Kernel. Aus den Bootmeldungen sehe ich, dass der momentan genutzte
Datenträger /dev/sda ist. jetzt control-alt-delete - ich logge mich
nicht ein!

wenn ich aber in der busybox lande, ist der genutzte Datenträger IMMER
/dev/sdb; die letzten Meldungen sind dann, dass er MAJOR und MINOR in
/proc/diskstats nicht finden konnte - beide sind angeblich '.' . jetzt
control-alt-delete...

Wer kommt da bei mir nicht mit dem geänderten Device (sdb statt sda)
zurecht? Wir greifen doch nur noch über UUIDs auf die Partitionen zu,
also sollte dies doch nicht mehr passieren. Dass die Geräte von udev
nicht immer in der gleichen Reihenfolge erkannt werden, weiss ich -
deshalb die UUIDs.

Wer hat einen USB-Datenträger mit einem 4er Kernel stabil (!!!) am laufen?

Groetjes
Stefan

[Marcus Roeckrath]

Hallo Stefan,

Post by Stefan Puschek
ich mache mal einen neuen Thread auf, damit es nicht zu unübersichtlich
wird - hoffentlich mache ich mich nicht unbeliebt damit...
ein Minimal-e1 auf einem USB-Datenträger (egal ob Stick oder HDD - beide
getestet) mit dem letzten 3er Kernel. Die erste Partition (für /boot)
ist bereits vergrössert auf 130MB.
ich mache das Update auf Kernel 4.9 und reboote.
grob die Hälfte aller Reboots lande ich in der Busybox! ich habe jetzt
die letzten 3 Stunden laut Strichliste 51 Reboots gemacht, 28 Mal nur
busybox.

Ich kann das nicht nachvollziehen:

Der SUB-Stick aus der Testphase des neuesten 3er-Kernel basierten Installers
läuft in diesem Zustand beim Boot als sda.

Ist auch klar, da hier keine Treiber für den Sata-Controller geladen werden,
also der USB-Stick immer als erster zum Zuge kommt.

Update auf den 4er-Kernel durchgeführt, wobei auch die lilo.conf auf by-id
und by-uuid umgeschreiben wurden.

Damit nun etwa eine Handvoll Boots durchgeführt - mit Einloggen, sofortiges
Runterfahren mit Strg-Alt-Entf ...

Kam jedesmal wieder problemlos hoch - keine Busybox, Rettungskonsole, ...

Bei diesen Boots war der Stick immer sdb!

Auch das ist erklärlich, denn nun ist ja mit dem 4er-Kernel auch schon beim
Boot udev aktiv und lädt nun das Modul für die interne Platte schon beim
Boot, die nun fest zu sda wird.

Das ist ja der Vorteil des Umschreibens auf by-id und by-uuid.

Mehr kann ich jetzt auch nicht sagen.

[Stefan Puschek]

Hallo Marcus,
...

Post by Marcus Roeckrath

Post by Stefan Puschek
grob die Hälfte aller Reboots lande ich in der Busybox! ich habe jetzt
die letzten 3 Stunden laut Strichliste 51 Reboots gemacht, 28 Mal nur
busybox.

Der SUB-Stick aus der Testphase des neuesten 3er-Kernel basierten Installers
läuft in diesem Zustand beim Boot als sda.
Ist auch klar, da hier keine Treiber für den Sata-Controller geladen werden,
also der USB-Stick immer als erster zum Zuge kommt.
Update auf den 4er-Kernel durchgeführt, wobei auch die lilo.conf auf by-id
und by-uuid umgeschreiben wurden.
Damit nun etwa eine Handvoll Boots durchgeführt - mit Einloggen, sofortiges
Runterfahren mit Strg-Alt-Entf ...
Kam jedesmal wieder problemlos hoch - keine Busybox, Rettungskonsole, ...
Bei diesen Boots war der Stick immer sdb!
Auch das ist erklärlich, denn nun ist ja mit dem 4er-Kernel auch schon beim
Boot udev aktiv und lädt nun das Modul für die interne Platte schon beim
Boot, die nun fest zu sda wird.
Das ist ja der Vorteil des Umschreibens auf by-id und by-uuid.
Mehr kann ich jetzt auch nicht sagen.

Toll: mit einem frisch installierten e1 und anschliessendem Kernelupdate
klappts bei mir auch - ich habs vlt. zehnmal getestet...

Was ist der Unterschied zu meinem Rettungssystem aus 2010 ???

bei mir werden in der initrd auch libata, libahci und ahci geladen...
Also werde ich dies jetzt korrigieren und dann wieder das Update testen.

Ich melde mich mit dem Ergebnis!

Groetjes
Stefan

[Stefan Puschek]

Hallo Marcus,

Post by Stefan Puschek
...

Post by Marcus Roeckrath

Post by Stefan Puschek
grob die Hälfte aller Reboots lande ich in der Busybox! ich habe
jetzt die letzten 3 Stunden laut Strichliste 51 Reboots gemacht,
28 Mal nur busybox.

Der SUB-Stick aus der Testphase des neuesten 3er-Kernel basierten
Installers läuft in diesem Zustand beim Boot als sda.
Ist auch klar, da hier keine Treiber für den Sata-Controller
geladen werden, also der USB-Stick immer als erster zum Zuge
kommt.
Update auf den 4er-Kernel durchgeführt, wobei auch die lilo.conf
auf by-id und by-uuid umgeschreiben wurden.
Damit nun etwa eine Handvoll Boots durchgeführt - mit Einloggen,
sofortiges Runterfahren mit Strg-Alt-Entf ...
Kam jedesmal wieder problemlos hoch - keine Busybox,
Rettungskonsole, ...
Bei diesen Boots war der Stick immer sdb!
Auch das ist erklärlich, denn nun ist ja mit dem 4er-Kernel auch
schon beim Boot udev aktiv und lädt nun das Modul für die interne
Platte schon beim Boot, die nun fest zu sda wird.
Das ist ja der Vorteil des Umschreibens auf by-id und by-uuid. Mehr
kann ich jetzt auch nicht sagen.

Toll: mit einem frisch installierten e1 und anschliessendem
Kernelupdate klappts bei mir auch - ich habs vlt. zehnmal
getestet...
Was ist der Unterschied zu meinem Rettungssystem aus 2010 ???
bei mir werden in der initrd auch libata, libahci und ahci geladen...
Also werde ich dies jetzt korrigieren und dann wieder das Update testen.
Ich melde mich mit dem Ergebnis!

ich habe also in init in der initrd die Zeilen mit diesen Modulen
auskommentiert und die initrd neu gebaut (nach wiki) aber das brachte
keine Verbesserung...

nachdem das nicht funktioniert hat, baue ich mir nun einen neues
USB-Stick als Rettungssystem.

Groetjes
Stefan

[Marcus Roeckrath]

Hallo Stefan,

Post by Stefan Puschek

Post by Stefan Puschek
bei mir werden in der initrd auch libata, libahci und ahci geladen...
Also werde ich dies jetzt korrigieren und dann wieder das Update testen.
Ich melde mich mit dem Ergebnis!

ich habe also in init in der initrd die Zeilen mit diesen Modulen
auskommentiert und die initrd neu gebaut (nach wiki) aber das brachte
keine Verbesserung...
nachdem das nicht funktioniert hat, baue ich mir nun einen neues
USB-Stick als Rettungssystem.

Wie ich schon schrieb, wird nun über udev die Module geladen!

[Thomas Bork]

ich habe also in init in der initrd die Zeilen  mit diesen Modulen
auskommentiert und die initrd neu gebaut (nach wiki) aber das brachte
keine Verbesserung...

Ich verstehe nicht:

In der initramfs für den 4.9er Kernel gibt es nicht einen expliziten
Aufruf eines Treibers. Alles wird von udev erledigt.

[Thomas Bork]

Post by Thomas Bork
In der initramfs für den 4.9er Kernel gibt es nicht einen expliziten
Aufruf eines Treibers. Alles wird von udev erledigt.

Siehe

https://web.nettworks.org/wiki/pages/viewpage.action?pageId=37421194

Wenn Du Dir auf diese Art und Weise die Datei init ansiehst, dann siehst
Du bei einer initramfs für den Kernel 4.9.x folgende Zeilen:

# Start udevd.
echo > /proc/sys/kernel/hotplug
UDEVD=/sbin/udevd
echo "Executing \"${UDEVD} --daemon --resolve-names=never\" ..."
${UDEVD} --daemon --resolve-names=never
echo "Executing \"udevadm trigger --action=add --type=subsystems\" ..."
udevadm trigger --action=add --type=subsystems
echo "Executing \"udevadm trigger --action=add --type=devices\" ..."
udevadm trigger --action=add --type=devices
echo "Executing \"udevadm trigger --action=change --type=devices\" ..."
udevadm trigger --action=change --type=devices
echo "Executing \"udevadm settle\" ..."
udevadm settle

Wenn Du die nicht sehen solltest, hast Du überhaupt keine initramfs für
den Kernel 4.9.x auf Deinem Stick. Kläre das zuerst.

Wenn Du diese Zeilen siehst und damit immer noch nicht booten kannst,
könntest Du eine Pause vor der weiteren Verarbeitung des Skriptes
einfügen. Da usb_storage bis zu 2 Sekunden benötigen kann, bis er die
Medien erkennt und einbindet, könntest Du vor "udevadm settle" folgende
Zeile einfügen:

sleep 2

Damit würde der komplette Block so aussehen:

# Start udevd.
echo > /proc/sys/kernel/hotplug
UDEVD=/sbin/udevd
echo "Executing \"${UDEVD} --daemon --resolve-names=never\" ..."
${UDEVD} --daemon --resolve-names=never
echo "Executing \"udevadm trigger --action=add --type=subsystems\" ..."
udevadm trigger --action=add --type=subsystems
echo "Executing \"udevadm trigger --action=add --type=devices\" ..."
udevadm trigger --action=add --type=devices
echo "Executing \"udevadm trigger --action=change --type=devices\" ..."
udevadm trigger --action=change --type=devices
sleep 2
echo "Executing \"udevadm settle\" ..."
udevadm settle

Baue die initramfs danach wieder laut Beschreibung zusammen, kopiere sie
an ihren Platz, führe lilo aus und teste.

[Stefan Puschek]

Hallo Tom,

Du kannst von Glück reden, dass ich dieses Posting von Dir nicht
übersehen habe in dem Wust Eurer Unterhaltung gestern...

Post by Thomas Bork

Post by Thomas Bork
In der initramfs für den 4.9er Kernel gibt es nicht einen expliziten
Aufruf eines Treibers. Alles wird von udev erledigt.

Siehe
https://web.nettworks.org/wiki/pages/viewpage.action?pageId=37421194
Wenn Du Dir auf diese Art und Weise die Datei init ansiehst, dann siehst
# Start udevd.
echo > /proc/sys/kernel/hotplug
UDEVD=/sbin/udevd
echo "Executing \"${UDEVD} --daemon --resolve-names=never\" ..."
${UDEVD} --daemon --resolve-names=never
echo "Executing \"udevadm trigger --action=add    --type=subsystems\" ..."
udevadm trigger --action=add    --type=subsystems
echo "Executing \"udevadm trigger --action=add    --type=devices\" ..."
udevadm trigger --action=add    --type=devices
echo "Executing \"udevadm trigger --action=change --type=devices\" ..."
udevadm trigger --action=change --type=devices
echo "Executing \"udevadm settle\" ..."
udevadm settle

ich "sehe" sie :)

Post by Thomas Bork
Wenn Du die nicht sehen solltest, hast Du überhaupt keine initramfs für
den Kernel 4.9.x auf Deinem Stick. Kläre das zuerst.

s.o.

Post by Thomas Bork
Wenn Du diese Zeilen siehst und damit immer noch nicht booten kannst,
könntest Du eine Pause vor der weiteren Verarbeitung des Skriptes
einfügen. Da usb_storage bis zu 2 Sekunden benötigen kann, bis er die
Medien erkennt und einbindet, könntest Du vor "udevadm settle" folgende
sleep 2
# Start udevd.
echo > /proc/sys/kernel/hotplug
UDEVD=/sbin/udevd
echo "Executing \"${UDEVD} --daemon --resolve-names=never\" ..."
${UDEVD} --daemon --resolve-names=never
echo "Executing \"udevadm trigger --action=add    --type=subsystems\" ..."
udevadm trigger --action=add    --type=subsystems
echo "Executing \"udevadm trigger --action=add    --type=devices\" ..."
udevadm trigger --action=add    --type=devices
echo "Executing \"udevadm trigger --action=change --type=devices\" ..."
udevadm trigger --action=change --type=devices
sleep 2
echo "Executing \"udevadm settle\" ..."
udevadm settle
Baue die initramfs danach wieder laut Beschreibung zusammen, kopiere sie
an ihren Platz, führe lilo aus und teste.

done

Ergebnis: klappt nicht :(

also war ich mir nicht sicher, ob mein sleep überhaupt drin ist; also
habe ich vor dem sleep moch ein echo "XXXXXXXXXXXXXXXXXXXX" eingebaut -
denn die Xe finde ich hoffemntlich im output...

die Xe sind erschienen wenn ich in der busybox zurückgescrollt habe -
aber eine Pause von 2 Sekunden habe ich im durchscrollenden Output auch
nicht bemerkt.

Also habe ich die Wartezeit verlängert; 5 Sekunden reichte nicht, erst
bei 10 Sekunden klappts dauerhaft!

Was mich wundert: man merkt die 10 Sekunden nicht wirklich - beim
Bootprozess stockt er lediglich einmal für 2-3 Sekunden - mehrfach getestet.

Ich denke wenn Du hier eine Pause von 10 Sekunden vorsiehst, wird das
reichen. Und da der USB-Stick-Noot eh nicht der Schnellste ist, kann man
das verschmerzen.

Vielen Dank für Deine Hilferstellung!

Groetjes
Stefan

[Thomas Bork]

Post by Stefan Puschek
Was mich wundert: man merkt die 10 Sekunden nicht wirklich - beim
Bootprozess stockt er lediglich einmal für 2-3 Sekunden - mehrfach getestet.

Die Kernel-Meldungen erscheinen natürlich trotzdem, auch wenn das Skript
im sleep hängt.

Post by Stefan Puschek
Ich denke wenn Du hier eine Pause von 10 Sekunden vorsiehst, wird das
reichen. Und da der USB-Stick-Noot eh nicht der Schnellste ist, kann man
das verschmerzen.

Da Du bisher der Einzige bist, bei dem das auftritt, finde ich 10
Sekunden längere Bootzeit für alle etwas fett. Da muss eine andere
Lösung her. Eventuell kann man auf das Auftauchen eines Devices prüfen.

Post by Stefan Puschek
Vielen Dank für Deine Hilferstellung!

Gerne.

[Thomas Bork]

Post by Thomas Bork
Da Du bisher der Einzige bist, bei dem das auftritt, finde ich 10
Sekunden längere Bootzeit für alle etwas fett. Da muss eine andere
Lösung her. Eventuell kann man auf das Auftauchen eines Devices prüfen.

Funktioniert das bei Dir auch, wenn Du den sleep hinter

"udevadm settle"

hängst? Glaube ich zwar nicht, denn angeblich wartet ja "udevadm settle"
solange, bis alle notwendigen Devicenodes erstellt sind - aber Versuch
macht kluch :-)

Ich versuche gerade eine Lösung zu bauen, die auf das Vorhandensein der
UUID des root-Devices unter /dev/disk/by-uuid prüft und erst bei deren
Erscheinen weitermacht. Die UUID bekomme ich per "cat /proc/cmdline",
dahin übergibt sie lilo.

[Stefan Puschek]

Hallo Tom,
...

Post by Thomas Bork

Post by Thomas Bork
Da Du bisher der Einzige bist, bei dem das auftritt, finde ich 10
Sekunden längere Bootzeit für alle etwas fett. Da muss eine andere
Lösung her. Eventuell kann man auf das Auftauchen eines Devices prüfen.

Funktioniert das bei Dir auch, wenn Du den sleep hinter
"udevadm settle"
hängst? Glaube ich zwar nicht, denn angeblich wartet ja "udevadm settle"
solange, bis alle notwendigen Devicenodes erstellt sind - aber Versuch
macht kluch :-)

nun sind wir klucher :)

der sleep 2 HINTER udevadm settle hat den gewünschten Effekt.

ich bin bei zehn von zehn reboots NICHT in der busybox gelandet. Und
mein Intel-Atom-Board hat damit auch klaglos gebootet - das hat vorher
(ohne einen sleep) NIEMALS geklappt

Post by Thomas Bork
Ich versuche gerade eine Lösung zu bauen, die auf das Vorhandensein der
UUID des root-Devices unter /dev/disk/by-uuid prüft und erst bei deren
Erscheinen weitermacht. Die UUID bekomme ich per "cat /proc/cmdline",
dahin übergibt sie lilo.

das könnte dann wohl überflüssig sein...

Groetjes
Stefan

[Thomas Bork]

Post by Stefan Puschek
nun sind wir klucher :)
der sleep 2 HINTER udevadm settle hat den gewünschten Effekt.

Danke für den Test :-)

Post by Stefan Puschek

Post by Thomas Bork
Ich versuche gerade eine Lösung zu bauen, die auf das Vorhandensein
der UUID des root-Devices unter /dev/disk/by-uuid prüft und erst bei
deren Erscheinen weitermacht. Die UUID bekomme ich per "cat
/proc/cmdline", dahin übergibt sie lilo.

das könnte dann wohl überflüssig sein...

Könntest Du noch etwas testen? Nimm den sleep oben noch einmal raus und
modifiziere bitte den folgenden Abschnitt der Datei init in der initramfs:

Original:

if $($GREP -q '^UUID' /rootdev)
then
# UUID=2381eff1-9677-4a04-9faa-323247ec2f83
string="$($CAT /rootdev)"
echo "rootdev is a UUID: $string, converting it to device ..."
UUIDDEV="$(findfs "$string")"
echo "UUIDDEV is $UUIDDEV."
$RDEV "$UUIDDEV"
echo "rootdev is now $($CAT /rootdev)."
fi


Nach Änderung:

if $($GREP -q '^UUID' /rootdev)
then
# UUID=2381eff1-9677-4a04-9faa-323247ec2f83
string="$($CAT /rootdev)"
echo "rootdev is a UUID: $string"

root_uuid="$(echo "$string" | $AWK -F'=' '{print $2}')"
# 2381eff1-9677-4a04-9faa-323247ec2f83
for try in 0 1 2 3 4 5 6 7 8 9
do
# wait max 10 seconds
test -L /dev/disk/by-uuid/${root_uuid} && break
echo "Waiting for ${root_uuid} to appear in /dev/disk/by-uuid ..."
sleep 1
done

if [ ! -L /dev/disk/by-uuid/${root_uuid} ]
then
echo ""
echo "Cannot find ${root_uuid} in /dev/disk/by-uuid/. Giving up
..."
shell
fi

echo "Converting $string to device ..."
UUIDDEV="$(findfs "$string")"
echo "UUIDDEV is $UUIDDEV."
$RDEV "$UUIDDEV"
echo "rootdev is now $($CAT /rootdev)."
fi

Wie gehabt initramfs zusammen packen, nach /boot kopieren, lilo
ausführen und testen.

[Stefan Puschek]

Hallo Tom,
...

Post by Thomas Bork

Post by Stefan Puschek
nun sind wir klucher :)
der sleep 2 HINTER udevadm settle hat den gewünschten Effekt.

Danke für den Test :-)

graag gedaan :)

Post by Thomas Bork

Post by Stefan Puschek

Post by Thomas Bork
Ich versuche gerade eine Lösung zu bauen, die auf das Vorhandensein
der UUID des root-Devices unter /dev/disk/by-uuid prüft und erst bei
deren Erscheinen weitermacht. Die UUID bekomme ich per "cat
/proc/cmdline", dahin übergibt sie lilo.

das könnte dann wohl überflüssig sein...

Könntest Du noch etwas testen? Nimm den sleep oben noch einmal raus und
if $($GREP -q '^UUID' /rootdev)
then
    # UUID=2381eff1-9677-4a04-9faa-323247ec2f83
    string="$($CAT /rootdev)"
    echo "rootdev is a UUID: $string, converting it to device ..."
    UUIDDEV="$(findfs "$string")"
    echo "UUIDDEV is $UUIDDEV."
    $RDEV "$UUIDDEV"
    echo "rootdev is now $($CAT /rootdev)."
fi
if $($GREP -q '^UUID' /rootdev)
then
    # UUID=2381eff1-9677-4a04-9faa-323247ec2f83
    string="$($CAT /rootdev)"
    echo "rootdev is a UUID: $string"
    root_uuid="$(echo "$string" | $AWK -F'=' '{print $2}')"
    # 2381eff1-9677-4a04-9faa-323247ec2f83
    for try in 0 1 2 3 4 5 6 7 8 9
    do
        # wait max 10 seconds
        test -L /dev/disk/by-uuid/${root_uuid} && break
        echo "Waiting for ${root_uuid} to appear in /dev/disk/by-uuid ..."
        sleep 1
    done
    if [ ! -L /dev/disk/by-uuid/${root_uuid} ]
    then
        echo ""
        echo "Cannot find ${root_uuid} in /dev/disk/by-uuid/. Giving up
..."
        shell
    fi
    echo "Converting $string to device ..."
    UUIDDEV="$(findfs "$string")"
    echo "UUIDDEV is $UUIDDEV."
    $RDEV "$UUIDDEV"
    echo "rootdev is now $($CAT /rootdev)."
fi
Wie gehabt initramfs zusammen packen, nach /boot kopieren, lilo
ausführen und testen.

done

das Notebook hat 10 von 10 reboots überlebt - keine busybox

auch der Test auf meinen Atömchen ist positiv verlaufen

HTH

Groetjes
Stefan

[Thomas Bork]

Post by Stefan Puschek
das Notebook hat 10 von 10 reboots überlebt - keine busybox
auch der Test auf meinen Atömchen ist positiv verlaufen

Vielen Dank, kommt so in die nächste Version :-)

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork

ich habe also in init in der initrd die Zeilen  mit diesen Modulen
auskommentiert und die initrd neu gebaut (nach wiki) aber das brachte
keine Verbesserung...

In der initramfs für den 4.9er Kernel gibt es nicht einen expliziten
Aufruf eines Treibers. Alles wird von udev erledigt.

Es gilt zwar weiterhin die alte Anleitung zur Manipulation der
initrd/initramfs, werde aber wohl hier den Zusatz zu udev und dem nicht
mehr expliziten Laden von Modulen ergänzen.

[Stefan Puschek]

Hallo Tom,
...

Post by Thomas Bork

ich habe also in init in der initrd die Zeilen  mit diesen Modulen
auskommentiert und die initrd neu gebaut (nach wiki) aber das brachte
keine Verbesserung...

In der initramfs für den 4.9er Kernel gibt es nicht einen expliziten
Aufruf eines Treibers. Alles wird von udev erledigt.

wenn ich DAS gewusst hätte, dann hätte ich mir diesen Test sparen können...

Groetjes
Stefan

[Marcus Roeckrath]

Hallo Stefan,

Post by Stefan Puschek

Post by Thomas Bork
In der initramfs für den 4.9er Kernel gibt es nicht einen expliziten
Aufruf eines Treibers. Alles wird von udev erledigt.

wenn ich DAS gewusst hätte, dann hätte ich mir diesen Test sparen können...

Im Wikirtikel
https://web.nettworks.org/wiki/display/e/Anmerkungen+zum+Wechsel+vom+3.16er+zum+4.9er+Kernel
steht:

"Die Bootdateien des neuen Kernels nutzen schon udev und bringen außerdem
alle möglichen Module für Festplatten-Controller mit. Dadurch kann eine
Installation ohne Änderung der initrd auf eine neue Hardware übertragen
werden und sollte dort problemlos booten.

Dadurch werden allerdings die Bootdateien viel größer als bisher, wodurch
der Platz in /boot eng werden kann. Gegebenenfalls muss mittels
entsprechender Tools die boot-Partition vergrößert werden.

Es werden prinzipiell nur zwei Varianten der initrd erzeugt, je nachdem, ob
das spätere Bootmedium eine interne Platte oder ein USB-Stick ist:

Im ersten Fall werden die Module usb-storage und uas blacklisted, damit sich
Devices eventuell angeschlossener USB-Sticks/Platten nicht zwischen die
Devices der internen Platten schieben können; insbesondere könnte es sonst
passieren, dass sich ein USB-Device zwischen die Platten eines RAIDs
drängelt. Die Module usb-storage und uas werden in diesem Fall erst nach
der Durchlaufen der initrd im Init-Prozess geladen.

Im zweiten Fall werden die Module usb-storage und uas nicht blacklisted, da
sie beim Booten für den Zugriff auf das auf USB installierte System
benötigt werden."

Thomas schrieb in der ankündigung:

"Die initramfs, aus der das System startet, musste umgearbeitet werden,
damit sie mittels udev die nötigen Treiber als Ersatz für den ehemals fest
eingebauten IDE-Treiber findet. Die Kernel-Pakete mussten umgearbeitet
werden, damit sie von und zu /dev/disk/by-id und /dev/disk/by-uuid
konvertieren könnten usw."

Sollte das deutlicher formuliert werden?

[Stefan Puschek]

Hallo Marcus,

Post by Marcus Roeckrath

Post by Stefan Puschek

Post by Thomas Bork
In der initramfs für den 4.9er Kernel gibt es nicht einen expliziten
Aufruf eines Treibers. Alles wird von udev erledigt.

wenn ich DAS gewusst hätte, dann hätte ich mir diesen Test sparen können...

Im Wikirtikel
https://web.nettworks.org/wiki/display/e/Anmerkungen+zum+Wechsel+vom+3.16er+zum+4.9er+Kernel

den hatte ich gelesen

Post by Marcus Roeckrath
"Die Bootdateien des neuen Kernels nutzen schon udev und bringen außerdem
alle möglichen Module für Festplatten-Controller mit. Dadurch kann eine
Installation ohne Änderung der initrd auf eine neue Hardware übertragen
werden und sollte dort problemlos booten.
Dadurch werden allerdings die Bootdateien viel größer als bisher, wodurch
der Platz in /boot eng werden kann. Gegebenenfalls muss mittels
entsprechender Tools die boot-Partition vergrößert werden.
Es werden prinzipiell nur zwei Varianten der initrd erzeugt, je nachdem, ob
Im ersten Fall werden die Module usb-storage und uas blacklisted, damit sich
Devices eventuell angeschlossener USB-Sticks/Platten nicht zwischen die
Devices der internen Platten schieben können; insbesondere könnte es sonst
passieren, dass sich ein USB-Device zwischen die Platten eines RAIDs
drängelt. Die Module usb-storage und uas werden in diesem Fall erst nach
der Durchlaufen der initrd im Init-Prozess geladen.
Im zweiten Fall werden die Module usb-storage und uas nicht blacklisted, da
sie beim Booten für den Zugriff auf das auf USB installierte System
benötigt werden."
"Die initramfs, aus der das System startet, musste umgearbeitet werden,
damit sie mittels udev die nötigen Treiber als Ersatz für den ehemals fest
eingebauten IDE-Treiber findet. Die Kernel-Pakete mussten umgearbeitet
werden, damit sie von und zu /dev/disk/by-id und /dev/disk/by-uuid
konvertieren könnten usw."
Sollte das deutlicher formuliert werden?

ich weiss nicht, ob das geholfen hätte :)

selbst nachdem ich mir nun die neue init angesehen habe, weiss ich immer
noch nicht, WIE udev die Treiber einbindet.

Und ausserdem war ich fälschlicherweise davon ausgegangen, dass die
SATA-Treiber (ahci, libata, libahci) immer in der initrd geladen werden
müssen; keine Ahnung wo ich die Fehlinformation herhatte...

Aber jetzt läufts - mit einem sleep 10 - zuverlässig.

Danke für die Hilfestellung!

Groetjes
Stefan

[Marcus Roeckrath]

Hallo Stefan,

Post by Stefan Puschek
selbst nachdem ich mir nun die neue init angesehen habe, weiss ich immer
noch nicht, WIE udev die Treiber einbindet.

Muss man das wirklich wissen? Müssen wir genau wissen, was der Kernel so
tut?

Prinzipiell erkennt der Kernel die Hardware, wobei anhand der Vendor- und
Geräte-ID ermittelt wird, welches Modul zuständig ist. Bin mir nicht
sicher, ob das Modul nicht sogar schon vom Kernel geladen wird.

Jedenfalls meldet der Kernel an udev gewisse Daten über die hardware, die
dann udev anhand seines Regelwerks bearbeitet.

Diese Regeln finden sich unter /etc/udev und /usr/lib/udev und sind
Standardregeln, die man aber auch ändern kann, wie wir das auch in einigen
Fällen getan haben.

udev kümmert sich im wesentlichen um das Anlegen von Devicefile unter /dev.
Daher muss ein Linuxsystem mit udev nicht mehr sämtliche denkbaren Ddevices
mitliefern, die Zahl dürfte bestimmt im vierstelligen Bereich liegen,
sondern es werden nur die notwendigen Devices angelegt.

[Thomas Bork]

Post by Marcus Roeckrath
Prinzipiell erkennt der Kernel die Hardware, wobei anhand der Vendor- und
Geräte-ID ermittelt wird, welches Modul zuständig ist. Bin mir nicht
sicher, ob das Modul nicht sogar schon vom Kernel geladen wird.

Wenn der Kernel die Module laden würde, wären bisher keine Ladebefehle
für Treiber in der initramfs zum Einbinden der Laufwerke notwendig
gewesen. Diese Ladebefehle existieren jetzt nur nicht mehr, weil udev
das übernimmt.

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Marcus Roeckrath
Prinzipiell erkennt der Kernel die Hardware, wobei anhand der Vendor- und
Geräte-ID ermittelt wird, welches Modul zuständig ist. Bin mir nicht
sicher, ob das Modul nicht sogar schon vom Kernel geladen wird.

Wenn der Kernel die Module laden würde, wären bisher keine Ladebefehle
für Treiber in der initramfs zum Einbinden der Laufwerke notwendig
gewesen. Diese Ladebefehle existieren jetzt nur nicht mehr, weil udev
das übernimmt.

So muss es sein, denn man unterbindet ja auch auf Wunsch durch blacklisten
Module in udev, was ja nicht ginge, wenn der Kernel einfach schon laden
würde.

[Marcus Roeckrath]

Hallo Stefan,

Post by Stefan Puschek
Toll: mit einem frisch installierten e1 und anschliessendem Kernelupdate
klappts bei mir auch - ich habs vlt. zehnmal getestet...
Was ist der Unterschied zu meinem Rettungssystem aus 2010 ???

Keine Ahnung.

Post by Stefan Puschek
bei mir werden in der initrd auch libata, libahci und ahci geladen...
Also werde ich dies jetzt korrigieren und dann wieder das Update testen.

Da ist nichts zu korrigieren; beim neuen 4er-Kernel werden die Module durch
udev und nicht mehr durch explizite Angabe in der initrd geladen.

Das ist ja gerade der Vorteil, das die Installation dadurch auch auf neuer
Hardware ohne Änderung booten würde.

[Thomas Bork]

Post by Stefan Puschek
Toll: mit einem frisch installierten e1 und anschliessendem Kernelupdate
klappts bei mir auch - ich habs vlt. zehnmal getestet...

Auf dem selben Rechner mit dem selben Stick?

Post by Stefan Puschek
Was ist der Unterschied zu meinem Rettungssystem aus 2010 ???

Es gibt keinen. Die erzeugte initrd ist immer gleich.

Post by Stefan Puschek
bei mir werden in der initrd auch libata, libahci und ahci geladen...
Also werde ich dies jetzt korrigieren und dann wieder das Update testen.

Was in der alten initrd passiert, ist völlig unerheblich. Es wird ja die
neue initrd benutzt. In der werden keine Treiber explizit geladen, alles
wird von udev erledigt.

[Thomas Bork]

Post by Marcus Roeckrath
Bei diesen Boots war der Stick immer sdb!
Auch das ist erklärlich, denn nun ist ja mit dem 4er-Kernel auch schon beim
Boot udev aktiv und lädt nun das Modul für die interne Platte schon beim
Boot, die nun fest zu sda wird.

Dann ist das bei Dir zufällig zu 100 % immer so. Bei Stefan nur zu 50 %.
Bei Stefan wird zu 50 % zuerst der usb_storage geladen und es
funktioniert. Zu 50 % wird zuerst der hdd-Treiber geladen und es
funktioniert nicht.

Ich vermute, dass bei Stefan der USB-Stick noch nicht richtig da ist,
wenn zuerst der hdd-Treiber geladen wird...

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Marcus Roeckrath
Bei diesen Boots war der Stick immer sdb!
Auch das ist erklärlich, denn nun ist ja mit dem 4er-Kernel auch schon
beim Boot udev aktiv und lädt nun das Modul für die interne Platte schon
beim Boot, die nun fest zu sda wird.

Dann ist das bei Dir zufällig zu 100 % immer so. Bei Stefan nur zu 50 %.
Bei Stefan wird zu 50 % zuerst der usb_storage geladen und es
funktioniert. Zu 50 % wird zuerst der hdd-Treiber geladen und es
funktioniert nicht.

Moemnt; war es bei Stefan nicht so, dass es knallt, wenn bei ihm der Stick
zu sdb wird?

Genau das funktioniert bei mir zuverlässig, denn er wird immer zu sdb.

sda bekomme ich beim Boot von dem Stick nicht hin.

Post by Thomas Bork
Ich vermute, dass bei Stefan der USB-Stick noch nicht richtig da ist,
wenn zuerst der hdd-Treiber geladen wird...

Timingprobleme sind da nie auszuschliessen, das F9-Boot-Menu des HP-Laptop
zeigt den Stick mal als USB-HDD oder mit seinem Namen (Verbatim...) an.

Auf den Boot hat das hier aber keinen negativen oder ändernden Einfluss.

[Thomas Bork]

Post by Marcus Roeckrath
Moemnt; war es bei Stefan nicht so, dass es knallt, wenn bei ihm der Stick
zu sdb wird?

Ja, wenn ein anderer Treiber mit dem Schema sdX zuerst geladen wird.

Post by Marcus Roeckrath
Genau das funktioniert bei mir zuverlässig, denn er wird immer zu sdb.

Bei ihm nicht.

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork

Moment; war es bei Stefan nicht so, dass es knallt, wenn bei ihm der
Stick zu sdb wird?

Ja, wenn ein anderer Treiber mit dem Schema sdX zuerst geladen wird.

Genau das funktioniert bei mir zuverlässig, denn er wird immer zu sdb.

Bei ihm nicht.

???

Zitat:

"wenn ich aber in der busybox lande, ist der genutzte Datenträger IMMER
/dev/sdb"

Bei ihm wird er mal sda, dann kommt die interne Platte erst danach, und es
geht; oder zu sdb, also nach der internen Platte, dann knallts.

[Thomas Bork]

Post by Marcus Roeckrath
Bei ihm wird er mal sda, dann kommt die interne Platte erst danach, und es
geht; oder zu sdb, also nach der internen Platte, dann knallts.

Sag ich doch.

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Marcus Roeckrath
Bei ihm wird er mal sda, dann kommt die interne Platte erst danach, und
es geht; oder zu sdb, also nach der internen Platte, dann knallts.

Sag ich doch.

Ich glaube, wir reden irgendwie aneinander vorbei. :-))

Was bei ihm also nicht geht, geht bei mir immer: Die interne Platte drängelt
sich vor den Stick, was keine Auswirkung auf den Boot hat.

[Thomas Bork]

Post by Stefan Puschek
wenn ich aber in der busybox lande, ist der genutzte Datenträger IMMER
/dev/sdb; die letzten Meldungen sind dann, dass er MAJOR und MINOR in
/proc/diskstats nicht finden konnte - beide sind angeblich '.' . jetzt
control-alt-delete...

In dem Fall wurde von udev wahrscheinlich der hdd-Treiber zuerst geladen.

Post by Stefan Puschek
Wer kommt da bei mir nicht mit dem geänderten Device (sdb statt sda)
zurecht? Wir greifen doch nur noch über UUIDs auf die Partitionen zu,
also sollte dies doch nicht mehr passieren. Dass die Geräte von udev
nicht immer in der gleichen Reihenfolge erkannt werden, weiss ich -
deshalb die UUIDs.

Ich könnte mir eigentlich nur ein Timing-Problem vorstellen:
Das Start-Skript versucht schon vom Stick zu booten, bevor dieser
komplett bereit ist.