Changing /home and Emergency shell

I recently installed an SSD with a hardware RAID 1 configuration in my computer running Fedora 40. My purpose is to be my /home storage, so (hopefully) prevent data loss.
I copied all my data over, and edited /etc/fstab (both manually and using Gnome Disks, and both using UUID and device path /dev/sdb). When I rebooted, I was thrown into an emergency shell. I can login to the eshell and ‘mount /dev/sdb /home’ and then ‘exit’ to finish booting. I did get a warning to do ‘systemctl daemon-reload’, which I did, both in the eshell and when logged into my user account (even with ‘sudo’). Yet, I still get thrown into the eshell when I reboot.
I have not found anything else that seems to need to be edited or run to update the mount points.

The system logs only show ‘failed to mount home/mount’ , but they do mention to run ‘systemctl status home.mount’, which (from GUI) says all is as it should be; /etc/fstab generated, active (mounted), etc. I do not see a cause as for why, even before the line ‘Mounting home.mount - /home’.

Any ideas?

If your fstab entry is correct, you should be able to mount /home with just mount /home. When you use the mount /dev/sdb /home form, that bypasses the fstab lookup.

2 Likes

I haven’t tried it, but the more important point is the fact Fedora won’t finish booting without my manually mounting the home directory.

You can add nofail to the list of options for the fstab entry to prevent your system from dropping to an emergency shell if that mount fails. Be sure to set root’s password before doing that though or else you may find that you won’t be able to log in with any user. (If the entry for /home still fails, but booting continues, you won’t be able to log in with any “normal” accounts that have home directories under /home.) Also, you’ll probably have to switch to a VT to sign in with root (e.g. CTRL+ALT+F3 for VT 3).

1 Like

Well, nofail did not work. It hung on the error (which is somewhat progress) that it failed to mount.

I did also try the mount /home, however it said it did not exist. I verified the entry was still valid in /etc/fstab, and the /home folder and the /dev/sdb entries existed. Also, again, mount /dev/sdb /home still works perfectly.

If the mount /home fails then it is likely your fstab has an error.

