System Not Booting After Update and Forced Shutdown - dropped into an emergency shell

Hello,

I realize there are similar topics here, and I have checked one too many of them in the last 2 days.

I am using Manjaro (Linux manjaro-gnome 6.9.2-1-MANJARO).
I was updating my system 2 days ago while I was working on another machine, I then noticed before the update finished, the screen has frozen and a button was flashing. I couldn’t turn it off, so I had to force shut down through the physical button.

When I booted again, I was welcomed to my grub boot menu where I had Manjaro and my Win 10 installation. I tried to boot from the newer kernel of Manjaro, and all the others I have installed:

mhwd-kernel -li && mhwd -l -li:
Currently running: 6.9.2-1-MANJARO (linux69)
The following kernels are installed in your system:
   * linux419
   * linux510
   * linux515
   * linux516
   * linux65
   * linux66

I have gone ahead and booted a live ISO on USB (which I am posting from), and run a few commands as I suspected the system crashed before update finished.

manjaro-chroot -a # into the installation
pacman-mirrors --fasttrack 5
pacman -Syyu
grub-update

I booted again and that’s when I got

ERROR: Failed to mount 'UUID=c0383bcd-8410-16ce-b585-7f64336c6954' on real root
You are now being dropped into an erergency shell.
sh: can't access tty: job control turned off

This is the output running blkid:

/dev/loop1: BLOCK_SIZE="262144" TYPE="squashfs"
/dev/nvme0n1p7: LABEL="WinVault" BLOCK_SIZE="512" UUID="3DAC65666A012E3E" TYPE="ntfs" PARTLABEL="WinVault" PARTUUID="e59b6641-7c44-42b7-a64d-e9c3c6b7e54f"
/dev/nvme0n1p5: LABEL="Manjaro /home" UUID="5723eae0-0cf3-4eed-a3c1-08c8626fb13c" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Manjaro home" PARTUUID="a2ad136a-d965-9347-9326-df3747e8cb2c"
/dev/nvme0n1p3: UUID="43f6478e-e8e1-4999-a161-8972c6d2cdef" TYPE="swap" PARTLABEL="Swap" PARTUUID="95aa5535-4291-5445-a613-cac6e87fed9a"
/dev/nvme0n1p1: LABEL="Vault" UUID="35e104c6-e6de-4d57-b6b6-006b6dfd695d" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Vault" PARTUUID="e2db2ef4-bd08-4dff-9335-faa9b88deb0b"
/dev/nvme0n1p6: LABEL="Vaultx" UUID="a54f37c8-8929-4914-a77a-4ad9a927ff7b" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Vaultx" PARTUUID="12b545d5-0674-47a8-81cb-b491afb52575"
/dev/nvme0n1p4: LABEL="Manjaro OS" UUID="c0383bcd-8410-40ce-b505-7f64336c6954" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Manjaro OS" PARTUUID="d377a77f-f979-314a-8168-134c0e3d947e"
/dev/nvme0n1p2: LABEL_FATBOOT="EFI SYSTEM" LABEL="EFI SYSTEM" UUID="041B-7283" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="boot" PARTUUID="2d5ca045-0497-8142-ba7e-5257b773daea"
/dev/loop2: BLOCK_SIZE="262144" TYPE="squashfs"
/dev/loop0: BLOCK_SIZE="262144" TYPE="squashfs"
/dev/mapper/ventoy: BLOCK_SIZE="2048" UUID="2024-05-29-17-37-21-00" LABEL="MANJARO_GNOME_2401" TYPE="iso9660" PTTYPE="dos"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="VTOYEFI" LABEL="VTOYEFI" UUID="223C-F3F8" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="VTOYEFI" PARTUUID="cc7fed56-d30b-8691-03fd-abb8408ba539"
/dev/sda1: LABEL="Ventoy" UUID="DFA4-2C91" BLOCK_SIZE="512" TYPE="exfat" PARTLABEL="Ventoy" PARTUUID="c3db6c4e-9baa-df71-8eaf-f4117b40573f"
/dev/loop3: BLOCK_SIZE="262144" TYPE="squashfs"

