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

Groups > linux.debian.user > #225652 > unrolled thread

grub update and reinstallation

Back to article view | Back to linux.debian.user

Contents

  grub update and reinstallation Ross Boylan <rossboylan@stanfordalumni.org> - 2020-07-31 20:30 +0200
    Re: grub update and reinstallation Brian <ad44@cityscape.co.uk> - 2020-07-31 20:40 +0200
      Re: grub update and reinstallation Andrew Cater <amacater@gmail.com> - 2020-07-31 21:30 +0200
        Re: grub update and reinstallation Tom Dial <tddial@comcast.net> - 2020-08-01 09:10 +0200
          Re: grub update and reinstallation Graham Seaman <graham@theseamans.net> - 2020-08-01 13:30 +0200
            Re: grub update and reinstallation Sven Joachim <svenjoac@gmx.de> - 2020-08-01 15:10 +0200
              Re: grub update and reinstallation Graham Seaman <graham@theseamans.net> - 2020-08-01 19:30 +0200
                Re: grub update and reinstallation Andrew Cater <amacater@gmail.com> - 2020-08-01 22:00 +0200
                Re: grub update and reinstallation Tom Dial <tddial@comcast.net> - 2020-08-02 05:50 +0200
                  Re: grub update and reinstallation Graham Seaman <graham@theseamans.net> - 2020-08-03 00:00 +0200
                  Re: grub update and reinstallation Andrew Cater <amacater@gmail.com> - 2020-08-03 18:40 +0200
                  Re: grub update and reinstallation Leslie Rhorer <lesrhorer@att.net> - 2020-08-03 23:50 +0200
            Re: grub update and reinstallation Tom Dial <tddial@comcast.net> - 2020-08-01 22:40 +0200
      Re: grub update and reinstallation Ross Boylan <rossboylan@stanfordalumni.org> - 2020-08-01 00:40 +0200

#225652 — grub update and reinstallation

[Multipart message — attachments visible in raw view] — view raw

The recent security updates to grub inspire two questions:
1) Do the changes require updating the info put in the boot sector?
2) Does the upgrade do that installation automatically?

I couldn't find documentation that addressed either issue, though I think
the answer to 2) for my system is yes.

When I did the upgrade the terminal showed
-----------------------------------------------------
Setting up grub-pc (2.02+dfsg1-20+deb10u1) ...
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
--------------------------------
The second line suggests an installation happened, though it's not clear.
In particular, it doesn't mention any particular installation location.

Mucking around in the scripts,
/var/lib/dpkg/info/grub-pc.postinst includes
              if grub-install --target=i386-pc --force --no-floppy
$real_device ; then
and grub-pc/install-devices is set to a plausible value in
/var/cache/debconf/config.data.
So my guess is it is installed there.  But I'm not sure the actual
execution hits that code path.

It is perhaps reassuring that "Installing for" does not occur in the
postinst script, so that it seems likely to have come from the invocation
of grub-install.

Thanks.
Ross Boylan

[toc] | [next] | [standalone]

#225653

On Fri 31 Jul 2020 at 11:21:06 -0700, Ross Boylan wrote:

> The recent security updates to grub inspire two questions:
> 1) Do the changes require updating the info put in the boot sector?

Yes.

> 2) Does the upgrade do that installation automatically?

Yes.

> I couldn't find documentation that addressed either issue, though I think
> the answer to 2) for my system is yes.
> 
> When I did the upgrade the terminal showed
> -----------------------------------------------------
> Setting up grub-pc (2.02+dfsg1-20+deb10u1) ...
> Installing for i386-pc platform.
> Installation finished. No error reported.
> Generating grub configuration file ...
> --------------------------------
> The second line suggests an installation happened, though it's not clear.

It is abundantly clear. What else could be meant?

> In particular, it doesn't mention any particular installation location.

Why should it?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#225660

[Multipart message — attachments visible in raw view] — view raw

