Bug 2402976

Created attachment 2109242 [details]
syslog

Created attachment 2109243 [details]
program.log

Created attachment 2109244 [details]
anaconda.log

Created attachment 2109245 [details]
storage.log

Created attachment 2109246 [details]
lvm.log

Created attachment 2109247 [details]
storage.state

Created attachment 2109248 [details]
packaging.log

Proposed as a Blocker for 43-final by Fedora user chrismurphy using the blocker tracking app because:

 The rescue mode of the installer must start successfully and be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations. 

https://fedoraproject.org/wiki/Fedora_43_Beta_Release_Criteria#Rescue_mode

Did it work in previous releases? I'm not actually sure this is implemented.

This is what we do in rescue mode, and have for a long time:

    def _mount_and_prompt_for_shell(self):
        self._rescue.mount = True
        self._mount_root()
        self._show_result_and_prompt_for_shell()

and _mount_root, as its name indicates, only mounts the root partition (if it finds more than one it asks you which to mount).

I checked anaconda-40.22.3.9 as a random 'pretty old version' and it does the same. So I think this is more of a feature request than a bug.

Huh. Maybe it never worked on UEFI? I'm certain (possibly certainly wrong) that it worked on BIOS way back when because it was a thing to have anaconda rescue mount all of it, and then run grub2-install grub2-mkconfig to fix the boot loader - which needed everything assembled and in a chroot for all those scripts to work.

If it's working as designed, then I'd say close as notabug. And not treat the report as a feature request. My Magic 8 Ball proposes a different rescue adventure going forward anyway.

ooh, wait. Now I dig into it more, I was wrong, I think.

There's a bit I overlooked in the `mount_root` bits in `rescue.py`. `RescueModeSpoke._mount_root` calls `self._rescue.mount_root`, which is `Rescue.mount_root`, which calls `self._device_tree_proxy.MountExistingSystemWithTask`, which - via a frankly *insane* pile of indirection - ultimately winds up as `pyanaconda.modules.storage.devicetree.root.mount_existing_system`, which is *basically* the same code that's existed all the way since e95be86ccde6c4997fd87729cc655c9072f865fd in 2009 , where it was introduced as `mountExistingSystem`. Along the way it got renamed, moved into blivet, then moved *back*, but it's always been around.

It works by parsing /etc/fstab . So...either your /boot and /boot/efi partitions aren't in /etc/fstab on the installed system...or /etc/fstab isn't in the root partition...or the parsing has broken, I guess?

parse_fstab has some log lines in it, it'd be interesting to see if you can find any trace of these messages:

log.info("cannot open %s for read", fstab_path)
log.debug("blkid.tab devs: %s", list(blkid_tab.devices.keys()))
log_exception_info(log.info, "error parsing blkid.tab")
log.debug("crypttab maps: %s", list(crypt_tab.mappings.keys()))
log_exception_info(log.info, "error parsing crypttab")

Created attachment 2109307 [details]
/etc/fstab

(In reply to Adam Williamson from comment #14)
> parse_fstab has some log lines in it, it'd be interesting to see if you can
> find any trace of these messages:

None of those but found this:

storage.log:INFO:blivet:Fstab file '' does not exist, setting fstab read path to None

hmm, interesting, but it's from blivet, so not sure whether it's relevant, need to trace things out further I guess.

syslog:04:46:45,544 NOTICE kernel:XFS (vda2): Mounting V5 Filesystem 0207ac84-d5d5-46d5-9cdd-6b50c2c34aa3
syslog:04:46:45,809 NOTICE kernel:XFS (vda2): Unmounting Filesystem 0207ac84-d5d5-46d5-9cdd-6b50c2c34aa3
..
syslog:04:46:51,785 NOTICE kernel:XFS (vda2): Mounting V5 Filesystem 0207ac84-d5d5-46d5-9cdd-6b50c2c34aa3
syslog-04:46:51,814 INFO kernel:XFS (vda2): Ending clean mount

The boot volume is mounted and unmounted twice. None of the logs show an actual mount command though, that's a big missing item.

Tested with F41 and F42 Server DVD media using the included Rescue boot option. Both F41 and F42 media mount the full filesystem, including /, /home/, /boot and /boot/efi. But the latest F43 image only mounts /, and nothing else. This clearly is a regression.

AGREED AcceptedFinalBlocker

Discussed at the 2025-10-13 (blocker / freeze exception) review meeting:

This is a clear regression in functionality and intentions. A system that is not fully mounted by the rescue operation is harder to fix. We consider the rescue mode criterion to be violated: https://fedoraproject.org/wiki/Fedora_43_Beta_Release_Criteria#Rescue_mode

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-10-13/f43-blocker-review.2025-10-13-16.00.txt

This appears to be a regression from the fstab handling move from anaconda to blivet in PR #6160 [1].
The issue might be in blivets FSTabManager initialization [2], there is even a comment that we need to change the fstab path in 'next fedora release'.

This would explain why F41/F42 worked (old anaconda fstab handling) but F43 broke (new blivet fstab handling).

[1] https://github.com/rhinstaller/anaconda/pull/6160
[2] https://github.com/storaged-project/blivet/blob/6738e77d7005f3ab2f4503be3482b45f86b42455/blivet/blivet.py#L57

upstream PR: https://github.com/storaged-project/blivet/pull/1423
updates image: https://vtrefny.fedorapeople.org/img/rhbz2402976.img

This fix does seem to work - it causes /boot and /home from the installed system to be mounted. I can't check ESP mounting because I can't use UEFI VMs on Silverblue.

Unfortunately the patch doesn't easily backport to 3.12.1, so I can't do a quick build with the fix for this. I'd rather not put 3.13.0 in f43 unless it's *really* necessary.

FEDORA-2025-372f201c05 (python-blivet-3.12.1-9.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-372f201c05

FEDORA-2025-372f201c05 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-372f201c05`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-372f201c05

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

With F43 RC1.4 this seems fixed

FEDORA-2025-372f201c05 (python-blivet-3.12.1-9.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.