Description of problem: Automatic installation creates two 600M EFI System partitions. One is FAT and not used. The other is HFS+ and is used. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Unpartitioned free space is created in advance. 2. Start the installer, and choose Automatic partitioning. Actual results: 4 partitions: there is a "spare" 600M FAT volume that is formatted, but not used Expected results: 3 partitions: EFI system (HFS+), boot (ext4), root+home (btrfs) Additional info: This is on a mac. I think there's mactel-boot related confusion.
Created attachment 1701684 [details] anaconda.log
Created attachment 1701685 [details] program.log
Created attachment 1701686 [details] storage.log
Fedora-Workstation-Live-x86_64-Rawhide-20200719.n.0.iso anaconda 33.23-1.fc33
/dev/sda3 is the bogus partition storage log: line 1996 number: 3 path: /dev/sda3 type: 0 line 3397 "INFO:program:Running... mkdosfs /dev/sda3" Basically it's creating two ESPs: one FAT, one HFS+, but only using the HFS+ one. The resulting /etc/fstab is using the HFS+ one. The system is bootable. So while it's an odd duck, it works and isn't an egregious waste of space, I'd say this is not a blocker. We don't really have a criterion for "anomalous automatic partitioning layouts that still work OK".
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
I believe this is because the requirements specific to mac are only appended to the other boot requirenments, not replacing them. So the underlying code indeed requests both partitions. See https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/storage/platform.py - Lines 164-178 are the thing that happens, and the call to super().set... is lines 146-161 right above. I assume removing the EFI requirement in the mac routine would work, though it feels kind of brittle. Like so: > def set_platform_bootloader_reqs(self): > + ret = super().set_platform_bootloader_reqs() > del ret[-1] # remove the regular EFI partition request > ret.append(PartSpec(mountpoint="/boot/efi", fstype="macefi", > size=Size("200MiB"), max_size=Size("600MiB"), > grow=True)) > return ret
Ow, the + should have gone to the next line. Never mind, should be self explanatory. Chris, given you have the hardware, would you be open to testing a fix for this?
Started with: Fedora-Workstation-Live-x86_64-33-20200813.n.2.iso Modified /usr/lib64/python3.9/site-packages/pyanaconda/modules/storage/platform.py as described Do the two reproduce steps in the description But I get a crash right after clicking Begin https://bugzilla.redhat.com/show_bug.cgi?id=1868866 Crash doesn't happen on unmodified iso.
I wonder what the Anaconda test is, to know whether it's a mac? If it's possible to inject something into a UEFI VM to make the installer think it's a mac, it'd be easier to test.
Ah, sorry! I did not mean you should have a go at it as is - rather I would look into this and once reasonably sure, ask you for testing the supposed fix. But thank you nevertheless! I'll try go with the original plan. I think diverting the check is best done here: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/storage/bootloader/factory.py#L45 Then again, I'd still call myself new at this, so no guarantees...
(In reply to Chris Murphy from comment #10) > I wonder what the Anaconda test is, to know whether it's a mac? If it's > possible to inject something into a UEFI VM to make the installer think it's > a mac, it'd be easier to test. It's actually in blivet, driven by data from /sys/class/dmi/id/chassis_vendor https://github.com/storaged-project/blivet/blob/3.3-devel/blivet/arch.py#L201
Guess I can't change that. Any idea for skipping the check and just hard wiring the value before I launch Anaconda?
Guess I could set all the mactel = False to mactel = True :P
Any update on this bug? Final Freeze will start in 1 week + 1 day. We should probably list it in Common Bugs as every Mac user will run into it.
This is a bit worse than I thought. Custom partitioning doesn't show the extra EFI System partition, so the problem can't be avoided. And the Summary of Changes shows that both ESP's will be mounted at /boot/efi. So is it possible one of them might "win" in certain installations? *shrug*
Created attachment 1723854 [details] summary of changes screenshot
Created attachment 1723855 [details] custom partitioning screenshot
We don't get a Summary of Changes for blivet-gui, so I'm not sure if the problem happens there because right now I can't do a completely clean install on this laptop. Draft common bugs: On Apple Macs, Automatic and Custom (Manual) partitioning's "Click here to create them automatically" option, will create a spare 600M FAT formatted partitioning that won't be used for anything. You don't need to do anything, the spare partition is harmless. Alternative: A work around is to perform a completely manual installation. Remember to create a "Linux HFS+ ESP" partition mounted at /boot/efi. It's suggested to next add a /boot mount point. Followed by swap (optional). And end with creating '/' and '/home' mount points. When using the Btrfs partition scheme, it's advised to leave the Desired Capacity field blank when creating the '/' and '/home' mount points, which results in all remaining free space being assigned to the Btrfs volume. The "root" and "home" subvolumes have no fixed size, they will share free space on the Btrfs volume.
Fixed in https://github.com/rhinstaller/anaconda/pull/2968.
re: comment 20 the alternative mentions "completely manual" which means don't click the blue "create them for me automatically" text.