This is the output running lsblk (relevant part here being nvme0n1):

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0 152.4M  1 loop /run/miso/sfs/livefs
loop1         7:1    0   1.1G  1 loop /run/miso/sfs/mhwdfs
loop2         7:2    0   1.6G  1 loop /run/miso/sfs/desktopfs
loop3         7:3    0 810.9M  1 loop /run/miso/sfs/rootfs
sda           8:0    1  28.8G  0 disk 
├─sda1        8:1    1  28.8G  0 part 
│ └─ventoy  254:0    0   3.7G  1 dm   /run/miso/bootmnt
└─sda2        8:2    1    32M  0 part /run/media/manjaro/VTOYEFI
nvme0n1     259:0    0   1.8T  0 disk 
├─nvme0n1p1 259:1    0 195.5G  0 part 
├─nvme0n1p2 259:2    0     1G  0 part /mnt/boot/efi
├─nvme0n1p3 259:3    0   8.9G  0 part 
├─nvme0n1p4 259:4    0 387.5G  0 part /mnt
│                                     /mnt
├─nvme0n1p5 259:5    0 426.4G  0 part /mnt/home
├─nvme0n1p6 259:6    0 421.8G  0 part 
└─nvme0n1p7 259:7    0 421.8G  0 part /mnt/mnt

My Manjaro OS exists on nvme0n1p4, and boot on nvme0n1p2. As also shown below in image:

After I updated the Grub, I couldn’t even see Windows anymore in the boot menu, tried to add it manually via adding:

menuentry "Windows 10" {
    insmod part_gpt
    insmod ntfs
    search --no-floppy --set=root --fs-uuid 3DAC65666A012E3E
    chainloader +1
}

to

`vim  /etc/grub.d/40_custom`

But it didn’t work.
Just to clarify, when the machine froze at the update and I forced shut it, I could still see windows on the boot menu, and I used it as well, but after my commands (sys update, grub update, etc), I couldn’t see it anymore, nor did it fix my issue.

I am a bit exhausted over this and would appreciate any help. Please let me know if you need anymore info!

P.S: I also need to mention the fact that I update my system often. I have updated it about a week since the last update when it crashed.

UPDATE:

  1. I can now see Windows 10 on boot menu, but once I click on it, I get error: 1nvalid EFI file path. Press any key to continue.. on the screen and immediately get returned to boot menu.
  2. Another thing I noticed when clicking on any of the kernels available for manjaro at boot, there’s this message on the screen:
[0.1025231] Spectre V2 : VARNING: Umprivileged eBrF is enabled with eIBRS on,
data leaks possible via Spectre v2 BHB attackst
:: ruming early hook Cudev]
:* running hook [udeu]
:: Triggering uevents...
:: runing hook Ckeynap]
: Loading keymap...done.
:: ruming hook plynouth]

After this, the loading screen loads with 3 dots, then I get the error message I mentioned early and in title.

UPDATE 2: From BIOS, I can set windows as first in boot menu and it boots successfully. Seems issue is purely with my Manjaro.

I just noticed that this ID here (blkid output) seems to be incomplete…not sure if it’s supposed to be like that…or is relevant.

Anyone? :frowning:

It’s doesn’t seem to be an actual partition, it’s the image of gnome on the ventoy drive.

That’s not a type of UUID I’ve ever seen, it’s a datetime. Perhaps ventoy uses the creation or modification time of the iso.

Those UUIDs are similar but don’t match.

4 Likes

Well spotted :+1:

3 Likes

I am sorry, I really have no idea how or why these got to be different when I posted, but they actually are not. I just verified when I double checked. I got the one in

ERROR: Failed to mount 'UUID=c0383bcd-8410-16ce-b585-7f64336c6954' on real root

Wrong. In reality it matches the one in blkid output! I just entered it incorrectly on my post.
I think this is not the issue at hand it seems. :frowning:
Sorry for the trouble, @dmt @omano!

1 Like