[ Dropping the CC to Chad here ]
On Sat, Aug 01, 2020 at 02:36:25PM +0100, Colin Watson wrote:
>On Sat, Aug 01, 2020 at 01:52:41PM +0100, Steve McIntyre wrote:
>> * Do we need to scan? if grub is installed and doing an upgrade and
>> there is only one disk of an appropriate type (BIOS with DOS, or
>> UEFI with GPT), then always install there?
>
>Possibly. I'd still be inclined to have a scan as a guard-rail in that
>case, since we'd need to have the code anyway, and the point is to try
>to discover the disk that the system booted from so by definition it
>must have GRUB there if it's to be valid.
Nod. Of course, it's a guess at best - we have ~no way to know *for
sure* which disk we actually booted off. It would be lovely if we did,
but there's no protocol for grub to pass on that information that I
can see.
>> * (Maybe) we could add an option for grub-pc to always grub-install
>> to *all* the BIOS-visible disks? Yes, I know there's a potential
>> for breakage there with multi-boot systems. Maybe only do this on
>> systems where os-prober has not found anything but the Debian
>> installation?
>
>One concern I have is filtering out things like optical drives, which
>are BIOS-visible but not sensible grub-install targets. I'm also
>slightly reluctant to add more invocations of os-prober while it's as
>slow as it can sometimes be. I do see the utility of this though.
Nod. Can we not rely on os-prober already having been run once and use
that data? (Sorry, not sure of the ordering here.)
>> * If we do add the code to scan boot sectors, maybe check all the
>> BIOS-visible disks and flag any that look like they have GRUB, but
>> are not our version? (Not sure how feasible this is without
>> digging!)
>
>Unfortunately I believe this to be essentially infeasible. As an
>illustration, this is the scan code which exists in the current postinst
>to support migration from GRUB Legacy, and believe me I didn't resort to
>this horror before trying to find more sensible alternatives:
>
> # In order to determine whether we accidentally ran grub-install without
> # upgrade-from-grub-legacy on versions older than 1.98+20100617-1, we need
> # to be able to scan a disk to determine whether GRUB 2 was installed in its
> # boot sector. This is specific to i386-pc (but that's the only platform
> # where we need it).
> scan_grub2()
> {
> if ! dd if="$1" bs=512 count=1 2>/dev/null | grep -aq GRUB; then
> # No version of GRUB is installed.
> return 1
> fi
>
> # The GRUB boot sector always starts with a JMP instruction.
> initial_jmp="$(dd if="$1" bs=2 count=1 2>/dev/null | od -Ax -tx1 | \
> head -n1 | cut -d' ' -f2,3)"
> [ "$initial_jmp" ] || return 1
> initial_jmp_opcode="${initial_jmp%% *}"
> [ "$initial_jmp_opcode" = eb ] || return 1
> initial_jmp_operand="${initial_jmp#* }"
> case $initial_jmp_operand in
> 47|4b|4c|63)
> # I believe this covers all versions of GRUB 2 up to the package
> # version where we gained a more explicit mechanism. GRUB Legacy
> # always had 48 here.
> return 0
> ;;
> esac
>
> return 1
> }
>
>The actual package version does get embedded in the boot loader, but
>only in the "normal" module, not anywhere that could be usefully
>discovered by a scan. Otherwise the best we could do would basically be
>a big list of signatures, which I'm not enthusiastic about.
Argh, yes. Basically what I expected, I'll be honest. Oh, hmmm -
that's the boot sector. Could we pick up on more from the embedded
binary "stage 1.5" lump? This is getting hairy, maybe, but
could/should be a wider thing to go upstream?
>> * For UEFI, I'd love to switch to using the monolithic GRUB image
>> even for non-signed use. It makes a lot of the issues go away if
>> ~all the modules necessary for boot are always built-in.
>
>I think I agree, though we should take that to a separate bug; I'd like
>to keep this one for the BIOS situation.
Agreed. Just something I thought to mention while it was in my
head. :-)
>> * Finally, we should also stop using debconf as a registry like we
>> are. It's annoying the DSA folks (at least). By all means use
>> debconf to help manage things, but we should be storing the lasting
>> config in a config file that people can edit. We already store some
>> of our stuff in /etc/default/grub, let's push more of our config
>> there?
>
>Agreed in general terms; this has been on my to-do list for a long time.
>Of course we need to consider the migration path carefully. In terms of
>specifics, I'm not sure I want to extend /etc/default/grub for this,
>though; that has configuration file management issues, and generally I
>don't really want to overload the upstream grub-mkconfig configuration
>file with packaging-specific things for grub-install. I'd be inclined
>to go for /etc/default/grub-pc instead, or maybe something under
>/etc/grub/.
Sure. The exact setup is something we can work out. But of course (?)
we *should* be dealing with this properly as a user-facing config
file. What's the problem with /etc/default/grub, OOI?
--
Steve McIntyre, Cambridge, UK. [email protected]
"Since phone messaging became popular, the young generation has lost the
ability to read or write anything that is longer than one hundred and sixty
characters." -- Ignatios Souvatzis
