Stuck In Emergency Mode Limbo

Hi. I've been using Garuda (KDE Dr460nized Edition specifically) for about five months, but I recently encountered a problem where my system boots directly into emergency mode, with no successful way to exit it.

inxi results:

System:
	Kernel: 5.15.10-zen1-1-zen x86_64
		bits: 64
	compiler: gcc
		v: 11.1.0
	Console: tty 1
	Distro: Garuda Linux
		base: Arch Linux
Machine:
	Type: Desktop
	System: ASUS
	product: N/A
	v: N/A
	serial: N/A
	Mobo: ASUSTeK
	model: ROG STRIX B450-F GAMING
		v: Rev 1.xx
		serial: <filter>
	UEFI: American Megatrends
		v: 0901
		date: 11/02/2020
Logical:
	Message: No logical block device data found.
	Device-1: luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a
		type: LUKS
		dm: dm-0
		size: <...>
RAID:
	Message: No RAID data found.
Drives:
	Local storage:
		total: <...>
		used: <...>
	ID-1: /dev/sda
		vendor: <...>
		model: <...>
		size: <...>
		speed: <...>
		type: SSD
		serial: <filter>
		rev: 2B6Q
		scheme: GPT
	ID-2: /dev/sdb
		vendor: <...>
		model: <...>
		size: <...>
		speed: <...>
		type: HDD
		rpm: 5400
		serial: <filter>
		rev: 0A80
		scheme: GPT
Partition:
	ID-1: /
		size: <...>
		used: <...>
		fs: btrfs
		dev: /dev/dm-0
		mapped: luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a
	ID-2: /boot/efi
		size: <...>
		used: <...>
		fs: vfat
		dev: /dev/sda1
	ID-3: /home
		size: <...>
		used: <...>
		fs: btrfs
		dev: /dev/dm-0
		mapped: luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a
	ID-4: /var/log
		size: <...>
		used: <...>
		fs: btrfs
		dev: /dev/dm-0
		mapped: luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a
	ID-5: /var/tmp
		size: <...>
		used: <...>
		fs: btrfs
		dev: /dev/dm-0
		mapped: luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a
Info:
	Processes: 269
	Uptime: <...>
	wakeups: 0
	Memory: <...>
		used: <...>
	Init: systemd
		v: 249
	Compilers:
		gcc: 11.1.0
	Packages:
		pacman: 1793
	Shell: Bash
		v: 5.1.12
		running-in: tty 1
		inxi: 3.3.11


# COPIED BY HAND, skipped some information when obviously irrelevant '<...>'.

cat /etc/fstab results:

<file system>	<mount point>	<type>	<options>	<dump>	<pass>

UUID=26CD-D220	/boot/efi	vfat	umask=0077	0	2
/dev/mapper/luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a	/	btrfs	subvol=@,noatime,space_cache,autodefrag,compress=zstd,sdd	0	0
/dev/mapper/luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a	/home	btrfs	subvol=@home,noatime,space_cache,autodefrag,compress=zstd,sdd	0	0
/dev/mapper/luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a	/root	btrfs	subvol=@root,noatime,space_cache,autodefrag,compress=zstd,sdd	0	0
/dev/mapper/luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a	/srv	btrfs	subvol=@srv,noatime,space_cache,autodefrag,compress=zstd,sdd	0	0
/dev/mapper/luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a	/var/cache	btrfs	subvol=@cache,noatime,space_cache,autodefrag,compress=zstd,sdd	0	0
/dev/mapper/luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a	/var/log	btrfs	subvol=@log,noatime,space_cache,autodefrag,compress=zstd,sdd	0	0
/dev/mapper/luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a	/var/tmp	btrfs	subvol=@tmp,noatime,space_cache,autodefrag,compress=zstd,sdd	0	0

/dev/sdb1	/media/sdb1	btrfs	defaults	0	0

blkid results:

/dev/sdb:
	PTUUID="d7cb8ea8-d8b5-8041-82fe-de7617879617"
	PTTYPE="gpt"
/dev/mapper/luks-44fb6bb4-6a73-45cb-b2ed-17958221c96a:
	UUID="dd885b99-d260-4c4e-b7a2-c0a8ee949b9c"
	UUID_SUB="25b702a7-c190-411a-ac34-5ace9149d7f7"
	BLOCK_SIZE="4096"
	TYPE="btrfs"
/dev/sda2:
	UUID="44fb6bb4-6a73-45cb-b2ed-17958221c96a"
	TYPE="crypto_LUKS"
	PARTLABEL="root"
	PARTUUID="f11758a6-c1af-e542-a42f-3602229f1d03"
/dev/sda1:
	LABEL_FATBOOT="NO_LABEL"
	LABEL="NO_LABEL"
	UUID="26CD-D220"
	BLOCK_SIZE="512"
	TYPE="vfat"
	PARTUUID="bcca63fc-64f8-da40-966d-544be7a76f8b"
/dev/zram0:
	LABEL="zram0"
	UUID="db5d24a0-57bc-4ba3-8311-c165e43cb770"
	TYPE="swap"

Navigating through bash with cd , I can access all my files and everything seems to be fine on that front.

Using mount -a I got:
mount: /media/sdb1: special device /dev/sdb1 does not exist.
'/dev/sdb' is an empty disk that I was previously trying to install Gentoo on, which is probably where things got screwed up. I remember using chroot and mkdir /dev/sdb1/ but none of my installation attempts went past choosing the keymap before I shut everything off.

Using fsck I got:

fsck from util-linux 2.37.2
fsck.fat (2021-31-01)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
	65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
[123?q]? 3
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
[12?q]? 2
/dev/sda1: 6 files, 1412/524252 clusters

I chose 'No action' both times because I didn't want to risk making things worse.

Compared to pictures I've seen online, my fstab doesn't look right, but that might have to do with the fact that I use encryption on my main disk.
My first instinct would be to remove /dev/sdb1 from fstab but I don't know how to do that as vim, nano and gedit (the text editors I see recommended online) don't seem to work, probably because they were never installed in the first place).

Any help would be appreciated.

Hi there, welcome.
Maybe you could edit the /etc/fstab from a live USB and remove that line.
If not working, you could chroot into /dev/sda2 and reinstall the GRUB in /dev/sda1

4 Likes

May be filesystem corruption. Boot via liveusb and check filesystem (btrfs check). And check the SMART of your drive.

4 Likes

Garuda uses micro instead of nano, open /etc/fstab using micro. Then comment out the line relating to the partition that is causing errors. If the drive is a physically separate drive you may even want to disconnect the drive from your system before you reboot.

4 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.