Bug 1858649

Summary: default partitioning on Macs creates an extra 600M FAT32 volume that goes unused
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: anacondaAssignee: Vendula Poncova <vponcova>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 33CC: anaconda-maint-list, jkonecny, jonathan, kellin, kparal, vanmeeuwen+fedora, vponcova, vslavik, wwoods
Target Milestone: ---Keywords: CommonBugs
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: https://fedoraproject.org/wiki/Common_F33_bugs#macs-unused-partition
Fixed In Version: anaconda-34.12-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-04-30 07:28:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
summary of changes screenshot
custom partitioning screenshot none

Description Chris Murphy 2020-07-19 22:47:30 UTC
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:

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.

Comment 1 Chris Murphy 2020-07-19 22:49:08 UTC
Created attachment 1701684 [details]

Comment 2 Chris Murphy 2020-07-19 22:49:20 UTC
Created attachment 1701685 [details]

Comment 3 Chris Murphy 2020-07-19 22:49:32 UTC
Created attachment 1701686 [details]

Comment 4 Chris Murphy 2020-07-19 22:50:44 UTC
anaconda 33.23-1.fc33

Comment 5 Chris Murphy 2020-07-19 23:35:35 UTC
/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".

Comment 6 Ben Cotton 2020-08-11 13:47:52 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 7 Vladimír Slávik 2020-08-12 13:31:18 UTC
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

Comment 8 Vladimír Slávik 2020-08-12 14:06:52 UTC
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?

Comment 9 Chris Murphy 2020-08-14 04:24:45 UTC
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


Crash doesn't happen on unmodified iso.

Comment 10 Chris Murphy 2020-08-14 04:31:45 UTC
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.

Comment 11 Vladimír Slávik 2020-08-17 12:39:38 UTC
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...

Comment 13 Brian Lane 2020-08-17 15:58:16 UTC
(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


Comment 14 Chris Murphy 2020-08-17 16:06:44 UTC
Guess I can't change that. Any idea for skipping the check and just hard wiring the value before I launch Anaconda?

Comment 15 Chris Murphy 2020-08-17 16:08:44 UTC
Guess I could set all the mactel = False to mactel = True  :P

Comment 16 Chris Murphy 2020-09-28 08:24:42 UTC
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.

Comment 17 Chris Murphy 2020-10-23 22:12:27 UTC
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*

Comment 18 Chris Murphy 2020-10-23 22:12:50 UTC
Created attachment 1723854 [details]
summary of changes screenshot

Comment 19 Chris Murphy 2020-10-23 22:14:39 UTC
Created attachment 1723855 [details]
custom partitioning screenshot

Comment 20 Chris Murphy 2020-10-23 22:28:02 UTC
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.

Comment 21 Vendula Poncova 2020-10-30 14:34:04 UTC
Fixed in https://github.com/rhinstaller/anaconda/pull/2968.

Comment 22 Chris Murphy 2020-10-30 17:11:17 UTC
re: comment 20 the alternative mentions "completely manual" which means don't click the blue "create them for me automatically" text.