In addition - this is booting in legacy/BIOS mode not in UEFI - otherwise
it would have mentioned grub-efi

On Fri, Jul 31, 2020 at 6:38 PM Brian <ad44@cityscape.co.uk> wrote:

> On Fri 31 Jul 2020 at 11:21:06 -0700, Ross Boylan wrote:
>
> > The recent security updates to grub inspire two questions:
> > 1) Do the changes require updating the info put in the boot sector?
>
> Yes.
>
> > 2) Does the upgrade do that installation automatically?
>
> Yes.
>
> > I couldn't find documentation that addressed either issue, though I think
> > the answer to 2) for my system is yes.
> >
> > When I did the upgrade the terminal showed
> > -----------------------------------------------------
> > Setting up grub-pc (2.02+dfsg1-20+deb10u1) ...
> > Installing for i386-pc platform.
> > Installation finished. No error reported.
> > Generating grub configuration file ...
> > --------------------------------
> > The second line suggests an installation happened, though it's not clear.
>
> It is abundantly clear. What else could be meant?
>
> > In particular, it doesn't mention any particular installation location.
>
> Why should it?
>
> --
> Brian.
>
>

[toc] | [prev] | [next] | [standalone]

#225675

On 7/31/20 13:27, Andrew Cater wrote:
> In addition - this is booting in legacy/BIOS mode not in UEFI -
> otherwise it would have mentioned grub-efi
> 
> On Fri, Jul 31, 2020 at 6:38 PM Brian <ad44@cityscape.co.uk
> <mailto:ad44@cityscape.co.uk>> wrote:
> 
>     On Fri 31 Jul 2020 at 11:21:06 -0700, Ross Boylan wrote:
> 
>     > The recent security updates to grub inspire two questions:
>     > 1) Do the changes require updating the info put in the boot sector?
> 
>     Yes.
> 
>     > 2) Does the upgrade do that installation automatically?
> 
>     Yes.

But not always, it seems. I have a laptop that became unbootable because
the initial loader failed to find a symbol (grub_calloc) and balked.
Like the one mentioned here, it uses legacy boot. One explanation has it
that this happened because the MBR and the remainder of grub were not
both updated or were updated with slightly incompatible data.

One fix appears to be to reinstall grub using a rescue CD or another
system. That worked for me.

Tom Dial

> 
>     > I couldn't find documentation that addressed either issue, though
>     I think
>     > the answer to 2) for my system is yes.
>     >
>     > When I did the upgrade the terminal showed
>     > -----------------------------------------------------
>     > Setting up grub-pc (2.02+dfsg1-20+deb10u1) ...
>     > Installing for i386-pc platform.
>     > Installation finished. No error reported.
>     > Generating grub configuration file ...
>     > --------------------------------
>     > The second line suggests an installation happened, though it's not
>     clear.
> 
>     It is abundantly clear. What else could be meant?
> 
>     > In particular, it doesn't mention any particular installation
>     location.
> 
>     Why should it?
> 
>     -- 
>     Brian.
> 

[toc] | [prev] | [next] | [standalone]

#225689

On 01/08/2020 07:50, Tom Dial wrote:
> I have a laptop that became unbootable because
> the initial loader failed to find a symbol (grub_calloc) and balked.
> Like the one mentioned here, it uses legacy boot. One explanation has it
> that this happened because the MBR and the remainder of grub were not
> both updated or were updated with slightly incompatible data.
>
> One fix appears to be to reinstall grub using a rescue CD or another
> system. That worked for me.

My home server sits in my loft managing comms with the outside world; 
yesterday it overheated (not a surprise) and went down. On reboot after 
cooling it came back up with the grub_calloc problem, so like Tom I 
reinstalled after which it appears to be OK.

