(unsure of actual component that tests for existing Windows vs macOS - but it's showing up in anaconda-webui, so setting it as the component) The test system has macOS installed, but Anaconda claims Windows is installed. See screenshot. Reproducible: Always Steps to Reproduce: MacbookPro with existing macOS installed 1. Boot Fedora-Workstation-Live-42-20250324.n.0.x86_64 (which uses anaconda 42.27.5-1.fc42) 2. Run installer 3. Actual Results: Anaconda claims Windows is installed. Expected Results: Anaconda claims macOS is installed.
Created attachment 2081780 [details] screenshot
Created attachment 2081781 [details] storage.state
Created attachment 2081782 [details] storage.log
Created attachment 2081783 [details] program.log
Created attachment 2081784 [details] anaconda.log
Proposed as a Blocker for 42-final by Fedora user chrismurphy using the blocker tracking app because: This is a stretch... but here it goes. https://fedoraproject.org/wiki/Fedora_42_Final_Release_Criteria#macOS_dual_boot We have a macOS dual boot specific criterion in part to ensure it's partitioned correctly (uniquely from Windows) via mactel-boot. But the misidentification as Windows prevents that from happening. Otherwise we'd just have one criterion for Windows and macOS. NOTE 1: The system boots Fedora OK. I can use the firmware built-in boot manager to choose either Fedora or macOS and that works. NOTE 2: I don't think this bug is going to pass the "last blocker" test. NOTE 3: A possible compromise: Make it a blocker, then wave it with one of the exceptional cases, punting it to the next milestone (F43 beta). https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases
Switching the component to 'anaconda' as it's backend that gives the incorrect information to anaconda-webui.
@Chris, or anyone with MaC OS seeing the same, can you please post the output of lsblk so that I can see the partition types UUIDs for the MAC OS partitions? `lsblk -o +PARTTYPE` Anaconda backend detects Windows if it matches the following partition types: WINDOWS_PARTITION_TYPES = [ "e3c9e316-0b5c-4db8-817d-f92df00215ae", # Microsoft Reserved Partition "ebd0a0a2-b9e5-4433-87c0-68b6b72699c7", # Microsoft Basic Data "de94bba4-06d1-4d40-a16a-bfd50179d6ac", # Windows Recovery Environment "af9b60a0-1431-4f62-bc68-3311714a69ad", # Logical Disk Manager Data Partition ]
# lsblk -o +PARTTYPE NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS PARTTYPE sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 368M 0 part /boot/efi c12a7328-f81f-11d2-ba4b-00a0c93ec93b ├─sda2 8:2 0 35.3G 0 part /macsys 48465300-0000-11aa-aa11-00306543ecac ├─sda3 8:3 0 619.9M 0 part 426f6f74-0000-11aa-aa11-00306543ecac ├─sda4 8:4 0 429.7G 0 part /home/macdata 48465300-0000-11aa-aa11-00306543ecac ├─sda5 8:5 0 4.1G 0 part [SWAP] 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f ├─sda6 8:6 0 31.8G 0 part / 0fc63daf-8483-4772-8e79-3d69d8477de4 ├─sda7 8:7 0 31.8G 0 part /disks/s151 0fc63daf-8483-4772-8e79-3d69d8477de4 └─sda8 8:8 0 397.9G 0 part /home 0fc63daf-8483-4772-8e79-3d69d8477de4 # parted -l Model: ATA ST1000DM003-1SB1 (scsi) Disk /dev/sda: 1000GB Number Start End Size File system Name Flags 1 1049kB 387MB 386MB fat16 EFI boot, esp 2 387MB 38.3GB 37.9GB hfsx sda2 Mac OS X HFS+ system 3 38.3GB 38.9GB 650MB hfs+ Recovery HD 4 38.9GB 500GB 461GB hfsx sda4 Mac OS X HFS+ data 5 500GB 505GB 4429MB linux-swap(v1) sda5 Linux Swap swap 6 505GB 539GB 34.1GB ext4 sda6 openSUSE 15.5 7 539GB 573GB 34.1GB ext4 sda7 openSUSE 15.1 8 573GB 1000GB 427GB ext4 sda8 Linux Home
This from a Macbook Pro 11,3: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS PARTTYPE loop0 7:0 0 2G 1 loop /run/rootfsbase sda 8:0 0 465.9G 0 disk ├─sda1 8:1 0 200M 0 part c12a7328-f81f-11d2-ba4b-00a0c93ec93b └─sda2 8:2 0 465.7G 0 part 7c3457ef-0000-11aa-aa11-00306543ecac sdb 8:16 1 29.8G 0 disk ├─sdb1 8:17 1 2.2G 0 part /run/initramfs/live ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 └─sdb2 8:18 1 30M 0 part c12a7328-f81f-11d2-ba4b-00a0c93ec93b sdc 8:32 1 0B 0 disk zram0 252:0 0 8G 0 disk [SWAP]
That's helpful thanks. The reason we detect Window is because we expect "ebd0a0a2-b9e5-4433-87c0-68b6b72699c7" to belong to Windows OS as it's Microsoft Basic Data partition type UUID. We should remove this partition type from the list of partition types that we map to Windows exclusively. Looks like other OSes use it for reasons I don't understand.
Upstream fix: https://github.com/rhinstaller/anaconda/pull/6307
FEDORA-2025-63711d039a (anaconda-42.27.9-1.fc42 and anaconda-webui-30-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-63711d039a
https://en.wikipedia.org/wiki/Microsoft_basic_data_partition states "Linux used the same partition type GUID for basic data partition as Windows prior to introduction of a Linux specific Data Partition GUID 0FC63DAF-8483-4772-8E79-3D69D8477DE4." If the partitions in question might have been created by an old Fedora install, I *guess* that might explain this? Still, it does seem like a point in favor of not assuming it indicates the presence of a Windows install.
FEDORA-2025-63711d039a (anaconda-42.27.9-1.fc42 and anaconda-webui-30-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
Very sure the GUIDs on the test machine were same as comment 10 for device /dev/sda. C12A7328-F81F-11D2-BA4B-00A0C93EC93B 7C3457EF-0000-11AA-AA11-00306543ECAC I don't recall having any other drives connected, but it's possible a Windows formatted FAT32 USB stick was connected in addition to the installation USB stick. If it was connected, it likely had GUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 But I'm not sure why Anaconda would be looking at any device other than the one I've selected for installation.