Manjaro booted nicht nach Freeze

[eltono91]

Moin zusammen,

vorweg: Ein Backup per Back in Time von /home und /root ist vorhanden. Weiß aber nicht genau wie ich das unter einer Live Umgebung einspielen könnte. Zudem Dual-Boot aus Manjaro und Windows 11.

Wollte gestern mein Manjaro updaten und dabei ist das System eingefrohren. Seit dem bootet der Rechner nur noch ins Grub Menü aber nicht mehr ins Manjaro. Ich bekomme folge Meldung:

Fehler: Datei >>/boot/vmlinuz-6.1-x86_64<< nicht gefunden
Fehler: Sie müssen zuerst den Kernel laden.

Beliebige Taste drücken, um fortzusetzen...

Im Grub-Menü werden mir dann folgende Kernel angeboten (machen aber alle keinen Unterschied):

Kernel: 6.1.85-1-MANJARO x64
Kernel: 6.1.85-1-MANJARO x64 - fallback initramfs
Kernel: 4.19.307-1-MANJARO x64
Kernel: 4.19.307-1-MANJARO x64 - fallback initramf

Ich habe daraufhin erstmal eine Live-USB-Stick von Manjaro erstellt und die Google Suche angeworfen. Da gibt es auch viel. War allerdings nicht von Erfolg gekröhnt. Hier wird erstermal

manjaro-chroot -a

empfohlen. Hier geht das Problem allerdings schon los. Ausgabe sieht wie folgt aus:

manjaro-chroot -a                                       1 ✘  7s 
grub-probe: error: cannot find a GRUB drive for /dev/sda1.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sda1.  Check your device.map.
==> Mounting (ManjaroLinux) [/dev/nvme0n1p7]
 --> mount: [/mnt]
 --> mount: [/mnt/boot/efi]
 --> mount: [/mnt/home]
chroot: failed to run command '/bin/bash': Input/output error
 --> umount: [/mnt/home]
 --> umount: [/mnt/boot/efi]
 --> umount: [/mnt]

Manuell zu mounten bringt auch keinen Erfolg.

mount /dev/sdyC /mnt
mount: /mnt: fsconfig system call failed: /dev/sdyC: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.

Alle weiteren Versuche Grub zu updaten etc. haben dann nicht funktioniert.

Falls noch wichtig fdisk-l

Spoiler: fdisk-l

sudo fdisk -l
Disk /dev/nvme0n1: 1,86 TiB, 2048408248320 bytes, 4000797360 sectors
Disk model: KINGSTON SKC3000D2048G               
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 17F17A3C-0CF2-D74B-9283-E3CAA3099BD8

Device              Start        End    Sectors    Size Type
/dev/nvme0n1p1       2048     206847     204800    100M EFI System
/dev/nvme0n1p2     206848     239615      32768     16M Microsoft reserved
/dev/nvme0n1p3     239616 1716959231 1716719616  818,6G Microsoft basic data
/dev/nvme0n1p4 1716959232 1718271999    1312768    641M Windows recovery environment
/dev/nvme0n1p5 1718272000 1719320575    1048576    512M EFI System
/dev/nvme0n1p6 1719320576 1750571007   31250432   14,9G Linux swap
/dev/nvme0n1p7 1750571008 1875570687  124999680   59,6G Linux filesystem
/dev/nvme0n1p8 1875570688 4000797326 2125226639 1013,4G Linux filesystem


Disk /dev/sda: 115,5 GiB, 124017180672 bytes, 242221056 sectors
Disk model: DataTraveler 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot   Start     End Sectors  Size Id Type
/dev/sda1  *         64 7672335 7672272  3,7G  0 Empty
/dev/sda2       7672336 7680527    8192    4M ef EFI (FAT-12/16/32)


Disk /dev/loop0: 151,17 MiB, 158515200 bytes, 309600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 1,05 GiB, 1129431040 bytes, 2205920 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop2: 1,56 GiB, 1674661888 bytes, 3270824 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop3: 791,93 MiB, 830402560 bytes, 1621880 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Tja daher nun die Frage was tun? Über Terminal bin ich bisher nicht weiter gekommen. Kann man Manjaro vom Live USB Stick neu installieren und dann per Back In Time das Backup wieder einspielen? /home müsste eigentlich unberüht bleiben, da eigene Partition.

Gruß und Danke

 

[madmax2010]

wohin hast du deine EFI Partition gemounted?

mount /dev/XXXXXXX /boot/EFI
grub-install --target=x86_64-efi --efi-directory=/boot/EFI --bootloader-id=GRUB --recheck
grub-mkconfig -o boot/grub/grub.cfg

