Existing Fedora 42 pre-release is installed using defaults. Rerun the installer and it shows it detects Fedora 42, but there isn't an option to (re)install while keeping the existing /home directory. Reproducible: Always Steps to Reproduce: 1. New clean default installation of Fedora 42 2. Reboot and run the installer again 3. Actual Results: The available options for installation don't include detecting and keeping the existing /home Expected Results: An installation option should include detecting and keeping the existing /home (with a new / if necessary). anaconda 42.27.3-1.fc42
Created attachment 2080136 [details] storage.state
Created attachment 2080137 [details] storage.log
Created attachment 2080138 [details] program.log
Created attachment 2080139 [details] anaconda.log
Created attachment 2080140 [details] screenshot, unexpected
Created attachment 2080153 [details] screenshot, expected The top option is what I'm expecting. There must be something about the storage state that Anaconda isn't picking up on as containing a Fedora home suitable for being preserved.
$ sudo btrfs sub list -t / ID gen top level path -- --- --------- ---- 256 176 5 root 257 176 5 home 258 173 256 var/lib/machines 259 164 5 root42.20250304 The last two subvolumes aren't created by anaconda, is it possible their existence is causing confusion?
@Chris thanks for the report. We currently do not support the 'Reinstall Fedora' (Home reuse) option if there are non default mount points in the existing installation. In this case, /var/lib/machines is the unexpected one. So what you 're seeing is the current expected behavior. The check happens here: https://github.com/rhinstaller/anaconda-webui/blob/main/src/components/storage/scenarios/ReinstallFedora.jsx#L100
I just checked, I also have var/lib/machines, so it seems common. What generates that? $ sudo btrfs sub list -t / ID gen top level path -- --- --------- ---- 258 4573885 5 home 1257 4573885 5 root 1258 4573265 1257 var/lib/machines (I originally commented on the preserving /home issue at https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/MRGUHW3JWZH77LFQNQI2A76SHQ56Z67A/ ).
I have it on my other 2 machines as well, so 3 total. All of them were GNOME Workstation Live installs. I thought it might be my QEMU/KVM guest, but that's only on one of them, so that's not it. I have a /var/lib/machines *directory* which is empty and is owned by systemd-container, that must be part of the default install.
Same on my F42 VM (other machines are F41 bare metal), also a GNOME Workstation Live install.
/var/lib/machines isn't a mount point, it's a (nested) subvolume created by systemd automatically at some point (I'm not sure when it creates it). So I don't think this explains the problem.
OK so two cases: 1. Reuse home feature isn't shown (screenshot, unexpected) 2. Reuse home feature is shown (screenshot, expected) The `/etc/fstab` for the two underlying installations is the same. And `mount | grep vda` shows identical results. And var/lib/machines is present in both cases.
OK, we should allow /home reuse when there is a /var/lib/machines subvolume present. We should reformat /var/ to ensure a clean system installation, but do not format or overwrite /var/lib/machines if it is on a separate subvolume.
The lack of the reuse home feature seems to follow the existence of a snapshot of the root subvolume in the top-level of the Btrfs. e.g. the home reuse feature is still available following sudo mount /dev/vda3 /mnt; cd /mnt sudo btrfs subvolume snapshot -r home home.20250314 e.g. the home reuse feature is not available following sudo mount /dev/vda3 /mnt; cd /mnt sudo btrfs subvolume snapshot -r root root.20250314 In effect this looks like multiple Fedora installations, and it's *that* check that's resulting in the missing reuse home feature. The existence of /var/lib/machines doesn't inhibit the reuse home feature.
RE: c14 I think the installation should not reuse the existing root subvolume for new installations. It should leave old root subvolume untouched, create a new subvolume for the new root, and (re)install Fedora there. The user can migrate the old var/lib/machines manually (not your problem).
Currently we 'reformat'[1] root subvolume with all its subvolumes[2] - including var/lib/machines as in this case. I think the issue here is indeed the root42.20250304. It is not a subvolume of the recreated root, but it is mounted (I assume in /etc/fstab) as a mount point we are not able to handle - therefore we don't offer the Reinstall option. Similar use cases could become supported in the future - perhaps automatically in some cases, but more likely by providing a supportive (ie confirm suggested action) UI for the user to decide (add the mountpoint to the preserved/reused ones - for now it is only /home which is preserved) [1] Actually for btrfs we need to recreate the subvolume (destroy and create) [2] unless the subvolume is mounted in /etc/fstab - in which case we don't offer the option to Reinstall
(In reply to Chris Murphy from comment #16) > RE: c14 > > I think the installation should not reuse the existing root subvolume for > new installations. It should leave old root subvolume untouched, create a > new subvolume for the new root, and (re)install Fedora there. The user can > migrate the old var/lib/machines manually (not your problem). We can consider this for the future. At least as an option (it might not be desired default action as it would require more space for example). But anyway that is for a discussion / design beyond the scope of Fedora 42 IMO. The target for the F42 as I understand it was to provide a reasonable default without the need of user interaction that would offered only in safe enough use cases.
(In reply to Radek Vykydal from comment #17) > I think the issue here is indeed the root42.20250304. It is not a subvolume > of the recreated root, but it is mounted (I assume in /etc/fstab) as a mount > point we are not able to handle It's not listed in /etc/fstab, the /etc/fstab is unmodified. The subvolume snapshot "root42.20250304" is located in the top-level of the file system, i.e. same level as the default "root" and "home" subvolumes created by Anaconda.
(In reply to Chris Murphy from comment #19) > (In reply to Radek Vykydal from comment #17) > > I think the issue here is indeed the root42.20250304. It is not a subvolume > > of the recreated root, but it is mounted (I assume in /etc/fstab) as a mount > > point we are not able to handle > > It's not listed in /etc/fstab, the /etc/fstab is unmodified. The subvolume > snapshot "root42.20250304" is located in the top-level of the file system, > i.e. same level as the default "root" and "home" subvolumes created by > Anaconda. Yes, I was wrong in my assumption, I wonder where the snapshot comes from. And will try to find out why it actually blocks the option.
(In reply to Chris Murphy from comment #15) > The lack of the reuse home feature seems to follow the existence of a > snapshot of the root subvolume in the top-level of the Btrfs. > > e.g. the home reuse feature is still available following > > sudo mount /dev/vda3 /mnt; cd /mnt > sudo btrfs subvolume snapshot -r home home.20250314 > > e.g. the home reuse feature is not available following > > sudo mount /dev/vda3 /mnt; cd /mnt > sudo btrfs subvolume snapshot -r root root.20250314 > > In effect this looks like multiple Fedora installations, and it's *that* > check that's resulting in the missing reuse home feature. The existence of > /var/lib/machines doesn't inhibit the reuse home feature. Yes, you are completely right. I checked locally with the same result. The check: https://github.com/rhinstaller/anaconda-webui/blob/048854fffc67088705db88749fb076df7589d0bc/src/components/storage/scenarios/ReinstallFedora.jsx#L70
Sorry. The snapshot "root42.20250304" was manually created by me (for reasons unrelated to testing anaconda, and didn't consider it was a possible factor until comment 7). However, its existence likely makes Anaconda think there's more than one OS on the file system and therefore triggers the no reinstall policy. In effect there is more than one OS. Option A: Inform user there are multiple OS's installed (or possibly snapshots of one OS), and therefore installation can't proceed. Option B: Some kind of test for each subvolume snapshot to see if they're the same OS, e.g. check /etc/fedora-release and /etc/machine-id