bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.

[Bengt Richter <bokr@bokr.com>]

Hi,

On +2020-10-19 16:57:49 +1100, Brendan Tildesley wrote:
> 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
>

I agree that existing contents should not matter, UNLESS:
You are about to shoot yourself in the foot by overwriting the wrong disk.

I think it is risky to target disks just by /dev/<kname>, so if doing that,
with e.g. /dev/sdb, I would like a safe confirmation dialog displaying the output of

$ lsblk -o mountpoint,type,kname,model,serial /dev/sdb
MOUNTPOINT      TYPE  KNAME     MODEL              SERIAL
                disk  sdb       SanDisk_3.2Gen1    xxxxxx...

with automatic verification that it is not mounted, is type disk, and asking me
if the model and serial number look right. The nice thing about the serial number
is (AFAIK) that it persists for selection even after zapping GPT/MBR UUIDs.

Similar checks before overwriting any pre-existing disk or partition, please. 

Maybe also have a target-disk-serial parameter that can be part of my-system.scm
to lock in the right target disk? Similary for partitions for /boot and / and any others.

(Hm, BTW, how are stable disk type, model and serial number lsblk outputs above
provided for virtual disks? )

[later]
Hm, I decided to test the serial number persistence, and 
the brand new Sandisk_3.2Gen1 made lsblk show a whopping 120-character string
for that xxxxxx... serial, but after zapping it fully with gdisk, the output
was the first 39 characters, Presumably gdisk enforced a 40-byte
buffer size with a null in the last byte.

BUT: Waitaminit -- how could it do that if that buffer was manufactured read-only??
I'll try dd-ing zeroes over the front end, and seeing if there's a serial after that...

So it that a bug in lsblk, or in SanDisk manufacturing?
Well, the confirmation dialog would work either way, but the target-disk-serial parameter
would have to do a prefix-match or something, until all parties get their acts together ;-)
[later]
zapped the first 1GiB of /dev/sdb with dd, and lsblk returned 39 chars like after gdisk zap,
BUT: now it's back to the same long number, which also shows up at /dev/disk/by-id/*

Meanwhile, did: apt install sdparm (mentioned at [1]), and then sdparm got me the first 20 characters
of lsblk's version:

--8<---------------cut here---------------start------------->8---
sudo sdparm --page=sn /dev/sdb
[sudo] password for bokr: 
    /dev/sdb:  USB   SanDisk 3.2Gen1  1.00
Unit serial number VPD page:
  xxxxxxxxxxxxxxxxxxxx
--8<---------------cut here---------------end--------------->8---

and lsblk and /dev/disk/by-id both show the original long serial, 
which suggests they share some code, since they agree and both
disagree with the 20-char version from sdparm.

Per [1], the serial number isn't stored in the data writeable part,
it's in the scsi controller innards, retrieved by saying the right
thing to the controller, unlike other ways of serializing storage.

But is sdparm right? 20 characters seems stingy.

┌──────────────────────────────────┐
│ ISTM there's a bug somewhere ;-) │
└──────────────────────────────────┘

I'm mCurrently running (per uname -a):
Linux LionPure 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux

...without guix though, sorry, I like guix :/
(though there's lots of scraps around, until I can install one with absolute
minimal use of sudo :) 

[1] https://stackoverflow.com/questions/2432759/usb-drive-serial-number-under-linux-c

HTH make things better (at least with the confirmation dialog part :)
And maybe a clue to a bug.
-- 
Regards,
Bengt Richter