BUT because I have no idea why the original problem occurred, or why a 
reinstall fixed the problem, I have no idea if this is a permanent fix, 
or if I have a system which is liable to fail to reboot again in the 
future. Does anyone know? It's a very simple single drive system with 
legacy boot. I run it with security updates on auto, and check for other 
updates manually once a week or so. Should I change this pattern for a 
while while possible grub problems are sorted upstream?

Graham

[toc] | [prev] | [next] | [standalone]

#225698

On 2020-08-01 12:23 +0100, Graham Seaman wrote:

> On 01/08/2020 07:50, Tom Dial wrote:
>> I have a laptop that became unbootable because
>> the initial loader failed to find a symbol (grub_calloc) and balked.
>> Like the one mentioned here, it uses legacy boot. One explanation has it
>> that this happened because the MBR and the remainder of grub were not
>> both updated or were updated with slightly incompatible data.
>>
>> One fix appears to be to reinstall grub using a rescue CD or another
>> system. That worked for me.
>
> My home server sits in my loft managing comms with the outside world;
> yesterday it overheated (not a surprise) and went down.

You should probably open the machine up and clean it. :-)

> On reboot
> after cooling it came back up with the grub_calloc problem, so like
> Tom I reinstalled after which it appears to be OK.
>
> BUT because I have no idea why the original problem occurred, or why a
> reinstall fixed the problem, I have no idea if this is a permanent
> fix, or if I have a system which is liable to fail to reboot again in
> the future. Does anyone know? It's a very simple single drive system
> with legacy boot.

In this case the error is quite unlikely to occur, I have no idea why it
happened for you in the first place.

> I run it with security updates on auto, and check
> for other updates manually once a week or so. Should I change this
> pattern for a while while possible grub problems are sorted upstream?

I would recommend to run "dpkg-reconfigure grub-pc".  This should bring
up three dialogues, the last of which asks for the disk(s) to install grub
on.  On your system this is most likely /dev/sda.

Or get the device name from the debconf database:

readlink -f $(debconf-show grub-pc 2>/dev/null | grep grub-pc/install_devices: | cut -d ':' -f2)

Cheers,
       Sven

[toc] | [prev] | [next] | [standalone]

#225707

On 01/08/2020 14:00, Sven Joachim wrote:
> On 2020-08-01 12:23 +0100, Graham Seaman wrote:
> 
>> On 01/08/2020 07:50, Tom Dial wrote:
>>> I have a laptop that became unbootable because
>>> the initial loader failed to find a symbol (grub_calloc) and balked.
>>> Like the one mentioned here, it uses legacy boot. One explanation has it
>>> that this happened because the MBR and the remainder of grub were not
>>> both updated or were updated with slightly incompatible data.
>>>
>>> One fix appears to be to reinstall grub using a rescue CD or another
>>> system. That worked for me.
>>
>> My home server sits in my loft managing comms with the outside world;
>> yesterday it overheated (not a surprise) and went down.
> 
> You should probably open the machine up and clean it. :-)

The outdoor temperature was 38 centigrade; in my loft it was
considerably more. The machine is spotless :-)

> 
>> On reboot
>> after cooling it came back up with the grub_calloc problem, so like
>> Tom I reinstalled after which it appears to be OK.
>>
>> BUT because I have no idea why the original problem occurred, or why a
>> reinstall fixed the problem, I have no idea if this is a permanent
>> fix, or if I have a system which is liable to fail to reboot again in
>> the future. Does anyone know? It's a very simple single drive system
>> with legacy boot.
> 
> In this case the error is quite unlikely to occur, I have no idea why it
> happened for you in the first place.
>

It has happened to quite a range of users in the last week (search for
'grub calloc') - users running ubuntu, lubuntu, debian-mint, vanilla
debian, that I've seen. So I assume its some upstream problem with grub.
Some people seem to think the problem only shows on multi-boot-disk or
raid systems, but that didn't apply in my case.


