Archinstall should correctly erase/resize the ESP/fat32 partition from Windows when entire disk erase is selected

[jm2]

Currently there appears to be a bug in the way archinstall is formatting a disk when the previous OS was Windows.

Windows 10+ uses an 100MB FAT32 ESP as the first partition, however Arch defaults to 512MB due to /boot kernel disk usage.

When the option to erase the entire disk is selected, the ESP/boot partition is created as a 512MB partition, but the 100MB FAT32 filesystem size from Windows is reused, which causes /boot to be 99% full on first install. The only way I've been able to get parted to work around this oddity is to fully erase the quasi-100MB/512MB FS/partition combo and create/format it from scratch and reinstall GRUB and files afterward. This is super annoying because my primary use case for archinstall is replacing Windows.

[Torxed]

Sadly this is not something we can do without 100% certainty, as there might be a risk of data loss or that microsoft resets the partition. What we can do is:

1. Warn that there's an issue and manual intervention is required
2. Create a separate boot partition (where possible)

I'm leaning more towards option 1, as it's less prone to errors and something users have to do today anyway.

[jm2]

To be clear, this is occurring specifically when "erase the entire disk and format as Arch sees fit" is selected. I would honestly expect this option to erase/format the Windows ESP partition entirely along with the rest of the Windows partitions as it already does. I suppose option 1 is okay as well, but why preserve the 100MB ESP partition when the NTFS partitions are blown away as expected?

[Torxed]

That is true, and that works better in master and will come in the next release.
The reason for this was safety flags, I built in some security checks to make sure we didn't accidentally wipe data in a unintended manner, this check was to "powerful" and preserved the partition even tho the option to wipe the drive was selected.

The new partitioner is more "what you enter is what you get" : )

[jm2]

Great to hear, thanks! :)

[omentic]

So this appears to cause occasional boot failures on kernel upgrades for people who have previously installed Fedora, as detailed over here (related issues: #591). I reinstalled Arch with the installer (and latest ISO: 12.01) today to try and fix the problem. Unfortunately, the extra entries in the boot menu remain.

@Torxed: Should the new partitioner be wiping these entries, and is it included in the December ISO?

[Torxed]

So this appears to cause occasional boot failures on kernel upgrades for people who have previously installed Fedora, as detailed over here (related issues: #541, #591, #592). I reinstalled Arch with the installer (and latest ISO: 12.01) today to try and fix the problem. Unfortunately, the extra entries in the boot menu remain.

@Torxed: Should the new partitioner be wiping these entries, and is it included in the December ISO?

The extra entries still remain.
I still haven't found a clean way to look those up and remove old entries.
We could iterate all the /boot/loader/entries/*.conf but there's a risk some exoteric user out there runs the root filesystem on a removable device, and we'd be wiping that config for them. But regarding #592 and #541 these should be fixed, as they were both caused by network issues and not partitioning issues. And pacstrap will not silently continue on error ould not strap in packages: 256

The december ISO should however wipe anything on /dev/sdX if "wipe all partitions" was selected. If that's not the case, please submit the log here and I'll have a look what's going on. (i've gone through the log in #541 but can't see why it would fail)

[omentic]

The install itself went great! And whoops, #592 and #541 are unrelated, I confused the error message with the one I was getting on kernel updates.

I think I recall either Ubuntu or Manjaro's installer wiping the boot menu so I'm going to play around with those to see if any will wipe it. Interestingly though, /boot/loader/entries/ only has one entry. And I grepped through /boot/ but wasn't able to find anything matching "Fedora" or "Linux Boot Manager".

[Torxed]

One thing we could do, is append a comment to our boot loaders, and only wipe those.
But it would have to be a --clear-boot-entries parameter to start with. I suspect this is how others do it roughly.