Nach System-Absturz bleibt boot am Anfang hängen, weil initram die System-Partition nicht findet

[gosia]

Hallo loik,
na, deine BusyBox ist sehr spärlich bestückt. Ich habe da mindestens das dreifache an Kommandos zur Verfügung. Aber das nur nebenbei, ist wohl nicht das Problem. So richtig weiss ich nicht weiter. Im Netz gibt es verschiedene Ansätze:
1. Reperatur der Partition mit fsck /dev/sdXY -> aber das hattest Du wohl schon probiert.
2. Im BIOS den AHCI-Modus einschalten. Ist je nach BIOS verschieden, meist im Advanced Modus -> IDE-Konfiguration -> unter SATA-Einstellungen (wenn es daran liegt, müsste deine FP aber eigentlich an einer anderen Maschine booten, kannst aber trotzdem nachsehen)
Und was sagen denn diese Kommandos?

Code: Select all

cat /proc/cmdline
cat /proc/modules
ls /dev/disk/by-uuid
ls /dev/disk/by-label

viele Grüsse gosia

[loik]

Hallo, Gosia.

BIOS-AHCI
Da will ich erst mal noch nicht dran rumfummeln.
Zumal das System an 6 völlig unterschiedlichen PCs und NBs mit dem exakt selben Fehler scheitert.

Und wie du weißt, war es in den VMs von Virt-Manager und VB ebenso.


Die ausgaben der Terminalbefehle sahen so aus:


Interessant, der Widerspruch.
Das die korrekte UUID aufgelistet ( wohl aus Grub-Config ausgelesen ? ) wird, aber am ende weder per uuid noch per label auffindbar sei.

[gosia]

Hallo loik,

der Widerspruch. Das die korrekte UUID aufgelistet

naja, so ein Widerspruch ist das nicht. Wie Du schon vermutest, die UUID steht ja in der grub.cfg. Ich vermute, es fehlt ein Kernel-Modul, mit dem die Partition gefunden/gemountet werden kann. Ist aber nur eine Vermutung.
Könnte auch ein Fehler im initramfs Image sein. Kannst ja mal probieren, es neu zu erstellen. Hänge dazu die externen USB-FP an einen Rechner mit einem laufenden System (Q4OS) und führe das aus:

Code: Select all

sudo mount /dev/sdXY /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt
update-initramfs -u
update-grub
reboot

sdXY natürlich anpassen

viele Grüsse gosia

[loik]

Hallo, Gosia.

Danke für den Versuch.

Diese Befehlskette hatte ich in der Vergangenheit ausschließlich benutzt, bis ich hier im Forum auf Chroot-Rescue-Scann hingewiesen wurde.
Das erleichtert das chroot-Laden des Fremdsystems erheblich.
Und ich hatte es in diesem Fall auch schon ca. 30 mal angewendet.
update-initramfs -u -k all
update-grub

Aber es hatte nie nix genutzt.
Der "händische" Versuch mit den Befehlen über das Terminal leider auch nicht.

Ja, es fehlt anscheinend etwas.
Deshalb hatte ich bereits per chroot-recue-scan den Kernel 6.1.0-32 rekonfiguriert.

Code: Select all

dpkg-reconfigure linux-image-686

auch eine Neuinstallation des Kernels hatte ich gemacht:

Code: Select all

apt install --reinstall linux-image-686

auch habe ich alternativ den Vorgänger-Kernel installiert

Code: Select all

apt install linux-image-6.1.0-31-686 linux-headers-6.1.0-31-686 linux-headers-6.1.0-31-common

Aktuelle habe ich auch noch den 6.1.0-33 installiert

Code: Select all

apt install linux-image-6.1.0-33-686 linux-headers-6.1.0-33-686 linux-headers-6.1.0-33-common

Alles nix genutzt.

Natürlich hatte ich nach jeder Aktion auch durchgeführt

Code: Select all

update-initramfs -u -k all

Code: Select all

update-grub

Interressant, bei update-grub werde ich immer auf deaktiviertes OS-Prober hingewiesen.

Code: Select all

chroot> update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-33-686
Found initrd image: /boot/initrd.img-6.1.0-33-686
Found linux image: /boot/vmlinuz-6.1.0-32-686
Found initrd image: /boot/initrd.img-6.1.0-32-686
Found linux image: /boot/vmlinuz-6.1.0-31-686
Found initrd image: /boot/initrd.img-6.1.0-31-686
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done

Könnte das der Grund sein?
Ich hatte mir da nix schlimmes bei gedacht, weil ich es in der Vergangenheit bei meinen Multiboot-Subsystemen bisher immer selber in den Subsystemen deaktiviert hatte, damit Update-grub des Hauptsystems nicht eine unendlich lange Schleifen-Liste an Boot-Eintträgen erstellt.
Hier hatte ich aber nicht meine Finger im Spiel.

Habe mal in /etc/defalt/grub
nachgeschaut.

Da war ein Infotext, der genau das bestätigt, was ich ebend über die Schleifen-Boot-Einträge geschrieben habe
Die zum Text gehörige Komanozeile

Code: Select all

#GRUB_DISABLE_OS_PROBER=false

Habe ich auskommentiert. ( Raute entfernt ).
Danach sah update-grub so aus.

Code: Select all

chroot> update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-33-686
Found initrd image: /boot/initrd.img-6.1.0-33-686
Found linux image: /boot/vmlinuz-6.1.0-32-686
Found initrd image: /boot/initrd.img-6.1.0-32-686
Found linux image: /boot/vmlinuz-6.1.0-31-686
Found initrd image: /boot/initrd.img-6.1.0-31-686
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
ERROR: mkdir /var/lock/dmraid
done

Das Boot-Problem blieb aber bestehen.
Ich verstehe es nicht

[gosia]

Hallo loik,
das sind alles Images von der betreffenden externen FP? Also alles Q4OS-Aquarius-Trinity? Oder haben wir hier eine neue Baustelle? Und alle enden bei der Auswahl im gleichen Disaster?
Aber sonst gehen mir die Ideen aus. Eigentlich hast Du ja alles probiert, was existiert, auch fsck, wenn ich mich richtig erinnere.
Ich hoffe, es hat noch jemand anderes eine zündende Idee. Tut mir leid...

viele Grüsse gosia

[loik]

Hallo, Gosia.

Geliefert wurde das Q4OS mit dem Kernel 6.1.0-32.
Die beiden anderen habe ich via chroot über das Terminal nachinstalliert, in der Hoffnung, so das System für den Bootprozess wieder auffindbar zu machen.
Hat nichts geändert.
Zeigt aber, eben so wie ein ausführbaren apt update und apt dist-upgrade, dass das System vorhanden und benutzbar ist.

Danke für deine Hilfe.
Zeigt sie mir doch, dass ich bei meinen bisherigen Versuchen nichts übersehen hatte und zuvor schon auf dem gleichen Reparaturpfad gewndelt bin, wie du ihn auch beschritten hättest.

Das war nun zwar nicht erfolgreich, bewirkt aber, dass ich mich nicht total dumm fühle, da nun bestätigt, dass das Übel unerkennbar tiefer liegt.

Ich hoffe darauf, dass sich Fehlix vielleicht noch locken lässt, über diese spezielle Boot-Problem nachzudenken.
So aus sportlichem Interesse heraus vielleicht ?