Cannot Upgrade Fedora Atomic - FSTab Errors

Ask Fedora
,
1

I cannot seem to upgrade my Kinoite installation. My current deployment is 44.20260717.0 and my pending deployment is 44.20260920.0.

I have tried removing all layered packages, but get the same boot errors.

It seems to be related to my FSTab file. My FSTab is edited, but only to add a partition on an external drive. The contents are pasted below.

The boot errors seem to be complaining that my /home mount point contains a symlink. I cannot fathom how this could be true. I’ve been updating successfully for months now, and haven’t changed anything dramatic about my config files. A screenshot of journalctl in emergency mode is attached.

I can successfully boot my current installation, I’m just unable to upgrade. Any help would be appreciated.

# /etc/fstab
# Created by anaconda on Tue Feb  3 12:44:28 2026
#
# 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.
#
# Updated by bootc-fstab-edit.service
UUID=da822420-8a07-4eec-a49f-f32aad44d386 / ext4 defaults,ro 1 1
UUID=b130c0d6-a37f-4f6d-b0b4-7f3212693612 /boot ext4 defaults 1 2
UUID=e5d3ceec-0edc-435f-b99f-27d0ac9128e9 /home ext4 defaults 1 2
UUID=b9044e80-a675-4740-ac90-2ace288efd03 /mnt/Storage ext4 defaults 1 2

Emergency Mode Boot Log
Emergency Mode Boot Log1920×1769 555 KB

2

You do not tell us if you get an error when running the rpm-ostree upgrade command or get an error when booting into the new deployment.

This may be a related topic:

https://discussion.fedoraproject.org/t/silverblue-updates-after-8-16-26-result-in-emergency-mode-and-failure-to-mount-home-when-using-ext4/200074

3

Apologies. This occurs when booting into the new deployment.

That link does indeed look like it describes my issue.

4

It looks like this is the issue I should be watching

5

I can confirm that running rpm-ostree kargs --append=systemd.gpt_auto=0 fixes the issue.

But I see you said that this should be considered a workaround, not a fix. I’ll try and remember to check back in on that issue, and remove the kernel arg when it gets resolved.

Thanks for the help!

6

While not a fix in itself, a good practice for non-system entries in /etc/fstab is to use the nofail flag. That way, should something go wrong, the system is still bootable.

7

I see an fsck error
image

It would seem wise to boot into some live media and run fsck on all your file systems to rule out (or fix) actual file system errors as the cause.