#882766 Proposal: reinstate automated device selection, blacklisting d-i?

Package:
grub-installer
Source:
grub-installer
Submitter:
Cyril Brulebois
Date:
2017-11-27 14:51:08 UTC
Severity:
important
#882766#5
Date:
2017-11-26 14:34:54 UTC
From:
To:
Hi,

If records/recollection are correct, we've been prompting for the boot
device to install grub on since this upload:
| grub-installer (1.86) unstable; urgency=low
|
|   [ Vincent McIntyre ]
|   * Support menu selection of GRUB boot disk. Closes: #706112
|
|  -- Cyril Brulebois <kibi@debian.org>  Mon, 29 Apr 2013 13:53:27 +0200


One of the reasons was that there seemed to be no reliable way to detect
what device we've booted the installer from, and we've had issues with
wiping the d-i installation images for several years before that upload.

Proposal: restore the old device detection, and blacklist anything that
seems to be holding a Debian Installer image. Beware: we don't want to
trigger the same side effects as os-prober did (see os-prober uploads
between 1.72 and 1.75). One way to avoid the read-only mounting could be
to ensure a given token is present in a certain location of Debian
installation images.

Feedback welcome!


KiBi.
#882766#10
Date:
2017-11-26 17:53:07 UTC
From:
To:
The ISO images contain a directory .disk with some files.
# cat .disk/info
Debian GNU/Linux 9.2.1 "Stretch" - Official amd64 NETINST 20171013-13:07

Inside the d-i calling blkid /dev/sr0 outputs something like this:
/dev/sr0: UUID="2017-10-13-13-09-57-00" LABEL="Debian 9.2 amd n" TYPE="iso9660" .....

I think the first is more d-i specific.
#882766#15
Date:
2017-11-26 22:02:23 UTC
From:
To:
Dear Thomas,

Thomas Lange <lange@informatik.uni-koeln.de> (2017-11-26):

I'm pretty sure I did mention I would like to avoid having to mount
anything, so this is definitely a no-go.

Example of a problematic d-i environment with no information on the d-i
medium whatsoever:
| rootfs on / type rootfs (rw,size=792460k,nr_inodes=92575)
| none on /run type tmpfs (rw,nosuid,relatime,size=79248k,mode=755)
| none on /proc type proc (rw,relatime)
| none on /sys type sysfs (rw,relatime)
| devtmpfs on /dev type devtmpfs (rw,relatime,size=370312k,nr_inodes=92578,mode=755)
| devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

Looping over all devices under /dev/ and callling blkid on all of them
doesn't return anything here.


KiBi.
#882766#20
Date:
2017-11-26 23:15:23 UTC
From:
To:
    > I'm pretty sure I did mention I would like to avoid having to mount
    > anything, so this is definitely a no-go.
I missed that, sorry.

ls -l /dev/disk/by-label gives

Debian\x209.2.1\x20amd64\x20n -> ../../sr0

This is a kvm virtual machine booting from CD.
#882766#25
Date:
2017-11-26 23:45:00 UTC
From:
To:
After loading addition components, the CD is mounted and we can see
which device it is. I would guess that the additional components will
be loaded from the same device as we booted the installer.

Still have to check it when booting from USB.
#882766#30
Date:
2017-11-27 01:18:48 UTC
From:
To:
It would be good to make this change.

Is there some reason to not include a build stamp in the installer
initrd at, say, /build-stamp? This would be the same string as in
boot-screens/f1.txt (e.g. 20170615+deb9u2).

Regards
#882766#35
Date:
2017-11-27 14:49:25 UTC
From:
To:
    > ls -l /dev/disk/by-label gives

    > Debian\x209.2.1\x20amd64\x20n -> ../../sr0

    > This is a kvm virtual machine booting from CD.

Booting real hardware from USB stick with an buster netinst shows

Debian\x20buster-DO-a1\x20amd64\x20n -> ../../sdb1

After loading the additional components in the installer the USB stick
is mounted from /dev/sdb1 to /cdrom.