Upgrade from Lucid to Precise results in broken grub configuration

Bug #949992 reported by Rick McBride
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Performed update-manager -d upgrade from lucid VM to precise. On completion, rebooted, and rather than Precise, I'm confronted with a

grub>

prompt.

Attempted recovery by setting root and loading config, but get "unknown command hwmatch" when it tries to load the grub.cfg.

Manually loading vmlinuz and initrd after setting root only gets me as far as a busybox prompt.

Obviously I can't get to the point where I can run ubuntu-bug in that VM, so my ability to get logs is currently limited.

I'm still attempting recovery of the VM, as it's blocking further Ubuntu One upgrade testing that I'm engaged in. I'll add further information if/as I find it.
---
ApportVersion: 1.94.1-0ubuntu1
Architecture: amd64
DistroRelease: Ubuntu 12.04
GsettingsChanges:
 com.ubuntu.update-manager first-run false
 com.ubuntu.update-manager launch-time 1331071487
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
Package: update-manager 1:0.156.7
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
Tags: precise dist-upgrade
Uname: Linux 3.2.0-18-generic x86_64
UpgradeStatus: Upgraded to precise on 2012-03-07 (0 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Revision history for this message
Rick McBride (rmcbride) wrote :

grub reinstall from live CD image seems to have worked. I'm not sure what forensics would be useful here...

Revision history for this message
Brian Murray (brian-murray) wrote :

It would be helpful if you were to run apport-collect 949992 from the system you had the issue with as this should collect the log files in /var/log/dist-upgrade which will help us debug the issue. Thanks!

affects: ubuntu → update-manager (Ubuntu)
Changed in update-manager (Ubuntu):
status: New → Incomplete
Revision history for this message
Rick McBride (rmcbride) wrote :

running that now.

tags: added: apport-collected dist-upgrade precise
description: updated
Revision history for this message
Rick McBride (rmcbride) wrote : Dependencies.txt

apport information

Revision history for this message
Rick McBride (rmcbride) wrote : VarLogDistupgradeAptHistorylog.txt

apport information

Revision history for this message
Rick McBride (rmcbride) wrote : VarLogDistupgradeAptclonesystemstate.tar.gz

apport information

Revision history for this message
Rick McBride (rmcbride) wrote : VarLogDistupgradeAptlog.txt

apport information

Revision history for this message
Rick McBride (rmcbride) wrote : VarLogDistupgradeApttermlog.gz

apport information

Revision history for this message
Rick McBride (rmcbride) wrote : VarLogDistupgradeLspcitxt.txt

apport information

Revision history for this message
Rick McBride (rmcbride) wrote : VarLogDistupgradeMainlog.txt

apport information

Revision history for this message
Rick McBride (rmcbride) wrote : VarLogDistupgradeTermlog.txt

apport information

Changed in update-manager (Ubuntu):
status: Incomplete → New
Revision history for this message
Brian Murray (brian-murray) wrote :

I haven't seen this before:

Setting up grub-pc (1.99-17ubuntu1) ...^M
Removing update-grub hooks from /etc/kernel-img.conf in favour of^M
/etc/kernel/ hooks.^M
Replacing config file /etc/default/grub with new version^M
Generating grub.cfg ...^M

Revision history for this message
Colin Watson (cjwatson) wrote :

Could you show me the output of:

  sudo debconf-show grub-pc

and also describe the disks attached to this VM?

(The debconf configuration may now be correct, though, in which case there's not much more to be done.)

Revision history for this message
Colin Watson (cjwatson) wrote :

Briefly, the problem is almost certainly that grub-pc's debconf configuration was misconfigured such that it failed to actually install a new version of the boot loader such that the VM would boot from it, but it upgraded the configuration file anyway. There is no guarantee that new configuration files will be compatible with old boot loaders; if the boot loader isn't properly installed on upgrade, that's an invalid state.

Revision history for this message
Rick McBride (rmcbride) wrote :

  grub2/kfreebsd_cmdline:
  grub2/device_map_regenerated:
* grub2/linux_cmdline:
* grub-pc/install_devices_empty: true
  grub-pc/install_devices_failed: false
  grub-pc/chainload_from_menu.lst: true
  grub-pc/hidden_timeout: true
  grub-pc/timeout: 10
  grub-pc/kopt_extracted: false
* grub-pc/install_devices:
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/disk_description:
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/partition_description:
  grub-pc/install_devices_disks_changed:
* grub2/linux_cmdline_default: quiet splash
  grub-pc/mixed_legacy_and_grub2: true

Revision history for this message
Rick McBride (rmcbride) wrote :

the only disk associated with this VM is a single 28GB volume.

boot partition is vda1, virtio bus, raw format.

The VM itself is a clone of a reference Lucid image I've been keeping for tests like this. if the configuration is somehow invalid, I'd like to know how to correct it.

Revision history for this message
Rick McBride (rmcbride) wrote :

I'm going to get info from the pre-upgrade version of the system (I've been cloning along the way)

Revision history for this message
Rick McBride (rmcbride) wrote :

from the lucid system pre-update:

  grub-pc/kopt_extracted: false
  grub2/kfreebsd_cmdline:
* grub-pc/install_devices:
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/disk_description:
* grub2/linux_cmdline:
* grub-pc/install_devices_empty: true
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/partition_description:
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_disks_changed:
* grub2/linux_cmdline_default: quiet splash
  grub-pc/chainload_from_menu.lst: true
  grub-pc/hidden_timeout: true
  grub-pc/timeout: 10

Revision history for this message
Colin Watson (cjwatson) wrote :

You should run 'sudo dpkg-reconfigure grub-pc' and instruct it to install the boot loader somewhere, probably /dev/vda.

The debconf database shows that the following question was presented to you at some point:

  You chose not to install GRUB to any devices. If you continue, the boot loader may not be properly configured, and when this computer next starts up it will use whatever was previously in the boot sector. If there is an earlier version of GRUB 2 in the boot sector, it may be unable to load modules or handle the current configuration file.

  If you are already using a different boot loader and want to carry on doing so, or if this is a special environment where you do not need a boot loader, then you should continue anyway. Otherwise, you should install GRUB somewhere.

  Continue without installing GRUB?

Do you remember seeing this question? It was intended to strongly discourage setups like this ...

Revision history for this message
Rick McBride (rmcbride) wrote : Re: [Bug 949992] Re: Upgrade from Lucid to Precise results in broken grub configuration

Actually, during the dist-manager -d install, I did get a dialog that
was all "unknown character" blocks in the message and on the buttons. I
don't know what it was asking. It didn't appear to block (I never
answered it, not being able to read it), but it was perhaps that
message. I HAVE seen it in the past, but not during this testing session.

I had meant to reproduce and document that weird dialog, but got
distracted by this problem. I'll go back and get more info on that
either over the weekend or Monday, when I have capacity on my VM host to
make another pre-update clone and run the process again.

The only dialog that I recall, apart from the typical "remove these
packages?" type things, was to do with restarting services.

On 03/09/2012 11:48 AM, Colin Watson wrote:
> You should run 'sudo dpkg-reconfigure grub-pc' and instruct it to
> install the boot loader somewhere, probably /dev/vda.
>
> The debconf database shows that the following question was presented to
> you at some point:
>
> You chose not to install GRUB to any devices. If you continue, the
> boot loader may not be properly configured, and when this computer next
> starts up it will use whatever was previously in the boot sector. If
> there is an earlier version of GRUB 2 in the boot sector, it may be
> unable to load modules or handle the current configuration file.
>
> If you are already using a different boot loader and want to carry on
> doing so, or if this is a special environment where you do not need a
> boot loader, then you should continue anyway. Otherwise, you should
> install GRUB somewhere.
>
> Continue without installing GRUB?
>
> Do you remember seeing this question? It was intended to strongly
> discourage setups like this ...
>

Revision history for this message
Rick McBride (rmcbride) wrote :

That's meant to be update-manager -d of course.

On 03/09/2012 01:31 PM, Rick McBride wrote:
> Actually, during the dist-manager -d install, I did get a dialog that
> was all "unknown character" blocks in the message and on the buttons. I
> don't know what it was asking. It didn't appear to block (I never
> answered it, not being able to read it), but it was perhaps that
> message. I HAVE seen it in the past, but not during this testing session.
>
> I had meant to reproduce and document that weird dialog, but got
> distracted by this problem. I'll go back and get more info on that
> either over the weekend or Monday, when I have capacity on my VM host to
> make another pre-update clone and run the process again.
>
> The only dialog that I recall, apart from the typical "remove these
> packages?" type things, was to do with restarting services.
>
>
>
> On 03/09/2012 11:48 AM, Colin Watson wrote:
>> You should run 'sudo dpkg-reconfigure grub-pc' and instruct it to
>> install the boot loader somewhere, probably /dev/vda.
>>
>> The debconf database shows that the following question was presented to
>> you at some point:
>>
>> You chose not to install GRUB to any devices. If you continue, the
>> boot loader may not be properly configured, and when this computer next
>> starts up it will use whatever was previously in the boot sector. If
>> there is an earlier version of GRUB 2 in the boot sector, it may be
>> unable to load modules or handle the current configuration file.
>>
>> If you are already using a different boot loader and want to carry on
>> doing so, or if this is a special environment where you do not need a
>> boot loader, then you should continue anyway. Otherwise, you should
>> install GRUB somewhere.
>>
>> Continue without installing GRUB?
>>
>> Do you remember seeing this question? It was intended to strongly
>> discourage setups like this ...
>>
>

Revision history for this message
Brian Murray (brian-murray) wrote :

In comment #18 you mention that the output is from Lucid before running update-manager and in that comment 'grub-pc/install_devices: ' is empty. This means that some time during Lucid, or when installing the sytem, this choice was made.

Changed in update-manager (Ubuntu):
importance: Undecided → Low
Revision history for this message
Rick McBride (rmcbride) wrote :

On 03/12/2012 01:12 PM, Brian Murray wrote:
> In comment #18 you mention that the output is from Lucid before running
> update-manager and in that comment 'grub-pc/install_devices: ' is empty.
> This means that some time during Lucid, or when installing the sytem,
> this choice was made.
>
> ** Changed in: update-manager (Ubuntu)
> Importance: Undecided => Low
>

Hmm. That IS interesting then. I'll have to examine the source image.
I've been using that as a lucid baseline for a long time, without any
sort of boot problem.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in update-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Paul Broadhead (pjbroad) wrote :

I just had the same result using a clone of a Lucid VM. I was prompted part way though the process to allow grub install. A single tick box was present, un-ticked, asking if I didn't want to install grub. Leaving un-ticked and clicking forward did not work, nothing happened after waiting for sometime. So I ticked the box and continued assuming it would be OK. This was a test upgrade on a clone VM so I can repeat the process if required. I'm off to manually fix the problem and continue testing...

Revision history for this message
Sasa Stamenkovic (umpirsky) wrote :

I'm getting this "unknown command hwmatch" message on each boot after I installed Ubuntu 16.04 following this steps: https://gist.github.com/umpirsky/6ee1f870e759815333c8

Special attention to `apt-get install -y grub-efi-amd64` part https://gist.github.com/umpirsky/6ee1f870e759815333c8#file-ubuntu-raid-sh-L40

For some reason I couldn't use apt-get, so I installed it manually downloading deb and using dpkg -i.

System boots normally, but I would like to fix this error. Is there any way to update config and fix it?

Thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.