>> I run it with security updates on auto, and check
>> for other updates manually once a week or so. Should I change this
>> pattern for a while while possible grub problems are sorted upstream?
> 
> I would recommend to run "dpkg-reconfigure grub-pc".  This should bring
> up three dialogues, the last of which asks for the disk(s) to install grub
> on.  On your system this is most likely /dev/sda.
>

I already reinstalled grub-pc (using a rescue-usb) , that's how I got
the system booting again. But I don't know if the current grub is
trustable or not.

Graham


> Or get the device name from the debconf database:
> 
> readlink -f $(debconf-show grub-pc 2>/dev/null | grep grub-pc/install_devices: | cut -d ':' -f2)
> 
> Cheers,
>        Sven
> 

[toc] | [prev] | [next] | [standalone]

#225712

[Multipart message — attachments visible in raw view] — view raw

Folk are onto this: the Buster point release is happening right now. People
are aware: the issue is also being raised in debian-cd. There are
workarounds - it will be sorted.

On Sat, Aug 1, 2020 at 5:20 PM Graham Seaman <graham@theseamans.net> wrote:

>
>
> On 01/08/2020 14:00, Sven Joachim wrote:
> > On 2020-08-01 12:23 +0100, Graham Seaman wrote:
> >
> >> On 01/08/2020 07:50, Tom Dial wrote:
> >>> I have a laptop that became unbootable because
> >>> the initial loader failed to find a symbol (grub_calloc) and balked.
> >>> Like the one mentioned here, it uses legacy boot. One explanation has
> it
> >>> that this happened because the MBR and the remainder of grub were not
> >>> both updated or were updated with slightly incompatible data.
> >>>
> >>> One fix appears to be to reinstall grub using a rescue CD or another
> >>> system. That worked for me.
> >>
> >> My home server sits in my loft managing comms with the outside world;
> >> yesterday it overheated (not a surprise) and went down.
> >
> > You should probably open the machine up and clean it. :-)
>
> The outdoor temperature was 38 centigrade; in my loft it was
> considerably more. The machine is spotless :-)
>
> >
> >> On reboot
> >> after cooling it came back up with the grub_calloc problem, so like
> >> Tom I reinstalled after which it appears to be OK.
> >>
> >> BUT because I have no idea why the original problem occurred, or why a
> >> reinstall fixed the problem, I have no idea if this is a permanent
> >> fix, or if I have a system which is liable to fail to reboot again in
> >> the future. Does anyone know? It's a very simple single drive system
> >> with legacy boot.
> >
> > In this case the error is quite unlikely to occur, I have no idea why it
> > happened for you in the first place.
> >
>
> It has happened to quite a range of users in the last week (search for
> 'grub calloc') - users running ubuntu, lubuntu, debian-mint, vanilla
> debian, that I've seen. So I assume its some upstream problem with grub.
> Some people seem to think the problem only shows on multi-boot-disk or
> raid systems, but that didn't apply in my case.
>
>
> >> I run it with security updates on auto, and check
> >> for other updates manually once a week or so. Should I change this
> >> pattern for a while while possible grub problems are sorted upstream?
> >
> > I would recommend to run "dpkg-reconfigure grub-pc".  This should bring
> > up three dialogues, the last of which asks for the disk(s) to install
> grub
> > on.  On your system this is most likely /dev/sda.
> >
>
> I already reinstalled grub-pc (using a rescue-usb) , that's how I got
> the system booting again. But I don't know if the current grub is
> trustable or not.
>
> Graham
>
>
> > Or get the device name from the debconf database:
> >
> > readlink -f $(debconf-show grub-pc 2>/dev/null | grep
> grub-pc/install_devices: | cut -d ':' -f2)
> >
> > Cheers,
> >        Sven
> >
>
>

[toc] | [prev] | [next] | [standalone]

#225724

