Page 1 of 1

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

Posted: Tue Apr 15, 2025 5:22 am
by loik
Hallo, Forum.

Nach System-Absturz bleibt der Boot am Anfang hängen, weil initram die System-Partition nicht findet.
Es ist kein MX-System sondern ein Q4OS-Aquarius-Trinity-32bit.
Weil es aber ebenfalls Debian 12 ist und ich glaube, dass das Problem nicht OS spezifisch sondern generell Linux-boot betrifft, hoffe ich das ihr mir weiter helfen könnt.


Das System befindet sich auf einem externen USB-Datenträger und wird an unterschiedlichen kompatiblen Rechnern ( nicht UEFI ) betrieben.

Das System ist im Betrieb eingefroren,sodas ich es gewaltsam ausschalten musste.
Beim Wiederhochfahren erhielt ich folgende Fehlermeldung:

Image

Die Aussage, dass genanntes System mit angegebener UUID nicht existiere, stimmt aber nicht.

Grub startet immer noch und gibt eine Boot-Auswahl.
Aber egal welchen Eintrag ich wähle, es läuft immer auf den gleichen Abruch mit selber Fehlermeldung hinaus.


Wenn ich mir das per MX-Live-USB-Stick anschaue, ist die System-Partition vorhanden und die UUID stimmt an allen Punkten wo sie stimmen muss:
-fstab
-/etc/default/grub
-/boot/grub/grub.cfg

Ich kann über den Dateimanager des Live-Systems auf das System von Q4OS zugreifen.
Per Terminal eine Systemprüfung und Reparatur durchzuführen war machbar, hat keinen Fehler ergeben.

Code: Select all

sudo fsck.ext4 -v -f -c /dev/sdy0

Code: Select all

sudo e2fsck.ext4 -v -f -c /dev/sdy0
Die Partition ist als Boot-Fähig markiert.

Ich kann via Live-System und "MX-Chroot Rescue Scan" auf das Q4OS zugreifen und Updates durchführen.
Sowohl Apt-Paket-Updates, als auch Update von grub und initramfs.
Installiert war der Kernel 6.1.0-32
Ich habe sowohl --reconfigure als auch neu Installation des Kernels vorgenommen.
Ohne Verbesserung.
Auch das Installieren eines Alternativ-Kernels 6.1.0-31 hatte nichts verbessert.

Neuinstallationen von Grub mit MX-Boot-Reparatur hat auch nicht geholfen.


Zuletzt habe ich der Q4OS_System-Partition mit gparted eine neue UUID verpasst.
Diese natürlich in fstab angepasst und natürlich updated-grub und updated-initramfs ausgeführt.
Hat nichts geholfen.
Noch mal Grub neu installiert und anschließend noch mal update-grub und update-initramfs, auch nicht.
Jetzt bezieht sich die Fehlermeldung auf die neue UUID des System und behauptet, das nun eben diese nicht existent sei.
Boot-Markierung ist immer noch vorhanden.

Kann jemand von euch aus der Fehlermeldung des geposteten Screenshots eine Lösungs-Idee finden ?

Dies ist die neue UUID, mit der der Gleiche Fehler wie auf dem Screenshot auftritt.
Diese UUID wir nun ebenfalls in der Fehlermeldung benannt und es wir ebenso verkündet, das diese Laufwerk nicht existiere:

Code: Select all

/dev/sdd6: LABEL="Q4OS-AQ-32" UUID="e23b380b-f645-449c-8ae3-26c7362487b6" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c8eccff7-06"

Code: Select all

chroot> inxi -Fxxxrza
System:
  Kernel: 5.10.197-antix.1-686-smp-pae arch: i686 bits: 32 compiler: gcc
    v: 12.2.0 parameters: quiet splash lang=de_DE kbd=de,us tz=Europe/Berlin
  Desktop: Xfce info: xfce4-panel wm: xfwm dm: N/A Distro: Q4OS 5.8.1-n1
Machine:
  Type: Laptop System: FUJITSU SIEMENS product: AMILO Li3910 v: 10600997318
    serial: <filter> Chassis: type: 10 v: 30_ serial: <filter>
  Mobo: FUJITSU SIEMENS model: EF9 v: Rev 1.0 serial: <filter> BIOS: Phoenix
    v: 1.03 date: 10/06/2008
