When using Fedora-Workstation-Live-42_Beta-1.4.x86_64.iso with the "Reinstall Fedora" option to replace an existing cleanly installed F41 on a legacy BIOS machine, the above error prevents proceeding further. If I choose "Use entire disk" instead, I can proceed with the install. Seen on 3 different legacy BIOS machines. Two are dual boot Windows 10/Fedora 41, one was Fedora 41 only (I reinstalled F42 Beta on this one with the "Use entire disk" option). Reproducible: Always Steps to Reproduce: 1. Install Fedora 41 (or probably anything older than 42) on a legacy BIOS machine. 2. Attempt to use the "Reinstall Fedora" option to reinstall Fedora 42 Beta from the GNOME Workstation Live image (or possibly any install method?). Actual Results: Error "No devices found for boot loader partition 'biosboot'" prevents proceeding further. Expected Results: Should be able to proceed to the next step (Review and Install?).
BTW, it's not necessary to actually do the reinstall to see the bug. As soon as one chooses "Reinstall Fedora" and hits the Next button, the error message appears at the top of the page and prevents proceeding further. So anyone with a legacy BIOS machine and an existing Fedora install should be able to verify this nondestructively.
It works for me, the installation proceeds. Do you actually have a biosboot partition? This is the disk layout for a default F41 Workstation install (in a VM) for me: $ sudo parted /dev/vda p Model: Virtio Block Device (virtblk) Disk /dev/vda: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: pmbr_boot Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB bios_grub 2 2097kB 1076MB 1074MB ext4 bls_boot 3 1076MB 21.5GB 20.4GB btrfs
Unfortunately, my Fedora-only machine, which was legacy BIOS, is now UEFI, and I used "Use entire disk" to get the F42 Beta install done. I still have the other two dual boot Windows 10/Fedora 41 legacy BIOS machines with the same configuration. My output on one of those is # parted /dev/sda p Model: ATA WDC WD20EZRX-00D (scsi) Disk /dev/sda: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 525MB 524MB primary ntfs boot 2 525MB 275GB 274GB primary ntfs 3 275GB 276GB 1074MB primary ext4 4 276GB 2000GB 1724GB extended 5 276GB 2000GB 1724GB logical btrfs The output on the other machine is probably almost identical.
Here's the output for the other, older, machine: # parted /dev/sda p Model: ATA WDC WD20EARX-00P (scsi) Disk /dev/sda: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 525MB 524MB primary ntfs boot 2 525MB 275GB 274GB primary ntfs 3 275GB 276GB 1074MB primary ext4 4 276GB 2000GB 1724GB extended 5 276GB 2000GB 1724GB logical btrfs
You really don't have a biosboot partition, which means the error message is correct. It seems you installed Windows first, and Fedora second. I wonder whether it was correct for Anaconda to let you perform a Fedora install without the biosboot partition present.
I installed Windows first on the entire disk, then shrank the Windows partition and installed Fedora on the free space. Since then, I've been able to do clean Fedora installs on these machines with each new Fedora version for years, preserving /home with the instructions at https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home .
My Fedora-only machine was legacy BIOS and I did the initial Fedora install circa early September 2018 so it would have been Fedora 28, so when I saw the same error on that machine, I had whatever partitioning was created by the F28 GNOME Workstation Live installer when using the entire disk, except for changes by later reinstalls.
On the Fedora-only machine, I initially ran the F42 Beta GNOME Workstation Live installer when it was still legacy BIOS, just to see what the preserve home option looked like, and got the "No devices found for boot loader partition 'biosboot'" error. Then I replaced the firmware with a UEFI BIOS. Then I ran the installer again and got the error "No devices found for boot loader partition 'efi'". That's when I gave up and used the "Use entire disk" option to get the install done.
Just to be clear, I knew that after replacing the firmware with UEFI, the original Fedora install wouldn't be bootable anymore and I'd have to reinstall it. So it was luck that I ran the installer before that and captured the original error. Then I tested on my other two legacy BIOS machines and saw the exact same error.
Sorry, just realized that I wasn't using the preserve home option until BTRFS became the default in Fedora 33. So the partitioning on all 3 machines must have been basically that of a clean F33 install, with later clean reinstalls preserving /home.
(In reply to Kamil Páral from comment #5) > You really don't have a biosboot partition, which means the error message is > correct. It seems you installed Windows first, and Fedora second. I wonder > whether it was correct for Anaconda to let you perform a Fedora install > without the biosboot partition present. I believe it's recommended that when dual booting Windows and Fedora, that the Windows partitions come first, which is why I've always installed Windows first. Is it possible to just manually run a command to add the necessary flags to the appropriate partitions to make the WebUI installer happy, and if so would Windows still work normally? It's unfortunate that I don't have the parted output from the Fedora-only machine before the reinstall. All I know is that I was NOT preserving /home up to and including F33, but after that I did, up to and including F41, using the instructions at https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home . I don't know if it's relevant but when following those instructions I always deleted the previous installation's root subvolume first (on all 3 of my machines).
(In reply to Andre Robatino from comment #11) > (In reply to Kamil Páral from comment #5) > Is it possible to just manually run a command to add the > necessary flags to the appropriate partitions to make the WebUI installer > happy, It's not about adding flags, you need to have a dedicated biosboot partition: https://en.wikipedia.org/wiki/BIOS_boot_partition I'm not sure if it can be an extended partition, though, or has to be a primary one. Maybe this requirement wasn't checked/enforced in older Anaconda versions. And maybe some old Fedoras installed without this partition completely. I'll let Anaconda devs to speak to that. But I think it's correct that it's now enforced. So my recommendation would be to either do a system upgrade (not reinstall), or back up your data and make a clean Fedora install, or create all the partitions manually and then mount them as required.
(In reply to Kamil Páral from comment #12) > (In reply to Andre Robatino from comment #11) > > (In reply to Kamil Páral from comment #5) > > Is it possible to just manually run a command to add the > > necessary flags to the appropriate partitions to make the WebUI installer > > happy, > > It's not about adding flags, you need to have a dedicated biosboot partition: > https://en.wikipedia.org/wiki/BIOS_boot_partition Unfortunately I don't understand 90% of that page, but it seems to say that it's only a requirement when using GPT. Aren't my two dual-boot machines (with parted output in comments 3 and 4) MBR? I thought that under legacy BIOS, Windows insists on MBR. (I'm pretty clueless about this stuff so feel free to correct any or all of what I just said.)
(In reply to Andre Robatino from comment #13) > it seems to say that > it's only a requirement when using GPT Oh, right. Good catch. > Aren't my two dual-boot machines > (with parted output in comments 3 and 4) MBR? Yes, they are. Leaving this to Anaconda devs :)
I don't know if my Fedora-only machine was MBR before, but hopefully that was the cause of the same error. As I mentioned in comment 8, after replacing the firmware with UEFI, and running the installer again with "Reinstall Fedora", the error message changed to "No devices found for boot loader partition 'efi'", so with UEFI it seems to require "efi" instead of "biosboot". The parted output on that machine, after upgrading to UEFI and doing the install with "Use entire disk", is # parted /dev/sda p Model: ATA SanDisk SSD U100 (scsi) Disk /dev/sda: 16.0GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 630MB 629MB fat32 EFI System Partition boot, esp 2 630MB 1704MB 1074MB ext4 bls_boot 3 1704MB 16.0GB 14.3GB btrfs so whatever it was before, it's now GPT and it looks like the labels are present, so hopefully reinstalls will work fine going forward.
I found dmesg output for the Fedora-only machine from January 2023, when it was running F37, indicating that it was using MBR at that time. (The output contains "BOOT_IMAGE=(hd0,msdos1)/vmlinuz-6.1.5-200.fc37.x86_64", currently the corresponding output is "BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.14.0-0.rc7.56.fc42.x86_64".) The change https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault happened with F37, and I'm pretty sure that from F38 through F41 I always preserved /home and so the switch from MBR to GPT would never have happened. This will probably affect lots of people with legacy BIOS machines even if they're Fedora-only, if the initial install was before F37. Should this be a Final blocker? I looked through the criteria earlier and didn't see anything obvious. Almost certainly a FE, though.
We are not supporting the MBR partitioning use case in the current implementation. I think the reason for that is that Fedora installation defaults to GPT since Fedora 37: https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault. Although there was not explicit decision of not supporting it IIRC, I think it was more considered as rather non-frequent use case. Adding the support would require Anaconda backend update.
(In reply to Radek Vykydal from comment #17) > We are not supporting the MBR partitioning use case in the current > implementation. Hey Radek, can you please elaborate on this? - Is this just webui, or also GTK? - Does it mean that just "reuse home" approach won't work, or anything except "erase whole drive" won't work? - Will manual mount point assignment work? - Is this new in F42, or already present in older releases? If this was a big change over F41, I would consider writing a CommonBugs entry for it. Thanks.
On a legacy BIOS machine, with a Fedora-only install, one can do a one-time "Use entire disk" and restore /home from backup, and then have GPT, no big deal. (I would have done that on my Fedora-only machine earlier if I'd been aware.) But AIUI Windows insists on MBR on legacy BIOS, so anyone dual booting with Windows couldn't preserve /home and would have to use "Use entire disk" on each reinstall, or settle for upgrades. Dual boot with Windows and legacy BIOS are still both supported (though I know legacy BIOS support will go away eventually). Does not being able to preserve /home on a reinstall violate the Final criteria? BTW, up to and including F41, I was able to reinstall and preserve /home (using the instructions at https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home ), on the same machines. This is definitely new.
Although to be fair, Windows 11 officially requires UEFI, and Windows 10 loses support in October.
(In reply to Kamil Páral from comment #18) > (In reply to Radek Vykydal from comment #17) > > We are not supporting the MBR partitioning use case in the current > > implementation. > > Hey Radek, can you please elaborate on this? > - Is this just webui, or also GTK? > - Does it mean that just "reuse home" approach won't work, or anything > except "erase whole drive" won't work? > - Will manual mount point assignment work? I tested this today. Only WebUI is affected, GTK UI (tested in KDE) is fine. If the disk has MBR, there are basically two working options: * Use the whole disk - which will turn it into GPT and remove everything present * Use free space - worked fine at least in my limited testing What doesn't work: * Assign mountpoints manually - because it requires a biosboot partition, which isn't present and can't even be created (it seems) * Reinstall Fedora (while keeping home intact) - the same issue as with manual mountpoints Cockpit storage doesn't allow biosboot partition to be created on a MBR drive, and I didn't even manage it to do it manually using parted. The required "bios_grub" partition flag can't be set (it says "invalid token", maybe it's not valid for MBR, no idea). The effect is that those two workflows above are completely inaccessible on a MBR drive. The only available workaround seems to be using the Everything netinst image (which does have a few different defaults compared to the Workstation image, though). I feel that this should again go through a blocker discussion. We've already approved that the WebUI doesn't need to offer bootloader location selection, if the existing workflows work as expected with this feature missing. Something similar needs to be done again, it seems. Currently at least this criterion [1] seems affected (notice that it explicitly mentions ms-dos disk label = MBR). Our job is to ensure that existing features work correctly and no feature disappears unintentionally, we're not here to dictate what features Anaconda must support. However, similarly to the bootloader feature, I haven't seen this MBR change highlighted anywhere, and it might surprise quite a few users (and the error message will not tell them much), so let's discuss this. [1] https://fedoraproject.org/wiki/Fedora_42_Beta_Release_Criteria#Custom_partitioning
(In reply to Kamil Páral from comment #18) > (In reply to Radek Vykydal from comment #17) > > We are not supporting the MBR partitioning use case in the current > > implementation. > > Hey Radek, can you please elaborate on this? > - Is this just webui, or also GTK? > - Does it mean that just "reuse home" approach won't work, or anything > except "erase whole drive" won't work? > - Will manual mount point assignment work? > - Is this new in F42, or already present in older releases? > > If this was a big change over F41, I would consider writing a CommonBugs > entry for it. Thanks. I was talking specifiacally about home reuse in WebUI
Confirmed that the 42 Beta netinstall ISO is still GTK, and according to https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation , the Workstation ISO is the ONLY WebUI media for 42. So using one of the other media seems like a reasonable workaround for now. Windows 10 loses support in October, around the release time of F43. After that, supported Windows will officially require UEFI and use GPT partitioning. P.S. I know there are hacks to get Windows 11 installed (but unsupported) without satisfying the usual requirements, including UEFI. I don't know if when it's installed that way on a legacy BIOS machine, it's possible to get GPT partitioning or if it will still insist on MBR.
I can reproduce this on Windows 10 using Bios based VM and Fedora Workstation 42 installation. I could also confirm that it is possible to reinstall Fedora and retain the home partition using Anaconda GTK.
> The required "bios_grub" partition flag can't be set (it says "invalid token", maybe it's not valid for MBR, no idea) This is a partition type which only exists in GPT, it just doesn't exist in MBR. See https://en.wikipedia.org/wiki/Partition_type (MBR partition types) vs. https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs (GPT partition types). A "BIOS boot partition" is a partition on a GPT disk with the UUID 21686148-6449-6E6F-744E-656564454649 . There is no MBR equivalent.
this was noted by the people at the register: "Even on our elderly, legacy-BIOS-only hardware, Fedora 42 insisted on partitioning the X301's tiny 120 GB SSD with a GUID Partition Table (GPT). The machine was previously running Void Linux, but we couldn't reuse the existing partitions, as they were on an MBR partition table. For most users this will make no difference at all, but it does mean you can forget about dual-booting Fedora 42 with some older OSes – such as 32-bit Windows, or any version in legacy-boot mode." https://www.theregister.com/2025/03/24/fedora_42_beta/
Discussed during the 2025-03-24 blocker review meeting [1]: * AGREED: 2353002 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration". We note that resolving this does not require implementation of MBR support; this could be sufficiently addressed by not allowing the user to attempt unsupported operations on an MBR-labelled disk. [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-03-24/f42-blocker-review.2025-03-24-16.02.log.html
> this could be sufficiently addressed by not allowing the user to attempt unsupported operations on an MBR-labelled disk Well technically speaking Anaconda doesn't allow them already. "Mount point assignment" is grayed out already, "Reinstall Fedora" is selectable, but shows an error message when trying to continue with it (this could be improved to be grayed out from the beginning as well). The storage editor is a bit weird, it only says "requirements not met" without any further detail. (I'm attaching screenshots of all of this). I believe we're also asking for a more understandable error message. "Bios boot partition missing" is confusing for a MBR drive, where it can't even exist. Something like this would improve the clarity: "For most operations, a GPT-formatted disk is required at this moment. You can work around this limitation by using a GTK UI of the installer.". While not ideal, I think it's much better and allows users to figure out what to do next (we can even embed a link to a common issues entry, if you want).
Created attachment 2081851 [details] guided-form.png
Created attachment 2081852 [details] reinstall-attempted.png
Created attachment 2081853 [details] storage-editor.png
(In reply to Kamil Páral from comment #28) > > this could be sufficiently addressed by not allowing the user to attempt unsupported operations on an MBR-labelled disk > > Well technically speaking Anaconda doesn't allow them already. "Mount point > assignment" is grayed out already, "Reinstall Fedora" is selectable, but > shows an error message when trying to continue with it (this could be > improved to be grayed out from the beginning as well). The storage editor is > a bit weird, it only says "requirements not met" without any further detail. > (I'm attaching screenshots of all of this). > > I believe we're also asking for a more understandable error message. "Bios > boot partition missing" is confusing for a MBR drive, where it can't even > exist. Something like this would improve the clarity: "For most operations, > a GPT-formatted disk is required at this moment. You can work around this > limitation by using a GTK UI of the installer.". While not ideal, I think > it's much better and allows users to figure out what to do next (we can even > embed a link to a common issues entry, if you want). Such an error needs to give people a way to launch the GTK UI directly from the error.
> this could be sufficiently addressed by not allowing the user to attempt unsupported operations on an MBR-labelled disk I actually don't think this is a valid option, since the criterion in question explicitly mentions DOS/MBR *and* GPT, and we cannot tell people they can't install on an MBR disk (especially since we require it for ARM still!).
We discussed that in the meeting, and my reading is that we had consensus that it's OK for that to be explicitly not supported in webui since it *is* supported in gtkui. Whether this requires changing the criteria is up for debate a bit, but that's clearly what we decided.
(In reply to Neal Gompa from comment #32) > Such an error needs to give people a way to launch the GTK UI directly from > the error. I consider that completely unrealistic. Maybe devs will feel differently. But just to be clear, this is not something that we asked for, in our blocker review meeting output.
(In reply to Kamil Páral from comment #35) > (In reply to Neal Gompa from comment #32) > > Such an error needs to give people a way to launch the GTK UI directly from > > the error. > > I consider that completely unrealistic. Maybe devs will feel differently. > But just to be clear, this is not something that we asked for, in our > blocker review meeting output. There is no realistic way for someone to launch the GTK UI from something that uses the Web UI. So we cannot use the GTK UI as an escape hatch either.
Upstream fix being worked on: https://github.com/rhinstaller/anaconda/pull/6306
For the record, the upstream fix ought to allow install on an MBR-labelled disk to work, so it renders the above discussion moot.
(In reply to Katerina Koukiou from comment #37) > Upstream fix being worked on: > https://github.com/rhinstaller/anaconda/pull/6306 Yes, the fix will in general loose the biosboot/efi part constraint to allow installations on MBR partitioned disks using Cockpit Storage and/or mount point assignment. It will loose it too much as for F42 we are not able to come with a safe enough solution that would keep the constraints for GPT disks working (we want to improve it in F43). It means there will be cases where the mount point assignment option will be available even with missing /boot/efi when using GPT disks. The user will be notified about the missing partition when trying to leave the mount point assignment screen, he can still add it (for example by going back to the Cockpit Storage). This is reflected by the update of one of tests: https://github.com/rhinstaller/anaconda-webui/pull/732/commits/156a6a1682056edf0729383af275ffdea0dce2ff. (For the record, on EFI machines the /boot/efi is still required in mount point assignment screen (the m-p-a option is available even if the partition is missing but I suppose it is expected at least in scope of this BZ).
FEDORA-2025-900bb2b163 (anaconda-42.27.10-1.fc42 and anaconda-webui-31-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-900bb2b163
FEDORA-2025-900bb2b163 has been pushed to the Fedora 42 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-900bb2b163` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-900bb2b163 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-900bb2b163 (anaconda-42.27.10-1.fc42 and anaconda-webui-31-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
I just booted from the latest compose Fedora-Workstation-Live-42-20250330.n.0.x86_64.iso (which is supposed to include the above updates) on one of my dual-boot machines and got the same error "No devices found for boot loader partition 'biosboot'" (although the "Reinstall Fedora" option was chosen by default and I think previously it wasn't).
Running live, "rpm -q anaconda anaconda-webui" confirms the above two package versions. I also tried removing the anaconda-webui package and then running the installer again and it does indeed come up in GTK mode, so that's a workaround. How long is that trick expected to continue working?
Using the last Fedora-Workstation-Live-42-20250330.n.0.x86_64.iso I can't reproduce this on a bios firmware VM (kvm qemu virt-manager)
Created attachment 2082728 [details] susceeded to reproduce the bug in last 0330 iso sorry for the noise at the last comment, I managed to reproduce the bug at virt-manager, as this print show. Fedora-Workstation-Live-42-20250330.n.0.x86_64.iso
Created attachment 2082729 [details] print from the advanced partition manager without problems strangely, in the same install from the last print, if I choose to open the advanced partition manager it doesn't show any error asking for "biosboot" partition like the bug description said.
Created attachment 2082730 [details] it shows the message but installation goes on
In the update we enabled re-installation on MBR-partitionied disks via mount point assignment or cockpit storage. I think the real reason for making the issue a blocker was no option to re-install / preserve home at all, which I believe was fixed. But as the comments above show there is another issue introduced by current solution: the "Reinstall Fedora" option is now available, although it will fail on a backend check with the "No devices found for boot loader partition 'biosboot'" message on the screen. Backend of the Reinstall feature is not ready for this use case and fixing it was not intended in this update. The message doesn't prevent further use of the two methods mentioned above but still it can be very confusing for users and it is not great for the feature being introduced ("Reinstall") to had such issue (although with limited scope). I think we should be able to disable the "Reinstall Fedora" option in the frontend: https://github.com/rhinstaller/anaconda-webui/pull/742
Radek, that sounds reasonable to me. Let's disable "Reinstall Fedora" for MBR disks, and I'll document in CommonBugs that custom mount point assignment or cockpit storage needs to be used in that case. Thanks.
What about removing the anaconda-webui package while running Live, then running the installer in GTK mode? Is that expected to work reliably? It has the advantage of being familiar to those like me who have been using the instructions at https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home the last couple years. If not, I'll use the netinstall, but I prefer Live if possible.
That ought to be reliable if you want to do that, yes. At least so long as we're shipping gtkui on all the other lives, there's no reason I can think of that it won't keep working.
FEDORA-2025-f4b60a3d74 (anaconda-42.27.11-1.fc42 and anaconda-webui-32-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-f4b60a3d74
Here's an openQA-built netinst that can be used for testing the fix: https://adamwill.fedorapeople.org/04891868-FEDORA-2025-f4b60a3d74-netinst-x86_64.iso
live image, for webui testing: https://adamwill.fedorapeople.org/04891897-Fedora-Workstation-Live-x86_64-FEDORA-2025-f4b60a3d74.iso
Huh, trying to verify the fix for this, I already couldn't reproduce it with Fedora-Workstation-Live-42-20250402.n.0.x86_64.iso - when I try and install on an MBR disk which has a Fedora 41 install (just /boot and / ext4 partitions), I don't see the "Reinstall Fedora" option, only "Share disk with other operating system", "Use entire disk" and "Mount point assignment". Not sure why not. So I can't verify that this is fixed. Kamil, Andre or Geraldo, could one of you check it, if you have a reliable reproducer? Thanks!
I tested Fedora-Workstation-Live-42-20250402.n.0.x86_64.iso and got the same result as with Fedora-Workstation-Live-42-20250330.n.0.x86_64.iso, I see "Reinstall Fedora" and get the biosboot error on clicking "Next". Also verified the versions of anaconda and anaconda-webui are the same. Will now test the Live you posted in comment 55.
The Live from comment 55 does not show the "Reinstall Fedora" option - it has the other three, and "Share disk with other operating system" is chosen by default (and to use that I'm required to reclaim space). "rpm -q anaconda anaconda-webui" confirms anaconda-42.27.11-1.fc42 and anaconda-webui-32-1.fc42. This test and the previous one were both on my old dual boot Win 10/F42 machine from comment 4.
so, that sounds like this is fixed and we can set VERIFIED?
FEDORA-2025-f4b60a3d74 has been pushed to the Fedora 42 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-f4b60a3d74` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-f4b60a3d74 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I tested the 04891897-Fedora-Workstation-Live-x86_64-FEDORA-2025-f4b60a3d74.iso from @adamwill and it indeed doesn't have anymore the option for home reuse with MBR disk. I still can reuse home at "mount point assignment" mode and "advanced partition manager" mode, which seems good.
(In reply to Adam Williamson from comment #56) > when I try and install > on an MBR disk which has a Fedora 41 install (just /boot and / ext4 > partitions), I don't see the "Reinstall Fedora" option I don't know the exact heuristics that Anaconda uses, but this can't possibly work, if you don't have /home as a separate partition, or subvolume (on btrfs).
huh? yes it can? we don't even create /home as a separate partition by *default* unless the disk is 50GB in size.
My assumption is that "Reinstall Fedora" means "Reinstall Fedora while keeping /home intact", otherwise it's not offered. If that's not the case, I'd like to learn the actual state :) And with btrfs being default now on Workstation, home is always a separate subvolume.
oh, right, that would make sense - I see what you mean now, it wouldn't "work" in the sense of reproducing the bug. I hadn't thought about it that way, but it sort of makes sense, yeah, if we start from the basis that the reinstall option is only useful with separate /home .
I tested that MBR drives can be configured through both cockpit-storage and mountpoint assignment, and Andre confirmed that "Reinstall Fedora" disappeared. I think we can consider this fixed.
@adam, I checked again your build using EFI and it doesn't show anymore the option to reuse home, even on full efi preinstalled disks and machine, so... a regression?
I thought this option at the fisrt screen would still be present at full efi installs.
OOps, checked again and confirmed this: - it shows correctly the option to reuse home at screen 2 (sorry, said first screen at the former comment but is screen 2). - but, if you choose another type os install and change your mind at screen 3, and return to screen 2 then it doesn't show anymore the option at screen 2. So: I thing this other behavior is just something to document at comom issues don't you think?
(In reply to Geraldo Simião from comment #69) > - but, if you choose another type os install and change your mind at screen > 3, and return to screen 2 then it doesn't show anymore the option at screen > 2. I tried several times, but couldn't reproduce this issue.
FEDORA-2025-f4b60a3d74 (anaconda-42.27.11-1.fc42 and anaconda-webui-32-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
I was not able to figure out how to use "Mount point assignment" to preserve home on a dual-boot machine with MBR partitioning. Posted at https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/5WL6547S7RY3JHF74HC2YO6PNQJJ2WFM/ . Maybe the wiki page needs to be clearer? If necessary I'll use the GTK installer after removing anaconda-webui.
I think I know now how I'm supposed to use WebUI to preserve home, but I hit what seems to be a bug (see the test list thread above). If I'm doing something wrong, I can't imagine what. If it is a bug this will need to be reopened.
Now that I know what I'm doing, I'm not hitting the bug any more. It may be something that's only triggered by someone who stumbles around before getting the settings right. The instructions at https://fedoraproject.org/wiki/QA:Testcase_partitioning_webui_guided_btrfs_preserve_home aren't detailed enough, I had to also watch a video at https://fedoramagazine.org/anaconda-installer-redesign/ before figuring out exactly what to do. It would help if that preserve home page had the same level of detail as the old page https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home .
Do you still want to CommonBugs anything here, Kamil?
Yes, I'll create a CommonBugs entry about information in comment 50 .
Common Issue topic: https://discussion.fedoraproject.org/t/common-issue/148694
*** Bug 2358089 has been marked as a duplicate of this bug. ***