sollte da eigentlich tun

Aber erst wenn chroot tut..
mal /dev/nvme0n1p7 nach /mnt gemounted und dann arch-chroot /mnt probiert?

 

[eltono91]

Moin Madmax,

hatte EFI wie folge gemounted:

mount /dev/nvme0n1p5 /boot/EFI

Ergebnis war dann:

mount: /boot/EFI: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.

 

[madmax2010]

bist aber im chroot?
Wenn ja, leg den PFad mal an
sudo mkdir /boot/EFI

 

[Malaclypse17]

Ich weiß nicht ob es in diesem Fall case sensetive ist, aber der der Pfad müsste eher /boot/efi/ heißen.

 

[eltono91]

@madmax2010 Da kam erstmal folgendes:

sudo mkdir /boot/EFI
mkdir: cannot create directory ‘/boot/EFI’: File exists

hab jetzt dann nochmal

manjaro-chroot -a

gemacht. Ergebnis wie im Eingangspost

mal /dev/nvme0n1p7 nach /mnt gemounted und dann arch-chroot /mnt probiert?

Da sagt er mir er kennt den Befehl nicht

sudo -i
[manjaro-gnome ~]# mount /dev/nvme0n1p7 /mnt
[manjaro-gnome ~]# arch-chroot
-bash: arch-chroot: command not found

 

[madmax2010]

sollte da drin sein

Da sagt er mir er kennt den Befehl nicht

https://archlinux.org/packages/extra/any/arch-install-scripts/
einmal kurz in der Live-Umgebung installieren

 

[eltono91]

Kommt leider mit einer Fehlermeldung: Failed to prepare transaction. Target not found: arch-install-scripts

 

[0x7c9aa894]

Hattest Du irgendwelche kernel module, o.ä. aus AUR installiert?

 

[eltono91]

Nicht bewusst

 

[0x7c9aa894]

Anmerkung:

Ist doch klar, daß es kein "arch-chroot" gibt, wenn dann müßte es "manjaro-chroot" sein.

Ich habe nach dem AUR gefragt, da Arch einige Dinge anders mancht als Manjaro, und die AUR Pakete nicht angepasst sind. Eine Installation aus AUR kann dir leicht das System zerschießen, muß aber nicht sein.

Ich würde vorschlagen eine Befehl nach dem anderen auszuprobieren:
Also zuerst

sudo mount /dev/nvme0n1p7 /mnt
ls -l /mnt

das ls um zu checken ob alles geklappt hat und ob das EFI Verzeichnis auch da ist oder nicht.

 

[eltono91]

sudo mount /dev/nvme0n1p7 /mnt
ls -l /mnt
total 112
lrwxrwxrwx   1 root root     7  8. Apr 17:26 bin -> usr/bin
drwxr-xr-x   5 root root  4096 20. Mai 20:09 boot
-rw-r--r--   1 root root 23205 16. Mär 2023  desktopfs-pkgs.txt
drwxr-xr-x   2 root root  4096  5. Apr 2023  dev
drwxr-xr-x 129 root root 12288 20. Mai 20:09 etc
drwxr-xr-x   2 root root  4096  5. Apr 2023  home
lrwxrwxrwx   1 root root     7  8. Apr 17:26 lib -> usr/lib
lrwxrwxrwx   1 root root     7  8. Apr 17:26 lib64 -> usr/lib
drwx------   2 root root 16384  5. Apr 2023  lost+found
drwxr-xr-x   4 root root  4096 13. Mai 10:19 mnt
drwxr-xr-x   6 root root  4096 15. Apr 2023  opt
drwxr-xr-x   2 root root  4096  5. Apr 2023  proc
drwxr-x---   8 root root  4096  7. Feb 16:21 root
-rw-r--r--   1 root root  5273 16. Mär 2023  rootfs-pkgs.txt
drwxr-xr-x   2 root root  4096  5. Apr 2023  run
lrwxrwxrwx   1 root root     7  8. Apr 17:26 sbin -> usr/bin
drwxr-xr-x   4 root root  4096 16. Mär 2023  srv
drwxr-xr-x   2 root root  4096  5. Apr 2023  sys
drwxrwxrwt   2 root root  4096  5. Apr 2023  tmp
drwxr-xr-x   9 root root  4096 20. Mai 20:09 usr
drwxr-xr-x  13 root root  4096 20. Mai 20:09 var

Das erhalte ich als Antwort

 

[0x7c9aa894]

Das sieht doch schon mal gut aus. Ist ein EFI Verzeichnis unter boot?

ls -l /mnt/boot

 

[eltono91]

