Home not mounted after update from Fedora 39 to Fedora 40 prerelease

Problem: Boot partition not mounted after update to Fedora 40 prerelease

Cause

I have dualboot (fedora + ubuntu) where fedora uses btrfs with separate subvolume for /home partition. After update to fedora 40, It seems systemd is failing to load fstab content. See dmesg log:

[    6.258830] systemd[1]: Successfully loaded SELinux policy in 94.288ms.
[    6.291464] systemd[1]: Relabeled /dev, /dev/shm, /run, /sys/fs/cgroup in 26.711ms.
[    6.295352] systemd[1]: systemd 255.4-1.fc40 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[    6.295359] systemd[1]: Detected architecture x86-64.
[    6.665665] systemd[1]: bpf-lsm: LSM BPF program attached
[    6.860263] audit: type=1400 audit(1713191078.472:4): avc:  denied  { read } for  pid=553 comm="systemd-fstab-g" name="fstab" dev="nvme0n1p3" ino=3161532 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
[    6.868581] (sd-exec-[541]: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.

Content of my fstab file:

UUID=f385bf73-0205-4bca-89ba-11c73c45e07d /                       btrfs   subvol=root,compress=zstd:1 0 0
UUID=2c169925-243d-4195-b9f6-bf6d85b39b69 /boot                   ext4    defaults        1 2
UUID=5708-D701                            /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=f385bf73-0205-4bca-89ba-11c73c45e07d /home                   btrfs   subvol=home,compress=zstd:1,errors=remount-ro 0 0


Related Issues

Bugzilla report: #NNNN

Workarounds

After user login, I mount home partition manually using the following command

sudo mount -o subvol=home /dev/nvme0n1p3 /home

This solves the problem until next reboot. Any hint how I can resolve this permanently ?

Please run the command lsblk -f to see the UUID for /home then compare that to the value entered into /etc/fstab. I suspect a discrepancy there may be the issue. lsblk should reveal the uuid needed for the home sub-volume.

On my system where I only have one btrfs volume and it contains both root and home sub-volumes the fstab entries have the same UUID and the options designate which sub-volume to mount. You have similar so it should work.

From Proposed Common Issues to Ask Fedora

Added quality-team

You got a SELinux error

audit: type=1400 audit(1713191078.472:4): avc:  denied  { read } ...

Please run the command

sudo restorecon -R /etc
3 Likes

@computersavvy
I am sure UUID is correct. Indeed it’s the same as your system (same UUID with two subvolume ; which is the default Fedora disk layout with btrfs)

@vekruse
Yes, I also suspect something went wrong with permissions… I tried restorecon that you supplied, and now I cannot boot into fedora anymore! I get the following error:

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, or "exit" to continue bootup.

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

(When I press enter, the same text is displayed again…)

I tried to edit grub linux boot adding “selinux=0” but that didn’t help.

Luckily I still have ubuntu working…

At that stage I would have liked to se the output of lsblk -f to verify that the UUID entries are correct, also for the other entries.

I have managed to unlock fedora root from ubuntu, but somehow user login is now failing. Even after I updated the user password using passwd.

Here is the output of lsblk -f looks like (from ubuntu OS) :

NAME        FSTYPE   FSVER LABEL                 UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       squashfs 4.0                                                                    0   100% /snap/bare/5
loop1       squashfs 4.0                                                                    0   100% /snap/code/156
loop2       squashfs 4.0                                                                    0   100% /snap/code/157
loop3       squashfs 4.0                                                                    0   100% /snap/core20/2264
loop4       squashfs 4.0                                                                    0   100% /snap/core22/1122
loop5       squashfs 4.0                                                                    0   100% /snap/firefox/3836
loop6       squashfs 4.0                                                                    0   100% /snap/firefox/4090
loop7       squashfs 4.0                                                                    0   100% /snap/gnome-42-2204/141
loop8       squashfs 4.0                                                                    0   100% /snap/gnome-42-2204/176
loop9       squashfs 4.0                                                                    0   100% /snap/gtk-common-themes/1535
loop10      squashfs 4.0                                                                    0   100% /snap/snap-store/1113
loop11      squashfs 4.0                                                                    0   100% /snap/snap-store/959
loop12      squashfs 4.0                                                                    0   100% /snap/snapd/21184
loop13      squashfs 4.0                                                                    0   100% /snap/snapd/21465
loop14      squashfs 4.0                                                                    0   100% /snap/snapd-desktop-integration/157
loop15      squashfs 4.0                                                                    0   100% /snap/snapd-desktop-integration/83
nvme0n1                                                                                              
├─nvme0n1p1 vfat     FAT32                       5708-D701                             573,8M     4% /boot/efi
├─nvme0n1p2 ext4     1.0                         2c169925-243d-4195-b9f6-bf6d85b39b69                
├─nvme0n1p3 btrfs          fedora_localhost-live f385bf73-0205-4bca-89ba-11c73c45e07d                
└─nvme0n1p4 ext4     1.0                         ed2fa2d4-c98a-4443-b01b-7006f0a4caff  375,4G     4% /var/snap/firefox/common/host-hunspell

(not sure what the squashfs things are ; those are not there on fedora)

They are snap packages. Run snap list --all.

You can set a password for root like so sudo passwd root. With that, when you end up in emergency mode, you can enter the password for root, and then you can examine various log files.

Happy to share that the issue is finally resolved! Thanks @computersavvy and @vekruse for your support!
The command sudo restorecon -R /etc seem to have solved the permission issue which is the root cause, but then I needed to unlock the root from ubuntu, and I also had to delete the option errors=remount-ro in fstab which I added earlier and and forgot about it…

1 Like

More than once I have done similar – made a change and overlooked the change at some later time. :upside_down_face: (scratching my head while trying to figure out why the fix does not work !!)

T’is a common tale but true. Some colleagues use sticky notes stuck to the monitor frame with reminders for such things – I should probably make that a habit.

Just wanted to chime in and say I had this issue as well after updating from 39 to 40 today; a little over a month post release of 40 official. Following the DNF System Plugin guide, I attempted to relabel using the command provided in the guide sudo fixfiles -B onboot. This did not change the failure to mount /home and my other custom subvolumes which were mounting fine prior to the upgrade.

I was even able to successfully go about my merry way running sudo mount -a on a tty after boot and then I could log in without issue. However, on next reboot, I would have to do this again.

Finally found this thread and the sudo restorecon -R /etc did indeed do the trick. I have no idea what is breaking this as I updated my laptop from 39 to 40 about 8 hours ago and it did not have this problem. I do have a non-default btrfs partitioning scheme on my computer that had this issue, so perhaps that had something to do with it. Unfortunately I’m still quite new to linux and have a lot to learn.

Cheers! Thanks for this thread!

I’ve just updated to Fedora 40 and had the same issue. sudo restorecon -R /etc solved the issue.

2 Likes

I too faced the same issue after updating from fedora workstation 39 to 40. Since the home folder was not mounted, the system won’t even login when using Gnome with X11. The logs revealed that X11 requires access to some folders in home (.local/share/…) because of which it was erroring out.
I then logged in with wayland (“Gnome” option on the login password screen) to find via terminal that the home directory was empty. sudo restorecon -R /etc and a reboot solved it. Thanks.