Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1020063

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

Show all headers | View raw

[ 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.                                steve@einval.com
"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

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Paul Menzel <pmenzel@molgen.mpg.de> - 2020-07-31 00:00 +0200
  Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Paul Menzel <pmenzel@molgen.mpg.de> - 2020-07-31 06:40 +0200
  Bug#966575: I was affected as well Norbert Kiesel <nkiesel@gmail.com> - 2020-07-31 08:40 +0200
    Bug#966575: I was affected as well Steve McIntyre <93sam@debian.org> - 2020-07-31 15:30 +0200
  Bug#966575: Security update can break grub - grub_calloc not found Geoff Gibbs <g.gibbs42@gmx.co.uk> - 2020-07-31 13:00 +0200
    Bug#966575: Security update can break grub - grub_calloc not found Steve McIntyre <steve@einval.com> - 2020-07-31 15:40 +0200
      Bug#966575: Security update can break grub - grub_calloc not found Geoff Gibbs <g.gibbs42@gmx.co.uk> - 2020-07-31 16:10 +0200
        Bug#966575: Security update can break grub - grub_calloc not found Steve McIntyre <93sam@debian.org> - 2020-07-31 16:30 +0200
        Bug#966575: Security update can break grub - grub_calloc not found Colin Watson <cjwatson@debian.org> - 2020-08-01 01:10 +0200
  Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Steve McIntyre <93sam@debian.org> - 2020-07-31 15:30 +0200
  Bug#966575: grub-pc: error: symbol `grub_calloc' not found Steve McIntyre <93sam@debian.org> - 2020-07-31 15:40 +0200
  Bug#966575: same error message here cacatoes@tuxfamily.org - 2020-07-31 23:00 +0200
  Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Chad Phillips <thehunmonkgroup@gmail.com> - 2020-07-31 23:10 +0200
    Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Colin Watson <cjwatson@debian.org> - 2020-08-01 01:00 +0200
      Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Steve McIntyre <93sam@debian.org> - 2020-08-01 15:00 +0200
        Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Colin Watson <cjwatson@debian.org> - 2020-08-01 15:40 +0200
          Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Steve McIntyre <93sam@debian.org> - 2020-08-01 16:40 +0200
  Bug#966575: same error message here Colin Watson <cjwatson@debian.org> - 2020-08-01 01:10 +0200
  Bug#966575: grub-pc: error: symbol `grub_calloc' not found. MichaIng <micha@dietpi.com> - 2020-08-01 01:30 +0200
  Bug#966575: same error message here Colin Watson <cjwatson@debian.org> - 2020-08-01 02:10 +0200
  Bug#966575: Requested information about affected system (two disks, no raid) "Christoph K." <christoph@kobenetz.de> - 2020-08-03 14:10 +0200
  Bug#966575: How to fix LLVM/LUKS installs? Todd Howe <todhowe@sourcefire.com> - 2020-08-11 19:00 +0200
    Bug#966575: How to fix LLVM/LUKS installs? Colin Watson <cjwatson@debian.org> - 2020-08-11 19:10 +0200

csiph-web