ls -l /mnt/boot
total 100
-rw-r--r-- 1 root root 81920 21. Feb 16:11 amd-ucode.img
drwxr-xr-x 2 root root  4096  5. Apr 2023  efi
drwxr-xr-x 6 root root  4096 19. Apr 07:02 grub
-rw-r--r-- 1 root root    23 23. Feb 16:34 linux419-x86_64.kver
-rw-r--r-- 1 root root    21 10. Apr 20:50 linux61-x86_64.kver
drwxr-xr-x 2 root root  4096 20. Jan 12:06 memtest86+

Scheint so

 

[0x7c9aa894]

OK. Also können wir versuchen die EFI Partition zu mounten:

sudo mount /dev/nvme0n1p5 /boot/efi

Ergänzung (21. Mai 2024)

Sorry das war falsch!

Ergänzung (21. Mai 2024)

sudo mount /dev/nvme0n1p5 /mnt/boot/efi

 

[eltono91]

sudo mount /dev/nvme0n1p5 /boot/efi
mount: /boot/efi: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.

Funktioniert leider nicht.

 

[0x7c9aa894]

Mit df -h kannst du checken ob alles OK ist

 

[Donnerkind]

Ich verstehe nicht ganz, wie du darauf kommst, die EFI-Partition wäre das Problem, @madmax2010. Denn erstens wurde sie laut Ausgabe von manjaro-chroot bereits gemountet, zweitens:

chroot: failed to run command '/bin/bash': Input/output error

sieht das da nach Hardwaredefekt aus. Wenn die Datei lediglich nicht da wäre, bekäme man eher „File not found“.

Manuell zu mounten bringt auch keinen Erfolg.

War das „sdyC“ eine Anonymisierung oder hast du das so eingegeben? Wenn letzteres, ist es klar, dass das die Fehlermeldung wirft.

Funktioniert leider nicht.

Weil der Mountpfad nicht richtig war. Es hätte vermutlich /mnt/boot/efi sein müssen. Zur Erklärung: du willst dein System unterhalb von /mnt betreten, also mountest du die Root-Partition bei /mnt und alles antere muss unterhalb von /mnt erscheinen.

 

[0x7c9aa894]

Weil der Mountpfad nicht richtig war. Es hätte vermutlich /mnt/boot/efi sein müssen.

richtig gesehen, ich hatte mich ja verbessert.

Ergänzung (21. Mai 2024)

Also wie gesagt:

sudo mount /dev/nvme0n1p5 /mnt/boot/efi
ls -l /mnt/boot/efi
df -h

Ergänzung (21. Mai 2024)

Es kann sein, daß du bei dem ls ein sudo davor brauchst.

 

[eltono91]

@Donnerkind
Einen Hardware Defekt hätte ich erstmal ausgeschlossen, weil ich ja noch Problemlos in Windows unterwegs sein kann und es unmittelbar mit dem Update gestern zusammen hängt

@0x7c9aa894
Ergebnis ist auch mit dem neuen Pfad das selbe:

sudo mount /dev/nvme0n1p5 mnt/boot/efi
mount: mnt/boot/efi: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.

Ergebnis von df-h

df -h                                                        INT ✘
Filesystem      Size  Used Avail Use% Mounted on
dev              14G     0   14G   0% /dev
run              14G  107M   14G   1% /run
efivarfs        128K   22K  102K  18% /sys/firmware/efi/efivars
/dev/sda        3,7G  3,7G     0 100% /run/miso/bootmnt
cowspace        256M     0  256M   0% /run/miso/cowspace
overlay_root     21G  476M   21G   3% /run/miso/overlay_root
/dev/loop0      152M  152M     0 100% /run/miso/sfs/livefs
/dev/loop1      1,1G  1,1G     0 100% /run/miso/sfs/mhwdfs
/dev/loop2      1,6G  1,6G     0 100% /run/miso/sfs/desktopfs
/dev/loop3      792M  792M     0 100% /run/miso/sfs/rootfs
overlay          21G  476M   21G   3% /
tmpfs            14G     0   14G   0% /dev/shm
tmpfs            14G  580K   14G   1% /tmp
tmpfs            14G  2,8M   14G   1% /etc/pacman.d/gnupg
tmpfs           2,8G  184K  2,8G   1% /run/user/1000
/dev/nvme0n1p7   59G   29G   27G  52% /mnt

Könnte ich nicht über den Manjaro Installer die EFI Partition (/boot/efi) formatieren & neu installieren, die Manjaro Partition (/) formatieren und neu installieren, die /home Partition beibehalten und mit /home labeln? Sprich Manjaro neu installieren, Home beibehalten und anschließend mein Back in Time Backup für "/" einspielen? Quasi so?