Please show the contents of your /etc/fstab’ and the output of lsblk -f`.

/etc/fstab

Created by anaconda on Wed May 15 21:36:48 2024

Accessible filesystems, by reference, are maintained under ‘/dev/disk/’.

See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.

After editing this file, run ‘systemctl daemon-reload’ to update systemd

units generated from this file.

UUID=562482c9-df68-477e-808f-4a8480c67b45 / btrfs subvol=root,compress=zstd:1 0 0
UUID=afe1487d-84d9-4435-8270-dcf9842af2c0 /boot ext4 defaults 1 2

/dev/sdb /home btrfs subvol=home,compress=zstd:1,x-gvfs-name=home 0 0
/dev/disk/by-uuid/e1b411c8-0bf7-4875-8abc-fad6b49d910a /run/media/Tera auto nosuid,nodev,nofail,x-gvfs-show 0 0

NAME   FSTYPE FSVER LABEL         UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                   
├─sda1                                                                                
├─sda2 ext4   1.0                 afe1487d-84d9-4435-8270-dcf9842af2c0  487.7M    43% /boot
└─sda3 btrfs        fedora_fedora 562482c9-df68-477e-808f-4a8480c67b45  416.9G     6% /
sdb    btrfs        Home          804eb7f5-a336-4f4b-9734-173f93ca53a7  342.9G    23% /home
sdc                                                                                   
└─sdc1 btrfs        Downloads     e1b411c8-0bf7-4875-8abc-fad6b49d910a    833G    10% /run/media/Tera
zram0                                                                                 [SWAP]

Jun 14 08:08:03 feddev40 mount[679]: mount: /home: fsconfig system call failed: No such file or directory.
Jun 14 08:08:03 feddev40 mount[679]: dmesg(1) may have more information after failed mount system call.
Jun 14 08:08:03 feddev40 systemd[1]: home.mount: Mount process exited, code=exited, status=32/n/a

When I login tot he eshell and issue mount /dev/sdb /home the logs show:

Jun 14 08:08:04 feddev40 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 >
Jun 14 08:08:04 feddev40 systemd[1]: Received SIGRTMIN+21 from PID 410 (plymouthd).
Jun 14 08:08:04 feddev40 systemd[1]: Received SIGRTMIN+21 from PID 410 (plymouthd).
Jun 14 08:08:09 feddev40 systemd[1]: systemd-rfkill.service: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ The unit systemd-rfkill.service has successfully entered the ‘dead’ state.
Jun 14 08:08:09 feddev40 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 m>
Jun 14 08:14:25 feddev40 kernel: BTRFS: device label Home devid 1 transid 3832 /dev/sdb scanned by mount (852)
Jun 14 08:14:25 feddev40 kernel: BTRFS info (device sdb): first mount of filesystem 804eb7f5-a336-4f4b-9734-173f93ca53a7
Jun 14 08:14:25 feddev40 kernel: BTRFS info (device sdb): using crc32c (crc32c-intel) checksum algorithm
Jun 14 08:14:25 feddev40 kernel: BTRFS info (device sdb): using free-space-tree
Jun 14 08:14:25 feddev40 systemd[1]: Reloading requested from client PID 817 (‘systemd-sulogin’) (unit emergency.service)…
Jun 14 08:14:25 feddev40 systemd[1]: Reloading…
Jun 14 08:14:25 feddev40 systemd[1]: Reloading finished in 307 ms.
Jun 14 08:14:25 feddev40 audit: BPF prog-id=45 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=46 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=39 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=40 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=47 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=33 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=48 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=49 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=34 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=35 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=50 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=44 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=51 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=41 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=52 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=53 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=42 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=43 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=54 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=36 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=55 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=56 op=LOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=37 op=UNLOAD
Jun 14 08:14:25 feddev40 audit: BPF prog-id=38 op=UNLOAD
Jun 14 08:14:25 feddev40 systemd[1]: emergency.service: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ The unit emergency.service has successfully entered the ‘dead’ state.
Jun 14 08:14:25 feddev40 systemd[1]: Stopped emergency.service - Emergency Shell.

What do you get when you run : cat /proc/cmdline :thinking:

Also did you run grub2-mkconfig -o /boot/grub2/grub.cfg :thinking:

BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.8.11-300.fc40.x86_64 root=UUID=562482c9-df68-477e-808f-4a8480c67b45 ro rootflags=subvol=root rhgb quiet

As I had not done anything to alter the boot device, kernel, init image, etc, I had not. However, I just did, rebooting now.
Edit: No change post re-making Grub config.

The more important point, as was already mentioned, is that you modified the disk arrangement for /home. This requires that the fstab entry is correct in order for the system to boot properly and failure to test that the fstab entry works properly with the new disk arrangement seems the cause of the boot issues.

If you test the proper mounting within the emergency shell using mount -a or mount /home and it fails then you should fix the fstab entry.

As mentioned by George, the use of the device name bypasses the fstab entry.

Most fstab entries contain a UUID for mounting /home and you should verify that matches the current /home UUID before dismissing the suggestion.

I see that you modified the entry in fstab to use /dev/sdb instead of the btrfs UUID of 804eb7f5-a336-4f4b-9734-173f93ca53a7.

I also note that you have the entry in fstab showing the subvol ‘home’ and the file system at /dev/sdb is the root volume for that file system.

You said you created a raid 1 for /home, but I do not see the raid devices in what you posted. Did you try to leave the /home on sda3 and then mirror that subvolume to /dev/sdb ?
Exactly how was the raid created and what are its members.

Odd its sdb not sdb1 - does that mean there is no GPT on the sdb disk?
Systemd/udev maybe confused because of the missing GPT.

I initially put it in as the UUID, but I tried the device path as the alternate option. I have also used Gnome Disks to edit the fstab entry.

The RAID 1 is a hardware adapter. It is a SATA → dual M2 adapter, from StarTech. Thus, it appears as a normal SATA disk.

On sdb vs sdb1, I did not partition it before setting it up; I didn’t think about it prior. It shouldn’t matter, but it is worth considering. I’ll see what I can do (nondestructively).

I see that you set subvol=home for your home Btrfs filesystem, but you did not set a subvol name for your downloads Btrfs filesystem. Is your home filesystem in a subvolume? With ZFS, it is possible (though not recommend) to use the top-level filesystem, but I don’t know if Btrfs allows that.

Entering mount while your /home is successfully mounted might reveal what mount options are required.

The issue is resolved.
I changed the label to home (lower case), synced and rebooted, and the issue is gone.
Despite home.mount being given everything else, it was using the label during boot, which was failing.

Thank you all who helped point to the issue in /etc/fstab, as that was almost exactly where the issue was.

4 Likes