EFI install formats EFI partition with exfat not fat/vfat

[insanemal]

I'll start with an apology, I don't have logs. I can attempt it again (4 attempts previously) if required.

When doing the partitioning step it formats the EFI partition with exfat and fails install. It works if you manually format the boot partition with mkfs.fat -F32.

[insanemal]

Had a look at the code, looks like something is happening in the detection code. Need to recreate the situation. The disk had an exfat partition on it. I chose whole disk reformat option, and it seems it preserved that exfat formatting after deleting the single partition (disk was used in a hardware video recorder hence exfat formatting of whole device) and creating the new partition. Manual intervention seems to have resolved the issue. So it seems it's not updating the filesystem value from what was initially scanned, or its overwriting it at one step. I'll look into it more later, unless someone else does.

But it appears the steps to recreate the issue are:

1. Have partition 0 of target disk be exfat
2. Select the "re-partition whole disk" option
3. It will format it with exfat instead of fat32

And if partition 0 is exfat you have to manually reformat it or in some way prevent the detection of the existing formatting (dd the FAT header probably) which explains the fact it failed on retry. Also this explains why it hasn't cropped up yet. I doubt many people are installing to SSDs or other storage that was formatted entirely as exfat previously (well unless they are installing to a USB 'thumb drive' that has never been used)

[grazzolini]

I don't think this is accurate:

https://github.com/archlinux/archinstall/blob/master/archinstall/lib/disk.py#L318

[runbmp]

I believe the issue is caused here? I see the same thing when doing a btrfs efi installation inside virtualbox.

https://github.com/archlinux/archinstall/blob/1d60e307e81a99ebd6cbfe26a92e5dfa96a8870a/archinstall/lib/disk.py#L478

[Torxed]

I believe the issue is caused here? I see the same thing when doing a btrfs efi installation inside virtualbox.

https://github.com/archlinux/archinstall/blob/1d60e307e81a99ebd6cbfe26a92e5dfa96a8870a/archinstall/lib/disk.py#L478

This particular line is just an indicator to the formatter that this should be executed: https://github.com/archlinux/archinstall/blob/master/archinstall/lib/disk.py#L318-L319

^- Apparently I don't know how to do fancy inline code references any more..

But there seams to be an issue, where when /boot has an existing (bad) partition file system from previous installations, archinstall won't touch it (for safety reasons). And this borks the process quite hard. Something I'll have to consider for the partitioner re-design in v2.2.0.

[insanemal]

But there seams to be an issue, where when /boot has an existing (bad) partition file system from previous installations, archinstall won't touch it (for safety reasons). And this borks the process quite hard. Something I'll have to consider for the partitioner re-design in v2.2.0.

This feels like the issue. I guess if I'm selecting the "nuke my disk" option. And it successfully re-partitions it, I'm a bit puzzled why I ended up with both partitions claiming to be formatted if it didn't touch the "bad" one.

But then again the ExFAT header is at the start of the disk. So even if it did re-partition the disk, it would look formatted, just incorrectly.

I think, if you have repartitioned it, all bets are off and not touching things stops making sense, to a degree. I mean you could just 'fix' the partition table. BUT the other partitions have been formatted, so even that wouldn't save things.

I mean if you aren't going to touch something because of a "bad" filesystem you shouldn't touch anything and error out. Not re-partition, format things (potentially killing the thing you didn't want to touch in the process) and then bomb out.

[insanemal]

Oh is there a document about the redesign. I would love to help where I can, with implementation that is.

[grazzolini]

But there seams to be an issue, where when /boot has an existing (bad) partition file system from previous installations, archinstall won't touch it (for safety reasons). And this borks the process quite hard. Something I'll have to consider for the partitioner re-design in v2.2.0.

Yeah, if the user tells you do use the whole disk, it should get rid of all the partitions and format them again, regardless of what they had on them previously.

[insanemal]

I mean, totally put up warnings "THIS WILL NUKE YOUR DRIVE. THERE IS NO COMING BACK FROM THIS." with like a "Type 'Yes I am sure' to continue:" kind of prompt. Like deliberate warning and not just bump Y to continue kind of thing.

But after that, format away. You warned them and spelled out the result already.

[Torxed]

Oh is there a document about the redesign. I would love to help where I can, with implementation that is.

I'm writing up a mission statement, I'll write up a design goal for the partitioner. A rough estimate is that I'll have this done most likely this upcoming weekend :) Good idea btw!

[insanemal]

Cool. Well I'd love to help where I can. The code base is still small enough for me to grok it quickly.

[Torxed]

I mean, totally put up warnings "THIS WILL NUKE YOUR DRIVE. THERE IS NO COMING BACK FROM THIS." with like a "Type 'Yes I am sure' to continue:" kind of prompt. Like deliberate warning and not just bump Y to continue kind of thing.

But after that, format away. You warned them and spelled out the result already.

We do have that warning, after confirmation a countdown will start. I think this should be enough for everyone. Even the Installation Guide doesn't have this much protection (I think) ^^

I'm closing this issue once I've re-worked the partitioner. But the issue is known and there is a fix coming.

[Torxed]

This was fixed in v2.1.4 (released yesterday). we've also added some more logging during installation to catch errors like these.