Hello everyone, I have a dual boot system of Garuda Linux and Windows 10. I haven’t used Garuda for a few days, and when I boot into the system, I can’t log in and I’m taken to the Emergency shell. It seems that the system is unable to mount directories including /root.
Boot a garuda live session and post your garuda-inxi.
Have you ever looked in there?
You are in emergency mode. After logging in, type "journalctl -xb" to view system logs
Did you voluntarily participate in Windows Patchday yesterday? If so, then Windows probably updated its bootloader and kicked out Garuda.
2 Likes
Use last working snapshot or use live ISO, chroot, update.
4 Likes
Recently my Windows OS update itself on patchday, but I don’t think it related to the problem because I could still see the GRUB menu when booting.
I have chrooted into a live USB and this is the output of journalctl -xb :
[root@garuda-dr460nized-gaming /]# sudo journalctl -xb
No journal files were found.
Failed to get boot id: Function not implemented
And garuda-inxi:
[root@garuda-dr460nized-gaming /]# garuda-inxi
12System:
12Kernel 6.8.7-zen1-2-zen 12arch x86_64 12bits 64 12compiler N/A 12clocksource N/A
12Console N/A 12Distro Garuda 12base Arch Linux
12Machine:
12Message No machine data: try newer kernel. Is dmidecode installed? Try -M --dmidecode.
Can't use an undefined value as an ARRAY reference at /usr/sbin/inxi line 10852.
Garuda (2.6.26-1):
System install date: 2024-05-08
Last full system update: 2024-04-22 ↻
Is partially upgraded: No
Relevant software: snapper NetworkManager connman dracut
Windows dual boot: No/Undetected
/proc/ is not mounted. This is not a supported mode of operation. Please fix
your invocation environment to mount /proc/ and /sys/ properly. Proceeding anyway.
Your mileage may vary.
Running in chroot, ignoring command 'list-units'
Failed units:
It’s too late for that, you should have done that in emergency mode when you took the photo. But you can do this again if you are in emergency mode.
inxi cannot read dmi data and when I look at the mount errors and the btrfs error in your photo, it smells strongly of a killed file system…or hardware error.
Can you load a snapshot?
2 Likes
Be sure to disable the “fast startup” feature from your Windows installation.
Have you tried starting from a cold boot? (As opposed to a reboot.)
2 Likes
actually no. If chrooting works I doubt anything is lost. Seems to me like the boot image broke or something like that.
Could you try running garuda boot repair to (hopefully) regenerate the boot images?
At the moment I agree with you too.
To me it smells like Windows right from the start.
@Eragonvn:
Boot into your windows and check if fast startup is disabled.
Then you shut down Windows correctly: right-click on the windows button and select shutdown.
Turn on your laptop, go to BIOS and check if Fast Boot is disabled.
Then try to boot garuda. If that doesn’t work, boot live ISO and try “Garuda Boot Repair” from “Garuda Welcome” App.
1 Like
You should be chrooting into the installed system. What is your method for establishing the chroot? Try like this, from the live environment:
garuda-chroot -a
If your installation is not detected or you get any errors when you set the chroot, paste them into the thread so we can take a look.
Where is the “unrecognized compression value lz4” error coming from? Did you modify /etc/fstab? The default mount option is compress=zstd.
From inside the chroot, cat your fstab and paste it into the thread so we can take a look.
cat /etc/fstab
Assuming no issues with fstab, reinstalling the kernel may be in order.
pacman -Syu linux-zen
Be sure to paste the full output into the thread; there could be useful clues in there. Then regenerate the Grub config.
update-grub
Exit the chroot.
exit
Reboot and test again.
5 Likes
Why is it trying to mount sdb? Do you have an HDD/SDD caddy in your e6530 or is garuda installed on an external drive?
I have done all of those steps, and Garuda Boot Repair didn’t work
Also the suggestions from @BluishHumility?
Please answer all questions.
My Garuda root partition is on sdb. It a HDD and my Windows is on the SSD (sda)
I understand that, but your laptop only has 1 internal slot for an HDD/SSD and 1 slot for an optical drive.
What kind of drive is sdb and where is it connected?
There was an optical drive, but I have removed it to install the SSD via a caddy bay. sdb is the HDD.
So a caddy after all, but for the winSSD.
Try the suggestions from @BluishHumility.
1 Like
I chrooted using the command and it returned error as follow:
garuda-chroot -a
grub-probe: error: cannot find a GRUB drive for /dev/sdc2. Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sdc2. Check your device.map.
==> Mounting (Garuda_Linux) [/dev/sdb6]
--> mount: [/mnt]
--> mount: [/mnt/boot/efi]
--> mount: [/mnt/home]
mount: /mnt/home: wrong fs type, bad option, bad superblock on /dev/sdb6, missing codepage or helper program,
or other error.
dmesg(1) may have more information after failed mount system call.
--> mount: [/mnt/root]
mount: /mnt/root: wrong fs type, bad option, bad superblock on /dev/sdb6, missing codepage or helper program,
or other error.
dmesg(1) may have more information after failed mount system call.
--> mount: [/mnt/srv]
mount: /mnt/srv: wrong fs type, bad option, bad superblock on /dev/sdb6, missing codepage or helper program, o
r other error.
dmesg(1) may have more information after failed mount system call.
--> mount: [/mnt/var/cache]
mount: /mnt/var/cache: wrong fs type, bad option, bad superblock on /dev/sdb6, missing codepage or helper prog
ram, or other error.
dmesg(1) may have more information after failed mount system call.
--> mount: [/mnt/var/log]
mount: /mnt/var/log: wrong fs type, bad option, bad superblock on /dev/sdb6, missing codepage or helper progra
m, or other error.
dmesg(1) may have more information after failed mount system call.
--> mount: [/mnt/var/tmp]
mount: /mnt/var/tmp: wrong fs type, bad option, bad superblock on /dev/sdb6, missing codepage or helper progra
m, or other error.
dmesg(1) may have more information after failed mount system call.
I have modified the fstab earlier to change the btrfs file system compression algorithm to lz4 from zstd
lz4 is not a supported compression algorithm for Btrfs. Change it back to zstd, or use another supported compression algorithm like lzo or zlib. You can edit /etc/fstab from the live environment and reboot, that should resolve your issue.
5 Likes
Do I have to chroot to my existing Garuda system to edit the /etc/fstab ?