On 19/10/20 3:03 am, Mathieu Othacehe wrote:
Hello Miguel & Brendan,
AFAIU from the code, the first partition should not be created by the
installer but it won't be removed if it was found on the disk
beforehand. Tomorrow I'll give a try at the full installation process,
I must have overlooked something if it still being created in that
case...
Thanks for your help on this topic! Brendan is probably using a GPT
partitionned disk on a non-UEFI compatible machine. Hence, as you
noticed, the installer does not create a bios_grub partition.
This is a problem as this partition is necessary for GRUB and I think
that your patch is fixing the problem. The "auto-partition!" procedure
is also leaving a probably pre-existing ESP partition, but I don't
really understand how it appeared in the first place.
Brendan, did you use "manual partitioning" to create an ESP partition?
Hmm I forget what was on this drive. I used to have Windows 10 on it,
then I can't
remember. I may have installed Arch Linux on it. What ever was on it, I
just ran the
installer letting it do it's thing selecting Encrypted root with LVM
because I wanted to
see if that worked. it didn't, then I tried the default, before posting
the bug report.
Finally I went though with Miguel's patch selecting all the defaults and
that was
the result.
I feel the installer should not care what was on the drive to begin
with, it should just
format the drive how it sees fit. Why should the existing contents of
the drive
affect the outcome when we are reformatting everything anyway?
Thanks,
Mathieu