Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Colin Watson]

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.

>  * (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.

>  * 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.

>  * 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.

>  * 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/.

-- 
Colin Watson (he/him)                              [cjwatson at debian.org]