On 8/1/20 11:09, Graham Seaman wrote:
> On 01/08/2020 14:00, Sven Joachim wrote:
>> On 2020-08-01 12:23 +0100, Graham Seaman wrote:
>>
>>> On 01/08/2020 07:50, Tom Dial wrote:
>>>> I have a laptop that became unbootable because
>>>> the initial loader failed to find a symbol (grub_calloc) and balked.
>>>> Like the one mentioned here, it uses legacy boot. One explanation has it
>>>> that this happened because the MBR and the remainder of grub were not
>>>> both updated or were updated with slightly incompatible data.
>>>>
>>>> One fix appears to be to reinstall grub using a rescue CD or another
>>>> system. That worked for me.
>>>
>>> My home server sits in my loft managing comms with the outside world;
>>> yesterday it overheated (not a surprise) and went down.
>>
>> You should probably open the machine up and clean it. :-)
> 
> The outdoor temperature was 38 centigrade; in my loft it was
> considerably more. The machine is spotless :-)
> 
>>
>>> On reboot
>>> after cooling it came back up with the grub_calloc problem, so like
>>> Tom I reinstalled after which it appears to be OK.
>>>
>>> BUT because I have no idea why the original problem occurred, or why a
>>> reinstall fixed the problem, I have no idea if this is a permanent
>>> fix, or if I have a system which is liable to fail to reboot again in
>>> the future. Does anyone know? It's a very simple single drive system
>>> with legacy boot.
>>
>> In this case the error is quite unlikely to occur, I have no idea why it
>> happened for you in the first place.
>>
> 
> It has happened to quite a range of users in the last week (search for
> 'grub calloc') - users running ubuntu, lubuntu, debian-mint, vanilla
> debian, that I've seen. So I assume its some upstream problem with grub.
> Some people seem to think the problem only shows on multi-boot-disk or
> raid systems, but that didn't apply in my case.
> 

Or mine.

> 
>>> I run it with security updates on auto, and check
>>> for other updates manually once a week or so. Should I change this
>>> pattern for a while while possible grub problems are sorted upstream?
>>
>> I would recommend to run "dpkg-reconfigure grub-pc".  This should bring
>> up three dialogues, the last of which asks for the disk(s) to install grub
>> on.  On your system this is most likely /dev/sda.
>>
> 
> I already reinstalled grub-pc (using a rescue-usb) , that's how I got
> the system booting again. But I don't know if the current grub is
> trustable or not.

My experience, now on eight machines, indicates that it should be if the
installed, configured, and used versions of grub components is

2.02+dfsg1-20+deb10u2.

I could be wrong, but here it has been the case for both UEFI (and root
on ZFS) and legacy boot setups, on both i386 and amd64. The only
exception is one root-on-ZFS VM that was slightly broken beforehand and
declines to boot for reasons I am fairly sure are unrelated to grub
installation.

Tom Dial


> 
> Graham
> 
> 
>> Or get the device name from the debconf database:
>>
>> readlink -f $(debconf-show grub-pc 2>/dev/null | grep grub-pc/install_devices: | cut -d ':' -f2)
>>
>> Cheers,
>>        Sven
>>

[toc] | [prev] | [next] | [standalone]

#225760

On 02/08/2020 04:31, Tom Dial wrote:
> On 8/1/20 11:09, Graham Seaman wrote:
>> I already reinstalled grub-pc (using a rescue-usb) , that's how I got
>> the system booting again. But I don't know if the current grub is
>> trustable or not.
> My experience, now on eight machines, indicates that it should be if the
> installed, configured, and used versions of grub components is
>
> 2.02+dfsg1-20+deb10u2.
>
> I could be wrong, but here it has been the case for both UEFI (and root
> on ZFS) and legacy boot setups, on both i386 and amd64. The only
> exception is one root-on-ZFS VM that was slightly broken beforehand and
> declines to boot for reasons I am fairly sure are unrelated to grub
> installation.
>
> Tom Dial2.02+dfsg1-20+deb10u2

OK, I have 2.02+dfsg1-20+deb10u2 on 2 debian systems which seem to be 
OK. Thanks for confirming!