Battery:
  ID-1: BAT1 charge: 2.7 Wh (100.0%) condition: 2.7/47.5 Wh (5.7%) volts: 12.5
    min: 10.8 model: SAN-SAN Main type: Li-ion serial: N/A status: full
  Device-1: hidpp_battery_0 model: Logitech Zone Touch Mouse T400
    serial: <filter> charge: Normal status: discharging
CPU:
  Info: model: Intel Pentium Dual T3200 socket: U2E1 bits: 64 type: MCP
    arch: Core2 Merom built: 2006-09 process: Intel 65nm family: 6
    model-id: 0xF (15) stepping: 0xD (13) microcode: 0xA3
  Topology: cpus: 1x cores: 2 smt: <unsupported> cache: L1: 128 KiB
    desc: d-2x32 KiB; i-2x32 KiB L2: 1024 KiB desc: 1x1024 KiB
  Speed (MHz): avg: 1000 min/max: 1000/2000 base/boost: 2000/2000 scaling:
    driver: acpi-cpufreq governor: ondemand volts: 3.3 V ext-clock: 667 MHz
    cores: 1: 1000 2: 1000 bogomips: 7979
  Flags: ht lm nx pae sse sse2 sse3 ssse3
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: KVM: VMX unsupported
  Type: l1tf mitigation: PTE Inversion
  Type: mds status: Vulnerable: Clear CPU buffers attempted, no microcode;
    SMT disabled
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data status: Unknown: No mitigations
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass status: Vulnerable
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
    sanitization
  Type: spectre_v2 mitigation: Retpolines, STIBP: disabled, RSB filling,
    PBRSB-eIBRS: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel Mobile 4 Series Integrated Graphics
    vendor: Fujitsu Solutions driver: i915 v: kernel arch: Gen-5
    process: Intel 45nm built: 2008 ports: active: LVDS-1 empty: DP-1,VGA-1
    bus-ID: 00:02.0 chip-ID: 8086:2a42 class-ID: 0300
  Display: server: X.Org v: 1.21.1.7 compositor: xfwm driver: X: loaded: N/A
    unloaded: fbdev,modesetting,vesa dri: crocus gpu: i915 note: X driver n/a
    display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1680x945 s-dpi: 96 s-size: 445x251mm (17.52x9.88")
    s-diag: 511mm (20.11")
  Monitor-1: LVDS-1 model: Seiko Epson 0x314b built: 2008 res: 1680x945
    hz: 60 dpi: 104 gamma: 1.2 size: 409x230mm (16.1x9.06") diag: 469mm (18.5")
    ratio: 16:9 modes: 1680x945
  API: OpenGL v: 2.1 Mesa 22.3.6 renderer: Mesa Mobile Intel GM45 Express
    (CTG) direct-render: Yes
Audio:
  Device-1: Intel 82801I HD Audio vendor: Fujitsu Solutions
    driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:293e
    class-ID: 0403
  API: ALSA v: k5.10.197-antix.1-686-smp-pae status: kernel-api
    tools: alsamixer,amixer
  Server-1: PulseAudio v: 16.1 status: off tools: pacat,pactl
Network:
  Device-1: Realtek RTL810xE PCI Express Fast Ethernet
    vendor: Fujitsu Solutions driver: r8169 v: kernel pcie: gen: 1
    speed: 2.5 GT/s lanes: 1 port: 3000 bus-ID: 07:00.0 chip-ID: 10ec:8136
    class-ID: 0200
  IF: eth0 state: up speed: 100 Mbps duplex: full mac: <filter>
  Device-2: Realtek RTL8187B Wireless 802.11g 54Mbps Network Adapter
    type: USB driver: rtl8187 bus-ID: 1-5:5 chip-ID: 0bda:8189 class-ID: 0000
    serial: <filter>
  IF: wlan0 state: down mac: <filter>
Drives:
  Local Storage: total: 535.26 GiB used: 7.3 GiB (1.4%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/sda maj-min: 8:0 vendor: Crucial model: CT480BX500SSD1
    size: 447.13 GiB block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s
    type: SSD serial: <filter> rev: 056 scheme: MBR
  ID-2: /dev/sdb maj-min: 8:16 type: USB vendor: SanDisk model: Cruzer Spark
    size: 28.65 GiB block-size: physical: 512 B logical: 512 B type: N/A
    serial: <filter> rev: 1.00 scheme: MBR
  ID-3: /dev/sdd maj-min: 8:48 type: USB vendor: Generic
    model: Storage Device size: 59.48 GiB block-size: physical: 512 B
    logical: 512 B type: N/A serial: <filter> rev: 0.00 scheme: MBR
Partition:
  ID-1: / raw-size: 21.16 GiB size: 20.66 GiB (97.64%) used: 7.3 GiB (35.3%)
    fs: ext4 block-size: 4096 B dev: /dev/sdd6 maj-min: 8:54
Swap:
  Kernel: swappiness: 75 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 4.79 GiB used: 0 KiB (0.0%)
    priority: -2 dev: /dev/sda9 maj-min: 8:9
Sensors:
  System Temperatures: cpu: 59.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Repos:
  Packages: pm: dpkg pkgs: 2044 libs: 1174 tools: apt,apt-get,synaptic
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/10_q4os.list
    1: deb http://q4os.org/q4repo/ q4os-5-0-cn main
  Active apt repos in: /etc/apt/sources.list.d/12_qtde.list
    1: deb http://q4os.org/qtderepo/ bookworm main
  Active apt repos in: /etc/apt/sources.list.d/20_debian.list
    1: deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/ bookworm-security main contrib non-free non-free-firmware
    3: deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/30_debian_backports.list
    1: deb http://deb.debian.org/debian/ bookworm-backports non-free-firmware non-free contrib main
  Active apt repos in: /etc/apt/sources.list.d/q4p-anydesk-20250407201413-rFm.list
    1: deb [signed-by=/usr/share/keyrings/q4a-anydesk.gpg] http://deb.anydesk.com/ all main
  Active apt repos in: /etc/apt/sources.list.d/q4p-q4os-mxtools-20250407201444-sS4.list
    1: deb [arch=amd64,i386] http://q4os.org/qextrepo/ bookworm-mx-cn main
  Active apt repos in: /etc/apt/sources.list.d/q4p-teamviewer-20250407201532-mBL.list
    1: deb [signed-by=/usr/share/keyrings/q4a-teamviewer.gpg] http://linux.teamviewer.com/deb/ stable main
  Active apt repos in: /etc/apt/sources.list.d/q4p-wine-20250407201558-N4a.list
    1: deb [signed-by=/usr/share/keyrings/q4a-winehq.gpg arch=amd64,i386] https://dl.winehq.org/wine-builds/debian/ bookworm main
Info:
  Processes: 234 Uptime: 12m wakeups: 4 Memory: 2.82 GiB
  used: 1.22 GiB (43.2%) Init: N/A v: N/A default: graphical tool: systemctl
  Compilers: gcc: 12.2.0 alt: 12 Shell: Bash (sudo) v: 5.2.15
  running-in: chroot-rescue inxi: 3.3.26

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

Posted: Sun Apr 20, 2025 2:23 pm
by loik
Frohe Ostern.

Ich erwarte ja gar nicht, dass mir jemand eine Komplettlösung zum Thema bieten wird, aber ich hoffe doch auf Ideen und Anregungen, wo nach dem Fehler zu suchen sein könnte.

Es ist mir einfach unbegreiflich, wieso beim Boot die Partition mit der benannten UUID nicht gefunden wird, gar behauptet wird, sie sei nicht existent.
Was ja, wie schon erklärt nicht stimmt.
Wozu gibt es denn UUID?
Die sollte doch wohl genau vor solch einem Missverständnis bewahren. :bagoverhead:

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

Posted: Sun Apr 20, 2025 2:59 pm
by gosia
Hallo loik,
loik wrote: Sun Apr 20, 2025 2:23 pmFrohe Ostern.
danke gleichfalls.
loik wrote: Sun Apr 20, 2025 2:23 pm ich hoffe doch auf Ideen und Anregungen, wo nach dem Fehler zu suchen sein könnte.
Hm, das einzige was mir auffällt, ist die merkwürdige Partitionsbezeichnung /dev/sdy0, genauer gesagt die Null am Ende. Die primären Partitionen werden normalerweise ab 1 durchnummeriert, also /dev/sdy1. /dev/sdy2 usw. bis maximal /dev/sdy4. Vielleicht liegt da der Hase im Pfeffer.
Häng doch mal die externe FP an einen Rechner ud poste die Ausgabe von

Code: Select all

blkid
viele Ostergrüsse gosia

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

Posted: Sun Apr 20, 2025 3:06 pm
by CharlesV
UUID (Universally Unique Identifier) wird zur Identifizierung einer Festplattenpartition verwendet und sollte immer genau und eindeutig sein.

Eine Frage, es sieht so aus, als ob die Meldung in Ihrem Bild nicht mit der UUID in Ihrer Testmeldung für /dev/sdd6 übereinstimmt ?

sollten diese identisch sein ?

Du könntest blkid verwenden und die Ergebnisse zurückschicken.

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

Posted: Sun Apr 20, 2025 5:45 pm
by loik
Hallo, gosia.
Hallo, Charles.
Danke für eure antworten und die aufmerksame Betrachtung, die gleich mal meine Schludrigkeit entlarvt haben.

y0 ist nur ein Platzhalter aus meiner Vorlage.
Kann mir nicht jeden befehlt im Detail merken.
Deshalb habe ich mir vorlagengemacht, um nicht dauernd im netzt suchen zu müssen.
Dateisystem Reparieren:
sudo e2fsck.ext4 -v -f -c /dev/sdy0

y0 steht also nur für ein mögliches a3 oder b7, oder, oder, oder ...
Ich hatte bei meinen geschilderten reparatur-Versuchen natürlich die richtige sd-Endung benutzt.


Beim Bild war ich zu faul einen neuen Screenshot zu erstellen.
Es zeigt noch die Ursprungs UUID der Partition.
Mit dieser hatte ich dieselben Probleme.
Da kam ich her.
Deshalb hatte ich versucht das Problem zu lösen, in dem ich für die Systempartition mit gparted eine neue UUID generiert habe.
Diese habe ich natürlich in fstab angepasst.
Und sie ist in der QSI zu sehen.
Aber jetzt wird dieselbe Partition mit dieser neuen UUID auch nicht gefunden.
Es kommt zu der gleichen Fehlermeldung, nur mit eben der neuen UUID zu der angeblich keine partition existiert.

Sorry für die Verwirrung in beiden fällen.

Ich werde einen aktualisierten schreenshot erstellen und blkid liefern.
Aber erst morgen abend oder Dienstag morgen.
Komme nicht vorher dran.

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

Posted: Mon Apr 21, 2025 2:18 am
by Kulmbacher
loik: ...Aber erst morgen abend oder Dienstag morgen...[/loik]

Er hat noch nicht alle Eier gefunden ;-)

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

Posted: Mon Apr 21, 2025 3:07 am
by loik
Moin, kulmbacher.

Ja, die Eier sind klein und deshalb schwer zu finden.
Aber am schwierigsten ist halt die Suche nach dem Hasen im Pfeffer, wie gosia es zutreffend benannt hat.

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

Posted: Mon Apr 21, 2025 12:46 pm
by loik
So, jetzt aber mal richtig:

Der Bootprozess von Q4OS beginnt, in dem ein Grub erscheint, der das System zum Booten anbietet.
Wenn es dann zu Booten beginnt, erscheinen erst mal folgende Zeilen:

Code: Select all

>>Q4OS Desktop 5.8 'Aquarius' << wird gebootet

Loading Q4OS operating system ...
Loading initial ramdisk ...
Dann dauert es ein wenig, bis der Bildschirm zu einem blinkenden Curser umspringt.
Nach dem der so ca. 1 Minute vor sich hingeflackert hat ( ohne dass weiteres geschieht ), spring der Bildschirm wieder um und es wird folgende Fehlermeldung angezeigt:

Image

Dann passiert nichts mehr und der Rechner muss gewaltsam ausgeschaltet werden.



Per Live-USB-Stick erhalte ich mit blkid folgende Info:

Code: Select all

$ blkid
/dev/sda1: LABEL="WinRE" BLOCK_SIZE="512" UUID="01D916E122B6D380" TYPE="ntfs" PARTUUID="640ebbc0-01"
/dev/sda2: LABEL="Ami-Adi__win10" BLOCK_SIZE="512" UUID="01D916E4960E1480" TYPE="ntfs" PARTUUID="640ebbc0-02"
/dev/sda4: LABEL="Ami-Adi__leer" BLOCK_SIZE="512" UUID="01D916ED81517600" TYPE="ntfs" PARTUUID="640ebbc0-04"
/dev/sda5: LABEL="Ami-Adi__DATEN__213_GB" BLOCK_SIZE="512" UUID="01D916EBCDCC8A80" TYPE="ntfs" PARTUUID="640ebbc0-05"
/dev/sda6: LABEL="Ami-Adi__ISOs_to_boot" BLOCK_SIZE="512" UUID="01D916ED6A7AE740" TYPE="ntfs" PARTUUID="640ebbc0-06"
/dev/sda7: LABEL="Ami_Adi__rootMX2" UUID="0e824497-7064-43c9-94c0-c0aadb83588b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="640ebbc0-07"
/dev/sda8: LABEL="Ami-Adi__ISO_WRK" UUID="b7ff772d-ee16-d901-30be-772dee16d901" BLOCK_SIZE="2048" TYPE="ext4" PARTUUID="640ebbc0-08"
/dev/sda9: UUID="ecf6dffb-39aa-49be-87ab-8dd301dcda80" TYPE="swap" PARTUUID="640ebbc0-09"
/dev/sdb1: LABEL="USB-DATA" UUID="73149f34-10bd-4072-9deb-d866b1e1dddb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3c67bc54-01"
/dev/sdb2: LABEL="Live-usb" UUID="c08ab12d-8855-4ff0-9a22-082910efc73c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3c67bc54-02"
/dev/sdb3: LABEL_FATBOOT="LIVE-UEFI" LABEL="LIVE-UEFI" UUID="DEBB-77B4" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3c67bc54-03"
/dev/sdc1: LABEL_FATBOOT="SD-64GB_DAT" LABEL="SD-64GB_DAT" UUID="C892-72D0" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c8eccff7-01"
/dev/sdc5: LABEL="Swap_auf_SD64GB" UUID="1cee3988-1058-4448-8cbf-4914364d6c36" TYPE="swap" PARTUUID="c8eccff7-05"
/dev/sdc6: LABEL="Q4OS-AQ-32" UUID="e23b380b-f645-449c-8ae3-26c7362487b6" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c8eccff7-06"



Wenn ich mich nun per MX-Chroot-Recue-Scan in das Q4OS-System begebe und dort blkid anwende, erhalte ich die gleiche Auskunft:

Code: Select all

chroot> blkid
/dev/sdb2: LABEL="Live-usb" UUID="c08ab12d-8855-4ff0-9a22-082910efc73c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3c67bc54-02"
/dev/sdb3: LABEL_FATBOOT="LIVE-UEFI" LABEL="LIVE-UEFI" UUID="DEBB-77B4" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3c67bc54-03"
/dev/sdb1: LABEL="USB-DATA" UUID="73149f34-10bd-4072-9deb-d866b1e1dddb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3c67bc54-01"
/dev/loop0: TYPE="squashfs"
/dev/sdc5: LABEL="Swap_auf_SD64GB" UUID="1cee3988-1058-4448-8cbf-4914364d6c36" TYPE="swap" PARTUUID="c8eccff7-05"
/dev/sdc1: LABEL_FATBOOT="SD-64GB_DAT" LABEL="SD-64GB_DAT" UUID="C892-72D0" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c8eccff7-01"
/dev/sdc6: LABEL="Q4OS-AQ-32" UUID="e23b380b-f645-449c-8ae3-26c7362487b6" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c8eccff7-06"
/dev/sda4: LABEL="Ami-Adi__leer" BLOCK_SIZE="512" UUID="01D916ED81517600" TYPE="ntfs" PARTUUID="640ebbc0-04"
/dev/sda2: LABEL="Ami-Adi__win10" BLOCK_SIZE="512" UUID="01D916E4960E1480" TYPE="ntfs" PARTUUID="640ebbc0-02"
/dev/sda9: UUID="ecf6dffb-39aa-49be-87ab-8dd301dcda80" TYPE="swap" PARTUUID="640ebbc0-09"
/dev/sda7: LABEL="Ami_Adi__rootMX2" UUID="0e824497-7064-43c9-94c0-c0aadb83588b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="640ebbc0-07"
/dev/sda5: LABEL="Ami-Adi__DATEN__213_GB" BLOCK_SIZE="512" UUID="01D916EBCDCC8A80" TYPE="ntfs" PARTUUID="640ebbc0-05"
/dev/sda1: LABEL="WinRE" BLOCK_SIZE="512" UUID="01D916E122B6D380" TYPE="ntfs" PARTUUID="640ebbc0-01"
/dev/sda8: LABEL="Ami-Adi__ISO_WRK" UUID="b7ff772d-ee16-d901-30be-772dee16d901" BLOCK_SIZE="2048" TYPE="ext4" PARTUUID="640ebbc0-08"
/dev/sda6: LABEL="Ami-Adi__ISOs_to_boot" BLOCK_SIZE="512" UUID="01D916ED6A7AE740" TYPE="ntfs" PARTUUID="640ebbc0-06"

/etc/fstab
gibt es in zwei Varianten, wovon nur eine jeweils aktiv ist, während die andere dann deaktiviert ist.
Und sie sind dann immer schön mit update-grub erfasst.

Code: Select all

# / was on /dev/sda6 during installation
UUID=e23b380b-f645-449c-8ae3-26c7362487b6 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=UUID=1cee3988-1058-4448-8cbf-4914364d6c36 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
oder

Code: Select all

# / was on /dev/sda6 during installation
UUID=e23b380b-f645-449c-8ae3-26c7362487b6 /               ext4    defaults,noatime 0 1
# swap was on /dev/sda5 during installation
UUID=1cee3988-1058-4448-8cbf-4914364d6c36 /swap           swap    defaults,noatime 0 0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
Es macht keinen unterschied, welche fstab ich verwende. Das Booten scheitert immer auf die gleiche Weise.

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

Posted: Mon Apr 21, 2025 2:51 pm
by gosia
Hallo loik,
loik wrote: Mon Apr 21, 2025 12:46 pm Dann passiert nichts mehr und der Rechner muss gewaltsam ausgeschaltet werden.
Naja, wenn Du nichts eingibst kann auch nicht viel passieren ;)
Gib dort nach dem (initramfs) zumindest mal exit ein. Dann sollten weitere (Fehler-)Meldungen erscheinen, die Du dann hier posten kannst.
Wenn exit nicht funktioniert, dann wenigstens wie vorgeschlagen

Code: Select all

help
eingeben.

viele Grüsse gosia

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

Posted: Tue Apr 22, 2025 12:53 am
by loik
Hallo, Gosia.

Hm, tja eine Eingabe von exit ändert Nichts.
Die Fehlermeldung wird wiederholt.

Die Kommandos, die help ausspuckt ergeben für mich keinen Nutzen.
Ist noch nicht mal ein sauberer Abbruch mit poweroff oder reboot möglich.
Dann doch wieder gewaltsam aus.
Das einzige Kommando, das in meinem Sinne erscheint, ist "continue" , was mich aber ebenfalls wieder zur Fehlermeldung zurück führt.

Vielleicht kannst du ja aus den andren help-Optionen etwas brauchbareres herauslesen.

Image

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

Posted: Tue Apr 22, 2025 4:42 pm
by 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

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

Posted: Wed Apr 23, 2025 1:19 am
by 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:
Image

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.

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

Posted: Wed Apr 23, 2025 3:04 pm
by gosia
Hallo loik,
loik wrote: Wed Apr 23, 2025 1:19 am 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

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

Posted: Thu Apr 24, 2025 3:40 am
by 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 :bawling:

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

Posted: Thu Apr 24, 2025 4:38 pm
by 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

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

Posted: Mon Apr 28, 2025 3:22 am
by 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 ? :wavehello: