2.02~beta2 requires manual testing

Bug #1269992 reported by Colin Watson on 2014-01-17
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
High
Colin Watson

Bug Description

I'm syncing GRUB 2.02~beta2 from Debian experimental into trusty-proposed. This requires some manual testing before we let it loose on trusty users in general, so this bug exists to ensure that it doesn't reach trusty before we're sure it's ready.

Colin Watson (cjwatson) on 2014-01-17
Changed in grub2 (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
status: New → Triaged
importance: Undecided → High
Sebastien Bacher (seb128) wrote :

Trying that new version on a laptop (one disk/OS, no secure boot, i386 trusty installation), the boot works without issue.

Trying to open the grub menu on boot to try the rescure option has has been leading to a situation where the grub menu is opening at every boot now though...

It seems also that a manual opening of the boot menu displays it with the 10 seconds timeout, where it used to open without timeout when manually triggered

Colin Watson (cjwatson) wrote :

These are different manifestations of the same problem. I think I dropped a little bit too much of quick_boot.patch when rebasing to 2.02~beta2; I'll see about fixing it up to preserve the previous behaviour.

Edwin Pujols (edwinpm5) wrote :

I have no issues booting either Windows 7 nor Ubuntu on a laptop (hp nx7400).

Elfy (elfy) wrote :

installed fine

booted to

error: symbol 'grub_term_highlight_color' not found

entered rescue mode - then I ended up at busybox

not really sure how I managed to get back (long day) but I've purged and reinstalled the original grub

Edwin Pujols (edwinpm5) wrote :

I set GRUB_TIMEOUT to 0 in /etc/default/grub, but the default entry isn't booted automatically.

Benjamin Donald-Wilson (benny) wrote :

It worked perfectly fine for my dekstop, dual booting with Windows XP. (i386)

Colin Watson (cjwatson) wrote :

Elfy (#5): Thanks for your report. We run across this pattern with every substantial enough change to GRUB. It's not actually a problem with the new upstream per se - it points to a misconfiguration in how GRUB is installed, and unfortunately we've never quite tracked down the root cause. However, I bet you'll find that if you run "sudo debconf-show grub-pc" you'll find that grub-pc/install_devices is set to something that doesn't include the device you're actually booting from (and please do tell us the current value). You can fix this by using "sudo dpkg-reconfigure grub-pc" and telling it to install to the master boot record of every disk in your system (it may be possible to get by with less, but this is generally a reasonable approach).

Edwin (#6): Thanks for your report. Timeout handling has changed around a bit recently, and not all the packaging is quite up to date yet (the transition is a bit tricky). You might like to review:

  info -f grub -n 'Simple configuration'

... to see how to adjust your configuration. If it still doesn't work, then do attach your /etc/default/grub so I can see what might be going on.

Edwin Pujols (edwinpm5) wrote :

Here's my /etc/default/grub, I think it's quite standard. I tried with hidden timeout commented out, too. And ran `update-grub` to save changes before restarting the machine. (After restarting the menu is shown with a 10 second timeout.)

Elfy (elfy) wrote :

@cjwatson - as soon as I get to chance to look again - either on this machine or another I will post back again - for the moment I've purged the beta grub and reinstalled 2.00-22 . Didn't have the time to spend on a completely unbootable machine last night.

Martin Pitt (pitti) wrote :

Tested on ThinkPad X230 amd64 with UEFI and SecureBoot enabled. The upgrade went flawlessly and two reboots worked just fine, one with a new kernel after a kernel dist-upgrade, and one "simple" reboot to the same kernel. In both cases I got the grub menu (10 s timeout) without asking for it, but I suppose that's fixed by comment 4.

I also tested the new "System Setup" menu entry, that works fine. Nice little feature!

syscon-hh (syscon-kono) wrote :

Here it won't work:

 **** tail of terminal output *****

root@USB-GDM-TRUSTY:~# grub-install -v
....
.... line numbers for indification only

line 1 : grub-install: Info: the core size is 0x26978.
line 2 : grub-install: Info: writing 0x27c00 bytes.
line 3 : grub-install: Info: copying `/usr/lib/shim/shim.efi.signed' -> `/boot/efi/EFI/ubuntu/grubx64.efi'.
line 4 : grub-install: Info: copying `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' -> `/boot/efi/EFI/ubuntu/grubx64.efi'.
line 5 : grub-install: Info: copying `/usr/lib/shim/MokManager.efi.signed' -> `/boot/efi/EFI/ubuntu/MokManager.efi'.
line 6 : grub-install: Info: copying `/boot/grub/x86_64-efi/load.cfg' -> `/boot/efi/EFI/ubuntu/grub.cfg'.
line 7 : grub-install: Info: Registering with EFI: distributor = `ubuntu', path = `\EFI\ubuntu\shimx64.efi', ESP at hostdisk//dev/sdd,gpt1.
line 8 : grub-install: Info: executing efibootmgr --version </dev/null >/dev/null.
line 9 : grub-install: Info: executing modprobe -q efivars.
line 10: grub-install: Info: executing efibootmgr -c -d /dev/sdd -p 1 -w -L ubuntu -l \EFI\ubuntu\shimx64.efi.
....
....

relevant error at line 3 -> writes 'grubx64.efi' instead of 'shimx64.efi'. This will be overwriten by line 4!

generating a correct line 3 manually as' shimx64.efi' will start / reboot fine.

this error was found on several systems and is reproducible after downgrading to 2.00 and upgrading back
 * UbuntuGNOME
 * Ububtu (Unity)
In all cases the entry inside NVRAM pointed out the 'shimx66.efi' file

Colin Watson (cjwatson) wrote :

syscon-hh: Thanks for your report. This was caused by a mistake of mine in translating the shell-based shim installation patch to C. I've fixed it for 2.02~beta2-4.

syscon-hh (syscon-kono) wrote :

Further no more working function found here -> all relevant systems after upgrade involved!

The background picture is stated in the '/etc/default/grub'
 -> GRUB_GFXMODE=1024x768
 -> GRUB_BACKGROUND="/usr/share/backgrounds/gnome/Stones.jpg"

Both versions 2.00-22 as well as 2.02~beta2-4 output of 'sudo update-grub' look identical:

/quote
**** part of grub.cfg -> /etc/grub.d/00_header ****
....
....
insmod jpeg
background_image -m stretch /@/usr/share/backgrounds/gnome/Stones.jpg

**** part of grub.cfg -> /etc/grub.d/05_debian_theme ****
....
....
insmod jpeg
if background_image /@/usr/share/backgrounds/gnome/Stones.jpg; then
  true
else
....
/unquote

No background picture will be shown in the '2.02~beta2-4' grub menu !?! Downgrading grub-packages the choosen picture will be shown again. No changes have been made in between on configuration.

Using the (long) configuration by '/boot/grub/themes/<name>' will work without restrictions.

Cavsfan (cavsfan) wrote :

It works great for me. I have a custom grub menu (font, picture and display) and the only difference I can see it an asterisk besides the selected line.

On Wed, Jan 22, 2014 at 05:54:05PM -0000, Cavsfan wrote:
> It works great for me. I have a custom grub menu (font, picture and
> display) and the only difference I can see it an asterisk besides the
> selected line.

Thanks. This was an intentional upstream change, so that the selection
would still be visible even if highlighting is lost for some reason.

Colin Watson (cjwatson) wrote :

syscon-hh: My guess is that this is due to:

2013-10-28 Vladimir Serbinenko <email address hidden>

        Make / in btrfs refer to real root, not the default volume.
        Modify mkrelpath to work even if device is mounted with subvolid option.

... so I think the question is why the "/@" prefix is still there.
Could you confirm the output of this command, please?

  sudo grub-mkrelpath /usr/share/backgrounds/gnome/Stones.jpg

Colin Watson (cjwatson) wrote :

Hm, no, I can reproduce this, so I don't need the output of grub-mkrelpath. It's not a general problem with btrfs, so my previous guess was wrong - booting works fine and that wouldn't work if we were handling relative paths wrongly. I'll see if I can reproduce this in a more stripped-down environment to diagnose it.

Colin Watson (cjwatson) wrote :

I can't load that background image with a rescue disk built from 2.00 either; background_image fails, apparently because it tries to create a width 0 / height 0 bitmap while loading the JPEG file in question. I suspect this is a bug in GRUB's JPEG reader, but I'm confused as to how it's a regression.

Colin Watson (cjwatson) wrote :

Stones.jpg is a progressive JPEG; as far as I can tell GRUB just doesn't support decoding these and never has. I'm happy to have a go at adding support, but this isn't your regression. Since you mention a themes directory, I suspect the non-loaded background image was being masked by a theme that did something with the background itself. Could I please have a copy of grub.cfg and the full theme in question attached to this bug? Feel free to redact any passwords, of course, but other than that I'd appreciate having exact copies.

Cliff Carson (ccarson1) wrote :

Have a standard install with 4 different levels of Ubuntu on 2 hard drives. No problems to report except that during the install got the prompt to keep the grub configuration or install the new one. I know what mods I have done so I said install the new configuration file and expected the modifications to be lost. They were not, still had my timeout = 3 and lunix boot not quiet.

syscon-hh (syscon-kono) wrote :

Hallo I'm back after a long periode of testing / investigations.

The problem is located inside 'secure-boot' !

Switching inside EFI-BIOS to 'non-secure-boot' option all works as axpected.

It's not based in the form of picture (*.png either *.jpg).

Based on the output of grub-shell showing ever the correct information to
 -> backgroung_image='path + picture'
I guess the background_image will be blocked by the 'secure-boot'.

syscon-hh (syscon-kono) wrote :
syscon-hh (syscon-kono) wrote :
syscon-hh (syscon-kono) wrote :
syscon-hh (syscon-kono) wrote :

The submitted '/boot/grub/grub.cfg' is the output of above '/etc/default/grub' and will not work below
 -> grub 2.02~beta2-4
but without any restriction below
 -> grub 2.00-22

The '/boot/grub/themes/***/theme.txt' ist working with 'secure-boot' witout restrictions on all systems.

Colin Watson (cjwatson) wrote :

Oh, right, we're missing the gfxterm_background module in the signed image. Thanks - I'll fix this for 2.02~beta2-5.

Colin Watson (cjwatson) wrote :

There's still the odd scattered problem, but I'm happy with the state of things now, and I think this is ready to land in trusty. Thanks everyone for the testing!

Changed in grub2 (Ubuntu):
status: Triaged → Fix Released
syscon-hh (syscon-kono) wrote :
Download full text (4.3 KiB)

I dont think so ! The problems with the picture is solved.

 Basic is a fresh installed trusty 'Kubuntu'.

 grub-version after installation was 2.00-22

 After the upgrade (activated proposed) grub packages 2.02~beta2-5 I got these:

 * an additional folder 'grub' -> see below

 **** information directory '/boot/efi/EFI' ****
root@USB-KUBUNTU:/boot/efi/EFI# ls -la
insgesamt 3
drwxr-xr-x 5 root root 512 Jan 28 11:38 .
drwxr-xr-x 3 root root 512 Jan 1 1970 ..
drwxr-xr-x 2 root root 512 Jan 27 18:27 Boot
drwxr-xr-x 2 root root 512 Jan 28 11:21 grub
drwxr-xr-x 2 root root 512 Jan 27 16:49 ubuntu
root@USB-KUBUNTU:/boot/efi/EFI# ls -la ubuntu
insgesamt 3361
drwxr-xr-x 2 root root 512 Jan 27 16:49 .
drwxr-xr-x 5 root root 512 Jan 28 11:38 ..
-rwxr-xr-x 1 root root 127 Jan 27 16:49 grub.cfg
-rwxr-xr-x 1 root root 905080 Jan 27 16:49 grubx64.efi
-rwxr-xr-x 1 root root 1178240 Jan 27 16:49 MokManager.efi
-rwxr-xr-x 1 root root 1355736 Jan 27 16:49 shimx64.efi
root@USB-KUBUNTU:/boot/efi/EFI# ls -la grub
insgesamt 3411
drwxr-xr-x 2 root root 512 Jan 28 11:21 .
drwxr-xr-x 5 root root 512 Jan 28 11:38 ..
-rwxr-xr-x 1 root root 128 Jan 28 11:37 grub.cfg
-rwxr-xr-x 1 root root 956792 Jan 28 11:37 grubx64.efi
-rwxr-xr-x 1 root root 1178240 Jan 28 11:37 MokManager.efi
-rwxr-xr-x 1 root root 1355736 Jan 28 11:37 shimx64.efi

 * sudo grub-install -v _> shows below (tail only):

 **** update grub version 2.02~beta2-5 ****
 grub-install: Info: copying `/usr/lib/shim/shim.efi.signed' -> `/boot/efi/EFI/grub/shimx64.efi'.
grub-install: Info: copying `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' -> `/boot/efi/EFI/grub/grubx64.efi'.
grub-install: Info: copying `/usr/lib/shim/MokManager.efi.signed' -> `/boot/efi/EFI/grub/MokManager.efi'.
grub-install: Info: copying `/boot/grub/x86_64-efi/load.cfg' -> `/boot/efi/EFI/grub/grub.cfg'.
grub-install: Info: Registering with EFI: distributor = `grub', path = `\EFI\grub\shimx64.efi', ESP at hostdisk//dev/sdd,gpt1.
grub-install: Info: executing efibootmgr --version </dev/null >/dev/null.
grub-install: Info: executing modprobe -q efivars.
grub-install: Info: executing efibootmgr -b 0000 -B.
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0002,0001,0003
Boot0001* Windows Boot Manager
Boot0002* Precise Pangolin
Boot0003* UEFI: Sony Storage Media 1.00
grub-install: Info: executing efibootmgr -c -d /dev/sdd -p 1 -w -L grub -l \EFI\grub\shimx64.efi.
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0001,0003
Boot0001* Windows Boot Manager
Boot0002* Precise Pangolin
Boot0003* UEFI: Sony Storage Media 1.00
Boot0000* grub
installation beendet. Keine Fehler aufgetreten.
root@USB-KUBUNTU:/boot/efi/EFI#

 * what function has the folder 'grub' and / or 'ubuntu' now?
 * an existing nvram-entry never should be deleted - only if allready existing -> overwritten

 **** grub-menu shell shows: ****
 grub> set

 cmdpath=(hd0,gpt1)EFI/grub
 ....
 config_directory=(hd0,gpt1)EFI/ubuntu
 config_file=(hd0,gpt1)EFI/ubuntu/grub.cfg

**** /etc/default/grub ****
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see...

Read more...

syscon-hh (syscon-kono) wrote :

Upgrade of an older 'Ubuntu-GNOME' installation
 * from 2.02~beta2-4 to 2.02~beta2-5
is working without any malfunction. No additional folder 'grub' has been created, picture is show now inside 'grub-menu'

Again: in the 'Kubuntu' installation the
 * 'nvram-entry' Boot0000* ubuntu
has been deleted and substituted by 'grub' - this should never happen!

Colin Watson (cjwatson) wrote :

syscon-hh: Can you please file a new bug report for this?

Edwin Pujols (edwinpm5) wrote :
  • grub Edit (1.2 KiB, application/octet-stream; name=grub)

Sorry, if this has already been pointed out. I notice that it's not only
the timeout that grub will ignore, recently I changed the style to
"countdown" but the menu is still shown.

On Tue, Jan 28, 2014 at 10:43 AM, syscon-hh <email address hidden> wrote:

> Done ->
> https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1273694
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1269992
>
> Title:
> 2.02~beta2 requires manual testing
>
> Status in “grub2” package in Ubuntu:
> Fix Released
>
> Bug description:
> I'm syncing GRUB 2.02~beta2 from Debian experimental into trusty-
> proposed. This requires some manual testing before we let it loose on
> trusty users in general, so this bug exists to ensure that it doesn't
> reach trusty before we're sure it's ready.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1269992/+subscriptions
>

Colin Watson (cjwatson) wrote :

Could you please file a new bug report for any remaining issues,
attaching any relevant information? This one is closed, and it's not
going to be a practical way to track things on an ongoing basis.

Edwin Pujols (edwinpm5) wrote :

Done, #1273764 :-)

On Tue, Jan 28, 2014 at 12:12 PM, Colin Watson <email address hidden>wrote:

> Could you please file a new bug report for any remaining issues,
> attaching any relevant information? This one is closed, and it's not
> going to be a practical way to track things on an ongoing basis.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1269992
>
> Title:
> 2.02~beta2 requires manual testing
>
> Status in “grub2” package in Ubuntu:
> Fix Released
>
> Bug description:
> I'm syncing GRUB 2.02~beta2 from Debian experimental into trusty-
> proposed. This requires some manual testing before we let it loose on
> trusty users in general, so this bug exists to ensure that it doesn't
> reach trusty before we're sure it's ready.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1269992/+subscriptions
>

Peng (pengwg) wrote :

I still have the problem described in #5. There's another bug report for it:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977

Valentijn Sessink (valentijn) wrote :

This new bug https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1298399 is also on trusty, with grub 2.02~beta2-7.

Valentijn Sessink (valentijn) wrote :

... also, build-depends of grub2-2.02 are not right, see bug #1299041
Required for building, but not in build-depends: lzop hfsplus squashfs-tools attr reiserfsprogs automake1.10

John Cottier (j-cottier) wrote :

I tried a test install of Trusty beta2 on 30/03/14. It installed fine then when I rebooted I got :-

error: symbol 'grub_term_highlight_color' not found
Entering rescue mode...

I am going to try boot-repair to see if that fixes it.

John Cottier (j-cottier) wrote :

It would not install boot-repair as its not available for 14.04 64 bit yet.
Tried sudo debconf-show grub-pc but did not seem to show any path.
Tried sudo dpkg-reconfigure grub-pc and it just gave a blank command line.
Booted the live CD to re-install and it offered an upgrade from 14.04 to 14.04 ?!? I let it run that but it had a lot of errors with bad packages. I had a suspicion that the original install had not in fact formatted the partition to wipe 13.10 off (even though it was selected to do that). So I used gparted from the live CD to delete the partition and start install again. This worked flawlessly. I seem to remember that happening in the past too. So I am guessing that on the original 14.04 install, it actually installed over the top of 13.10 and got confused over the files left over.

Asuna (811197881-8) wrote :

The --disk-module=MODULE option of grub-install don't work

My OS is ubuntu14.04.
And the command "grub-install -V" shows that the grub version is Grub 2.02~beta2-9.
Since I have two disk on my laptop, and one of them is not bootable, I have to use nativedisk option.
But the "--disk-module=MODULE" option of grub-install can not work normaly.
Command like:
sudo grub-install --disk-module=native /dev/sda

returns me the following message:
"
 --disk-module: (PROGRAM ERROR) Option should have been recognized!?
Try 'grub-install --help' or 'grub-install --usage' for more information.
"

Grub(-install)2.00 in ubuntu13.10 don't have this bug. Is there any way to solve this problem?

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

Other bug subscribers