2.02~beta2-36 seems to be ok on a UEFI ubuntu system.

Graham


>
>> Graham
>>
>>
>>> Or get the device name from the debconf database:
>>>
>>> readlink -f $(debconf-show grub-pc 2>/dev/null | grep grub-pc/install_devices: | cut -d ':' -f2)
>>>
>>> Cheers,
>>>         Sven
>>>

[toc] | [prev] | [next] | [standalone]

#225781

[Multipart message — attachments visible in raw view] — view raw

hmh@debian.org - Henrique de Moraes Holschuh posted this on LWN.net
earlier. It's about as clear as it gets so I'm cheating and copying this
direct into debian-cd so that others see it: thanks for the clarity,
Henrique

>>

For Debian, most of the issues reported with the security update were
linked to bad configuration at package update time, and an extremely
annoying shortcoming of the package: it cannot rollback when it fails to
install to the boot media, and it doesn't crash and burn the update run
either, so it will not be noticed if you are not reading the update run
output.

Run dpkg-reconfigure on your grub2 variant, so that it asks for your boot
devices. Ensure it is correct, and let it update the bootloader on disk.
Watch to ensure no errors are reported (i.e. do it from the terminal, not
some GUI). This will sync everything.

Examples:
dpkg-reconfigure grub-efi-amd64
dpkg-reconfigure grub-pc

The other issue was a chain loader breackage on EFI, already fixed in the
current packages.

<<

[The second issue affected chainloading EFI  for, say, a Debian / Windows
10 dual boot]

The fixed packages are all there now
ZFS on Debian - strictly, it's off-topic here since it's not supported in
Debian at the moment.

On Mon, Aug 3, 2020 at 4:18 PM D. R. Evans <doc.evans@gmail.com> wrote:

> Tom Dial wrote on 8/1/20 9:31 PM:
>
> >
> > My experience, now on eight machines, indicates that it should be if the
> > installed, configured, and used versions of grub components is
> >
> > 2.02+dfsg1-20+deb10u2.
> >
> > I could be wrong, but here it has been the case for both UEFI (and root
> > on ZFS) and legacy boot setups, on both i386 and amd64. The only
> > exception is one root-on-ZFS VM that was slightly broken beforehand and
> > declines to boot for reasons I am fairly sure are unrelated to grub
> > installation.
> >
>
> So if one has two bootable drives (call them A and B), will this update
> update
> the MBR on both A and B, not just the one that happened to have been used
> for
> the most recent boot?
>
> I ask because I have a couple of root-on-ZFS BIOS-boot machines that are
> both
> configured as two-disk mirrors and I want to be sure that, following this
> upgrade, I can still boot off either of the two disks (as I can at the
> moment)
> without having to perform any manual changes.
>
> The use case is, if it's not obvious, that if under normal circumstances
> disk
> A is used for booting, but then at some point A fails (so ZFS is running
> in a
> degraded state) I can still boot from drive B if necessary.
>
>   Doc
>
> --
> Web:  http://enginehousebooks.com/drevans
>
>

[toc] | [prev] | [next] | [standalone]

#225792

On 8/3/2020 11:18 AM, D. R. Evans wrote:
> Tom Dial wrote on 8/1/20 9:31 PM:
> 
>>
>> My experience, now on eight machines, indicates that it should be if the
>> installed, configured, and used versions of grub components is
>>
>> 2.02+dfsg1-20+deb10u2.
>>
>> I could be wrong, but here it has been the case for both UEFI (and root
>> on ZFS) and legacy boot setups, on both i386 and amd64. The only
>> exception is one root-on-ZFS VM that was slightly broken beforehand and
>> declines to boot for reasons I am fairly sure are unrelated to grub
>> installation.
>>
> 
> So if one has two bootable drives (call them A and B), will this update update
> the MBR on both A and B, not just the one that happened to have been used for
> the most recent boot?

	What update, specifically?  With multiple boot targets, in general any 
updates to boot process must be updated on the individual targets 
separately.  This is true of both UEFI and MBR boot processes.


> I ask because I have a couple of root-on-ZFS BIOS-boot machines that are both
> configured as two-disk mirrors and I want to be sure that, following this
> upgrade, I can still boot off either of the two disks (as I can at the moment)
> without having to perform any manual changes.

	You need to install GRUB on all of the mirrors, two in this case. 
Issue the commands `grub-install /dev/sda` and `grub-install /dev/sdb`, 
assuming the mirrors are /dev/sda and /dev/sdb.

	I am given to understand the ZFS pools will also need to be duplicated.

[toc] | [prev] | [next] | [standalone]

#225713

On 8/1/20 05:23, Graham Seaman wrote:
> On 01/08/2020 07:50, Tom Dial wrote:
>> I have a laptop that became unbootable because
>> the initial loader failed to find a symbol (grub_calloc) and balked.
>> Like the one mentioned here, it uses legacy boot. One explanation has it
>> that this happened because the MBR and the remainder of grub were not
>> both updated or were updated with slightly incompatible data.
>>
>> One fix appears to be to reinstall grub using a rescue CD or another
>> system. That worked for me.
> 
> My home server sits in my loft managing comms with the outside world;
> yesterday it overheated (not a surprise) and went down. On reboot after
> cooling it came back up with the grub_calloc problem, so like Tom I
> reinstalled after which it appears to be OK.
> 
> BUT because I have no idea why the original problem occurred, or why a
> reinstall fixed the problem, I have no idea if this is a permanent fix,
> or if I have a system which is liable to fail to reboot again in the
> future. Does anyone know? It's a very simple single drive system with
> legacy boot. I run it with security updates on auto, and check for other
> updates manually once a week or so. Should I change this pattern for a
> while while possible grub problems are sorted upstream?

My slightly educated and informed, and partly imagined, guess is that
the original problem - inability to find the grub_calloc symbol -
resulted from a packaging or installation glitch that left the boot
block that referenced grub_calloc out of sync with the main part of grub
with the piece that had the symbol.

If that is so, and if reinstalling grub fixes the problem at all, the
fix should be final. The grub-install done in conjunction with upgrade
to 10.5 just worked OK, as did the previous installation of
grub 2.02+dfsg1-20+deb10u2. I do not know if the fact it was on a VM
might have changed the outcome.

Tom Dial

> 
> Graham

[toc] | [prev] | [next] | [standalone]

#225667

[Multipart message — attachments visible in raw view] — view raw

Thanks for the information.  Your questions are probably rhetorical, but
I've responded anyway, below :)

On Fri, Jul 31, 2020 at 11:38 AM Brian <ad44@cityscape.co.uk> wrote:

> On Fri 31 Jul 2020 at 11:21:06 -0700, Ross Boylan wrote:
> ........
> > When I did the upgrade the terminal showed
> > -----------------------------------------------------
> > Setting up grub-pc (2.02+dfsg1-20+deb10u1) ...
> > Installing for i386-pc platform.
> > Installation finished. No error reported.
> > Generating grub configuration file ...
> > --------------------------------
> > The second line suggests an installation happened, though it's not clear.
>
> It is abundantly clear. What else could be meant?
>

That a debian package has been installed.  The grub.cfg was updated.  That
some files somewhere other than my boot sector have been updated.


> > In particular, it doesn't mention any particular installation location.
>
> Why should it?
>
So I can tell what has been updated, having more than one disk.   If I
interpret the script and config options correctly, it might even be
possible to have it update more than one location automatically.  Also,
giving the installation location would lessen the ambiguity referred to
above.

I think the problem is that the messages (I'm guessing lines 2 and 3 in my
excerpt above are from grub-install) are designed in the context of
invoking grub-install from the command line, in which case further
information would be pointless.  But when it's invoked in the context of a
Debian package upgrade, the context is less evident.

Ross

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web