Ubuntu 14.04 Update breaks grub, resulting in "error: symbol 'grub_term_highlight_color' not found"

[theghost]

The update from 13.10 to 14.04 via update-manager broke grub for me, which resulted in the grub error:

"symbol 'grub_term_highlight_color' not found"

on startup.

To fix the problem I had to boot to my persisting Ubuntu installation (e.g. using Super Grub Disk) and had to reinstall grub on my boot partition: "sudo grub-install --recheck /dev/sdx"

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: grub2-common 2.02~beta2-6
ProcVersionSignature: Ubuntu 3.13.0-16.36-generic 3.13.5
Uname: Linux 3.13.0-16-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Sun Mar 9 10:36:45 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-12-10 (88 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
ProcEnviron:
 LANGUAGE=de_DE
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: grub2
UpgradeStatus: Upgraded to trusty on 2014-03-07 (2 days ago)

[Peng (pengwg)]

It happened to me as well.

I have a Quantal liveUSB at hand and booted from it. I ran the grub-install from it and fixed the boot.

Now when I boot the grub version shows as 2.00. When I can boot to Trusty I ran grub-install again in hope of making the grub version current and I hit this error again.

So it appears there's a bug in the current 2.02 beta version.

[Launchpad Janitor (janitor)]

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

[Tamás Pénzes (penzes-tamas)]

It also happened to me, right now.

Fixed the following way:
-Boot from a pendrive
-Mount my root file system (where /boot is)
-run: "sudo grub-install --boot-directory=/mnt/<sth>/boot /dev/sdX"
Then reboot with HDD

I would say, otherwise it works well, but this was a surprise.

[erty (ertymail)]

im just installed ubuntu server (2014.04.01 build) on clean machin, and see this grub-rescue message right after first reboot.

[Samuel Taylor (samuel-taylor)]

How do I fix it?

[Phillip Susi (psusi)]

What does debconf-show grub-pc say?

[theghost (theghost)]

@Samuel Taylor: Please read the comments above, there are multiple ways on how to fix it.

[Peng (pengwg)]

I found out that I actually boot from /dev/sdc in my bios setting.
So manually run 'grub-install /dev/sdc' fixed my problem.

[Phillip Susi (psusi)]

I figured it was something like that. FYI, in the future, grub updates will probably break because you used grub-install manually. You should use dpkg-reconfigure grub-pc instead, so that the system can remember which drive(s) you have grub installed on and automatically reinstall it when grub is upgraded.

[Tamás Pénzes (penzes-tamas)]

After I've updated my system and rebooted today it happened again.
Then did a "dpkg-reconfigure grub-pc" as menitoned above, but right after then removed the old kernels with synaptic.
Rebooted again, and got the same error: "symbol 'grub_term_highlight_color' not found".

So it looks so, that this ticket is still valid. Grub is still buggy...

I boot from an OCZ 128GB SATA3 2,5" Vertex 4 VTX4-25SAT3-128G SSD with Gigabyte GA-Z87X-UD5H motherboard.
After manual grub install it works well, when removing/adding a kernel grub brakes something during the update...

[Phillip Susi (psusi)]

Please post the output of debconf-show grub-pc and sudo parted -l.

[Tamás Pénzes (penzes-tamas)]

$sudo debconf-show grub-pc
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/install_devices_empty: false
  grub2/device_map_regenerated:
  grub-pc/timeout: 0
* grub2/linux_cmdline:
  grub2/kfreebsd_cmdline_default: quiet splash
* grub2/linux_cmdline_default: quiet splash
  grub-pc/partition_description:
  grub-pc/kopt_extracted: false
  grub-pc/disk_description:
  grub2/kfreebsd_cmdline:
  grub-pc/postrm_purge_boot_grub: false
* grub-pc/install_devices: /dev/disk/by-id/ata-OCZ-AGILITY4_OCZ-1O5CE003PSR9O332
  grub-pc/install_devices_disks_changed:
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/hidden_timeout: false
  grub-pc/chainload_from_menu.lst: true

-------------------------------------------------------------------------------------------------------------------------------
$ sudo parted -l
Model: ATA OCZ-AGILITY4 (scsi)
Disk /dev/sda: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 128GB 128GB primary ext4 boot

Model: ATA SAMSUNG HD300LJ (scsi)
Disk /dev/sdb: 300GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 32,3kB 64,4GB 64,4GB primary ext4
 2 64,4GB 300GB 236GB primary ext2

[Phillip Susi (psusi)]

You have two disk drives with grub only installed on one of them. Most likely, you have an old, broken copy of grub installed in the other and that is what the system booted. Run dpkg-reconfigure grub-pc, and install grub to both drives so that either one should work.

[Nikon (neck-varentsov)]

Hi, I had it too, but not only after update, after I formatted my ubuntu partition and install it again, it happened again.
I can boot ubuntu, but when I choose 'Windows' in grub, that gonna crashed with "symbol 'grub_term_highlight_color' not found"

[Tamás Pénzes (penzes-tamas)]

Hi Phillip,

Thanks for the advice. I have checked and I'd really had a broken grub installed on my second drive. I've removed it and now it works perfectly.
I did it this way: http://askubuntu.com/questions/131168/how-do-i-uninstall-grub

Regards, Tamaas

[Roger Binns (ubuntu-rogerbinns)]

I just got bitten by this doing a fresh install of 14.04 with two drives. For whatever reason it decided to write to a different device than it had previously resulting in an unbootable system.

[Daniel Pazos i Guinea (daniel-pazos)]

Impossible to repair boot, impossible to boot windows.

grub rescue fails to boot too.

I can only boot my EFI machine using SuperGrubDisk2 cd.

Non Efi Core2duo machine seems unnafected, and boots propperly

[Gannet (ken20001)]

Recently upgraded 13.10 --> 14.04 and after first rebooting this appeared:

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

And this is on machine without UEFI.

[Ningfei Li (ningfei)]

As pointed out by Peng (pengwg) at #2, this might be confirmed a bug of grub 2.02. I upgrade my 13.10 to 14.04 (grub was upgraded to grub~beta2~9), then I encountered this problem.

My machine is with UEFI. When I see this error, I restarted my computer and selected boot from UEFI file. Then I navigated to the ubuntu uefi file and started my computer successfully. I tried the simple "sudo grub-install --recheck /dev/sdX" way. But it didn't work.

The I downgrade all the grub components: grub-common, grub2-common, grub-efi, grub-efi-amd64, grub-efi-amd64-bin to version 2.0. Rerun that "sudo grub-install --recheck /dev/sdX", restarted computer. Everything is back now. For me this owngrading of grub works.

Possibly a bug with grub-install in the 2.02 verion.

[René (rene-f83)]

Upgraded from 13.10 to 14.04 on a Lenovo S205 Pad. Also affected.

[Mukil Elango (mukilane)]

Upgraded from 13.10 to 14.04 on Acer TravelMate 5720 and got into the 'grub rescue' prompt, due to the " error: symbol 'grub_term_highlight_color' not found"

[Douglas Fink (doug1654)]

Also just happened to me -
Using BIOS Boot menu was able to boot from the Ubuntu disk - this did bring up the Grub boot menu.
Tried the sudo update-grub and that still led to the same problem.

[Phillip Susi (psusi)]

Once again, this is not a bug but a misconfigured system. You must make sure that dpkg-reconfigure grub-pc has your boot drive selected so that grub is properly upgraded there.

[René (rene-f83)]

After booting with subergrub2disk (thanks to daniel-pazos), here is my output (Lenovo S205):

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

$ sudo parted -l
Model: ATA HITACHI HTS54323 (scsi)
Disk /dev/sda: 320GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 1049kB 53,5MB 52,4MB fat16 boot
 2 53,5MB 316GB 316GB ext4 msftdata
 3 316GB 320GB 4194MB linux-swap(v1)

[Douglas Fink (doug1654)]

so here's my debconf output and parted -
  grub-pc/chainload_from_menu.lst: true
  grub-pc/install_devices_empty: false
  grub-pc/hidden_timeout: false
  grub2/device_map_regenerated:
  grub2/kfreebsd_cmdline_default: quiet splash
  grub-pc/postrm_purge_boot_grub: false
  grub2/kfreebsd_cmdline:
  grub-pc/disk_description:
  grub-pc/timeout: 10
  grub-pc/install_devices_failed_upgrade: true
* grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD1002FAEX-00Y9A0_WD-WMAW30554869
  grub-pc/mixed_legacy_and_grub2: true
* grub2/linux_cmdline:
  grub-pc/install_devices_failed: false
* grub2/linux_cmdline_default: quiet splash
  grub-pc/install_devices_disks_changed:
  grub-pc/kopt_extracted: false
  grub-pc/partition_description:
boardhead@boardhead-GM5048:~$ sudo parted -l
Model: ATA HDS725050KLA360 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 2 32.3kB 4656MB 4655MB primary fat32
 1 4656MB 500GB 495GB primary ntfs boot

Model: ATA WDC WD1002FAEX-0 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 2 1048kB 305GB 305GB extended
 5 1049kB 305GB 305GB logical ext4
 3 305GB 315GB 10.1GB primary linux-swap(v1)
 1 315GB 1000GB 686GB primary ntfs boot

Model: WD 10EACS External (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 32.3kB 900GB 900GB primary ntfs
 2 900GB 1000GB 101GB extended
 5 900GB 998GB 98.4GB logical ext4

My default boot drive should be the /dev/sda - (Windows ) and then Ubuntu is on /dev/sdb -
So do I need to run grub-install --recheck /dev/sda1 to reinstall grub there?

I can only boot from BIOS by selecting the Ubuntu drive and not the 'default'

[pureblood (freeseek)]

I have had the same problem. My guess is that, since I have two hard drives, the system is trying to start from the wrong drive where an old version of GRUB is installed. My solution was to start Ubuntu with a USB stick (it does not matter which version). Once you start, these commands will do it:
# mkdir /tmp/drive
# sudo mount /dev/sdX1 /tmp/drive
# sudo mount --bind /dev /tmp/drive/dev
# sudo mount --bind /proc /tmp/drive/proc
# sudo mount --bind /sys /tmp/drive/sys
# sudo chroot /tmp/drive
# dpkg-reconfigure grub-pc
Where sdX1 must be the drive where your system is installed. When you run the last command you should select the sdX drive, though I guess running it multiple times will install the new version of grub on each drive and give you some piece of mind.

[Phillip Susi (psusi)]

You need to use dpkg-reconfigure grub-pc instead of grub-install directly, so that the system knows that it needs to run grub-install on that drive the next time grub is upgraded.

[Jesse Caroompas (jessecaroompas)]

I encountered this same problem when updating Lubuntu 13.10 to 14.04 on an Asus netbook. The primary computer's harddrive has Windows 7 on it, and I'm running Lubuntu from a thumbdrive installation. (Short version as to why: the computer's not mine, I'm just on long term loan from a friend.)

pureblood's solution from post 27 worked to correct the Lubuntu grub installation, so I can now boot to Windows and Lubuntu 14.04 from the thumbdrive. However, lacking that thumbdrive, the grub rescue prompt still shows up when I try to boot natively, with an error showing a whole bunch of numbers and letters. pureblood's solution doesn't work, since mounting /dev/sda1 to /tmp/drive and then cding to the directory shows there's no native /dev, /proc, or /sys directory, and skipping to sudo chroot /tmp/drive fails with the message: "failed to run command '/bin/bash'; no such file or directory" (I'm guessing this is because Windows doesn't have bash). Therefore, I don't know how to get to a point where running dpkg-reconfigure grub-pc would work, and since the computer's not mine, I don't want to experiment too much.

What's the Windows 7 equivalent to the above solution?

[Phillip Susi (psusi)]

If you can boot Ubuntu using the thumb drive, then so so and run sudo dpkg-reconfigure grub-pc.

[Jesse Caroompas (jessecaroompas)]

That didn't work. I still get an error: no such device: (a bunch of numbers and letters) when I try to boot regularly into Windows without the thumb drive connected.

[_dan_ (dan-void)]

Wow, this is a serious bug and you set it to invalid and demand from users to run commandline commandos?
Are you serious?

I just run into this bug, all worked fine on 13.10 all day long, after upgrade my system does not boot anymore.
I can fix it, most guys here can fix it, but the 08/15 user runs into this and says "f... this linux" and installs something else.
You can NOT demand from a user to run dpkg commandos, or even know about dpkg.
Fact is the upgrade to 14.04 breaks the installation, no matter the reason and it needs to be addressed and fixed and not set to invalid.

This behavior is really discouraging and the effects are driving ppl away from linux.

[Bzzz (da-bzzz)]

Crashed a TP SL500 here, working well with 13.10 (kubuntu flavour), dead after error-free upgrade to 14.04.

You know, this is a LTS release, what about .tar.feather'ing the guy that is responsible for allowing a beta version for such a core part of the system? I don't get it, it's just off the dumbness scale. If you wanna p*ss off users back to Windows or OSX, that's the way to go...

[Michael Tsikerdekis (tsikerdekis)]

I managed to get it work. Have a look here for the solution: http://stackoverflow.com/questions/23164040/grub-2-cannot-find-efi-for-windows/23164859

You will have to adapt your configuration to reflect your system's setup but I've posted mine so you should have enough to get it work. You will have to downgrade the files mentioned here by another user. Then an additional step is needed to make Windows 8 (in my case work).

[Phillip Susi (psusi)]

Please stop changing the status of this bug and read the existing comments. This error message results from manually installing grub incorrectly. If you manually run grub-install instead of going through dpkg-reconfigure, it will break on upgrade.

[Jesse Caroompas (jessecaroompas)]

I didn't run grub-install. I did absolutely nothing to grub before upgrading. I simply upgraded to 14.04, and it broke.

Therefore, manually installing grub has nothing to do with it.

[Douglas Fink (doug1654)]

I agree with the others that this is clearly NOT due to manually running grub-install, since everything was working fine until the upgrade to 14.04 itself ran grub !!!!!

As the Head of Quality Management for an IT shop in a large international company, calling this invalid is ridiculous! This is a bug guys, now fix it.

This bug, along with other recent activities by Ubuntu (hacked accounts, anyone?), is really making me have second thoughts about keeping Ubuntu and just going with Windows.

[Douglas Fink (doug1654)]

By the way running dpkg-reconfigure grub-pc and installing grub to install to both the Windows Drive ( which should have been the primary boot drive when grub ran during the install) and to the Ubuntu drive seems to have worked - for now.
We will see what happens during the next upgrade.

[Forage (forage)]

Same thing occurred when I tried to upgrade ubuntu gnome from 13.10 to 14.04. I've got a dual boot system for year now and it was never considered incorrectly configured in the past, installing and upgrading Ubuntu always worked. I think this bug can't be considered invalid because we have supposedly done something wrong manually. This is not the case if you ask me.

Running boot-repair on a live usb fixed the issue for me, following the provided steps: https://help.ubuntu.com/community/Boot-Repair

[rgrig (radugrigore)]

Perhaps the problems are related but different. For me, "dpkg-reconfigure grub-efi" does not fix the problem. Downgrading grub as in comment #20 also did not work.

[_dan_ (dan-void)]

Stop marking it as invalid.
As you can clearly see, by the amount of users affected, its is a problem.

Its not that complicated. Since the dawn of time it worked a certain way but all of a sudden with 14.04 it does not work anymore as it used to.
If something changed, thats all fine but the update process has to handle that, for example. run the dpkg-reconfigure grub-pc during upgrade, all would be fine. Currently this is not the case which is a *Bug* and it breaks users systems.
You can NOT make users anticipate that change.

How you keep marking it as invalid and leave possible a lot of users with a broken system is beyond me. You are not being helpful.

[Launchpad Janitor (janitor)]

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

[rgrig (radugrigore)]

Here is what happened in my case:
1. After using BootRepair (see comment #39) it booted directly in Windows.
2. Since the (broken) Ubuntu install was almost pristine, I thought I'd just install it again. Booting from the Ubuntu CD it says "This computer currently has no detected operating systems." Somehow, it doesn't detect the (functioning) Windows OS.

I think it's clear that the message "error: symbol 'grub_term_highlight_color' not found" is not always caused by a user running "grub-install" instead of "dpkg-reconfigure".

[Ulrich Schreiner (ulrich-schreiner)]

same problem here. upgraded from 13.10, now this error. i did not do anything with grub, only "do-release-upgrade".

booting with a stick, chroot'ed /dev/sda1 and did a

dpkg-reconfigure grub-pc

but nothing changes. problem exists.

anything else what can be done?

[Øyvind (sieges)]

Experienced the bug here too.
Sony Vaio Pro Haswell Laptop. I did not touch the GRUB. Just clicked update in Update Center.

For those of us that are not extremely Linux Savvy - What is the best way to fix? Running boot-repair from LiveUSB?

[Adam Niedling (krychek)]

So does this bug only happen to people that have dual boot systems?

[sjampoo (missreemer)]

Nope, I don' t have a dual boot system and it happened to me.

[Jordi Llonch (llonchj-p)]

Same error here.

Updated from 13.10 to 14.04 several machines with 2x2Tb HD's without problem. Found the problem with one machine with 2x3Tb HD's.

Machines had only one OS: ubuntu 13.10

Working machines has partition table type "msdos", the failed one has partition table type "gpt" as per parted -l output.

Tried unsuccessful options to fix the error:

1) dpkg-reconfigure grub-pc

2) grub-install /dev/sda && grub-mkconfig -o /boot/grub/grub.cfg

3) reinstall grub:

      apt-get purge -y grub grub-pc grub-common
      rm /etc/grub.d /etc/default/grub* /boot/grub -fr
      apt-get install -y grub-common grub-pc

----

Some details for the failing machine:

# debconf-show grub-pc
  grub-pc/timeout: 10
  grub-pc/install_devices_failed: false
  grub-pc/partition_description:
  grub2/device_map_regenerated:
* grub2/linux_cmdline_default:
  grub-pc/disk_description:
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/install_devices_disks_changed:
  grub2/kfreebsd_cmdline_default: quiet splash
  grub-pc/install_devices_empty: false
  grub-pc/kopt_extracted: false
  grub-pc/chainload_from_menu.lst: true
  grub-pc/hidden_timeout: true
  grub-pc/postrm_purge_boot_grub: false
* grub2/linux_cmdline:
* grub-pc/install_devices: /dev/disk/by-id/ata-ST3000DM001-9YN166_W1F0MK3V
  grub-pc/mixed_legacy_and_grub2: true
  grub2/kfreebsd_cmdline:

# parted -l
Model: ATA ST3000DM001-9YN1 (scsi)
Disk /dev/sda: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
 4 1049kB 2097kB 1049kB bios_grub
 1 2097kB 68.7GB 68.7GB raid
 2 68.7GB 69.3GB 537MB raid
 3 69.3GB 3001GB 2931GB raid

Model: ATA ST3000DM001-9YN1 (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
 4 1049kB 2097kB 1049kB bios_grub
 1 2097kB 68.7GB 68.7GB raid
 2 68.7GB 69.3GB 537MB raid
 3 69.3GB 3001GB 2931GB raid

Model: Linux Software RAID Array (md)
Disk /dev/md0: 68.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number Start End Size File system Flags
 1 0.00B 68.7GB 68.7GB linux-swap(v1)

Model: Linux Software RAID Array (md)
Disk /dev/md1: 537MB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number Start End Size File system Flags
 1 0.00B 537MB 537MB ext3

Model: Linux Software RAID Array (md)
Disk /dev/md2: 2931GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number Start End Size File system Flags
 1 0.00B 2931GB 2931GB ext4

[Fengyang Wang (fengyang-wang-0)]

Also experiencing this bug. Machine is a dual boot system Ubuntu & Windows 8. Never ran grub-install until trying to fix this issue, so it must have nothing to do with manually fiddling with settings.

Things that did not work:
* sudo dpkg-reconfigure grub-efi
* sudo grub-install /dev/sda2 && sudo grub-install /dev/sda6, then sudo dpkg-reconfigure grub-efi
* sudo grub-mkconfig -o /boot/grub/grub.cfg

parted -l output:

<code>
Model: ATA HGST HTS541010A9 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 1049kB 420MB 419MB ntfs Basic data partition hidden, diag
 2 420MB 693MB 273MB fat32 EFI system partition boot
 3 693MB 827MB 134MB Microsoft reserved partition msftres
 4 827MB 491GB 490GB ntfs Basic data partition msftdata
 6 491GB 966GB 476GB ext4 msftdata
 7 966GB 975GB 8476MB linux-swap(v1)
 5 975GB 1000GB 25.6GB ntfs Basic data partition hidden, msftdata
</code>

[Fengyang Wang (fengyang-wang-0)]

Also, dpkg-reconfigure grub-efi has no output... not sure if this is normal or not.

[Tomdkat (tomdkat)]

I was in the process of upgrading my mom's Ubuntu 13.10 system to 14.04 when I encountered this issue, after the first reboot. I wasn't prepared for this so I'm off to research and gather the tools I'll need to recover. *sigh*

[Fengyang Wang (fengyang-wang-0)]

I looked around and noticed that grub-efi is a dummy packages, and I should reconfigure grub-efi-amd64 instead. But this just asks me for some command line commands; I'm not given the option to install grub anywhere. I also tried uninstalling and reinstalling grub to no avail.

Output of sudo debconf-show grub-efi-amd64:

* grub2/linux_cmdline:
  grub2/kfreebsd_cmdline:
  grub2/device_map_regenerated:
* grub2/linux_cmdline_default: quiet splash
  grub2/kfreebsd_cmdline_default: quiet splash

[Tester (erokul)]

The same bug here.
dpkg-reconfigure and all other solutions aren't helpful.
I have no idea how to fix this.

Here some details about the bug and my configuration: http://ubuntuforums.org/showthread.php?t=2218212

The only thing I could do - to boot ubuntu manually from "grub rescue" screen.

[Ulrich Schreiner (ulrich-schreiner)]

Hi,

"dpkg-reconfigure grub-pc" showed many default values, incl. /dev/sda1. But i do not have any sort of dualboot (never had), so i changed this to /dev/sda and now it works again.

After upgrade to 14.04 ubuntu decided to grub-install on /dev/sda1 (my root partition) instead of sda?

I don't know if this makes sense in a dual boot env, but it is useless in a single boot environment with only linux installed.

[Baby Buggy Bunny (baby-buggy-bunny)]

Hi,

Same behavior here. A brand new installation of a amd64 Ubuntu 14.04 (dual boot win 8) which resulted in a a broken grub2 ("symbol 'grub_term_highlight_color' not found"). This is fresh install, no grub-install. Grub2 is normaly on /dev/sda.

Using the BIOS Boot menu (or Super Grub 2 disk) is my only possibility to boot Ubuntu (maybe also with grub_rescue).

None of the propositions (grub install, dpkg-reconfigur, boot-repair ...) above fixed the issue.

There is clearly a bug somewhere.

[Adam Niedling (krychek)]

Can we have the priority back to critical please?

[Michael Prentice (splaktar)]

I hit this today while upgrading from 13.10 to 14.04 as well. Dual boot Windows 7 and Ubuntu x64. I agree that this needs to be marked critical. There are way too many people being affected by this issue and the number of people is only going to increase! This is not due to some people doing strange tinkering and manual changes. This is a bug with the upgrade and Grub in 14.04!

[Ningfei Li (ningfei)]

Another thing might needed to be mentioned is that, with the new version of grub(beta2~9, uefi machine), "grub-install --recheck /dev/sdX" just print out "Installing for x86_64-efi platform."and then "Installation finished. No error reported". But with the previous verion (2.0), this command will also print out the BootOrder (for two times) and all the boot options.

If you want to fix the problem using boot-repair, do NOT using the 14.04 livecd and manually installing boot-repair (since there's no ppa source for 14.04 so far). Try to use the boot-repair cd here: http://sourceforge.net/projects/boot-repair-cd/. I tried to boot with 14.04 and manually install boot-repair to fix the boot problem. But it didn't work out. There's always an error in the end. But with the boot-repair-cd. It did work.

Hope this might help.

[YakovButterfield (shulmice)]

I hit this today while upgrading from 13.10 to 14.04 as well. I have 3 hard drives, 2 with just data . I first did a standard upgrade with Update manager, then did a compleate reinstall after downloading the 32bit download to a USB drive. Same error "symbol 'grub_term_highlight_color' not found".
Then ran Boot Repair from a USB drive it works but I had to reinstall all my Brothers printer and scanner deb files.
I recommend to download onto the USB drive Boot Repair first and use a USB installer to install the .iso image to the USB Drive.
 http://sourceforge.net/p/boot-repair-cd/home
After you have Boot Repair on a seperate USB Drive just do a standard upgrade and restart with the Boot Repair USB Drive and repair GRUB

[Michael Prentice (splaktar)]

I had to boot from a 13.10 ISO and then run the following to fix this:

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair
boot-repair &

I hadn't run a grub-install directly in the past. No UEFI. Multiple hard drives, dual boot on primary.

The only drive that had its Grub corrupted was the primary Ubuntu boot drive, which the upgrade corrupted.

[Philippe Sainte-Marie (psm-o)]

Same here, i did the update on my dedicated (and remote) server and i think the no-boot comes from grub.

Is there a command-line tool similar to boot-repair somewhere ?

[Tomdkat (tomdkat)]

After many hours of frustration, I was able to get my mom's computer to boot. Michael Prentice's post, #60, provided some useful information. Previously, I used an Ubuntu 13.04 live DVD I have to boot the system, install and run the Boot-Repair utility but it didn't work. Once I booted an Ubuntu GNOME 13.10 live DVD I have, I was able to install and run the Boot-Repair utility and was able to boot the main system. Yay!

After getting the main system to boot, I confirmed it worked and shut it down. I then tried booting it again and it failed to boot. :( So, I re-boot the Ubuntu GNOME 13.10 live DVD, re-isntalled and re-ran the Boot-Repair utility and was able to boot the system again. I haven't shut it down yet.

With the system running, I was able to run the "dpkg-reconfigure" command mentioned above. Here are the results:

tom@computer:~$ sudo dpkg-reconfigure grub-pc
[sudo] password for tom:
dpkg-query: package 'grub-pc' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
/usr/sbin/dpkg-reconfigure: grub-pc is not installed
tom@computer:~$ sudo dpkg-reconfigure grub-efi
tom@computer:~$ sudo debconf-show grub-pc
  grub-pc/chainload_from_menu.lst: true
  grub2/kfreebsd_cmdline:
  grub2/kfreebsd_cmdline_default: quiet splash
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_disks_changed:
  grub-pc/hidden_timeout: true
  grub-pc/install_devices_failed: false
  grub-pc/kopt_extracted: false
  grub2/device_map_regenerated:
  grub-pc/partition_description:
  grub-pc/install_devices_empty: false
  grub-pc/disk_description:
  grub-pc/mixed_legacy_and_grub2: true
  grub2/linux_cmdline:
  grub2/linux_cmdline_default: quiet splash
  grub-pc/install_devices:
  grub-pc/timeout: 10
  grub-pc/install_devices_failed_upgrade: true
tom@computer:~$ sudo debconf-show grub-efi
tom@computer:~$

The main system does have UEFI but secure boot is disabled. The system came with Windows 8 pre-installed but I replaced that with Ubuntu 13.04 and then later upgraded the system to Ubuntu 13.10. I never set the system up to dual-boot with Windows and when I installed Ubuntu 13.04, I let the installer use the entire drive for the Ubuntu installation.

[Øyvind (sieges)]

So - I have tried to fix my this problem, but I am having real difficulties.

I have booted Boot-Repair from USB, but I have to set the BIOS to Legacy mode.
EFI mode shoes the GRUB, and boot repair is an option but it does not boot at all.

When I booted Boot-Repair (in Legacy) I am get all kinds of error messages (It needs to connect to the Internet, I am in Legacy mode etc).

So I downloaded 13.10 and made a LiveUSB - Was able to boot in UEFI mode and did what was discribed in post #60.
However, at the end the boot-repair said that I had experienced some sort of error without specifying - it was logged to http://paste.ubuntu.com/7292867. Tried to reboot - no go. In UEFI mode, Sony's "Automatic Repair Tool" start, and in Legacy "Operating System not found"

I had similar problems with I first installed Ubuntu as I wanted to keep the Windows 8 Recovery Partitions just in case i did not like Ubuntu - That time the Boor-Repair fixed the issue.

.. I am also a bit curious why this has not been taken more "seriosly". It seems that the Ubuntu officials are not regonizing this bug.

Any other options I should try?

[Phillip Susi (psusi)]

The case of the original reporter of this bug has been confirmed to be invalid. If you are experiencing a similar issue, please file your own bug report and include the output of parted -l, and debconf-show grub-pc. Bear in mind the following, that will indicate that you also have a misconfiguration, and not a valid bug:

1) If grub-pc/install_devices is empty, or only has one drive but you have multiple drives installed, then you need to run dpkg-reconfigure grub-pc and make sure you select all of your drives, as this error happens when you have a broken grub installed on one drive, and that is the drive your bios is booting, even if you have a good install on another drive

2) If you have used grub-repair in the past, that runs grub-install for you but does not update grub-pc/install_devices, so errors such as this will happen when grub is upgraded, since the system does not know it needs to run grub-install again to update your boot drive after upgrading the grub files in /boot/grub.

[Fengyang Wang (fengyang-wang-0)]

Phillip, Mathias Dietrich has never said that he ran grub-install manually, so the original report is not confirmed to be invalid.

[Gramler (maxf)]

Experienced the same issue as Mathias Dietrich describes here.

Of note is the fact that this happen on nearly "stock" instance.

Started as 13.04 server. (booting from unraided drive, config includes 2 drives in raid array)
Installed CouchDB, ElasticSearch, Added ubuntu desktop
Upgraded via command line to 13.10
Upgraded via desktop tool to 14.04

Recovery path was somewhat different but similar:
Booted from SuperGrub image: http://www.supergrubdisk.org/ Into 13.10 image (find the Ubuntu entry via supergrub menu)
Installed Jaunty version of boot-repair (trusty not available yet at time of writing) see:
http://askubuntu.com/questions/449818/boot-repair-ppa-404-error-on-ubuntu-14-04
Boor repair complained about missing "linux" package. I just removed this from apt-get command

That repaired it.

Sorry... i did not see the request for
parted -l, debconf-show grub-pc
 till just now

However, I am confident that if the same sequence is repeated.. the same thing will happen.
Note that NO manual editing changing of boot config was performed.
But 13.04 and 13.10 instances worked just fine.
Also the upgrade form 13.04 - 13.10 went through without any issues.

[Phillip Susi (psusi)]

@Fengyang: it does not matter: it was not installed correctly, and reinstalling it correctly resolved the issue. The fact that it was not installed correctly originally does not constitute a bug, unless you can describe a way to reproduce that state using the official installation methods.

[sjampoo (missreemer)]

@Phillip Susi: Please don't set to Invalid, because people tried to fix it -after- it broke down.

[Baby Buggy Bunny (baby-buggy-bunny)]

@Phillip: when you make a brand new installation of Ubuntu (no upgrade, no grub install ..) and it's lead to a grub error (and I'm not the only one in this case) I considere that there is a bug somewhere. Maybe the problem is a misconfiguration of grub yes, but this misconfiguration was set during a normal installation of Ubuntu. For me it is easy to reproduce this beahvior : follow the official installation method. So at this point I agree with sjampoo.

[theghost (theghost)]

@Philip: Why the heck do you try to close a non solved reproducable bug that is critical? You should be lucky that I reported it BEFORE the release date of Ubuntu, when I tried the Beta. Instead of looking into it, you tried to close it with all means. Thanks to this all other users were affected by the bug too and the one's here are just a small percentage, which are power users.
It's no wonder that Ubuntu has such a bad reputation, if such critical bugs are ignored.
As I said before this bug was triggered by updating Ubuntu via the standard update UI (update-manager). So why exactly is that a wrong installation ?

For all others who are interested in working around the bug, you can boot into your Ubuntu using Super Grub Disk.
Then reinstall grub on your boot partition, e.g.: https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows#The_terminal_way

It seems that this bug is caused by having > 1 HDDs where some partitions are on the one and some on the other HDDs.

[Cian Davis (davisc)]

I have also experienced this bug upgrading to Kubuntu 14.04 from the release upgrader (wish now I hadn't).

I have a 64GB SSD with /boot as /dev/sda1 and / on an LVM LV on the SSD.

/home is then on a 300GB SATA drive. It is possible that there was a grub installation on this drive previously.

I have upgraded kernels on this machine previously - so grub would have been re-run. However, I did not get the problem I have now until I upgraded Ubuntu. To me, this bug affects the ubuntu upgrader.

I now have a dead system and have to go looking for a USB boot key.

[Adam Niedling (krychek)]

Cian and everyone else affected: Before you try to fix this issue paste the output of the following commands: "sudo parted -l" and " sudo debconf-show grub-pc".

[Phillip Susi (psusi)]

Once again, this report is invalid because it does not describe a defect in the software that needs fixed. Once again, the problem with your installation is that grub-pc/install_devices was not set so the system did not know that it needed to run grub-install to reinstall grub on that disk after upgrading the grub files in /boot/grub.

As Mathias noticed, this happens to "power users". This is because you know enough to be able to install grub yourself, which gets it working at the time, but leaves grub-pc/install_devices incorrect so it will break on upgrade. You need to use dpkg-reconfigure grub-pc instead, so that grub-pc/install_devices will be set correctly and grub-install will be run automatically on upgrade.

Baby, if the installer fails to install grub, then it should file a new bug report about that and we can investigate.

[Mikhail Goncharov (goncharov-mikhail)]

I had the same issue while installing from USB stick with full HDD format.

`dpkg-reconfigure grub-pc`
did not fixed the issue

I have downloaded boot repair cd image (http://sourceforge.net/projects/boot-repair-cd/files/) - I used x64 as the Ubuntu installation is x64. Then installed ISO via unetbootin (http://unetbootin.sourceforge.net/). Performed regular repair and viola!

[_dan_ (dan-void)]

@Phillip Susi

I explained to you why this is an issue any why it needs to be adressed and why it affects the upgrade process.
You ignored all of that and removed, commentless, the ubuntu-release-upgrade link.
People are shredding their installations because something changed in ubuntu and the upgrade process does not take care of it.
This thread pictures perfectly what is wrong with ubuntu and the community and why so many people are turning away from it and stop supporting or filing bugs.

It worked perfectly that way since ubuntu 6.x, does not work this way anymore since 14.04 but hey, its easy to anticipate that change? Right?

[Cian Davis (davisc)]

Adam,
Apologies, I had fixed the problem by the time you posted and I didn't realise outputs from those commands would have been helpful. Thanks for taking the time to try and sort the issue.

Philip,
I installed my system from scratch a few months ago with Saucy. I applied updates as they came up and upgraded to Trusty this morning when offered by the system using the built-in ugrader. Grub was installed and working fine on my disk before I upgraded. Post reboot, all I got was a grub shell and the reported error. I don't know what you're referring to about grub-pc/install_devices and how or why I would change it. I haven't changed disk configs since I installed.

If this isn't a defect in the software, I don't know what is. It may be because of a few unlikely elements coming together. It may not actually be a problem with the grub package so the bug should be refiled. But there is certainly a problem somewhere - and it's a big one.

Dismissing people so vigourously when they report a bug is pretty disappointing. It's certainly put me off ever trying to assist with a bug again. I can fix the error myself but I've been encouraged by Ubuntu devs I know to help with bug reporting so that the overall quality of the software improves and new users don't have quite such a steep learning curve and will see Linux as a real alternative.

But I obviously have a naive view of the community - the priority is to close bugs saying why they shouldn't have been filed in the first place.

[Tomas Öqvist (tomoqv)]

This definitely is a serious issue. I spent 6-8 hours trial and error getting a new PC with EFI bios to single-boot Ubuntu 13.10 (still don't know exactly which of my numerous changes in boot-repair that made the difference). So, after updating to 14.04 this morning, "boot hell" was back with "error: symbol 'grub_term_highlight_color' not found". Relying on boot-repair to fix the issue has only gotten me back to the problem I had with 13.10 and grub2 menu not even loading. Just a message saying "No disk or disk has failed". Still haven't been able to resolve the issue.

Not having a setup program that properly handles boot issues on a modern PC is unacceptable and will surely prevent me from recommending Ubuntu to anyone as long as this cannot be fixed without extensive knowledge about grub, boot records etc.

[Phillip Susi (psusi)]

dan, there is no change we can make to grub to prevent this from happening if grub-pc/install_devices is not set correctly. Unless you can show that the installer does not set it correctly, then there is nothing we can do.

Cian, did you ever have an issue with grub before ( possibly when you first installed 13.10 ) and fix it by using boot-repair or otherwise? If you run debconf-show grub-pc, you should see the grub-pc/install_devices setting. That variable must point to your boot drive for grub to be upgraded properly. If the 13.10 installer failed to install grub for some reason, and you had to fix it, that would explain how that variable was not set correctly, which set the stage for the upgrade to fail.

[Sylvain (sylvain1970)]

Hi,
I solved this problem :

Grub installation with Ubuntu 14.04 live usb :

mount /dev/xxx /mount_point
(xxx like sda5 for example)

grub-install --root-directory=/mount_point /dev/xxx
(xxx like sda for example)

And reboot.

:-)

[Jordi Llonch (llonchj-p)]

@psusi, I am a bit confused.

As explained in #48, I have upgraded a few boxes with 2Tb disks, but the first one I have tried with 3Tb failed.

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

As you can see, grub-pc/install_devices looks set and still does not boot.

Can you please check the output of this server that failed as stated in #48? Any ideas?

Cheers

[Fengyang Wang (fengyang-wang-0)]

Phillip, please stop making excuses for this bug. It has nothing to do with being a "power user". I barely even knew what grub was before running into this, so there is no way I could possibly have misconfigured it. The *installer* must be misconfiguring the software then, hence it is still a bug.

Also, this did not happen on upgrade from 13.04 to 13.10, so it is a serious regression.

Since you insist that it is not a grub bug, I will change it to the upgrader, for which it is definitely a bug.

[Henk Boerboom (henk-tel)]

My father-in-law (79) called me, i didn't know what he was talking about, so he sent me a picture.
---
Boot from CD:
Boot from CD:
error: symbol `grub_term_highlight_color' not found.
Entering rescue mode...
grub rescue> _
---
2 months ago i did a fresh install of Lubuntu 13.10, besides winxp, on his PC.
I am not a superuser but now i know that he didn't do a security update, but an upgrade to 14.04.
He doesn't have a live Cd or stick, or can make one now.
Can i do something with ¨grub rescue¨ by phone ?
Or is this impossible ?

[Simen Langvik (airplanesimen)]

This bug also affects me;

did a clean install of the 14.10 distro, no other drives with Grub installed before.
The grub still tells me that error described in the bug.

I ended up reinstalling ubuntu, because it was a clean install, and it amazingly enough worked fine this time.

Just letting you know about this.

[Fengyang Wang (fengyang-wang-0)]

Henk (#82) brings up an interesting point. Maybe the reason this bug thread has more "power users" is because many of the non-"power users" have been locked out! They can't boot into their only computer and so can't report this bug.

Please stop closing critical bugs like this.

[theghost (theghost)]

Maybe this bug is filed against the wrong component (grub2) but then one (or more) of the following possible components is buggy:

1. the Ubuntu installer is/was broken because it did not set the "install_devices" setting before 14.04 (my case, I installed with 13.10 installer)
2 If it was not possible to set this option before 14.04 because we had grub1, then it's a fault in Ubuntu's grub1 -> grub2 migration scripts (14.04 release upgrader)

But it's definately not "invalid". As you can see more and more people are hit by it...

[Ningfei Li (ningfei)]

@Mathias #85 actually we've had grub2 for a long time (since 13.04 I think)...
Anyway, either "Release Upgrader" or "Grub2" can induce this problem.

I don't have that grub-pc package which Phillip mentioned all the time. My machine is on efi.
Everything works smoothly until doing this upgrade from saucy to "trusty"...
But it's lucky that my machine has a efi setup rather than bios/grub-pc. So when I see this grub error on starup, I can still boot by restarting the computer and choosing to boot from UEFI file. When I booted into the system, I tried to fix this problem by a manually grub-install (of course to the correct device). The "grub-install" command said finished and no error. But it didn't work at all. The problem still existed. Then a simple downgrade of grub-* packages solve the problem. This time "grub-install" printed out more information (as I pointed out at #58, the BootOrder and boot items ) besides just saying finished.

so where the problem is...

[_dan_ (dan-void)]

@Phillip Susi

The upgrade process to 14.04 has to take care of it. If something changed, upgrade process has to run dpkg-reconfigure grub-pc and set the devices. It worked before, does not work now -> upgrade process needs to take care of it.

[thilo (thilo-staebler-i)]

The same here... One harddisk (two partitions ext4, swap), no UEFI-system, only Ubuntu installed, automatic update last night from 13.10 to 14.04 crashed grub/Ubuntu - no grub-fiddling before...

[Dr Michael Brooks (michaeljtbrooks)]

Affects me too. Stock upgrade from 13.10 to 14.04.

The arrogance and buck-passing behaviour of the Ubuntu devs on here is astounding.

This is a very definite critical bug where the update process is failing to handle what seems to be a common situation. Stop arguing and start fixing, there clearly is a need.

[torry (tduffy-4)]

This is insane! I copied the the header and the bug report and you cant find it even though there are entries today. This is a major bug that you seem unwilling to admit to. two years ago when Fedora did the same thing they lost, and Ubuntu gained.

Everyone who has reported this fiasco has been snubbed or called ignorant. Simply updating to, or installing 14.04 causes the system to fail, taking all others loaded by grub2 with them.

Since the loader is wrapped in script, and components sprinkled around the root drive, it would seem that Ubuntu is falling into the same trap as Fedora.

Among other problems the Grub2 loader thinks that all my partitions should be renamed, "msdos1, msdos2, etc.

I have tried everything proposed and realize that the only way to fix this is to remove ALL ofGRUB including the service files.

If a fix is not forthcoming UBUNTU looses big time.

Torry Duffy

[Tamale (uictamale)]

Fresh install of 13.10, single drive, single OS laptop, nothing but official ubuntu package installs.

Followed on-screen upgrade procedures, ran into this exact bug. This is not "invalid".

[Felix Hall (phelicks)]

Fresh install of 13.10 a month ago, upgrade to 14.04 yesterday after recommendation from my login-motd, and this happened to me.. Nice..
Fixed by dpkg-reconfigure grub-pc, as recommended.

[Lupe Christoph (lupe)]

As a side note, I just found why my Sony Vaio SVS1511L3ES had this problem (had because I just fixed it ;-)

Sony is using the crappy Insyde H2O UEFI that has no UEFI boot menu. It always uses whatever it finds under /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi. When I installed Ubuntu 12.10 in December 2012, I copied the GRUB grubx64.efi to that path. Upgrading to 13.04 and 13.10 went without problems and I forgot about the hack until now.

With Ubuntu 14.04, one has to copy grubx64.efi again. Problem fixed. I doubt Boot-Repair knows this little trick, but I haven't checked.

[arco444 (grant-ellis)]

Had the exact same problem today. Upgraded from 13.10 to 14.04 this morning and was greeted by:

symbol 'grub_term_highlight_color' not found

and the grub rescue prompt.

Supergrubdisk did not work for me, neither did the various other methods mentioned above. I'm using 2 disks with LVM. /boot is located at sda1 and always has been. The rest of the OS is on the LVM partition which is spread across other partitions on sda and sdb. No manual changes have ever been made to grub since the system was built 7 months ago.

Solution was to manually load the kernel from the grub console

set root=(hd0,1)
linux /vmlinuz-3.13.x-xx-generic ro root=/dev/mapper/vg-root
initrd /initrd.img-3.13.x-xx-generic
boot

Once in the system, dpkg-reconfigure grub-pc had no effect.
Had to first run grub-install --boot-directory=/boot -v --recheck /dev/sda

This brought back expected grub menu options at boot.

A subsequent run of "dpkg-reconfigure grub-pc" was then successful.

[James Jones (jamesjones01)]

Had the same problem this morning. After problems trying to get the 334.21 NVIDIA driver installed on Mint for a new 750Ti card, I decided to just install the Ubuntu 14.04 and then use a PPA with the driver I'd found. The install went smoothly, I *think*. Part way through, the graphics on the screen were stretched vertically so I could no longer see informational messages or prompts; I just hit ENTER once the installation seemed to be done, and the DVD ejected and the system rebooted after I closed the try and hit ENTER again.

Everything looked normal until the lines

error: symbol `grub_term_highlight_color' not found.
grub rescue>

appeared.

I have NEVER installed grub myself.

[Cedders (cedric-gn)]

My guess is this is a regression in grub-mkconfig between 2.00-19ubuntu2.1 and 2.02~beta2-9. Neither of the situations in Phillip Susi's comment 64 applies to my case. Maybe there are several different possible causes for Grub2 not booting after an upgrade, and I'm not yet convinced these are distinct bugs.

In the case of this Lenovo laptop, there's only one drive, no EFI, but grub is installed to a partition. It came with Windows on 3 partitions, so I installed Lubuntu 13.04 to a logical partition, sda5; I later enlarged and moved that partition (Partition table entries are not in disk order) and upgraded to saucy (the only change I made to /etc/default/grub was to comment out GRUB_CMDLINE_LINUX=""). Then today I did the dist-upgrade through the Software Updater and there were no visible errors, but on reboot I got the grub rescue prompt with error "symbol 'grub_term_highlight_color' not found" and the same error in response to "insmod linux". The following warning was in the dist-upgrade log:

Installing for i386-pc platform.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.

parted -l output for the drive:

Model: ATA ST9250411AS (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 1259MB 1258MB primary ntfs boot
 2 1259MB 91.3GB 90.0GB primary ntfs
 4 91.3GB 194GB 103GB extended
 5 91.3GB 111GB 20.0GB logical ext4
 6 111GB 191GB 80.0GB logical ext4
 7 191GB 194GB 2999MB logical
 3 239GB 250GB 11.0GB primary ntfs

chrooted to sda5 to run debconf-show grub-pc:
  grub-pc/timeout: 3
  grub2/device_map_regenerated:
  grub-pc/disk_description:
  grub-pc/install_devices_failed_upgrade: true
* grub-pc/install_devices: /dev/disk/by-id/ata-ST9250411AS_5VG7HNEE-part5
  grub2/linux_cmdline_default: splash quiet
  grub-pc/hidden_timeout: false
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/install_devices_disks_changed:
  grub2/kfreebsd_cmdline_default: quiet splash
  grub-pc/chainload_from_menu.lst: true
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/partition_description:
  grub2/kfreebsd_cmdline:
  grub-pc/install_devices_empty: false
  grub-pc/kopt_extracted: false
  grub-pc/install_devices_failed: false
  grub2/linux_cmdline:

I booted from USB with 13.04 and did grub-install with "--root-directory=/mnt/sda5" as in Sylvain's helpful comment 79 and could then boot from sda (sometimes sda and sdb are reversed booting from USB). However, on running dpkg-reconfigure grub-pc from within 14.04 as Phillip suggested with the same settings (install to sda5), the problem re-emerged on next boot. A grub-install using 13.10 also seemed to fix it. After a grub-install in 14.04, I can no longer reproduce the grub failure, and am not sure which of these conditions are relevant. It could be that steps to reproduce are: ...

[Dana LeMoine (dana)]

I have Ubuntu 13.10 on two computers, a laptop and a desktop. Upgraded the laptop to 14.04 and everything is fine. Upgraded the desktop and ran into this error.

I am not a power user. Just a moderately computer-savvy business owner that is trying to avoid Windows 8. At this point, I am ready to consider my desktop dead. I may try some of the fixes proposed here, but honestly, I don't understand them well enough to really even know where to start.

I am saddened. Mostly because I thought I found an alternative to Windows.

-Dana

[BenM (benmottram)]

Another case here...

Desktop system, vanilla install of xubuntu 13.04 last year (August I think), updated as and when with patches. Last update was yesterday before the dist upgrade.

Upgraded yesterday to 13.10 with no issues at all.

Upgraded today and got the symbol not found error.

Interestingly when I try to load the linux module from the grub rescue prompt by hand I get the same error - http://ubuntuforums.org/showthread.php?t=1599293 hinted at how to perhaps get linux to boot from the rescue prompt.

I eventually worked around the issue by downloading a 13.10 image, booting and using the boot repair utility as described http://iambusychangingtheworld.blogspot.co.uk/2014/03/error-symbol-grubtermhighlightcolor-not.html

Using the above webpage the process asks where to install GRUB - I picked the RAID volume, rebooted when instructed to by boot-repair and everything works. I guess I will have to wait 6 months before trying the next update to see if a rinse and repeat is required - I guess I could do the same boot repair with a 14.04 live CD, or leave that to another user to try.

The desktop has an Intel hardware RAID controller - two 400gb disks mirrored; Grub was set to boot off the RAID volume. Looking up the thread if the previous version of grub, installed with 13.04/13.10 didn't mind about the RAID and the upgrade-manager installed version does that would explain how the work around works.

the boot-repair log can be found at http://paste.ubuntu.com/7338702/ is it is of any use.

Regards

BenM

[yarn (yetanotherrandomname)]

This affects me, too, and I've been unable to fix the problem.

I tried pureblood's #27 strategy and _tried_ using dpkg-recongifure grub-pc but even doing this with what I think are all my partitions it doesn't work.

I did set it up top dual boot into Windows 8 and Ubuntu 13.10. After update to 14.04 machine is now unusable, giving the "symbol 'grub_term_highlight_color' not found" error and going to "grub rescue."

Having no idea what to report or do here, I'll ape what others did:

====================================
Output from debconf-show grub-pc:
--------------------------------------------------

debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied
  grub2/kfreebsd_cmdline:
  grub2/linux_cmdline:
  grub-pc/install_devices_failed: false
  grub-pc/chainload_from_menu.lst: true
  grub-pc/postrm_purge_boot_grub: false
  grub2/kfreebsd_cmdline_default: quiet splash
  grub2/linux_cmdline_default: quiet splash
  grub-pc/hidden_timeout: true
  grub-pc/install_devices:
  grub-pc/partition_description:
  grub2/device_map_regenerated:
  grub-pc/kopt_extracted: false
  grub-pc/disk_description:
  grub-pc/install_devices_empty: false
  grub-pc/timeout: 10
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/install_devices_disks_changed:
  grub-pc/mixed_legacy_and_grub2: true

====================================
Output from sudo parted -l:
---------------------------------------

Model: ATA ST2000DM001-9YN1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 1049kB 420MB 419MB ntfs Basic data partition hidden, diag
 2 420MB 735MB 315MB fat32 EFI system partition boot
 3 735MB 869MB 134MB Microsoft reserved partition msftres
 4 869MB 716GB 715GB ntfs Basic data partition
 5 716GB 1970GB 1254GB ext4
 6 1970GB 2000GB 30.1GB linux-swap(v1)

Model: JetFlash Transcend 64GB (scsi)
Disk /dev/sdg: 63.2GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 63.2GB 63.2GB primary fat32

Model: Flash Drive AL_USB20 (scsi)
Disk /dev/sdh: 129MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 49.7kB 129MB 129MB primary fat16

Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0
has been opened read-only.
Error: Can't have a partition outside the disk!

====================================

I am just an ordinary user who'd hoped the "Linux for Human Beings" could be used by a normal one, but maybe I was wrong.

Thanks for any help anyone can provide.

[Roy F. Matthews (matthews-royf)]

I was able to fix this problem following advice of (Splaktar) by downloading a grub repair. It was an easy fix but a very difficult position caused by a simple automatic upgrade from 13-10. This is not a problem for non-technical users like myself to face. I've read the comments above, understood very little of it, other than it is widespread and can happen to anyone, even a novice. An automatic upgrade that automatically incapacitated my machine. I do thank all of you for helping me repair my broken GRUB.
MRoy

[yarn (yetanotherrandomname)]

I, however, did not find an easy fix. After spending all day (i.e., over 10 hours) trying to muddle through commands I don't really understand, I read that the solution is in fact to reformat your harddrive (http://ubuntuforums.org/showthread.php?t=2218362). Given this, I finally gave up worrying that fiddling with parts I don't understand by doing things I can't even pronounce is going to do even more damage to my machine than is done by making it utterly unbootable.

Released from care by knowing I'll probably have to start from scratch anyway, I start doing things nearly randomly, and may have added grub to every partition aliong the way. Continuing this strategy with the options in boot-repair, I stumble upon a combination of chosen options that lets me boot. I have no idea if I now (still?) have "a misconfigured system;" all I know is that after hours of trying random things after hours of having exhausted trying posted things, it finally works again.

For other's sake, I got it to work by using the general steps given here:
http://iambusychangingtheworld.blogspot.com/2014/03/error-symbol-grubtermhighlightcolor-not.html
with these these particulars (no idea what really mattered, so just giving it all):

=======================================

Boot-Repair Options
----------------------------

Advanced Settings:
Main options
- reinstall grub
- use standard efi
- backup and rename windows efi
- hid boot menu

GRUB options
- secure boot
- purge grub before reinstall
- did NOT upgrade grub to most recent version

GRUB location
- changed to windows (via sda5) [I think this was the critical point, but I really have no idea--I could have recited something from the Necronomicon and had as much faithin what I was donig]
- ata disk support

Output from boot-repair:
----------------------------------

Boot successfully repaired.

Please write on a paper the following URL:
http://paste.ubuntu.com/7341950/

In case you still experience boot problem, indicate this URL to:
<email address hidden> or to your favorite support forum.

You can now reboot your computer.
Please do not forget to make your BIOS boot on sda (2000GB) disk!

You may want to retry after deactivating the [Backup and rename Windows EFI files] option.

=======================================

With this, it rebooted to Windows fine. To reboot to Ubuntu, had to go to Advanced Ubutnu Setup in grub and choose an old kernel (3.11.0-18-generic); it won't work if I try a newer kernel.

Please understand that I very sincerely appreciate the hard, selfless work that went and continues to go into the creation of Ubuntu and related products. But please also understand that if you want people to share your work, you can't expect them to share your expertise.

There are those who love to tinker with their cars, playing with the cylinder timings, oil mixture, whatever. But like many end users, I have places to go and things to do. I use Ubuntu because, ideologically, I'm very for open source--but ahead of even strong ideological convictions are real-world obligations. If I can't reliably put my key in the ignition and go, then, yeah, f*** this. Spend all the time you want navel-gazing abou...

[Mark Kendall (markk)]

This bug effects me and booting up from CD, chrooting and then doing dpkg-reconfigure didn't work.
If this is a known issue that can't easily be worked around why can't it be detected pre upgrade and the upgrade stopped!

[theghost (theghost)]

As more and more people are stuck with this bug and don't know what to do, here's a small how I fixed it:

1. Download SuperGrubDisk2 Beta: http://www.supergrubdisk.org/category/download/supergrub2diskdownload/super-grub2-disk-beta/
2. Burn it to CD or put it on USB stick
3. Restart and choose the CD/USB as boot device
4. Boot manually into your Ubuntu from the Super Grub Disk menu
5. In Ubuntu run "Disk" or "Gparted" and determine your boot partition (e.g. like /dev/sda1)
6. Open Terminal and reinstall grub on the boot device (meaning leave out the partition number): "sudo grub-install --recheck /dev/sda"

With this grub is reinstalled and all installed OS are detected properly setup in grub.

[Max Wolf (max-2)]

I upgraded three machines and ran in the problem on just one.
boor-repair didn't work for me, but after a grub-install with the live-cd i got to the grub shell and succeeded booting manually.
running grub-install again from within 14.04 fixed it eventually.
I learned a lot about grub, but lost around a day sorting this out.
(I work as a half-time linux sysadmin, but i never had to deal with grub before).

This article helped me to understand how to boot manually: https://help.ubuntu.com/community/Grub2/Troubleshooting
But i doubt, that most end users can deal with this.

What concerns me more than the actual bug is the handling of this bug.
It's unclear to me, if somebody is taking care of this. I agree with the high priority.
This will make many users ran away from the distro of from linux in general.
psusi seems to be involved, but refuses to be helpful.
In a software company, somebody would would talk to his boss. But what is the escalation procedure here?

It seems, that none of the commenters here really understands what's causing this.
This requires a senior engineer with grub/updater know-how, who is willing to help.

My guess is, that it's not grub2 but the updater, that's causing this.

[olly_b (olly-xquest)]

I have encountered this bug on both an upgrade and an install of 14.04 with on a Toshiba Laptop

$ sudo parted -l
Model: ATA TOSHIBA MQ01ABD1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 1049kB 1075MB 1074MB ntfs Basic data partition hidden, diag
 2 1075MB 1347MB 273MB fat32 Basic data partition boot
 3 1347MB 1482MB 134MB ntfs Basic data partition msftres
 4 1482MB 496GB 494GB ntfs Basic data partition
 6 496GB 498GB 2048MB linux-swap(v1)
 7 498GB 968GB 470GB ext4
 8 968GB 988GB 20.0GB ext4
 5 989GB 1000GB 11.7GB ntfs Basic data partition hidden, diag

Here is a history:

Installed Ubuntu Studio 12.04 dvd-amd64 from DVD to sda5
No grub menu so ran boot repair:
sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair
boot-repair
rename EFI files - yes
grub menu ok - could boot to Ubuntu and Win 8, but no network connection due to PCI-E Qualcomm Atheros AR8161 incompatibilty, so

Installed Ubuntu Studio 13.04 dvd-amd64 from DVD to sda5
No grub menu so ran boot repair as above
grub menu ok - could boot to Ubuntu and Win 8 but Jack latency worse than 12.04 installation on inferior spec PC, so

Upgraded to 13.10
No grub menu so ran boot repair as above
grub menu ok - could boot to Ubuntu and Win 8 and Jack latency similar to 12.04

Ran all advised upgrades for a few months

Received message to upgrade to 14.04 as Saucy no longer supported, so

Ran 14.04 upgrade with no errors
Booted
error: symbol 'grub-term-highlight-color' not found.
grub rescue>

insert ubuntu 13.04 disk and select try unbuntu
sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair
boot-repair
Select Recommended Repair
rename EFI files - yes
http://paste.ubuntu.com/7320970/
Booted
error: symbol 'grub-term-highlight-color' not found.
grub rescue>
Downloaded and installed Ubuntu Studio 14.04 dvd-amd64 from USB to sda5
Booted
error: symbol 'grub-term-highlight-color' not found.
grub rescue>

insert ubuntu 14.04 disk and select try unbuntu
sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair
unable to locate package boot-repair
boot-repair
file not found

Installed Ubuntu Studio 13.04 dvd-amd64 from DVD to sda5
No grub menu so ran boot repair: as above
sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair
boot-repair
Select Recommended Repair
rename EFI files - NO
http://paste.ubuntu.com/7331102/
grub menu ok - can boot to Ubuntu and Win 8

$ sudo debconf-show grub-pc
  grub-pc/kopt_extracted: false
  grub2/kfreebsd_cmdline:
  grub2/device_map_regenerated:
  grub-pc/install_devices:
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/disk_description:
  grub2/linux_cmdline:
  grub-pc/install_devices_empty: false
  grub2/kfreebsd_cmdline_default: quiet splash
  ...

[Francesco Cetraro (4-francesco)]

The solution to this issue is banally simple actually... There is no point reinstalling grub over and over again (which I did) or use Boot-Repair to death... You just need to give Grub what it asks for.

So I went and edited /etc/grub.d/05_debian_theme, adding the last line below:

set_default_theme(){
 case $GRUB_DISTRIBUTOR in
  Tanglu|Ubuntu|Kubuntu)
   # Set a monochromatic theme for Tanglu/Ubuntu.
   echo "${1}set menu_color_normal=white/black"
   echo "${1}set menu_color_highlight=black/light-gray"
   echo "${1}set grub_term_highlight_color=black/light-gray"

running "sudo update-grub" after that did the trick, and I am now writing from a fully functional Xubuntu 14.04.

I would however like to stress my disappointment and frustration about how appalling it is of Canonical/Ubuntu to release an LTS with such a stupid bug in it on such a fundamental piece of software. Furthermore, there is no documentation to be found anywhere online on what the bloody "grub_term_highlight_color" is supposed to do. Lucikily, a simple test solved the issue.

[Adam Niedling (krychek)]

I'm still on 13.10 cuz I'm waiting with the upgrade. I just checked the file mentioned by Francesco:

$ cat /etc/grub.d/05_debian_theme | grep highlight
   echo "${1}set menu_color_highlight=black/light-gray"
   echo "${1}set menu_color_highlight=white/blue"
  echo " set color_highlight=${3}"

Does it mean that my upgrade is gonna fail too because I don't have "grub_term_highlight_color" in 05_debian_theme?

Why is it not there? Has it been removed by something? Is it gonna be put there by something during upgrade? Why is it so crucial for grub that it refuses to start without it?

[James Jones (jamesjones01)]

While I did not install grub myself, I did put it on the wrong drive, as I noticed when reinstalling. Corrected that (and told it not to install proprietary drivers during the initial install, so it wouldn't try something that didn't (quite) work on a recently acquired 750Ti graphics card and I could see what was going on all through the install), and all was well.

[RichardNeill (ubuntu-richardneill)]

I reported this on Mageia; you may find the following helpful.
https://bugs.mageia.org/show_bug.cgi?id=12423

As to what is happening, it has got *nothing* to do with the terminal_highlight_color.
Grub has 2 parts:
   The early stage, installed in the drive's bootsector
   The rest of the modules, installed in /boot/grub

These two are getting out of sync, and the ABI symbol mismatch is because there is an older version of one than of the other.
I suspect that:

1. The grub package, which installs binaries into /boot/grub is being updated
2. Something is failing to correspondingly update /dev/sdX's boot sector
3. No warning is emitted.

[Phillip Susi (psusi)]

@Jordi, you appear to have two drives but grub-pc/install_devices only points to one. You probably manually installed grub to the other at some point, and are booting from that drive. It didn't get reinstalled on that drive when grub upgraded. Run sudo dpkg-reconfigure grub-pc and select *both* drives.

@Fengyang: it has nothing to do with the upgrade tool. The upgrade scripts in the grub-pc package handle reinstalling grub, but can only do so if grub-pc/install_devices is set correctly. This only applies to grub-pc, not grub-efi, so if you are using grub-efi, your case is different. Do you only have the one disk you showed in comment #49? Do you have your efi system partition mounted in /boot/efi? Can you attach your /var/log/dist-upgrade/apt-term.log?

@Mathias: grub1 has not been used since ubuntu 9.04, and if you keep upgrading from there, you stay on grub1 rather than migrate to grub2.

@_dan_: the upgrade process does take care of it by using the value in grub-pc/install_device. If it is unset, or not set correctly, it has no way of knowing that isn't what you wanted, and so can not decide to force you to reconfigure it.

@tamale, same question as everyone else: is your grub-pc/install_devices set correctly? If not and you don't think you had any problem installing 13.10 and had to manually install grub, please attach your /var/log/installer/syslog file.

@Cedders, it looks like you have the Windows boot loader chain load grub rather than having it installed directly. This is not a supported configuration. The windows loader does not directly chain load grub from the partition you have it installed to, instead at the time you set it up, it copies the boot sector of the partition to a file and loads that. Thus this file was not updated when grub was, which lead to the error. You should install grub to the MBR instead and have it chain load windows.

@yarn, and @olly_b, like Fengyang, you appear to be using efi, so you should have grub-efi rather than grub-pc installed. Can you run df and make sure that /dev/sda2 is mounted in /boot/efi and attach your /var/log/dist-upgrade/apt-term.log file?

[Launchpad Janitor (janitor)]

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

[Tamale (uictamale)]

@psusi - I didn't manually install anything, unless you count the initial install of 13.10 from USB. I don't have anything to attach because my system was lost due to this bug. I had to install 14.04 fresh from USB to get a working computer again.

[Francesco Cetraro (4-francesco)]

@krychek
the line "echo "${1}set grub_term_highlight_color=black/light-gray"" was simply not there before, I had to add it manually to that file for this to work. Considering I could not find anything in the Grub documentation about this "grub_term_highlight_color" setting I suspect this is something new that has been added in 2.02 that wasn't there in 2.0.

Also, I should mention that I was affected by this bug on my own laptop that uses UEFI, but when I upgraded my gf's older laptop everything worked fine there, so I wonder if this error is only triggered when Grub is used in conjunction with UEFI.

[olly_b (olly-xquest)]

@psusi,
Thanks for the suggestions - As my laptop is currently running a fresh install of 13.04, I'm not sure the requested information is relevant:

olly@olly-laptop-1-ubuntu:/var/log/dist-upgrade$ ls
olly@olly-laptop-1-ubuntu:/var/log/dist-upgrade$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda8 19091584 7010924 11104124 39% /
none 4 0 4 0% /sys/fs/cgroup
udev 4017600 4 4017596 1% /dev
tmpfs 805424 904 804520 1% /run
none 5120 0 5120 0% /run/lock
none 4027112 72 4027040 1% /run/shm
none 102400 12 102388 1% /run/user
/dev/sda7 451651100 58118932 370582952 14% /home
/dev/sda2 262144 52420 209724 20% /boot/efi
olly@olly-laptop-1-ubuntu:/var/log/dist-upgrade$ sudo debconf-show grub-pc
  grub-pc/kopt_extracted: false
  grub2/kfreebsd_cmdline:
  grub2/device_map_regenerated:
  grub-pc/install_devices:
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/disk_description:
  grub2/linux_cmdline:
  grub-pc/install_devices_empty: false
  grub2/kfreebsd_cmdline_default: quiet splash
  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/mixed_legacy_and_grub2: true
  grub-pc/timeout: 10
olly@olly-laptop-1-ubuntu:/var/log/dist-upgrade$ sudo debconf-show grub-efi
olly@olly-laptop-1-ubuntu:/var/log/dist-upgrade$

I have only used the official install or upgrade procedures - I have not manually installed or reconfigured.
In every dual-boot installation I have done I have needed to run boot-repair.
12.xx and 13.xx installations have resulted in functional systems (after boot-repair).
Both 14.04 upgrade and install resulted in this error.
If grub-efi needs to be installed instead of grub-pc, why is this not done by the installer?

[Phillip Susi (psusi)]

@Francesco, grub_term_highlight_color is not a setting, it is a C function. It was removed in the 14.04 version of grub, so if you still have the 13.10 version of grub in the MBR, it is still looking for it and can't find it in the 14.04 grub modules, hence the error. It has nothing to do with 05_debian_theme.

@olly_b, if you have reinstalled then the information is lost. Also 13.04 is end of life and unsupported so you really shouldn't be running it. The installer *does* install grub-efi if you are running efi ( if it didn't you'd never boot ).

[_dan_ (dan-void)]

@Phillip Susi

As i said 2 times before, it worked that way since version 6.*, it stopped working with 14.04, which means something changed, which means upgrade process needs to take care of it. By the many reports here you can clearly see it did *not* even if you keep repeating yourself and blame the users.

This conversation is getting really tiresome, i think we have gotten to a point were it makes no sense anymore to talk further, at least with you.
This is a good example of pointlessly wasting time trying to help the ubuntu project.
Very disappointing.

[Ian McDonald (ian-mcdonald-jandi)]

Would totally agree. This is a real bug as we have around 25% of users hit
in a corporate environment. It didn't happen with other releases.

Sent from my Android phone

[karthikey hegde (karthikeyhegde)]

This grub behavior Im facing from the upgrade 13.04 to 13.10. When we do usb/dvd install it works nicely. But after the install if we do the software update whole grub boot loader will break.

Same problem exists with 14.04 also. It installs fine, works fine but when grub loader breaks after software updates (may be with grub updater).

Is there any other bootloader we can have with 14.04 so that till this issues get fixed we have peaceful days with software updates.

[Rostislav Hucka (hucka)]

Problem solved
The problem lied in somehow incomplete grub upgrade. The solution is quite simple:
1) Boot some live CD and chroot to the damaged instalation, like http://ubuntuforums.org/showthread.php?t=1156240
2) Purge all grub* packages
3) Check /boot directory and remove grub and grub2 folders completely
4) Install grub-pc and depending packages
5) Exit chrooted enviroment and reboot

[olly_b (olly-xquest)]

@psusi
I am aware that I should not be running 13.04; that is why I attemped to install 14.04, which failed due to the bug we are all discussing!
The information I gave is from a functional re-install of 13.04, which successfully boots either into Ubuntu or Win8, apparently without grub-efi.
When there is concensus on a procedure for a dual boot installation of 14.04 , I will try again.

[sde (sde)]

I spent about 8 hours trying different methods mentioned above, to repair a 14.04 upgrade from 13.10. The method that worked for me was boot-repair, selecting standard repair with the "rename Windows files" option (aka rename EFI files.)

Things that didn't work on my system: (all repairs required booting from a LiLi USB of 13.04 first)
1. boot-repair standard repair with no options, (after that it booted directly to Windows 8)
2. boot-repair again, which had some errors on missing 386 files (after that "1962 no operating system found" error)
3. switching to prioritize UEFI boot (still "1962") and back
4. boot-repair again with restore EFI files option
5. adding the missing expected line to grub by mounting the old system and chroot'ing in and editing 05_debian_theme and updating grub
6. chroot'ing in to the old system including setting up Internet access and reinstalling all grub and using 'dpkg-reconfigure grub-pc' (still "1962") This suggested solution was the hardest to do, and didn't by itself solve the problem, although it may have contributed.

The original install was 13.04 amd64 plus use of boot-repair to get a dual boot with Windows 8.

It would be really nice and cool if the upgrade installer for 14.04 or subsequent versions were improved to detect whether the grub installation was up-to-date and ready to be upgraded, before trying to upgrade it, instead of breaking the boot for the whole computer. There should be a warning, and if the warning isn't automatically just given when it's needed, it should be given to everyone using the installer, "If you've used boot-repair, then purge and reinstall grub before attempting upgrade," or something like that, whatever would prevent this problem.

[Tamale (uictamale)]

" It would be really nice and cool if the upgrade installer for 14.04 or subsequent versions were improved to detect whether the grub installation was up-to-date and ready to be upgraded, before trying to upgrade it, instead of breaking the boot for the whole computer. There should be a warning, and if the warning isn't automatically just given when it's needed, it should be given to everyone using the installer, "If you've used boot-repair, then purge and reinstall grub before attempting upgrade," or something like that, whatever would prevent this problem. "

^^^ This guy gets it. How is this not already what the upgrade manager does? Seems absolutely unacceptable for an LTS release to not do some simple sanity checks on core components before completely ruining your system.

[Phillip Susi (psusi)]

Because it isn't possible. There is no way to fully automate the decision of what disk your system is supposed to be booting from and whether grub should be installed there. That is why the information is stored in grub-pc/install_devices.

[Tamale (uictamale)]

Then don't fully automate it - just ask the user what to do. As suggested, it can guide them through removing any old / wrong version and install the correct one BEFORE rebooting...

[Jürgen (j-w-ott)]

(psusi) has given very helpful information. I assume in most cases people have added a new harddisk and grub is now on the wrong drive.

In my case I had to switch to bios boot options with <F12> and select my "old" /dev/sda as boot device.
Back in Linux :-) I followed the steps from (psusi) now everything works fine.

Maybe some documentaion regarding grub2 reinstallation should be enhanced

[Saurabh Rindani (saurabh-prl)]

I upgraded from 13.04 (via 13.10) to 14.04, and found this problem, and I need help to straighten it.

I get the grub rescue prompt with the error " symbol `grub-term-highlight-color' not found".

I managed to get the boot options after loading the kernel from the grub rescue prompt (though it did show some errors), and could boot into linux.

After that, I am unable to reboot correctly, except by a series of commands at the grub rescue prompt.

I found that I did not have the package grub-pc. I installed it however, and tried dpkg-reconfigure grub-pc. However, that has not helped.

I tried to install boot-repair, but I get the following message:
sudo add-apt-repository ppa:yannubuntu/boot-repair
Cannot add PPA: 'ppa:yannubuntu/boot-repair'.
Please check that the PPA name or format is correct.

What I found, however, was that I have efi boot on the Windows partition.

I need help to set things right, so that I can reboot without problem. Here are the outputs of blkid, df and debconf-show :

sudo blkid
/dev/sda1: LABEL="WINRE_DRV" UUID="A8066BD9066BA6D2" TYPE="ntfs"
/dev/sda2: LABEL="SYSTEM_DRV" UUID="546D-3E71" TYPE="vfat"
/dev/sda3: LABEL="LRS_ESP" UUID="546E-285B" TYPE="vfat"
/dev/sda5: LABEL="Windows8_OS" UUID="B8146FC1146F816C" TYPE="ntfs"
/dev/sda6: LABEL="Data" UUID="401E71E21E71D180" TYPE="ntfs"
/dev/sda7: LABEL="PBR_DRV" UUID="8A3269613269536D" TYPE="ntfs"
/dev/sda8: UUID="b0766ae7-bc15-491d-b889-2c733ca06908" TYPE="ext4"
/dev/sda9: UUID="b23dfdca-788a-4605-8a69-c1a25829f938" TYPE="swap"

df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda8 623487480 44357252 547435844 8% /
none 4 0 4 0% /sys/fs/cgroup
udev 4054856 12 4054844 1% /dev
tmpfs 813120 1196 811924 1% /run
none 5120 0 5120 0% /run/lock
none 4065600 152 4065448 1% /run/shm
none 102400 44 102356 1% /run/user
/dev/sda2 262144 28564 233580 11% /boot/efi

sudo debconf-show grub-efi

(no output)

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

Any suggestions for correcting the system?

[Adam Niedling (krychek)]

I don't see why this bug is not possible to fix. There was no issue like this prior to Ubuntu 14.04 so this must be a regression.

[Phillip Susi (psusi)]

@Saurabh, you should have grub-efi and not grub-pc installed if you are booting in efi mode. When you do boot, do you see the windows boot loader first, and then have to choose grub, or does grub come up straight away? Can you run ls /boot/efi/EFI/Microsoft/Boot?

@Adam, there have been issues like this on every release. The symbol name is different but the cause is the same: grub was only half updated.

[olly_b (olly-xquest)]

Some thoughts after reading the comments to date:

The root cause of this error is stated clearly on #109

Various successful workarounds have been reported, including:
Identifying the device mounted on /boot then chrooting to it.
Then either manually uninstalling and reinstalling the grub packages
or running grub-install
or running dpkg-reconfigure grub-pc

The concensus appears to be a preference for dpkg-reconfigure grub-pc

However, many of the reports are from users with dual-boot Win8 installations (like mine)
dpkg-query -l 'grub*' shows that I have grub-efi-amd64 installed, but not grub-pc or grub-efi
It is probable that most pcs with Win8 have 64bit installations.

Would this procedure work?

boot from usb or cd
dpkg-query -l 'grub*'
  to determine which grub packages are installed (grub-efi-amd64 in my case)
df
  to determine device mounted on /boot/efi (sda2 in my case)
cd /tmp
mkdir mount-point
sudo mount /dev/sda2 /tmp/mount-point
sudo mount --bind /dev /tmp/mount-point/dev
sudo mount --bind /proc /tmp/mount-point/proc
sudo mount --bind /sys /tmp/mount-point/sys
sudo chroot /tmp/mount-point
dpkg-reconfigure grub-efi-amd64

[olly_b (olly-xquest)]

refers to #129

Sorry - I got the sequence wrong!

boot from usb or cd
df
  to determine device mounted on /boot/efi (sda2 in my case)
cd /tmp
mkdir mount-point
sudo mount /dev/sda2 /tmp/mount-point
sudo mount --bind /dev /tmp/mount-point/dev
sudo mount --bind /proc /tmp/mount-point/proc
sudo mount --bind /sys /tmp/mount-point/sys
sudo chroot /tmp/mount-point
dpkg-query -l 'grub*'
  to determine which grub packages are installed (grub-efi-amd64 in my case)
dpkg-reconfigure grub-efi-amd64

[Saurabh Rindani (saurabh-prl)]

@Phillip, sorry for my ignorance, grub-pc and grub-efi are new to me. I discovered that I use efi boot only after I installed grub-pc to try and follow suggestions from this forum. I remember having to use boot-repair when I installed 13.04 first, and that probably resulted in the present grub location. Yes, I do see grub as soon as I can boot. Also, I can do ls /boot/efi/EFI/Microsoft/Boot and get an output.

[Terry Ellison (r61-terry)]

I am running Ubuntu on a Lenovo G770 laptop. I left the original Lenovo Win 7 config on the HDD (it's the only Windows boot image I have left and I need it for contingency) -- albeit with a minimal pair of partitions and configured dual boot pretty much as per the Trusty guide though I did this back with 12.10. I have upgraded Ubuntu 8 times, 3 on this laptop, and this has been my only fail. I use a standard grub-pc install, and am a reasonably experienced sysadmin and developer.

@psusi, I won't bother enumerating all the false tries, and cascade failures. The underlying failure appears to be that the upgrade process *silently* failed to install the new 2.02-beta2-9 MBR loader on my HDD, and as you described above, the root failure was that the MBR and /boot grub2 components were out of sync. Given that part 0 starts at a block 2K block rather than block 39, there is no reason why this MBR bootstrap installation should have failed. So a simple sudo grub-install /dev/sda fixed this, and now both images are booting cleanly.

Some general comments:

* LTS releases are supposed to be *stable*. Why are we rolling out a "beta2-9" version of anything? Especially if anything goes wrong it will render the entire system unbootable; and the fix requires intimate sysadmin knowledge so is not really user-workable.

* As others have said, any upgrade process which can leave a significant percentage of users system unusable is badly specified / implemented. This sort of bug is "Critical", IMO and not "High". At a minimum the upgrade process should carry out the necessary validation checks *before* starting the upgrade and abort with an informational error if there is going to be a failure.

* The https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Known_issues page does not list this. It should.

* The user comments in this bugrep include a lot of misleading chaff. A clearly defined diagnostic process and recovery process should be documented by the release team and referenced in the this known issues section.

Blaming the users for this happening is a mistake. Mistakes happen both by users and in development. The main goal here should be to move forward in a positive manner, and to minimise the total impact.

[Phillip Susi (psusi)]

@olly_b, the dpkg-reconfigure grub-pc only applies if you are booting in bios mode.

@Saurabh, the question was *what* output, not whether or not it exists. Also what is the output of sudo efibootmgr -v?

@Terry, once again, running grub-install /dev/sda fixes it today, but breaks the next time grub is upgraded. You need to use dpkg-reconfigure grub-pc so the system remembers that it needs to run grub-install /dev/sda after the next upgrade. Also, once again, it can't be validated in an automatic way.

[Terry Ellison (r61-terry)]

@psusi, Phillip, of course one of the first things that I did was to do a dpkg-reconfigure grub-pc, but this didn't rewrite the MBR bootstrap or give me any meaningful diagnostics to help me restore my system. Where are the configuration guidelines documented to set enable reconfiguration of this package to "run grub-install /dev/sda after the next upgrade"? A URI would be nice.

I believe that there's clearly a logic fail in this grub-pc package. I didn't do any nasty Q&Ds in the first place; I just did the obvious setup process to dual-boot, because -- at least until 13.10 -- it worked, out-of-the-box. From the number of people being hit, it seems that this failure is pretty systemic for a large class users who have other than a single-disk, single-boot image configuration

If your assertion that the upgrade (of grub) "can't be validated in an automatic way" is taken with the 14.04 team's decision to do a mandatory grub update as part of the 13.10->14.04 upgrade, then you are also implying that Ubuntu's position is that it is acceptable that the 14.04 upgrade for this class of users can trash their systems. And this isn't even documented as a caution in the 14.04 known issues.

In my mind, this position *isn't acceptable.* What should we tell such standard users in this class: are we just recommending that they should move to another Linux distro, or shall we just continue to trash a percentage of their PCs?

My own priority was to restore my laptop to a point where it was usable, and where I didn't have to bootstrap through a system recovery USB, leaving my main account with its encrypted home directory inaccessible through normal login. I trust that you guys, that is the Ubuntu grub2 developers, will fix this issue some time in the next six months. And if you don't then I have a work around that I will use again. For my own development work, I'll just stick with my contributions to PHP internals -- À chacun son goût, neh?

[Phillip Susi (psusi)]

@Terry, I am not aware of any documentation since normally the installer takes care of it. Also it does rewrite the mbr any and all drives you selected from the menu. As far as the number of people being hit, 89, out of the what? A million people using Ubuntu, is not a whole lot. Another linux distro won't help either. You can certainly use the workaround of manually running grub-install each time if you want, I'm just telling you how it is supposed to work so that you don't *have* to.

[Saurabh Rindani (saurabh-prl)]

@Phillip, sorry, here's the output of "ls /boot/efi/EFI/Microsoft/Boot":

BCD boot.stl es-ES ko-KR qps-ploc uk-UA
BCD.LOG bootx64.efi et-EE lt-LT Resources zh-CN
BCD.LOG1 bootx64.efi.grb fi-FI lv-LV ro-RO zh-HK
BCD.LOG2 cs-CZ Fonts memtest.efi ru-RU zh-TW
bg-BG da-DK fr-FR nb-NO sk-SK
bkpbootmgfw.efi de-DE hr-HR nl-NL sl-SI
bootmgfw.efi el-GR hu-HU pl-PL sr-Latn-CS
bootmgr.efi en-GB it-IT pt-BR sv-SE
BOOTSTAT.DAT en-US ja-JP pt-PT tr-TR

and here is the output of "sudo efibootmgr -v"

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0000,0001,0003,0004,0005
Boot0000* Windows Boot Manager HD(2,1f4800,82000,5e191502-eb3c-4c14-9cbf-d5fdcac1546a)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0001* ubuntu HD(2,1f4800,82000,5e191502-eb3c-4c14-9cbf-d5fdcac1546a)File(\EFI\ubuntu\grubx64.efi)
Boot0003* Windows Boot Manager HD(3,276800,fa000,def6d7b2-4331-475f-9970-f39d10813f72)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0004* ubuntu HD(2,1f4800,82000,5e191502-eb3c-4c14-9cbf-d5fdcac1546a)File(\EFI\Ubuntu\grubx64.efi)
Boot0005* ubuntu HD(3,276800,fa000,def6d7b2-4331-475f-9970-f39d10813f72)File(\EFI\Ubuntu\grubx64.efi)

[braoult (braoult)]

@psusi. You can add +1 to people having this issue. Don't say "1 million people have no problem",
if you don't speak about 14.04. Also, the 89 number is from prople who were able to boot.

My system is fresh 13.04, upgraded to 13.10, and 14.04.

I did not touch grub, and I was lucky enough to have a second computer (Apple) where I could
burn a boot-repair. What about others who just cannot, such as your mom? Silent, so no issue reported?

And no, I don't have dual boot. And yes I have 2 hard drives, but never booted from the second one.

This is a serious bug, really. My computer would have been stoned without the Mac to help.
Another distro could be better, of course, if change management (especially testing) is correctly done.

I would add: "Also, once again, it can't be validated in an automatic way" is a nonsence. A booting drive
(unique) can be validated. If the script is not sure, asking a question would not hurt.

[SatPhil (satphil)]

I hit the problem as well upgrading from 13.10 to 14.04. Quite a shock.

-0- After several tries, I finally got it to do an initial boot using "boot from EFI file" (see details below), but then made two changes, after which it kept rebooting OK without intervention, so not sure which of the two changes was critical. The two changes were:

-1- sudo dpkg-reconfigure grub-efi-amd64
as suggested by olly_b in #130 (thanks, Olly)

-2- in my /boot/efi, moved all subdirectories to /boot/efi/old
sudo mkdir /boot/efi/old
sudo mv Boot EFI Microsoft ubuntu /boot/efi/old/.
    and then did
sudo mkdir /boot/efi/EFI
sudo cp -r /boot/efi/old/EFI/ubuntu /boot/efi/EFI/.

More details:

My configuration:

On a 2012 HP Envy 6 notebook.

It's a dual boot setup: Windows 8.1 Update, using 500GB and 32GB internal drives and Ubuntu set up on a 31.6GB external USB flash drive as an encrypted physical volume /dev/sdc3 with the root file system and swap being on logical volumes.

It boots from EFI with /dev/sdc2 being mounted at /boot and /dev/sdc1 at /boot/efi.

---
$ sudo parted -l
Model: ATA Hitachi HTS54505 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 210MB 209MB primary ntfs boot
 2 210MB 479GB 479GB primary ntfs
 3 479GB 500GB 21.0GB primary ntfs
 4 500GB 500GB 113MB primary fat32 lba

Model: ATA SAMSUNG MZMPC032 (scsi)
Disk /dev/sdb: 32.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 8589MB 8588MB primary

Model: USB Flash Drive (scsi)
Disk /dev/sdc: 31.6GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 1049kB 512MB 511MB fat32 boot
 2 512MB 768MB 256MB ext2
 3 768MB 31.6GB 30.9GB

Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/ubuntu--vg-root: 22.4GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number Start End Size File system Flags
 1 0.00B 22.4GB 22.4GB ext4

Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/ubuntu--vg-swap_1: 8485MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number Start End Size File system Flags
 1 0.00B 8485MB 8485MB linux-swap(v1)

Error: /dev/mapper/sdc3_crypt: unrecognised disk label
---

Having an EFI boot setup, I should have run "sudo debconf-show grub-efi-amd64" but didn't before I fixed the problem. Anyway, this is how it looks now:

---
$ sudo debconf-show grub-pc
  grub2/kfreebsd_cmdline_default: quiet splash
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_disks_changed:
  grub2/device_map_regenerated:
  grub-pc/hidden_timeout: true
  grub-pc/install_devices:
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/disk_description:
* grub2/linux_cmdline_default: quiet splash
  grub-pc/timeout: 10
  grub-pc/chainload_from_menu.lst: true
* grub2/linux_cmdlin...

[Terry Ellison (r61-terry)]

@psusi, Philip, Just responding to your comments

> I am not aware of any documentation since normally the installer takes care of it.

So this tells me that from the PoV of the developers there is no relevant user documentation on this which I read is a statement that it is undocumented.

> Also it does rewrite the mbr any and all drives you selected from the menu.

I am not doing a virgin install, and there is no such dialogue in the upgrade process. But yes, I did specify this drive in the original install at 12.10, three upgrades ago and it didn't update the MBR on this upgrade, so this context has been lost somewhere along the line.

> As far as the number of people being hit, 89, out of the what? A million people ...

This is flawed logic. To put these numbers in perspective the corresponding counts for the 3 "critical" grub issues are:

    #1024383: 77 in 21 months
    #1061255: 20 in 18 months
    #1183392: 6 in 11 months

So in two weeks since the 14.04 release, this issue (#1289977) at 89 reports is already at the top, but is still not rated as critical, or from your wording as very important. note that one reporter (#117) stated: "This is a real bug as we have around 25% of users hit in a corporate environment". Luckily, most corporate and complex users (the sort that will be hit by this) wait a few months before upgrading -- to let such teething issues be fixed. IMO, if this issue isn't addressed soon then Ubuntu could face a shit-storm of bad publicity.

The respective counts for the 11 know issues detailed in the Release Notes section on Boot, Installation and Upgrade are 13, 4, 2, 2, 6, 6 3, 5, 5, 5 and 12 users. This issue at 89 clearly tops this total of 63 especially as only 5 these cause loss total system functionality as opposed to all 89 here.

It merits an explicit mention in the Release Notes, and it merits treatment as a serious issue.

[mpGoodwin (martin-launchpad-goodwin)]

Would it be possible to look into the bios (or efi) setup and check that this info (which is what the system will actually use to boot next time) corresponds to the info found in dpkg-reconfigure grub-pc. If not, the user could be prompted to do a manual selection of which drives to push the updated grub to (with recommendations as to what would be a sensible choice)

It might be possible to read the version of grub on each of these disks, and present that alongside the selection process, and also describe what scenarios could have caused this manual step to be needed (you may have added a second drive to the system, repartitioned, or...)

[Phillip Susi (psusi)]

@Saurabh, you seem to have a second copy of grub in the windows efi directory, and you are booting using the windows boot loader, which then chain loads this copy of grub when you select it from the menu. It is this second copy that is broken after upgrade since Ubuntu knows nothing about it. The question is, how did you come by this configuration? Did you install Windows after Ubuntu? Did you ever use grub-customizer?

[Saurabh Rindani (saurabh-prl)]

@Phillip, Windows was certainly loaded first (if I remember right, Windows 8 came pre-loaded on this touch-screen Lenovo Ideacentre all-in-one desktop). I did not use grub-cusomizer. However, what I do know is that when first attempts at loading Ubuntu 12.4 LTS and Fedora failed because they did not support the hardware on my machine, I installed Ubuntu 13.4 in July 2013. At that time, while I got the grub boot menu with Windows and LInux both listed, I could not boot any of them -- the system was just frozen. If I remember right, I booted using the live-CD and ran boot-repair, and that point onwards, everything worked fine. I then upgraded to 13.10 without any problem. There is a directory:

/var/log/boot-sav/log/2013-07-22__11h25boot-repair43

which contains files

boot-repair.log RESULTS.txt sda1 sda3 sda6 sda8
boot-repair.logb sda sda2 sda5 sda7

(of course, sd* are directories).

If it helps, I can list one or more of these files.

That of course is history. But I hope it helps to know how to repair what is broken. Thanks for your efforts.

[oldfred (oldfred)]

Boot-Repair does the rename for 'buggy' UEFI. Many HP & Sonys only boot with one of the fixes as the UEFI is hard coded to only boot Windows. The rename then lets UEFI think it boots Windows efi file but really boots to grub menu. But then Windows entry in UEFI only boots grub.

bkpbootmgfw.efi
That file is the Windows boot file and grub or shim are renamed to bootmgfw.efi.
Best to undo that before anything else, either with Boot-Repair or manually as that confuses all the other issues:

Always say no until proven that you only can boot Windows entry from UEFI menu.
buggy-kernel detected. Do you want to activate [Backup and rename Windows EFI files]? yes (if any choice fails, please retry with the other)

To undo & to rename files to their original names, you just need to tick the "Restore EFI backups" option of Boot-Repair.

[M. Sussman (mmsussman)]

I have the same problem.

I have 13.10 installed on a VM using VirtualBox. This VM is single-boot, but uses lvm with boot on /dev/sda1 and several disks in the lvm. In particular, root (/) is in the logical volume. On upgrade to 14.04, I got the dreaded "symbol 'grub_term_highlight_color' not found" error and the VM is no longer bootable. I tracked through several of the work-arounds, but I have not found instruction on how to mount the (lvm) root partition when booting a live CD, so I cannot see how to re-install grub.

I did nothing other than attempt to upgrade to 14.04. I did not re-install anything (I have never succeeded in booting the upgraded system) and the old system was working fine. I do not see how this could be my fault, and I cannot find instructions that I can follow to repair the upgrade. (I am a reasonably sophisticated user, but by no means a system administrator.)

I guess I will have to revert to the 13.10 "snapshot", but I would be willing to provide any information about the failed system before I do so. There is no personal information on this VM, so if you want a copy (about 10GB) tell me how to give it to you.

[Terry Ellison (r61-terry)]

@Phillip, I took a step back and analysed what went wrong with in my upgrade process. As part of the upgrade, the process executes a dpkg-reconfigure grub-pc which throws up a configuration dialogue, in my case listing the install devices as:

[ ] /dev/sda (500107 MB; ST9500325AS)
[ ] - /dev/sda5 (32212 MB; /)

I obviously did a mind-fart and checked sda5 instead of sda, latching the wrong configuration into the package. This in turn generates the warning:

Filesystem `ext2' doesn't support embedding. Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.

Since this was a "warning" the report then give the message "Installation finished. No error reported." However the old core.img has been left on track 0 so that the MBR -> (1.99)core.img -> (2.02)/boot installation now fails due to a version mismatch and the machine is unbootable -- except if you are an advanced user used to LiveCDs, etc.

At this point you can say "user error", not the package fault and close my call. This is fare enough -- from a package perspective, but NOT from a system perspective. Consider if you are a typical non-expert user:

* You are daily nagged that your configuration is no longer supported and you have to upgrade.

* Hopefully you read release notes, and click the button to start this "painless" operation.

* During the process, which involves a big download and the occasional dialogue prompt about configuration settings (nearly always the default is safe, but you may need to tweak configuration changes later). The system then reboots and you are live with the new version.

However one of these steps is grub reconfiguration, and a typical user knows nothing about this. If he or she has dual boot (say sda1 -- WinXX, sda5 -- Ubuntu), they might realise that they boot from the "ubuntu loader" and select that partition. If they do then there system will die on reboot.

The release notes make no mention of grub, nor any explanation or warning about the dialogue to come which can trash their system; no reference to read up or any links to how to recover their PCs.

One innocent mis-selection and the PC dies. As Ian McDonald said: this happened with 25% of his users, so it is easy to do.

* Given this, surely the Trusty Tahr release notes should include an explicit section on the fact that this release is upgrading grub and explain is plain user-friendly terms what this means and what the consequences of the selection are -- possibly with links to other articles to give a more in-depth explanation for those that would like it.

* The logic in the grub-pc configuration is incorrect. The install DOES upgrade /boot to 2.02, if the configuration results in no Stage 1.5 core.img being written to HDD, and and one isn't already on one of the putative targets, then the system WILL be unbootable. This is not a warning. It's a hard error; it should be reported as such and the system should not be rebooted.

* The wording of the dialogue is incomprehensible or misleading to a typical user

> The grub-pc package is being upgraded. This menu allows you to se...

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/04/2014 08:08 AM, Terry Ellison wrote:
> However one of these steps is grub reconfiguration, and a typical
> user knows nothing about this. If he or she has dual boot (say
> sda1 -- WinXX, sda5 -- Ubuntu), they might realise that they boot
> from the "ubuntu loader" and select that partition. If they do
> then there system will die on reboot.

You only get prompted to reconfigure if the previous configuration is
broken. That is to say, it says to install to a drive that is no
longer present. This is because the upgrade scripts know something
has gone wrong and manual intervention is required. If you get that
wrong, there's nothing we can do about it.

> * The logic in the grub-pc configuration is incorrect. The
> install DOES upgrade /boot to 2.02, if the configuration results in
> no Stage 1.5 core.img being written to HDD, and and one isn't
> already on one of the putative targets, then the system WILL be
> unbootable. This is not a warning. It's a hard error; it should
> be reported as such and the system should not be rebooted.

Stage 1.5 is a grub legacy thing. We also can't force a grub-install
since there are perfectly valid configurations where this will not be
done and they will still be bootable, and we certainly can't tell that
you didn't know what you were doing when you said to install to a
partition. We also can't *prevent* a reboot.

> * The wording of the dialogue is incomprehensible or misleading to
> a typical user
>
>> The grub-pc package is being upgraded. This menu allows you to
>> select
> which devices you'd like grub-install to be automatically run for,
> if any. <CR> Running grub-install automatically is recommended in
> most situations, to prevent the installed GRUB core image from
> getting out of sync with GRUB modules or grub.cfg. <CR> If you're
> unsure which drive is designated as boot drive by your BIOS, it is
> often a good idea to install GRUB to all of them. <CR> Note: it is
> possible to install GRUB to partition boot records as well, and
> some appropriate partitions are offered here. However, this forces
> GRUB to use the blocklist mechanism, which makes it less reliable,
> and therefore is not recommended.
>
> It could be better phrased, for example:
>
> GRUB is the boot loader which is used to load this and any other
> operating systems. The GRUB loader is normally installed in the
> area between the MBR and the first partition on your
> BIOS-designated boot disk (for example HD0 = /dev/sda).
>
> It is possible to install GRUB alternative locations, but refer to
> the <URL> documentation before any of selecting these.
>
> GRUB must be installed in at least one valid location OTHERWISE
> YOUR SYSTEM MAY NOT BOOT CORRECTLY.

This isn't a bad idea; you should file a separate bug report
requesting that.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTZsD7AAoJEI5FoCIzSKrwc5UH/i58nkRl4BLJafAmMt6/0BhL
WZNRldhjJ0tbAclym6hbHYPaUtRFN7myfBEIKrC9jluRwxJeGrgyyBTClpnJFLav
42+0+neTn2FFBcqbhd3yC7o4j1yoeCsVuCk5Sya57T/ewp43EzbUEyaZxycRihzl
b0W69msHIQqiYDkOEzM3qWj...

[Terry Ellison (r61-terry)]

Thanks Phillip, I'll file my last point as a separate report as you suggest. I take it that this should go down as a grub2 issue.

However to your point:

> You only get prompted to reconfigure if the previous configuration
> is broken. That is to say, it says to install to a drive that is no
> longer present. This is because the upgrade scripts know something
> has gone wrong and manual intervention is required. If you get that
> wrong, there's nothing we can do about it.

I can accept that this makes sense as a design intent, and is what the implementation should do. But what do you mean by "broken" here.

In my case, I never configured grub in the first place other than through the initial Ubuntu guided process, and I upgraded Ubuntu successfully to 13.04 and 13.10 on this system without issue. So why was it suddenly "broken" for the 14.04 upgrade? I have three system partitions: the original /dev/sda1 as Win7, /dev/sda4 as the Lenovo diagnostics and /dev/sda5 as my Ubuntu partition. GRUB was installed on /dev/sda. (sda2 is my Win7 user partition and sda6 LVM2). Pretty straight forward and unchanged since my initial install. If I want to dick around with systems I use VMs.

However, there's no point in debating this further as we've been through these arguments a few times and are repeating ourselves. Either the counts will continue to rack up or they won't. Thanks for your input anyway :-)

PS. I know GRUB 1.5 is politically incorrect with GRUB2, but IMO if it quacks like a duck ... Maybe you should correct the Wikipedia article on Grub. :-)

[Terry Ellison (r61-terry)]

As a poscript having just read #144, my swap partition is on LVM. Maybe its the use of LVM that's causing the grub configuration checks to throw a hissy-fart.

[Jarrod Sears (thaspius)]

I'm running on an Acer Aspire that I installed a fresh blank SSD in with Ubuntu last year. I've never touched or manually edited any grub settings.

The only grub install that I've ever done was directly done through the Ubuntu installer and/or any other subsequent Ubuntu version updates.

After upgrading to 14.04, the laptop boots directly to the grub error message reported in this bug.

This is a serious issue and is not due to screwing around with grub settings. It is a direct bug caused by upgrading to 14.04.

Now I get to spend the next several hours messing with downloading boot repair disks to public PCs and trying to fix this problem...

[Alex Sidorenko (asid)]

When I tried to upgrade one of my PCs (13.10->14.04) I met this problem and had to repair everything manually. Now I have three more PCs to upgrade: one running 13.10 and two running 12.04 LTS. Is there a procedure that can be used on these hosts _before_ upgrade to guarantee that upgrade will work without any problems? For example, assuming that I need grub-pc, will the following prevent reliably problems during upgrade:

1. run 'dpkg-reconfigure grub-pc'
2. Start the upgrade

Thanks,
Alex

[Michael Tsikerdekis (tsikerdekis)]

So is there an actual solution to this? I am stuck with ubuntu 14.04 with a grub2 from 13.10 and I don't do dist-upgrades because the beta9 grub2 version does not recognize windows properly. Any solutions?

[Scott Draper (scottwdraper)]

Hi,

I'm new to Ubuntu so all of this is new to me. I installed 13.10 and had a GRUB issue with it, so I ran a boot-repair DVD and that solved the GRUB issue in 13.10. After opening my brand new 13.10 OS, it asked if I wanted to upgrade to 14.04. I did and I get the "grub_term_highlight_color not found" error every time I boot my computer.

Here's my output for debconf-show grub-pc and parted -l:

ubuntu@ubuntu:~$ sudo debconf-show grub-pc
  grub2/kfreebsd_cmdline:
  grub2/linux_cmdline:
  grub-pc/install_devices_failed: false
  grub-pc/chainload_from_menu.lst: true
  grub-pc/postrm_purge_boot_grub: false
  grub2/kfreebsd_cmdline_default: quiet splash
  grub2/linux_cmdline_default: quiet splash
  grub-pc/hidden_timeout: true
  grub-pc/install_devices:
  grub-pc/partition_description:
  grub2/device_map_regenerated:
  grub-pc/kopt_extracted: false
  grub-pc/disk_description:
  grub-pc/install_devices_empty: false
  grub-pc/timeout: 10
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/install_devices_disks_changed:
  grub-pc/mixed_legacy_and_grub2: true
ubuntu@ubuntu:~$ sudo parted -l
Model: ATA Hitachi HTS72505 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 210MB 209MB primary ntfs boot
 2 210MB 288GB 288GB primary ntfs
 4 288GB 480GB 192GB extended
 5 288GB 480GB 191GB logical ext4
 6 480GB 480GB 511MB logical linux-swap(v1)
 3 480GB 500GB 19.8GB primary ntfs

Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0
has been opened read-only.
Model: hp CDDVDW TS-U633F (scsi)
Disk /dev/sr0: 4700MB
Sector size (logical/physical): 2048B/2048B
Partition Table: mac

Number Start End Size File system Name Flags
 1 8192B 24.6kB 16.4kB Apple
 2 3669MB 3678MB 9306kB EFI

I tried the steps in #27 (chrooting /tmp/drive and dpkg-reconfigure grub-pc) and #130 (chrooting /tmp/mount-point and then did dpkg-reconfigure grub-pc as suggested in #27) but neither of them worked. I chose sda5 as the partition for the /tmp/drive and /tmp/mount-point to mount /dev, /proc, and /sys as that looked to me to be the drive where Ubuntu is installed. In the dpkg-reconfigure grub-pc application, I (1) left the Linux command line blank, (2) left the default "quiet splash" as is in the prompt, and (3) made sda the drive for reconfiguration.

I'm at a loss what to do. I'd like to have the option to dual boot to either Ubuntu or windows but I can't do that as long as GRUB is broken. Do I need to delete and re-install GRUB 2.02 or do I have to downgrade GRUB 2.02 to 2.0 or what?

P.S. When you mount something in the terminal, does it really mount it even though the terminal just displays another prompt and makes no indication that anything was mounted? If it's supposed to say something, then maybe I mounted the files wrong.

[SatPhil (satphil)]

@Scott: Regarding mounting from the terminal, Linux inherited terseness from UNIX so only gives messages when commands don't work. "df -h" should show whether you mounted OK. Regarding "dpkg-reconfigure grub-pc", your sda and sda5 and other answers look good to me, could you have EFI rather than MBR boot? What do you see when you run "sudo efibootmgr -v"?

@psusi: Is anyone looking at what is causing this problem or do you somehow regard it as user error? It seems odd that previous upgrades seem to have avoided this problem - did the developer toss out what he thought was unnecessary code for this release?

[Michael Tsikerdekis (tsikerdekis)]

@Scott the only solution that worked for me was to actually install specific deb packages for grub2 from the 13.10 version. See my earlier post. the issue is that this fixes the problem but you cannot do a dist-upgrade without upgrading grub. there are workarounds for this but still it is a hassle.

[Phillip Susi (psusi)]

@Alex, yes, you can run sudo dpkg-reconfigure grub-pc before upgrading to make sure your boot disk is selected.

@SatPhil, one major culprit seems to be boot-repair, and this has happened in previous upgrades.

[Scott Draper (scottwdraper)]

@SatPhil: "sudo efibootmgr -v" was not recognized as a command for me, but I used two other methods that I think answer your question. See below:

ubuntu@ubuntu:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
BIOS
ubuntu@ubuntu:~$ dmesg | grep "EFI v"
ubuntu@ubuntu:~$

The second method ("dmesg | grep "EFI v"") didn't return any information, so that looks like I have BIOS instead of EFI/UEFI. Does that answer your question?

@tsikerdekis: Your earlier post referred to a link that no longer works. Any other link I can read explaining the steps you took? If not, what specific "deb" (Debian, I assume) packages should I download for grub2?

[Alexandre Hocquet (alexandre-hocquet)]

Affected, here, on a ACER Aspire S3 with dual boot Windows 7 + xubuntu 13.10. Encountered the symptoma when upgrading to 14.04. Plainly rebooting on a Live xubuntu 13.10 USB and applying boot-repair solved the problem for me, but i suspect, if i understand correctly what has been said here, that i will encounter the same issue when i do my next update. Do i understand correctly that it will be enough to do "dpkg-reconfigure grub-pc" before updating again?

[yellow (yellowshark)]

Same bug here.
Harddisk was blanked and partinioned before install off Ubuntu 13.04
Never installed Windows or other Dualboot.
Never touched Bootloader, ... (the last time I touched a boot manager and did Dualboot was with LiLo I think!)

This is a very serious bug!

[Chris Fryer (chrisf1874)]

I have the same problem. Since upgrade from 13.10 to 14.04, I've run Boot Repair which failed. I do recall some issues getting grub working when I originally installed 13.04 but don't have a record of how I got it working. Upgrade from 13.04 to 13.10 went OK.

I've spent the last five hours searching so any suggestions would be greatly appreciated.

When I try to dpkg-reconfigure grub-pc, I get:

chris:~$ sudo dpkg-reconfigure grub-pc
dpkg-query: package 'grub-pc' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
/usr/sbin/dpkg-reconfigure: grub-pc is not installed.

sudo grub-install runs and does not report any errors.

I've got no installed_devices listed.

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

chris:~$ sudo parted -l
Model: ATA TOSHIBA MQ01ABD1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 1049kB 420MB 419MB ntfs Basic data partition hidden, diag
 2 420MB 735MB 315MB fat32 EFI system partition boot
 3 735MB 869MB 134MB Microsoft reserved partition msftres
 4 869MB 248GB 247GB ntfs Basic data partition msftdata
 7 248GB 458GB 210GB ext4 msftdata
 8 458GB 966GB 508GB ntfs msftdata
 6 966GB 982GB 16.0GB linux-swap(v1)
 5 982GB 1000GB 18.3GB ntfs Basic data partition hidden, diag

chris:~$ dpkg-query -l 'grub*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==================-==============-==============-==========================================
un grub <none> <none> (no description available)
ii grub-common 2.02~beta2-9 amd64 GRand Unified Bootloader (common files)
un grub-coreboot <none> <none> (no description available)
un grub-doc <none> <none> (no description available)
un grub-efi <none> <none> (no description available)
ii grub-efi-amd64 2.02~beta2-9 amd64 GRand U...

[yellow (yellowshark)]

Boot-repair failed. After a few hours trying i did a new install. Now I will have to reinstall all my "special software", print server, ... phew :(
The problem might have come from my system with sda (system) and sdb (homes)?!?

[Michael Tsikerdekis (tsikerdekis)]

@Scott you can find the old deb packages here:
http://packages.ubuntu.com/saucy/grub2

You will have to fix any dependencies but it's easy just download the files needed. You may need to add Windows manually through editing /etc/grub.d/40_custom
In my case I had to add this:
menuentry "Windows 8" {
    insmod part_gpt
    insmod chain
    set root='(hd0,gpt3)'
    chainloader /EFI/Microsoft/Boot/bkpbootmgfw.efi
}

I am running UEFI system and that partition is the small one containing that folder. Also I had to use that specific efi file instead of the default bootmgfw.efi. The easiest way to figure out what works is to add multiple entries on the 40_custom file with various settings and test them. This will save you multiple reboots.

[Phillip Susi (psusi)]

@Chris, you don't have grub-pc because you are on an EFI system, and are dual booting with Windows. What is the output of sudo efibootmgr?

[Chris Fryer (chrisf1874)]

@Phillip, Sorry for the slow reply. I borrowed another windows PC for my urgent problem.

Here's the output:

chris:~$ sudo efibootmgr
BootCurrent: 0003
Timeout: 2 seconds
BootOrder: 0003,0005,0004,0002,0001,0000
Boot0000* Windows Boot Manager
Boot0001* HDD0:
Boot0002* HDD0:
Boot0003* ubuntu
Boot0004* HDD0:
Boot0005* HDD0:

I moved to the ubuntu boot using the 'bios' ... if EFI systems have bios's. It's the Windows Boot Manager that's broken.

I tried dpkg-reconfigure grub-efi-amd64 but it had no effect - there was nowhere to select the install device.

[Phillip Susi (psusi)]

@Chris, yes, the problem is that grub-repair put a copy of grub in the windows directory and configured the windows boot loader to chain load grub, and that copy is now out of date. Stick to booting Ubuntu/grub first.

[Scott Draper (scottwdraper)]

I fixed this problem, but FYI I have BIOS (MBR) on my computer, not EFI, so my solution might not work for devices with (U)EFI. The solution was very simple. I just downloaded boot-repair-disk at http://sourceforge.net/projects/boot-repair-cd/ and burned it to a CD (on another computer, of course, since I couldn't access any operating system on my laptop). I then did the following:

1. Booted my laptop. It automatically took me to the grub rescue screen.
2. Inserted boot-repair-disk and then hit control+alt+delete so the computer could reboot from the grub rescue screen.
3. Once the CD booted up, I hit F6 for "other"
4. Hit Escape
5. Typed "boot-repair" (without the quotes) at the end of the command that appeared toward the bottom of the screen
6. Brightened the screen (At this point for some reason, the actual program appeared really dark, so had to brighten screen)
7. Selected the "Recommended Repair" option
8. Rebooted the computercomputer

This got Grub working, and not just once, but RELIABLY after doing several restarts and shutdowns. Hopefully this will work for you.

[Lastique (andysem)]

I've also been affected by this bug. I'm on a MacBook Pro, dualboot with OS X. There is a single HDD split in several partitions. Kubuntu is installed on /dev/sda3 and boots in BIOS mode from ReFit (Kubuntu cannot boot in EFI mode on this laptop). OS X is on /dev/sda2. The bug appeared after the upgrade from 13.10.

Things I tried that did not help:

- I could not boot into Kubuntu from the grub rescue prompt. Grub displayed errors saying that commands "linux" and "initrd" were unknown. Trying "insmod linux" resulted in the same error "symbol 'grub_term_highlight_color' not found".

- Boot-Repair-Disk did not help. I used the latest standalone image (i.e. I did not install it under Ubuntu Live CD). The repair process failed with an error, here are a couple of logs:

http://paste.ubuntu.com/7457286/
http://paste.ubuntu.com/7457303/

- Running "dpkg-reconfigure grub-pc". I did that after I booted into Kubuntu 14.04 Live CD and created a chroot environment as described in comment #27. The command executed successfully but the problem stayed the same.

- Purging and re-installing "grub*" packages. After purging I made sure to delete /boost/grub with all its contents. I did this from chroot as well.

- Running "grub-install --boot-directory/boot -v -recheck /dev/sda3 --force". Basically, a similar command is executed during grub packages installation, so no surprise here.

What actually helped:

As I mentioned, Kubuntu is installed on /dev/sda3. Grub boot loader was also installed on that partition. I did not install the boot loader to MBR (/dev/sda), and it worked with 13.10. However, after the upgrade and attempts to fix the problem I tried to purge/reinstall grub packages and selected to install the boot manager to MBR (/dev/sda). After that the next boot succeeded.

This may be a result of weird behavior of ReFit as I was convinced it would use the /dev/sda3 boot record. I don't know what boot loader was in MBR before I reinstalled grub that last time.

So my final solution is:
1. Boot in Kubuntu 14.04 Live CD. I had to actually use DVD, my MacBook Pro doesn't boot in BIOS mode from USB sticks.
2. Mount the HDD and create a chroot command prompt as described in comment #27.
3. Purge grub packages: apt-get remove --purge 'grub*'
4. Remove any leftovers: rm -rf /boot/grub
5. Install grub packages: apt-get install grub-pc
6. When it asks where to install the boot loader I chose /dev/sda. It also offered /dev/sda3, I didn't select it this time, but in previous attempts I did try it. Maybe it's safer to install it on all partitions.
7. Reboot.

Bottom line: you have to know or at least guess which boot record is used by your BIOS and/or higher level boot loader, such as ReFit in my case. Otherwise the part of grub in the boot record is out of sync with the installed part in /boot/grub which results in problems like this.

PS: Regarding the bug treatment. It is obvious that it affects a lot of people. Closing it as Invalid is nonsense, the problem exists. Arguably, it may not be an easy one to fix, but you can't pretend it isn't there. I'm sad to say I can't imagine such treatment on MS or Apple part.

[pureblood (freeseek)]

I think Lastique got a good explanation. How many people with this bug have actually two hard drives on their computer? I certainly did. For those trying to follow instructions on #27, make sure you install grub on each of your hard drives (i.e., both sda and sdb) by running "dpkg-reconfigure grub-pc" multiple times. My suggestion for the ubuntu team is to start telling users to create a bootable CD/USB before performing any distribution upgrade. I can just imagine this bug caused endless headaches to less experienced linux users.

[olly_b (olly-xquest)]

After many attempts I have found a fix that works for my situation (Win 8 dual boot with 14-04 upgraded from 13-10 after running boot repair)

Status before fix
on power-up "symbol 'grub_term_highlight_color' not found"

boot from 14-04 USB

sudo parted -l
 Model: ATA TOSHIBA MQ01ABD1 (scsi)
 Disk /dev/sda: 1000GB
 Sector size (logical/physical): 512B/4096B
 Partition Table: gpt

 Number Start End Size File system Name Flags
  1 1049kB 1075MB 1074MB ntfs Basic data partition hidden, diag
  2 1075MB 1347MB 273MB fat32 Basic data partition boot
  3 1347MB 1482MB 134MB ntfs Basic data partition msftres
  4 1482MB 496GB 494GB ntfs Basic data partition
  6 496GB 498GB 2048MB linux-swap(v1)
  7 498GB 968GB 470GB ext4
  8 968GB 988GB 20.0GB ext4
  5 989GB 1000GB 11.7GB ntfs Basic data partition hidden, diag

sudo efibootmgr -v
 BootCurrent: 0004
 Timeout: 0 seconds
 BootOrder: 0004,0000,0003,2003,2001,2002
 Boot0000* ubuntu HD(2,200800,82000,ccc07869-f302-11e2-9c39-b3f1c77c46b3)File(\EFI\ubuntu\shimx64.efi)
 Boot0001* EFI Network 0 for IPv6 (08-9E-01-DF-22-D9) ACPI(a0341d0,0)PCI(1c,3)PCI(0,0)MAC(089e01df22d9,0)030d3c000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000RC
 Boot0002* EFI Network 0 for IPv4 (08-9E-01-DF-22-D9) ACPI(a0341d0,0)PCI(1c,3)PCI(0,0)MAC(089e01df22d9,0)IPv4(0.0.0.0:0<->0.0.0.0:0,0, 0RC
 Boot0003* Ubuntu HD(2,200800,82000,ccc07869-f302-11e2-9c39-b3f1c77c46b3)File(\EFI\ubuntu\grubx64.efi)RC
 Boot0004* Windows Boot Manager HD(2,200800,82000,ccc07869-f302-11e2-9c39-b3f1c77c46b3)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
 Boot2001* EFI USB Device RC
 Boot2002* EFI DVD/CDROM RC
 Boot2003* EFI Network RC

Fix Summary omitting all unsuccessful activities/reboots etc

sudo mkdir /mnt/temp /mnt/temp/boot
sudo mount /dev/sda8 /mnt/temp
sudo mount /dev/sda2 /mnt/temp/boot
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt/temp$i;
done
sudo cp /etc/resolv.conf /mnt/temp/etc/resolv.conf
sudo chroot /mnt/temp

mkdir /boot/EFI/old
cd /boot/EFI
mv Boot /boot/EFI/old/.

vi /etc/grub.d/40_custom

G (go to end of file)
a (append)

menuentry "Windows 8 on /dev/sda2" {
    insmod part_gpt
    insmod fat
    insmod chain
    set root='(hd0,gpt2)'
    chainloader /EFI/Microsoft/Boot/bkpbootmgfw.efi
}

ESC (quit text entry)
:wq! (save and exit)

dpkg-reconfigure grub-efi-amd64
 Installing for x86_64-efi platform.
 Installation finished. No error reported.
 Generating grub configuration file ...
 Found linux image: /boot/vmlinuz-3.13.0-24-lowlatency
 Found initrd image: /boot/initrd.img-3.13.0-24-lowlatency
 Found linux image: /boot/vmlinuz-3.13.0-24-lowlatency
 Found initrd image: /boot/initrd.img-3.13.0-24-lowlatency
 Found linux image: /boot/vmlinuz-3.13.0-24-generic
 Found initrd image: /boot/initrd.img-3.13.0-24-generic
 Found Windows Boot Manager on /dev/sda2@/EFI/Microsoft/Boot/...

[Saurabh Rindani (saurabh-prl)]

I managed to solve the problem after a lot of struggle. I would like to summarize my efforts with my own idea as to how the problem was solved. (I will of course admit that I am not too knowledgeable!)

Firstly, I discovered that the system was running EFI (so reconfiguring grub-pc did not work -- it is possible that I checked the wrong partition while doing this, but I am not sure if that did some harm).

From the grub rescue stage, I found that I could go to grub stage using the following commands (sometimes only after using the full path and file name instead of /vmlinuz and /initrd.img)

insmod linux
linux /vmlinuz ro root=/dev/mapper/vg-root
initrd /initrd.img

The second of these commands gave
error: premature end of file

The last command gave
unaligned pointer ox3880621b1a006275
Aborted. Press any key to exit.

When I pressed a key, it gave me the grub menu, with all options of Ubuntu and Windows (until I ran boot-repair). So that was a partial success, despite the error messages.

I booted into the latest Ubuntu version, and ran boot-repair with the recommended option. This did not help.
http://paste.ubuntu.com/7403468
said
"An error occurred during the repair."

The bottom line seemed to be :
"The boot files of [The OS now in use - Ubuntu 14.04 LTS] are far from the start of the disk. Your BIOS may not detect them. You may want to retry after creating a /boot partition (EXT4, >200MB, start of the disk)."

Since Windows 8 came pre-installed in the first partition, and since everything worked fine until upgrade to 14.04, I did not want to follow this suggestion, which would mean reinstalling everything.

At this stage, I consulted a colleague in our computing centre. He found that in the bios boot priority list, windows came before ubuntu, and changed it to boot ubuntu first. After this change, the main problem was solved, and the system gave the grub menu with all operating systems listed.

However, this worked fine for booting ubuntu, but on trying to boot windows it failed.

At this stage, I remembered the posting of Fred Palmer on May 3 in this forum. He said that
"Boot-Repair does the rename for 'buggy' UEFI."
He also said:
" To undo & to rename files to their original names, you just need to tick
the "Restore EFI backups" option of Boot-Repair."

(See also the posting of SatPhil on May 2 in this forum, which is probably related).

I followed this instruction and ran boot-repair with the option he mentioned. Now I have a system which boots correctly ubuntu as well as windows.

I hope this will be helpful

[Laenny (l-launchpad-net-energy-spam-aenigma-de)]

In my case - on my Sony VAIO laptop, boot-repair did in fact install the grub also als "EFI/Boot/bootx64.efi" (backupping the old windows EFI loader). I did not find a way to change the EFI-Bootloader to use in BIOS on this Notebook, so this seemed somehow necessary (cannot find out now, why, that's ages ago).
But when I copied EFI/ubuntu/grubx64.efi to EFI/Boot/bootx64.efi (the new version, of course), everything went fine.

[Santosh Phuyal (phuyals)]

This is definitely a bug...I upgraded my 12.10 to 14.04 and suddenly had this problem with grub_term_highlight_color. I still get the option to choose win7 or Linux when my desktop boots (and if i choose win 7 it boots fine), but if i choose linux then i get that error which leads me to grub rescue. What can i do to fix this? I have made a bootable usb with SGD2, will it help? Or should i run a 14.04 from USB and fix the grub from there??

It's weird that the upgrade seriously messes things up like that...I mean i did not touch any thing, except pressing that "upgrade" button :-/

[teo1978 (teo8976)]

For god's sake this has been reported months ago and it's still not fixed?!?!?!?!

You should at least have made the upgrade unavailable until this was fixed!
Since the damn upgrade was released I've been prompted to upgrade, until I've finally decided to take the time to perform the upgrade... just to find myself with an unbootable computer!!!

Do you realize that thousands of users with a perfectly working system are getting it broken because of the upgrade?!?

Until you fix this huge bug, you have to IMMEDIATELY SHUTDOWN THE AUTOMATIC UPGRADES!!!!
You should have done this on the 10th of march.

[teo1978 (teo8976)]

OMFG "importance HIGH?!?"

Who is the idiot that set the importance to "high" and not "critical"??

[teo1978 (teo8976)]

* Renders the system temporarily or permanently unusable

[Teo (teo1978)]

It doesn't matter whether or not this is caused by having done anything manually with grub before.
If you have a system that works 100% fine, you run dist-upgrade and you get a broken system that won't even boot, there's a bug, be it in grub or in dist-upgrade.
At the very least, dist-upgrade MUST check if there's something that will prevent the upgrade to work, refuse to perform the upgrade (or warn you) and tell you exactly what needs to be fixed before upgrading.

In my case, I never touched anything grub-related manually, or if I did, it was to fix something that the previous upgrade or clean install screwed up because of a bug.

[Teo (teo1978)]

@169 I'm trying your method but I get "error: no such partition" at the last step (no errors at the second step).

I guess it's because: "(sometimes only after using the full path and file name instead of /vmlinuz and /initrd.img)"
How I figure out the full paths?

[Donald Lhoëst (d-lhoest-y)]

Happened to me too... Pain in the butt I might add :)

Anyway, thank you Scott Draper for the grub-repair-cd idea it worked perfectly well for me too at first try.
Please admins fix this ASAP, as much as I love Ubuntu this is quite the glitch...

[Teo (teo1978)]

Ok, so I followed all of the steps in comment 169 (after having kind of a hard time decyphering some of them) and it worked! I can now boot both Ubuntu and Windows 8.

Now I WONDER whether the whole process was really needed. I SUSPECT it could all be reduced to (starting from the very beginning when everything was screwed up and the computer wouldn't boot):
- change the boot order from bios and place ubuntu before Windows
- then maybe the working grub menu would appear and you could boot ubuntu already
- run boot repair once with the "restore efi backups" option (this means: unfolding the "advanced options", checking the checkbox with this name, leave everything else as is, and click "Apply", and then follow all BootRepair's instructions until the end).

This is just a conjecture, but it would be nice to know whether this is the case.

One thing I don't understand (whether or not the conjecture is right) is: how comes that Windows bootloader had always been before ubuntu in the bios boot order, and everything worked, and after the upgrade, among other things, we needed to change that order?

[Teo (teo1978)]

Whenever a fix for this is released, be sure not to mark the bug as fixed UNTIL it is guarantee that anybody that has had to run thorough any of the workarounds described in this thread won't end up with the system screwed up again AT THE NEXT DIST UPGRADE (because of the reinstall of grub or whatever). Fixing this bug means also making sure that everything is fixed for those who were hit.

Also, this must block the release of the next distribution upgrade, i.e. upgrade to 14.10 must NOT be released until this bug is made sure to be completely fixed (in the sense specified above).

[Saurabh Rindani (saurabh-prl)]

@Teo, I had submitted comment #169, and I am sorry not to be of help when you were following those steps --I was in bed, being in a different time zone! In any case, I am happy that you could decipher the steps from my somewhat vague comment and succeeded in setting right grub.

You have nicely summmarized the steps needed, and I agree with your conjecture. I hope this will be taken note of to resolve the bug.

[Teo (teo1978)]

@Saurabh lol I didn't mean to sound rude in my comment. Your comment 169 saved my life, thanks a lot!

[Joaquin Jimenez (jojive)]

Hi Teo / Saurabh,

How did you change your bios boot priority list to set first Ubuntu? I am not able to do it

Thanks in advance

[Teo (teo1978)]

Excuse me?
The change of status from Confirmed to Opinion is just ridiculous.
@psusi Could you explain the reasoning behind it?

There have been several users who have confirmed that they (we) had a perfectly working dual boot system which, after running the distribution upgrade (saying "yes" to the prompt whether to upgrade), were turned into unbootable bricks (fortunately reversible through a painful process). Under which point of view can this not be a bug?

And if your answer is "because your system had been modified by manually reinstalling grub", then please consider that:
1 - that was the only possible way of having a working Ubuntu 13.10 alongside Windows 8 on a modern computer that came with Windows 8 preinstalled. There is no such thing as a clean install of Ubuntu 13.10 on a computer with Windows 8 preinstalled and a UEFI bios, because the installer was broken and was uncapable of installing Ubuntu alongside with Windows 8, so whoever installed Ubuntu was FORCED to use boot repair or something similar to get the dual boot to work. So, that situation HAS to be supported
2 - even if that didn't have to be supported and handled, it HAS TO be detected and the Distirbution Upgrade MUST warn the user that the system is in such a situation that it will be uncapable of upgrading without screwing things up, giving the option whether to continue or abort.

It IS the distribution upgrade's job to check whether the conditions for performing a safe update are met, no matter what may cause them not to be met.

[Teo (teo1978)]

@jojive in my case I hit f2 immediately after turning on the computer. That brought the bios menu on and it contained a "boot" section where, among other things, there was a list of devices from which to boot, where you can change the order.

I guess all that may vary depending on the hardware manufacturer. If F2 didn't work maybe I would try F10 or F12...

[Joaquin Jimenez (jojive)]

Thanks Teo, I tried, but as far as I know, you can only change device order, but not operating system order as Saurabh says. Is that correct? How do you change operating system order to boot first ubuntu and not W8?

Thanks in advance

[Phillip Susi (psusi)]

Because there is nothing here but a bunch of people venting their frustration. There is nothing we can do to prevent or detect this kind of misconfiguration.

[Teo (teo1978)]

@jojive
You're right, I meant device order. Now that you make me realize, that's funny.
In my case one device was shown as "Windows" and the other as "Ubuntu" in the boot menu, though I don't remember what's the actual partition layout. The only thing I know for sure is I don't have separate physical discs for Windows and Ubuntu, they are on separate partitions on the same disk.
I guess the list includes partitions.

[Teo (teo1978)]

@psusi
First of all, it's not a "misconfiguration", it's a perfectly working configuration.

Secondly, the claim that there's nothing you can do detect and deal with it is ridiculous.
If there's a sequence of commands you can type to get the information and fix the problem, that can be automated.

Yep, there's nothing here but a bunch of people venting their frustration. Usually on a normal bug report there are people venting their frustration and people trying to fix it. But if you close it as "opinion" then yes, it will only be people venting their frustration (plus an - pardon - plus a person claiming such a thing is not a bug)

[Saurabh Rindani (saurabh-prl)]

@jojive
In my case, pressing F12 gave me the device booting order menu. It showed only my hard disk as the device (I have only one hard disk). However, below that it listed OS options: ubuntu twice (perhaps including earlier version) and also windows. Once could use arrow keys to select the OS to boot. However, using + and - keys one could change the order of the OS options in the menu.

I checked this again today, since I did not remember clearly what I did the first time.

@psusi

I entirely agree with Teo in that the only way to make 13.04 work for me was to use boot repair. If that was a misconfiguration, why is that I could upgrade to 13.10 without a hiccup? If the upgrade to 13.10 worked without a problem, the upgrade to 14.04 is clearly following a different system which does not take care of what the upgrade from 13.04 to 13.10 could take care of.

I also agree with Teo that those who are meant to fix the bug are not the ones who are helping, but people like us who are venting their frustrations also end up helping each other.

[Adam Niedling (krychek)]

Psusi: "There is nothing we can do to prevent or detect this kind of misconfiguration."

Are you basing this on just one commenter's output in comment #13 in which case the configuration is in fact bad? Or have you seen more bad configurations that led to this issue.

I'm just still not convinced there is nothing that can be done to fix this.

[BenM (benmottram)]

just a few thoughts (opinions ;) )...

I have posted previously in the thread and followed it since then. I sympathise with both sides - both 'its a bug' and 'its the user' but on consideration IMHO neither are 100% right.

My hardware is a Dell box with an Intel RAID controller set up with one volume mirroring a pair of 400(ish)Gb drives. As previously stated I installed 13.04 last year (LVM enabled) on a clean machine (no operating system) then this year upgraded to 13.10 successfully and then bricked the box with 14.04. At no time did I run boot-repair on the 13.x installs - if a boot loader is working I leave it well alone. So from an end user point of view there is a bug - a normal upgrade bricked my machine with no warning. Where that bug lies is kind of hard to pin down.

I have since set up a Virtualbox to try to replicate the issue - unfortunately(!) the upgrade chain didn't fail.
VirtualBox does not allow the emulation of hardware RAID controllers and I _think_ that this may be where the root cause of issue lies. It may be that the new version of grub installed by the system upgrade doesn't handle the LVM/HW RAID combination particularly well.

As to not being able to detect the issue that caused the bricking of many machines - that is not strictly true is it? Us human end users are detecting the issue using standard tools available to the upgrade process.

The big problem from a dev/support point of view is that there appears no auditable set of actions that can reproduce the issue - and I know that I am not about to tear down my now working 14.04 install, wipe the disks and start again from 13.04 just to prove (or not) a point - life is too short! Other end users are probably in the same position.

[Phillip Susi (psusi)]

Adam, so far there have been two variations on the problem presented:

1) You are booting in bios mode with grub-pc, and grub-pc/install_devices is not set, which results in the MBR not being reinstalled on upgrade. There are systems on which this is a perfectly valid configuration ( i.e. if they are booting using another boot loader, or grub installed in another OS ), so we can't stop the upgrade for this.

2) You are booting in EFI mode with grub-efi, and have used boot-repair at some point which made a copy of grub.efi in the windows efi directory, and configured windows to chain load that. After upgrade, this copy is now old and broken because we don't know anything about it and it shouldn't be there. Grub-repair shouldn't be doing this. Fortunately this one is quite easy to work around: tell your efi bios to boot grub instead of windows first.

[Alberto Salvia Novella (es20490446e)]

When the noise stops, the melody sounds.

So keep it easy peace.

[M. Sussman (mmsussman)]

Phillip, You know what causes this problem, so you can test for it before the upgrade starts. Wouldn't it be better to put an advisory comment up, warning the user that the system has a legitimate but possibly troublesome configuration? The comment could either fully explain how the trouble arises and what might happen or point to a web-based explanation. After all, leaving a user with a bricked system is not being considerate.

[Tamale (uictamale)]

All this noise is complicating the issue. It's really simple - there's a bug somewhere because as a user of Ubuntu 13.10 with no "custom configs", no "second OSs", and no "extra hard drives", I followed the upgrade procedure that was presented to me and was left with an unusual system.

I'm moving the bug to confirmed because I firmly believe it is my right and responsibility as a long time user of ubuntu and someone who wants to see it continuously improve.

Phillip, no offense, but I'm pretty sure this can be detected and a user warned (if not completely fixed) before trying to upgrade.

[Phillip Susi (psusi)]

The bug is in your configuration. As a developer, I have said there is nothing we can do on our end to mitigate this. As a user you need to avoid using grub-repair to get into an unsupported configuration. At this point your recourse is to take it up with the technical board.

[Teo (teo1978)]

Phillip you keep missing three things that have been said several times very clearly:

- there are users that NEVER used boot-repair (or grub-repair as you call it) and experienced the issue anyway
- there are situations where you CANNOT avoid using it as it's the only way to get Ubuntu to work
- there obviously ARE things that can be done on the developers' end (I hope not "your" end) to mitigate this.

[SatPhil (satphil)]

Hi Ubuntu Technical Board,

There is a lot of dissatisfaction about a problem that causes updates to
Ubuntu 14.04 to fail to boot. Phillip Susi of Ubuntu feels this is not
a bug whereas everyone who runs into feels that it is. We suspect it
may affect many more users and be very detrimental to Ubuntu's reputation.

Can we escalate this to you for your review? If you could publish your
findings on the launchpad bug thread, it would inform the affected
community and be much appreciated.

Many thanks

Phil Diacono

-------- Original Message --------
Subject: [Bug 1289977] Re: Ubuntu 14.04 Update breaks grub, resulting in
"error: symbol 'grub_term_highlight_color' not found"
Date: Mon, 26 May 2014 20:56:47 -0000
From: Phillip Susi <email address hidden>
Reply-To: Bug 1289977 <email address hidden>
To: <email address hidden>

The bug is in your configuration. As a developer, I have said there is
nothing we can do on our end to mitigate this. As a user you need to
avoid using grub-repair to get into an unsupported configuration. At
this point your recourse is to take it up with the technical board.

** Changed in: grub2 (Ubuntu)
       Status: Confirmed => Won't Fix

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1289977

Title:
  Ubuntu 14.04 Update breaks grub, resulting in "error: symbol
  'grub_term_highlight_color' not found"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977/+subscriptions

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/26/2014 06:19 PM, Teo wrote:
> - there are users that NEVER used boot-repair (or grub-repair as you call it) and experienced the issue anyway

I've chalked them up as mistaken/forgotten. Unless they can demonstrate how to reproduce it, there's nothing further to go on there.

> - there are situations where you CANNOT avoid using it as it's the only way to get Ubuntu to work

Then those situations should be addressed separately ( and several have ), and as I have said before, if you are using grub-pc you should be using dpkg-reconfigure grub-pc to reinstall it instead of boot-repair, or at the least, after using boot-repair to go back and reinstall grub right.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTg8nyAAoJEI5FoCIzSKrwyA0H/i9O5PxYnNzBoScT6wxG3RKb
hoK4jkcTdyKjxgwCGgNXRBh3DOL2DZEVAeoUCmD0BzFXiWH+urfjtLTvwSzPrKX2
WNTn+NJWz16dVf+UpNoqmSXEyD2lbtIwj9BuBEUXhjv/BX2vOdhiWSDl9wSoFm4x
En4Bgi8fqKHZsnYvSFMA4n3zb+JTIndwU6hr2hNG2KYaVnRgPFXUX1z24CXcIwfE
01nc88/Qa/HQt8c7gZHFj3zOwZ0RA6yeWA/rcotMpG7mnalcipqcaggvqyIhZ592
Ya+8whf6MJ5zQfUGGvC7qY5EUTGbZ5acyOrCecZSSgF2VwWsw4GLsSgoASrLF5c=
=I4AI
-----END PGP SIGNATURE-----

[YannUbuntu (yannubuntu)]

IMHO, that bug simply shows that dist-upgrade breaks the boot by blindly (re)installing GRUB whatever the boot setup is.
In other words, dist-upgrade does not support enough boot configurations.

A very simple and quick fix is: dist-upgrade should not install any bootloader. (why taking the risk of breaking the boot?)

Plus, there are probably several sub-bugs (several types of "unsupported configurations" leading to the same error message) mixed in that report, would be easier to understand if each user was creating his own report, then devs could regroup them into categories.

[Alberto Salvia Novella (es20490446e)]

If you feel this bug is real, please provide a series of steps that will break GRUB consistently in any given system.

Then you're allowed to set the status back to confirmed.

[Tamale (uictamale)]

For me it was this:

1) Install ubuntu 13.04
2) Upgrade to 13.10
2) Attempt to upgrade to 14.04 => this bug, unusable system

[xreuze (xreuze)]

When you are Migrateing -> to 14.04 LTS from previous any linux or have multiboot systems do this. When you are updateing a new KERNEL in your new installation or after complete new installation. New KERNEL module will be loaded up to make your 14.04 LTS have latest drives etc. After update or after new installation when you migrated from previous installation 12.04 or 13.10 etc. You need to clean your OLD kernel module out from your system. Install Ubuntu - Tweak , Janitor to remove old Kernel and Old stuff that can give problems to load new Kernel to work when booting up your new installation, or when you updated new KERNEL. Often will clear lots of problems with 'grub ' or multiboot systems.
http://ubuntu-tweak.com/

[xreuze (xreuze)]

http://www.omgubuntu.co.uk/2011/07/kernel-entries-gone

[_dan_ (dan-void)]

@Phillip Susi

I think the bug occurred for me because i changed sda to another hdd (where windows is), so the entries from debconf did not match the new hdd and therefor grub did not install itself on sda, only on sdb (linux), with the new version.

Don't you think this behavior is unwanted? Should a user have to know to rerun dpkg-reconfigure grub-pc when he/she changes the windows hdd, which has nothing to do with the Linux installation?
Should not take the upgrade process take care of that?

[xreuze (xreuze)]

_dan_(dan-void).. That happens when grub is your boot loader manager. Even in old versions with multiple operational systems the grub in it self was not the problem. Usually when i install ubuntu and i thick the radio button to install with what ever existing operation system is on the hda or hdd or what ever the drive letter is needed. It is hard since MBR which is master boot record to code a boot loader config file two load clean when a kernel wants the first bit to load from a location where a other OS is. Best to have disk partion done by gparted where you have adequate disk space over 4 giga to make smooth install. Grub will address a hex prefix to read the first bit from that installation. How ever when you do the installation of 14.04 lts there is still things every one needs to do since the time when you downloaded and made a boot usb or dvd or cd and when canonical uploaded it out was passed it is almost impossible to be up to date distro. Everyone needs to add in more by update to latest KERNEL module etc.
This site will get your system up to date after new install or if you migrated .

http://www.unixmen.com/top-things-installing-ubuntu-14-0413-1013-0412-1012-04/

Use always the ubuntu - tweak janitor to keep your system clean to void bugs with new KERNEL.

Hope all this helped everyone.

[xreuze (xreuze)]

If it is the issue of recovering of bad ' grub 2 ' then you can do this as in this video.

https://www.youtube.com/watch?v=ajs9rO5upZA

Getting your fingers used to fixing some simple admin tasks is part of getting to understand how Ubuntu works. I understand that in the beginning anything new can take time to learn. No one learns to drive a car or fly an air plane with out understanding a few fundamental things how things works. There is no auto - pilot that will not need to bet set before taking off the ground..

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/28/2014 10:53 AM, _dan_ wrote:
> Don't you think this behavior is unwanted? Should a user have to
> know to rerun dpkg-reconfigure grub-pc when he/she changes the
> windows hdd, which has nothing to do with the Linux installation?
> Should not take the upgrade process take care of that?

If you change your boot drive, then yes, you need to run
dpkg-reconfigure grub-pc to reinstall it properly.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJThh/oAAoJEI5FoCIzSKrw42EH/3KAwLIp67ThELKMgBNo2oBg
EI+pT+sij6qetBjjgdrHXJDBJA17akD6JCAgWVvDUXg/FKMBnl0FNSt2359wL2wR
/jf5khVu9BDCJhWTRlC8WClY9IvfC16c6ZGtZ4kvMDlr453STQzcsJhK3lYaWz8m
NQkTYAb7He3//Y1AddklnhCFgX7CYuuyZ2tz23hKCRO3Dlp4pUyiOpEbe6GlM66i
hCstTX20Zm8w9UeuFRmiVz1+mjBK8vNwCvf9+ovUNS92OGvRa+ZluHw3z4I92qWN
hPSnzhHoi6TKVflXPlAFpJmiqIyHy9ha8Mf9kfwtJPIqb0S5j7hnCtncdsgjvgs=
=hEZm
-----END PGP SIGNATURE-----

[Colin Watson (cjwatson)]

Phillip, please do not close this bug again. As the Debian/Ubuntu grub2 maintainer, I have a list of things that I intend to do here and I do not need you telling users to go away before I have a chance to do so.

[Colin Watson (cjwatson)]

On Tue, May 27, 2014 at 09:08:50AM +1000, Phil Diacono wrote:
> There is a lot of dissatisfaction about a problem that causes updates to
> Ubuntu 14.04 to fail to boot. Phillip Susi of Ubuntu feels this is not
> a bug whereas everyone who runs into feels that it is. We suspect it
> may affect many more users and be very detrimental to Ubuntu's reputation.

I have reopened this bug. Phillip, please could you refrain from
triaging grub2 bugs in this way? It creates *more* work for me, not
less, and does not help. It would in fact help me if there were as few
further comments as possible until I have a chance to address this
(which I plan to do for 14.04.1), so that I have less to wade through.

The hardest bugs to deal with are the ones that have descended into an
argument, and rejecting real problems out of hand (and this most
certainly is a real problem, probably one of the most common issues
reported to me) increases the probability of arguments.

Yes, this is complex, and there are indeed some cases that are largely
intractable; but I do have some ideas of how my code for dealing with
this class of problems could be improved so that at least it affects
many fewer people. However, the confrontational approach of "As a
developer, I have said there is nothing we can do on our end to mitigate
this", without even bothering to check with me whether that's an
accurate reflection of the opinions of the person who does most of the
work on the grub2 packaging, is not a good starting point for a
conversation.

--
Colin Watson [<email address hidden>]

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/29/2014 6:34 AM, Colin Watson wrote:
> I have reopened this bug. Phillip, please could you refrain from
> triaging grub2 bugs in this way? It creates *more* work for me,
> not less, and does not help. It would in fact help me if there
> were as few further comments as possible until I have a chance to
> address this (which I plan to do for 14.04.1), so that I have less
> to wade through.
>
> The hardest bugs to deal with are the ones that have descended into
> an argument, and rejecting real problems out of hand (and this
> most certainly is a real problem, probably one of the most common
> issues reported to me) increases the probability of arguments.

Indeed, part of the problem is that everyone piled into the same bug
with several different issues rather than troubleshooting it on a case
by case basis.

> Yes, this is complex, and there are indeed some cases that are
> largely intractable; but I do have some ideas of how my code for
> dealing with this class of problems could be improved so that at
> least it affects many fewer people. However, the confrontational
> approach of "As a developer, I have said there is nothing we can do
> on our end to mitigate this", without even bothering to check with
> me whether that's an accurate reflection of the opinions of the
> person who does most of the work on the grub2 packaging, is not a
> good starting point for a conversation.

It wasn't a starting point for a conversation; I had tried dozens of
times for weeks to get more information, identify the cause(es), and
explain why it was a result of incorrect action on the user's part.
That statement was made in direct response to someone saying that as a
user they felt they needed to reopen it ( yet again ) without
understanding why I had closed it, or offering any real
counter-argument. By that point I was throwing my arms in the air.

It would be helpful if you would comment if you think there actually
is something that might be done. Since this had gone on for some time
without any comment from you, I assumed you were ignoring it as just
another kvetch fest. I certainly would be interested in any ideas you
might have.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJThzjSAAoJEI5FoCIzSKrw7TEH/2TZLrcRVa0fjeM+ToK1uyzC
ol+vy6TSex4x9rKrp2caUkCtBfYX1+5ZEReMclkwn5RyXG7XKV08fgOtdWtdc9kd
RccyOMVcEaibbyhGKMGWIbxkT2DCyl470cLiqhFvyAd3DbHBOunSCcY33EZ2tnZN
SpLQqqor/dbZk0lXUHjglqtHP0ckA0a10sVk4iueOTgyrpu3yvZZHHg8Rowlsj3M
V+XUythsUbtPfTcYp1nYhYpiSJTEVvG4G053gib/e+uggyXMlTAqz1CFaTz8+ygN
0s6nUGMy5n/sKnJzvR+4N/2bITpV2Uv9OGvDtUXxnPb/UGUTnsANQqCwii7DIvM=
=qRUT
-----END PGP SIGNATURE-----

[Colin Watson (cjwatson)]

On Thu, May 29, 2014 at 09:40:34AM -0400, Phillip Susi wrote:
> Indeed, part of the problem is that everyone piled into the same bug
> with several different issues rather than troubleshooting it on a case
> by case basis.

This certainly happens, and I realise that's annoying; any bug like this
is likely to be only partially fixed, and at some point people who still
have problems will need to be directed to file new bugs rather than
continuing to comment on the closed bug. However, closing the bug
without making any technical changes is likely to be read as blowing
*everyone* off, no matter the good intentions, and just compounds the
problem.

> It wasn't a starting point for a conversation; I had tried dozens of
> times for weeks to get more information, identify the cause(es), and
> explain why it was a result of incorrect action on the user's part.
> That statement was made in direct response to someone saying that as a
> user they felt they needed to reopen it ( yet again ) without
> understanding why I had closed it, or offering any real
> counter-argument. By that point I was throwing my arms in the air.

When people repeatedly reopen a bug, it's often worth considering
whether it was actually the right thing to do to close it in the first
place. The sheer number of people affected by this class of bugs is an
indication that we shouldn't be closing it out of hand, even if you
don't immediately see what we can do about it. Given that we have
extensive maintainer script code for dealing with situations like this,
there's clearly scope for further improvement.

> It would be helpful if you would comment if you think there actually
> is something that might be done. Since this had gone on for some time
> without any comment from you, I assumed you were ignoring it as just
> another kvetch fest. I certainly would be interested in any ideas you
> might have.

I'm afraid I don't have time to read more than a tiny fraction of the
bug mail I get, although this had been escalated to me by several folks
in my management chain and I'd put it on my to-do list for 14.04.1; I'd
just been heads-down in the image build infrastructure changes I'm
currently doing, so hadn't emerged for long enough to dig through the
bug.

I don't yet have specific fixes in mind, but there is certainly plenty
of fodder for investigation here. For example, skimming through the bug
log, I see an instance
(https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977/comments/207)
where somebody swapped disks and then the maintainer scripts didn't
realise that they needed to install GRUB to the new disk. This
situation is *specifically* intended to be handled by the maintainer
script code I wrote some time ago (and wrote up in
http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-06-21-grub2-boot-problems.html),
so if it's failing then I need to investigate that, not discard it as a
situation we can't fix.

This is a long-standing class of bug, although the precise details have
varied over time. The reason it's so difficult to address is that the
root causes are often far removed in time: if you get your configuration
wrong then you often don't find ou...

[Tamale (uictamale)]

At a bare minimum, can't you detect whether the user has multiple hard drives and warn them before upgrading if they do and reference this bug report?

[Robert Tindall (robert-tindall)]

Well. Add me. Single drive, single boot, fresh 13.10 install using LVM and an encrypted partition. Upgraded to 14.04...and dead. So far running dpkg-reconfigure has been pointless, as have all the other steps I've tried. I find it rather amusing that the canned response is "not a bug, you've obviously misconfiguration something". Are we sure the Firefox people haven't taken over the Ubuntu project?

[Robert Tindall (robert-tindall)]

Well, gosh. That was EASY! Here's the simple steps I used to fix this; the sort of thing any generic user should be able to pull out of thin air. The gist is I booted to an xubuntu 14.04 live CD, mounted and chrooted to my normal system, then ran dpkg-reconfigure and update-grub. I selected both /dev/sda and /dev/sda1 (I think all I needed was /dev/sda) on the reconfiguration.

I expect SOMEONE will gripe about running on a root prompt, but that's been my modus operandi for doing rootish things since K&R invented the darn thing back when I was a yout.

root@xubuntu:~# cryptsetup luksOpen /dev/sda5 crypt
Enter passphrase for /dev/sda5:

root@xubuntu:~# cd /media/xubuntu/fb9186c7-9f3d-4a88-8d4b-9c8849e05a38/
root@xubuntu:/media/xubuntu/fb9186c7-9f3d-4a88-8d4b-9c8849e05a38# mount /dev/sda1 boot
root@xubuntu:/media/xubuntu/fb9186c7-9f3d-4a88-8d4b-9c8849e05a38# mount --bind /proc proc
root@xubuntu:/media/xubuntu/fb9186c7-9f3d-4a88-8d4b-9c8849e05a38# mount --bind /dev dev
root@xubuntu:/media/xubuntu/fb9186c7-9f3d-4a88-8d4b-9c8849e05a38# mount --bind /sys sys
root@xubuntu:/media/xubuntu/fb9186c7-9f3d-4a88-8d4b-9c8849e05a38# chroot ./

root@xubuntu:/# dpkg-reconfigure grub-pc

root@xubuntu:/# update-grub

[Michael Tsikerdekis (tsikerdekis)]

@robert-tindall I think you are definitely on to something. Your suggestions did help although my circumstances differed.

I was running 14.04 with a downgraded version of grub due to this issue. I decided to go ahead and do a dist-upgrade. After that I would this error msg that everyone has been having (so basically no boot menu, no options whatsover just straight to grub_rescue).

My laptop is a VAIO and does have EFI. Multiple restarts would still get me to grub_rescue. Then I decided to use the assist button and select load from USB (but I had no USB inserted). I got "Operation system not found!". Then I turned off my computer, turned it on again and suddenly grub menu worked!!!

I got into ubuntu and I tried to dpgk-reconfigure grub-pc only to find out that grub-pc was not installed and grub-efi was instead installed in its place. So, I did a apt-get install grub-pc and it automatically removed the grub-efi and install grub-pc.

Now, when I restarted everything worked fine BUT the moment I entered windows and then restarted my computer again, I got the beautiful grub_rescue screen. I bypassed it by using the asist button, booting through a USB that does not exist and restarting.

From what I've seen, grub-pc or grub-efi doesn't make a difference on the result. But, loading windows affects things. There is something that happens when loading windows in my case at least that forces ubuntu afterward to look for grub at the wrong place.

Any ideas on what may be the issue? I suspect that somehow MBR is affected by Windows but in an UEFI computer I am not sure how that may be,

[Dale Rekow (drekow75501)]

I see a lot of activity on this subject and as an end user I am going to try 13.10 now since 14.04 failed to install on a clean machine. If I have to go through all the extra trouble to install this version on a clean machine then what is the point of installing it to begin with. It has been years since I have used linux and back then my preference was Red Hat but I wanted to get back into linux again and after reading several posts Ubuntu was ranked high.

My process:
Installed from a USB drive. I followed the instructions for creating the USB drive directly from the Ubuntu web site.

The installation process was painful. I kept getting an error with nothing but "?"'s repeated. Finally got the install to work only to reboot to a black screen which led me here. I can't say for sure if it is a bug or not but it is a pain to me.

My system: Intel Server Board S2600GZ
RAID array: 2 drives mirrored
Dual Xeon quad core proc.
64 GB RAM

If 13.10 doesn't work I will move to another distro for testing purposes. I hope this was of some help to someone and if not, my apologies for wasting space on here.

[Peer (peer-i)]

I copied a hard disk with kubuntu 13.10 to a new (bigger) one with dd, taking extra care to verify the copy with hashing it using md5sum. The copy was fine.

It bootet correctly, everything behaved normally.

After the upgrade to 14.04, the system didn't boot any more because of the error discussed in this thread.

It could be made to run normally with the methods suggested somewhere in this thread, e.g. booting from a Live system (debian based that one), mounting relevant partitions, chrooting, rewriting the boot sector as described above, unmounting, rebooting.

So maybe this bug has to do with switching hard disk.

Is the installer creating some kind of hash or ID of the disk in order to determine it's course of action in some branches of it's code execution? This might be the reason for the breaking of the update in my case.

I had same data on a new disk.
If some hash/ID of the HD (as an individual HD) informs the installer that I switched the disk and that for that reason it shall not write the complete set of parts of the updated grub, then this is the reason why it failed in my case.

[Markus Weyermann (byro)]

I also encountered (bug description on top)

I found "Boot-Repair" advanced Settings "Secure Boot" to be enabled while in BIOS Settings it was not. So i simply switched the Setting in BIOS to "enabled" and error disapeared.

HP Pavilion g6 3277sz

Kind regards
Markus

[Markus Weyermann (byro)]

I forgot to indicate (#221)

efi/gpt

Kind regards
markus

[Colin S. (cbs228)]

I too experienced this bug: my perfectly-functional Ubuntu 13.10 (x86_64) system was rendered unbootable on upgrade to 14.04 with the grub "grub_term_highlight_color" error. My computer has two disk drives: one with Windows 8 and one with Ubuntu. I use GPT/EFI exclusively, with secure boot turned off. My EFI partition was formerly located on the Windows 8 drive.

To fix this problem, I created an empty EFI partition on my Ubuntu disk and installed rEFInd from its installer script. It appears that my motherboard's EFI does not remember NVRAM settings for symbolic names like "ubuntu" or "refind": it only remembers which device (i.e., disk) from which it should boot. In order to make refind work, I had to install it from its install script [1] as

   ./install.sh --usedefault /dev/sdXX

which makes refind the device default for the disk on which it is installed. Caution: read the install script's manual carefully first! Now I can boot both OSs.

I am not sure if this is the correct solution, but it helped me. If your system has been rendered unbootable in this state, Super Grub Disk can get you back into your OS so you can make these changes.

[1] http://www.rodsbooks.com/refind/installing.html#extra_installsh

[theghost (theghost)]

@ Colin Watson: Although I originally wanted to unsubscribe from this bug, to avoid the daily comments from this bug, I have to admit that it is good to hear that this is finally recognized as bug. As the original reporter of this bug, I can provide all the necessary configuration about my HDD setup, that made the grub-update script fail. If you are interested, just add a comment here about what you need.

[Timothy Gu (timothy-gu)]

@Colin Watson: any updates on the bug?

[DonQuichote (xubuntu-w-p)]

I know a lot has been said already, but I want to add my case just for the record. It just might contain info on what went unexpectedly right or wrong when it shouldn't have.

I had a working 13.10 installation on a (pretty ancient but indestructible) Panasonic CF-18 Toughbook. This is one of the devices from the time that PAE was enabled but kept secret. I had modified the grub configuration to show the menu at boot, using the "normal" way of editing /etc/default/grub and running sudo update-grub. The menu showed, so this worked. No error messages. I had 3 partitions on only one hard drive: /, /boot and swap. I always like to have a separate boot partition in case things go wrong, but reading the comments this has bitten me now.

From the grub_rescue prompt, I can barely do anything, but the "ls" command works and I see that:
(hd0,msdos3) contains an EMPTY /boot/grub directory,
(hd0,msdos2) contains no files (the swap partition)
(hd0,msdos1) contains the images (like vmlinuz-3.8.0-34-generic) in its root directory and a /grub directory, but no /boot directory.

Something is definitely broken here! For the record, none of these partitions were formatted with a FAT filesystem.

After I did "sudo do-release-upgrade", I waited with the reboot, and re-added my third party add-ins. I read that fake-pae was no longer needed, but a kernel option "forcepae" was, so I removed the repository that provided the fake-pae package, added that option to /etc/default/grub and ran "sudo update-grub". No error message there either.

My 2 cents: the release updater and update-grub should be able to tell what partition is the boot partition, so a misconfiguration on only one hard drive should be detected. I never manually messed with it, but just followed the installation wizzard when I installed Xubuntu. If the system was misconfigured, it gues that must have happened by either a system upgrade or the update-grub command. In any case, I would certainly expect update-grub to have warned me.

Well, the rest you can guess: I shut down the machine in full confidence of an upgrade done well and was left with a system that does not boot anymore. Don't take this too hard, I am a "half-power" user, so I am not afraid to fix things. I just want to add that I was not using UEFI, not using more than one drive and have not yet (or in the past) repaired the boot process, though I did do some minor configuration in the proper way. So, please take this bug seriously. I is a critical one.

By the way: the "grub rescue>" prompt does not know the "help" command.

[DonQuichote (xubuntu-w-p)]

Update: the boot repair disk fails to boot, because of the PAE bug. Adding "forcepae" to the boot options does not help either. However, "Super Grub2 Disk" does boot, recognizes the config and can be used to boot the system. Now I have the safest laptop ever! Nobody can boot it but me!

In the previous post I thought that the found filesystems were broken, bu this is not the case. The /boot directory on the / partition is off course empty because the /boot partition was mounted there. Reading this list and different forums on the internet, ot appears that the master boot record and the grub2 install are no longer in sync when / and /boot are on different partitions.

I tried a re-install (using synaptic) of the packages "grub-pc", "grub-pc-bin", and "grub2-common". It did not solve the issue.

[DonQuichote (xubuntu-w-p)]

I got my machine too boot again:

* I Used the Super Grub Disk to boot into the existing installation on my laptop
* I checked /etc/mtab to see which device was mounted (in my case /dev/sda)
* then I ran "sudo grub-install --boot-directory=/boot /dev/sda"

For people using the Super Grub Disk: selecting the mysterious option "everything" will enable you to select the existing boot configuration on your hard disk. If you booted from an external CD drive, you can remove it after booting.

The boot repair disk was not an option. It refuses to boot when burned to CD, adding the repository failed (the command add-apt-repository does not exist), and downloading the debs only gives a message "enresolvable dependencies", even when extra library debs were downloaded and tried first.

[Palmar Thorsteinsson (palmar)]

This happened to me when upgrading from 13.10 to 14.04.
I did not have any special Grub settings as far as I know.

I was unable to manually boot from the Grub rescue prompt as it could not read the partition filesystems (said they were msdos while they are ext).

I tried the recommended solution from comment #39, i.e. run Boot-repair from a live USB, but when it wanted to reinstall Grub from a chroot on the broken partition it failed because I also suffered this bug from the same upgrade: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1286404 .

Running "dpkg-reconfigure grub-pc" from a chroot on the broken partition using a live USB (Ubuntu GNOME 13.10 if I remember correctly) fixed the problem for me.

[nicobrainless (nicoseb)]

Thanks @palmar, easy fix, works well.
I did it with a lubuntu live-cd, but same all...

[jean (magiceye)]

I fix this by boot repair tool, very easy to use and worked for me (upgrade 13.10 to 14.04LTS).
refer: http://askubuntu.com/a/229982

[msth67 (msth67)]

I can't believe that anyone may chalk this up to a supposedly "incorrect setup":as many others have reported,I've just done a clean install (Lubuntu Trusty) from CD to a new hard drive,the installation process finished normally and then the system could not be booted,period.

After fiddling with grub commands and managing to boot the system only to confirm that once booted there were no issues and the problem was the boot process in itself,I've resorted to a separate boot partition as advised in many threads,which only partially solves the issue:the system can now boot,yet it still spits out error messages in the process,and furthermore can't be rebooted,it has to be shut down and then restarted.

I've installed several Debian and Debian-based distros so far (including earlier Ubuntu releases) on not-standard multi-boot setups,reinstalled Grub after recovering some partition,and not once run into this issue:I can't see how reinstalling/reconfiguring Grub,resorting to command line methods or having to otherwise repair Grub may be part of a normal installation process.

[Teo (teo1978)]

Ok, now the time has come to be scared.

Given that upgrading from 13.10 to 14.04 broke my boot and bricked my computer because of this bug, and that I fixed it (long ago) using the methods that have been commented above, and I have a wonderfully working 14.04 (in dual boot with Windows 8),

WILL installing these updates in GRUB (see screenshot) break my boot again? Should I be worried about installing these updates?

Please refrain from making educated guesses. I need a reliable answer, either from anybody that that had the problem when upgrading to 14.04, fixed it, and has now installed these updates, and can tell whether or not they broke the boot again; or by anyone that wrote the relevant source code or anyway knows FOR SURE whether or not these update will trigger the same kind of shameful disaster that the upgrade did.

[Teo (teo1978)]

F*** it, Launchpad silently discards the screenshot every time I try to attach it to this report, and it even keeps showing a confirmation that it has been attached though it doesn't show up anywhere.

However for some reason it has allowed me to attach it to another report, so here's the link to the screenshot:
https://launchpadlibrarian.net/180644403/Screenshot%20from%202014-07-24%2013%3A30%3A10.png

[Serhiy Yakovyn (syakovyn)]

Comment #14 helped me. I have dualboot laptop with Windows on the first disk where the old grub was installed and the second disk with Linux partition.

The issue was that the grub on the second disk was upgraded, but on the first one, that was actually used, wasn't.

I used USB installation disk to restore grub using boot-repair and after successful start of the laptop ran debconf-show to configure grub updates to be installed on both disks.

It would be fine if grub upgrade script checked for multiple grubs and issue warning/error about some grubs not being updated if that can make system not bootable

[Teo (teo1978)]

@cjwatson do you know the answer to my question in comment #234?

I have stopped updating my system since the update for grup has become available, because I fear I may incur in the same issue again. I think everybody who has had this issue and recovered from it urgently needs to know whether we can safely install these updates or not.

[Cian Davis (davisc)]

@Colin Watson: Thanks for taking the time to look into this. I was left very disheartened earlier in the year when I upgraded, hit this problem and then was just dismissed.

The reason I am commenting now is I ran an apt-get dist-upgrade yesterday. I booted the machine this evening and have hit the same error. I know I installed a new kernel, I'm guessing there was a grub upgrade.

I don't need the machine now so I can leave it before attempting to fix. What can I do to get more information to either determine whether this bug affects me or help with a solution? Adam Niedling previously suggested the output of "sudo parted -l" and "sudo debconf-show grub-pc" would be useful. Is that still the case?

Regards,
Cian

[DonQuichote (xubuntu-w-p)]

@Teo:

I updated grub, but afterwards, just to be sure, I ran the grub-install command like I did when I repaired my non-booting system.

My laptop still boots.

[aldo (coffee4kepi)]

I've made a clean install on a 13.04 dual-boot, efi notebook. first boot i got that error message. i tried boot-repair with and without secure-boot (disabled by bios), but that didn't worked. Here is the url of the report: http://paste.ubuntu.com/7951398/

so i tried to reset grub manually with
    dpkg --configure -a
    apt-get install -fy
    apt-get purge -y --force-yes grub*-common shim-signed linux-signed*
    apt-get install -y --force-yes grub-efi_amd64 linux
    grub-install /dev/sda2 ##efi partition

still nothing. i found that i couldchange the efi boot order and select ubuntu, which gives me a half working grub, because while ubuntu boots up, windows (even if os-prober finds it) does not. it doesn't even if i choose "boot from efi file" from efi boot menu.

any clue? thanks

[aldo (coffee4kepi)]

to be precise, here is my last boot-info report:

http://paste.ubuntu.com/8159797/.

strange thing is that on the last run in the log i found this:

locating grub_term_highlight_color at 0xb7e8 (0xb4e0).

[polyurmok (09689835g)]

I am still trying to fix my system after upgrading from xubuntu 13.10 to 14.04 (amd64). I ran boot-repair after installing 13.10 like many others. No hardware change since I bought the system. I have a hybrid harddisk, but the SSD is only used by Windows. BIOS config is UEFI with secure boot disabled.

   nm -A /boot/grub/x86_64-efi/*.mod | grep highlight_color

shows undefined references to grub_term_highlight_color in gfxterm.mod, normal.mod and terminfo.mod.

I don't know for sure if any of these files is causing this problem. Does anyone know how to find out what grub uses? Thanks.

[Marco Coletti (colemar)]

I can confirm that there is some regression going from grub2 2.00 to 2.02~beta2.

I have disk0 with traditional partition table and three partitions:
sda1 is Windows boot
sda2 is Windows system
sda3 is linux Mint root partition (with /boot inside it)

In the past I manually set up the Windows bootloader as to chainload with grub, therefore grub is installed only in sda3 boot sector.
This worked well until I attempted upgrade to Mint Quiana via do-release-upgrade. After the upgrade the Windows bootloader came up as before, but selecting the item for Mint gave exactly the error reported here.

Therefore I booted from a USB stick containing Boot-Repair-Disk (which I understand is really Lubuntu 13.04 "Raring Ringtail") and executed the following as root:
grub-install --force --boot-directory=/mnt/boot-sav/sda3/boot /dev/sda3
It showed the usual warning about blocklists, but the error went away and I was able to boot linux Mint through the Windows bootloader.

Once inside Mint I executed the following as root:
grub-install --force --boot-directory=/boot /dev/sda3
At the next boot the same identical error about "symbol 'grub_term_highlight_color' not found" was to be seen.

The relevant difference seems to be that Boot-Repair-Disk has grub2 2.00 while Mint Quiana has grub2 2.02~beta2.

[NomAAd (nomaad)]

I run the release upgrade from a completely up-to-date 12.04 from the Update Manager and it completed without problem. After the upgrade had finished I performed the restart and faced the
grub rescue>
prompt and got puzzled understandably.
Then I searched and found this bug and figured out that the error might be related to the boot order.
I have 2 HDDs in the box - one IDE and one SATA -, with a single Xubuntu installation. The BIOS was set to boot from the IDE HDD, the OS resides on that. In the BIOS boot order I moved the SATA HDD before the IDE HDD and after a reboot 14.04 booted like a charm.

Thought I share my experience, since I didn't see this solution here above. True, the report above is rather lengthy and I didn't read through all the posts, so I'm sorry if I duplicated.

[Teo (teo1978)]

@cjwatson again, could you please tell us whether or not it is safe to install the latest grub updates for those of us who had the bug, had the boot broken, and had fixed it?

The problem is: there are updates available and I have no idea whether installing them will cause the same thing to run which screwed up the boot on dist upgrade.

I appreciate comments made by other users but they don't calrify this point.

I understand you cannot guarantee whether anything bad will happen or not by updating grup, but given it's you who maintains the package, you should easily know whether or not:
1 - merely installing the updates will run the same scripts that ran on distupgrade which screwed up some boot configurations
2 - the issue has been addressed in any way so that even if (1) is the case, it may not cause the disaster any more

Obviously I won't take the risk if (2) is true, but I'd rather keep grub up to date if (1) is false.

[Hector Cline (hector-cline)]

Folks,
I was bit by this today, turning my dual-bootable laptop into a brick.
I tried a lot of things here and nothing worked.
What did work for me was following directions in http://community.linuxmint.com/tutorial/view/245
I'm running Linux Mint 17 Qiana, which is based on Ubuntu 14.04
I was upgrading from Mint 16 to Mint 17 and the install appeared to work fine.

For me, the following worked:

             mount /dev/sda5 /mnt
             grub-install --root-directory=/mnt/ /dev/sda
             reboot

which is close to some suggestions others made but those didn't work for me.
Obviously you'd need to change the sda5 to whatever is appropriate for you.
No, I have not made a typo above. There is no trailing number on the sda for the grub-install command.

The above for me worked, despite the error message:
          "grub-probe: error: failed to get canonical path of /cow."
Hope this helps.

[Br. Peter Totleben, O.P. (peter-totleben)]

Note that this problem also exists in Ubuntu 14.10.

Before I get in to all of this, I should explain my setup, so that people who are interested in my solution can figure out if they are in a similar boat. I have a Dell Inspiron laptop with UEFI and a Windows 8 partition. (Earlier I had already turned off SecureBoot in my computer's Setup). I have only one hard drive.

Previously I had Linux Mint 15 installed on my computer, and it was dual-booted with Windows 8. I have just installed Ubuntu-Gnome 14.10. After quit a bit of fussing, I have Ubuntu-Gnome 14.10 up and running, and can again successfully dual-boot Windows 8.

The problem here is actually a bug that is internal to grub itself, and not to Ubuntu, per se. The problem is that Ubuntu Trusty (14.04) and Ubuntu Utopic (14.10) both include buggy versions of Grub. This is because the Ubuntu people decided to include beta versions of Grub 2.02 in both Trusty and Saucy. (Why this was done, especially for an LTS release is not quite something that I understand).

For any Grub people that might happen to read this, the grub that is included with Ubuntu 14.10 (grub2.02-beta2-15) contains the undefined symbol `grub_term_highlight_color` in a few of the .mod files. This can be verified by typing `nm -A /boot/grub/x86_64-efi/*.mod | grep "grub_term_highlight_color"`

For anyone who has been bitten by this. The news is mostly good: your Ubuntu 14.04/14.10 installation is safe and sound on your computer, and if you have a Windows partition, that is okay as well. The only bad part is: fixing this error is a bit of a pain. What we have to do is to downgrade the version of grub that you are running to the one that is used in Ubuntu Saucy (13.10). Then, we can use boot-repair to get the Windows partition back onto the boot menu, if this is needed.

Here is how to do it . . .

**Part 0: Preliminaries**

Before I get in to the details of how to do all of this, I will tell you how my computer is set up, so that you can change the commands below as necessary.

-- I have a UEFI boot partition at /dev/sda0, which is mounted as /boot/efi
-- I have a Windows partition at /dev/sda5, which is mounted as /windows
-- I have a Linux Partition at /dev/sda8, which is mounted as /
-- I have another Linux partition for my home directories at /dev/sda9, which is mounted as /home
-- My home directory is /home/peter

Also, these instructions assume that you have a UEFI system, and that you are interested in the AMD-64 packages. If this is not the case for you, then you can try modifying the instructions below, but they may or may not work.

There are basically two different ways that you can get at your fresh Ubuntu 14.04/14.10 installation. On my Dell as the computer is first booting, while the Dell Splash Screen shows up, I can press F12 to get a boot menu. On this menu, I can select the "Ubuntu" option, and I can get into my installation. You might have something similar. If you can do this, then boot into your Ubuntu 14.04/14.10 installation in this way. It will make the process a little bit shorter for you.

If not, you need some sort of boot image that will get you to a Linux prompt. You can just use the installa...

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/27/2014 11:52 PM, Br. Peter Totleben, O.P. wrote:
> The problem here is actually a bug that is internal to grub itself,
> and not to Ubuntu, per se. The problem is that Ubuntu Trusty
> (14.04) and Ubuntu Utopic (14.10) both include buggy versions of
> Grub. This is because the Ubuntu people decided to include beta
> versions of Grub 2.02 in both Trusty and Saucy. (Why this was done,
> especially for an LTS release is not quite something that I
> understand).

No, it is not. The problem here is that people tinker with their
system to get a grub installation that works, yet is broken. Since it
"works", they don't notice it is broken until they upgrade, at which
time, the upgrade updates one part of grub, and not the other, leading
to the error. There is nothing wrong with grub itself; it is entirely
in how it is installed and upgraded.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUT53uAAoJEI5FoCIzSKrw+HcH/0xMFD4/ofzVeqnSSzMmJdZv
21Du5KsyA+fBek5nfBU5/QsDz3iOaUnhV6AKl/PhG4uV12Y9BNaCvBbDjq0WcKgM
i8mGKeh9MMcYj1mAUfG8mUx1RIfBB86EdAzSyypQSW6ar2b1/IZ1Pc/75tZzpgV0
PwXtbeA7Tnmt2iVcex9ksgv//HjGzySSxW9blf/mJ8geHYTyfHtqjNILm6Y4120n
ItVBO23hF85FoJglU4x3Dqp55PHh0yHx7gFug0QScvlPD8aCf9LN2ij3AJUtoxVJ
WNqK1UUIz6paHgbtBtWu858KqwMHVAKPhu7m/NGBDS4EWoeN+pYYHz1XWGbZEGI=
=ZcIS
-----END PGP SIGNATURE-----

[aldo (coffee4kepi)]

@psusi how can you tell that? A lot of people may have broken something in their grub that was exposed during the upgrade, but what about the others that found the problem with a plain system and a fresh install?

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/28/2014 01:07 PM, aldo wrote:
> @psusi how can you tell that? A lot of people may have broken something
> in their grub that was exposed during the upgrade, but what about the
> others that found the problem with a plain system and a fresh install?

I haven't seen anyone report this on a fresh install. It is always after an upgrade, which normally replaces both parts of grub on the disk. The symbol "grub_term_highlight_color" was removed from the new version of grub intentionally. When only one part of grub is upgraded, the other, older part generates this error because it is still looking for it and can't find it, because the part that used to contain it was upgraded.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUUDdaAAoJEI5FoCIzSKrwKZkH/32nWWq987LWIdmKjrQOTKZq
kR1yOHsERmQNXV/Kpiiidb/LP+Efor+qi3NM3ilZp3K69ukJzApdy7EhjPI5hURe
w/UJHpwMxUfSFV5eIBhLNum+bIunpbRaIrhD1zGCimgz6aZGyz0dDh6fDYfpO+LT
J0pKo0D8wPzNa4ZDL93fvq4MuzDpV3GXEU7yihgsmiyko2s6ui83nMIoDbpIAr6o
6XZ/bCdqKBIHBAGJUw24Ea2LQppvq8+HIzL00SnhK8r0XcvzAa/16EgIP9WjB27N
3UzuNdL+tJJrbPhHSvwZLe11ZaDXkiGP7HV3SOgDMSPP9GRo6CbqiS1h7zaVIho=
=zpuD
-----END PGP SIGNATURE-----

[Teo (teo1978)]

> I haven't seen anyone report this on a fresh install. It is always after an upgrade,

That's untrue and you know it.
There are a few comments on this very page reporting the issue on fresh install. And you did see them; I seem to remember you said you just don't believe them (I'm too lazy to look for it now), but that's a different thing.

Anyway, as already discussed, there is clearly some bug, whether it is in Grub or in Ubuntu, if a perfectly working dual boot (whether it was a "fresh install" or it was "tinkered" because that is the _only_ way to get a dual boot with windows 8 to run, as the official installer and all the officially documented methods fail to produce a working dual boot installation) gets bricked by a distupgrade without warning. The maintainer of the Ubuntu package himself agreed to that.

By the way, talking about @cjwatson, I'm still wating for an answer to whether or not those of us who were bitten by the bug and and fixed the broken boot can safely install the updates that have since been released, and whether the upgrade to 14.10 will bite us again.

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/28/2014 09:34 PM, Teo wrote:
> Anyway, as already discussed, there is clearly some bug, whether it
> is in Grub or in Ubuntu, if a perfectly working dual boot (whether
> it was a "fresh install" or it was "tinkered" because that is the
> _only_ way to get a dual boot with windows 8 to run, as the
> official installer and all the officially documented methods fail to
> produce a working dual boot installation) gets bricked by a
> distupgrade without warning. The maintainer of the Ubuntu package
> himself agreed to that.

No, as already discussed, there is a broken installation of grub. The reason Colin reopened this report is because he wants to put in some checks at some point to detect that it's broken and guide you through fixing it.

> By the way, talking about @cjwatson, I'm still wating for an answer
> to whether or not those of us who were bitten by the bug and and
> fixed the broken boot can safely install the updates that have since
> been released, and whether the upgrade to 14.10 will bite us again.

If you fixed it correctly so the package system knows where it needs to reinstall it in the future, then you won't have the problem again. If you fixed it by manually reinstalling grub outside the package system again, then you will face the problem again.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUUE92AAoJENRVrw2cjl5RA1oIAK2UTMf/t6FtADGgK8VPiAma
1nbLe3k3VG4o8M5TmsCi+IPmM+8lcnkdoqChErWX/PG2U9eKxvh25GTMaFFsc5QO
iu5u4h7b5v9ROYeCqH3vt4Zj1ifrMKhzORRMkkOv09A1u/6PVKGc0HLIvamFMF4c
QcLzgFLwEnPI7uBxkRXLIbO3EIKeVPWF4P7ROc9zAD9ggx6rU33qmNYJpd7by1vd
/+V+vc5GqsAOdRaHR00fWHSZ7vkjG1le5pgBaaQEmHEmo3lugJH1Tm8nMfApYeoV
5dEgkgPVeaQWS+u1Lx2RtbNtuAEG1vx37ab3UCVwS39s6IsC97XwDbTOcSE0QxA=
=K7FT
-----END PGP SIGNATURE-----

[Erick Brunzell (lbsolost)]

I have only encountered this if [for example] I had grub originally installed in some pbr (eg; sda6) and I later changed the location to the mbr (eg; sda) using grub-install /dev/sda rather than using dpkg-reconfigure grub-pc. Then apparently the release-upgrade reads the prior dpkg info therefore installing grub in the wrong location. That of course explains a broken boot but I never quite understood the error message, it's just not that hard to fix so I really haven't worried much about it.

[Saurabh Rindani (saurabh-prl)]

My answer to Teo's question regarding upgrades:

I have had no problem with updates of any of 10.04 packages. My history is that I did a fresh install of 9.04, ran into a problem which I could solve using grub-repair, then upgraded to 9.10 without any problem, and during upgrade to 10.04 ran into this bug, which I solved somehow.

[theghost (theghost)]

Even though it might not be a bug in grub, it's a bug in Ubiquity (which installs Grub the wrong way) or Ubuntu's updater (which updates Grub in a wrong way). Most users have these problems because Grub was automatically installed and upgraded, they had not configured it by hand. So closing the bug is no solution...

I guess it's normal these days for Ubuntu. Even critical bugs which breaks the user's system aren't fixed although the bug was reported on a beta 2 releases before. I have also seen this attitude in many other bug reports. Canonical only care's for Ubuntu mobile. I can only recommend to use and rest on LTS or switch to other user friendly distributions, which care more. It's the said reality, but we should face it. Its only getting worse...

[Teo (teo1978)]

@psusi
> No, as already discussed, there is a broken installation of grub. The reason Colin reopened this report is because he wants to put in some checks at some point to detect that it's broken and guide you through fixing it.

You start with "No,", but you confirm what I said. Note I didn't say the bug is in grub itself; I have no idea whether it's in grub or in Ubuntu or in Ubuntu's packaging of grub, but something is broken if this situation happens in the first place.

> there is a broken installation of grub
If there is a broken installation, something is broken.
A few users got that "broken installation" after a fresh install, so some piece of software responsible for installing it didn't do its job correctly.
I (and others) got that "broken installation" after having to manually touch things because the Ubuntu installer just hadn't been capable of installing the system. I didn't tinker with things because I wanted to, I was forced to because the Ubuntu installer doesn't do its job and the docs don't offer any instructions that work, so I had to try things. If I happened to touch something wrong, it was because I was forced to touch things that I shouldn't even have had to touch.

> Colin reopened this report is because he wants to put in some checks at some point to detect that it's broken and guide you through fixing it.

Which is what must be done to fix this issue. A robust OS (like any robust piece of software) cheks things and warns you if it's going to break.

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/29/2014 4:37 AM, Mathias Dietrich wrote:
> Even though it might not be a bug in grub, it's a bug in Ubiquity
> (which installs Grub the wrong way) or Ubuntu's updater (which
> updates Grub in a wrong way). Most users have these problems
> because Grub was automatically installed and upgraded, they had not
> configured it by hand. So closing the bug is no solution...

No; ubiquity installs it just fine. The problem comes when it *fails*
to install it ( typically because you asked it to install grub to the
wrong place ) and you manually install grub yourself, possibly via a
third party repair tool like grub-repair. That is when things go
wrong but you don't realize it because grub works... until it's time
to upgrade.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUUPqoAAoJEI5FoCIzSKrw4vIH/A4oIDJnYSVWmUMp/NNQkZ3a
/uu0qeaplfQasEcqsvub6DjcZBdNWNpN83o3NeKpp0ULcV/uL9fux1l2Jtkprvrv
L4dTeVNgT6io3hmM/KnlvWGLdlQzNsgGdcnho5WZyaaIDzYMDu/Oo8Yx4wAOQxiz
2k/KqpU2Ohf4SnVz3xjaX7apPMFEaRYpI7TVNHfr3GnjBKL22AYLNOwknidXkRuy
fKUmfSh33zVDW36GChHEaOa595TARK43LNfaBtJDNlXvMpVXTXK/kbCrOSDpZLvM
7zqemerM9XVstU6VYPwBeD7taxOUFKEkWLhgbvzHpDUiRqqdgCn1uJN2MYqPrtY=
=gUpS
-----END PGP SIGNATURE-----

[theghost (theghost)]

That's not what I did, I installed Ubuntu via LiveCD and then did upgrade via updater. I definitely didn't edit something manually.
I only used super grub disk to repair my grub after it was broken by the updater. But go on close this bug. Let's pretend this never happens. Also it's only grub, it's not that hard to repair it for every Ubuntu user affected.

[Tamale (joshua-buss)]

This is ridiculous. Can someone else please fix the root cause? It's well beyond obvious by now that Phillip Susi doesn't care at all about ubuntu and its users.

It sounds like Peter Totleben has the most complete and useful information so far - can you please submit a new bug report with your findings?

[Teo (teo1978)]

> If you fixed it correctly so the package system knows
> where it needs to reinstall it in the future, then you won't
> have the problem again. If you fixed it by manually reinstalling
> grub outside the package system again, then you will face the problem again.

I'm not sure how I fixed it. I followed the instructions provided in some of the comments above by some other victim of the issue.
But it was almost certainly the second way.

Will I (and others in my situation) hit the problem again "only" when dist-upgrading to 14.10 (which is already out btw) or also when installing the grub updates that have been available for a while? (which I have always avoided installing just in case)?

Secondly and most important, what should I do "so that the package system knows" whatever it needs to know, so that I can dist-upgrade without screwing up my working system again?

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/30/2014 11:19 AM, Teo wrote:
> Will I (and others in my situation) hit the problem again "only"
> when dist-upgrading to 14.10 (which is already out btw) or also
> when installing the grub updates that have been available for a
> while? (which I have always avoided installing just in case)?

It can happen on any update, but won't necessarily happen on every update.

> Secondly and most important, what should I do "so that the package
> system knows" whatever it needs to know, so that I can
> dist-upgrade without screwing up my working system again?

Assuming you are on a bios booting machine and therefore using
grub-pc, use dpkg-reconfigure grub-pc to select the correct drive(s)
where it should be installed.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUUnY1AAoJEI5FoCIzSKrwZxQH/jWlHYbmK7WdHiNV0iSlK3Ux
U4ANKhj6/hQyzL1E+CvkVmSr2Rg+9gUXFH43VREa/VlftCYWjYghAjmZu/wT9B8o
fBeoLt4teeTiN0QuTc8ZCPRNC1rdnmUdetaG8ed5SNiFl/sl2q/dlrVDcEXAPwyI
wPruW60Ku5dxoqhbbkMeoCxHUs4ak5SHkIVXri2O1cAyoDUSMcyUrJBhnmy+dcD/
AdD2FtiXUr8kykQiSSzRLT+6GcSEoNNUXAvg1U7hpaqiYug10xBhWh5NIVE2waaw
L9alqFZHViWp0NR3uGED2K7hlXvLD+9QOaTtEKcVikmcTmS8kw2FMyEvU9g0sQA=
=9F0a
-----END PGP SIGNATURE-----

[Br. Peter Totleben, O.P. (peter-totleben)]

@psusi,

You seem to not be listening to people.

All of the things that you say are the case are in fact not the case at all. And all of the things that you say are not the case are precisely the case.

I installed Ubuntu Gnome 14.10 by deleting all of my old Linux partitions and installing fresh. And I only have one HD. After installing, Grub was broken, with the indicated error.

After a little digging, I realized that "grub_term_highlight_color" was a symbol internal to Grub. It was being used in several Grub module files.

Then, I noticed that both Ubuntu 14.04 and 14.10 include the 2.02beta version of Grub. I wondered why the Ubuntu people were packaging releases (and LTS releases even!) with beta versions of the bootloader.

So, I downgraded to Grub 2.00 and everything worked perfectly fine for me. The module files for Grub 2.00 do not (AFAIK) include the undefined symbol "grub_term_highlight_color"

So, psusi, the problem is with the version of Grub included in Ubuntu 14.04 and 14.10. You are just making stuff up, and dismissing people's problems solely on the basis of your fabrications. Either provide constructive help or don't post.

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/31/2014 02:08 PM, Br. Peter Totleben, O.P. wrote:
> All of the things that you say are the case are in fact not the
> case at all. And all of the things that you say are not the case
> are precisely the case.

Seeing as how there have been hundreds of disjointed complaints in
this thread, that is possible. This is why I tried to get people to
file their own reports until they could be triaged and truly
identified to be the same, or a different issue, but alas, that didn't
happen so now it's all ajumble. Of that jumble I did spend some time
trying to carefully look into quite a few before it became clear to me
that they fall into basically the same category, with perhaps three
different subtle variations.

> I installed Ubuntu Gnome 14.10 by deleting all of my old Linux
> partitions and installing fresh. And I only have one HD. After
> installing, Grub was broken, with the indicated error.

Then your 14.10 install did not install grub correctly ( i.e. it
failed to install, or installed it to a place your system did not
actually boot from ), leaving the previous grub install you had to try
and fail to boot.

> So, psusi, the problem is with the version of Grub included in
> Ubuntu 14.04 and 14.10. You are just making stuff up, and
> dismissing people's problems solely on the basis of your
> fabrications. Either provide constructive help or don't post.

No, I am not "making stuff up". I understand what causes this
message, and the possible ways that could occur ( in general; perhaps
there are still one or two subtle variations I have not yet identified
), and confirmed these were in fact, the ways that many of the people
posting here arrived there.

The bottom line is that this message happens because you have one
version of grub in your MBR, and a different version in your /boot
directory. This does not happen when ubiquity installs grub
successfully and to the correct place. The only way that ubiquity
installs grub successfully but to the wrong place is when you either
explicitly tell it to install to the wrong place, or if you have
multiple disks, in which case it assumes your system boots from sda,
and if this is not the case, then yes, you do need to manually tell it
the correct drive and there just isn't anything we can do about that
other than your manual intervention there ( and then you only get this
error if you previously had installed an older version of grub on the
drive your system actually boots from ).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUVFXqAAoJENRVrw2cjl5R6esH/3q6H0iVe20l4Cv5gQRDbJDx
/2ZKg9tV+hD/V1PYWeG/+Cwo/mqN9/TL2NHcC492Nz3u0iQDqKGiXe9XZH0U81VV
G29fXJJJ7iWOWY7Qd0ysdJ/RNfeXFsARcPQiVCD8g8kl+2W89wcbcauYdC2UsA4r
zNUUv65PgQGWINXSCjrctr/By7eH5SPFS86mAPXZPh5Zq2ivYjuj860JhRcLAiFH
V+NoJKIvyGQbKOW3slEIfh8FCM3CIOUD2psOCcOOJmG0k0QcdQmc6J2s1w908b4s
mawApy77e6t8dfjyHpO77yhZwo2xo9sBqAjBmnUDv5pnk7YRyrTXupvIhPFLvhk=
=SJi0
-----END PGP SIGNATURE-----

[Teo (teo1978)]

> Then your 14.10 install did not install grub correctly ( i.e. it
> failed to install, or installed it to a place your system did not
> actually boot from ), leaving the previous grub install you had to try
> and fail to boot.

Which confirms there's a bug somewhere.

> The bottom line is that this message happens because you have one
> version of grub in your MBR, and a different version in your /boot
> directory.

Which is something that should never happen no matter what. The very fact that this can happen is _the_ bug (unless, of course, one manually runs a command to purposefully create that situation, with some kind of --force option or after answering "yes" to a warning prompt).

Assuming that your diagnosis is correct, that is. Of which I am not completely sure, given that you have a history of negating facts (as in "I haven't seen anyone report this on a fresh install").

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/01/2014 06:20 AM, Teo wrote:
> Which confirms there's a bug somewhere.

No, it does not. Installing grub to the wrong place because you
manually chose it is not a bug. Installing grub to /dev/sda by
default when your computer actually boots from another drive is also
not a bug, because unfortunately, there simply is no way to detect
which drive the computer boots from due to the limitations of the pc
bios. If grub outright failed to install, then there *may* be a bug.
 The installer automatically files a bug report when this happens so
it can be investigated.

> Which is something that should never happen no matter what. The
> very fact that this can happen is _the_ bug (unless, of course, one
> manually runs a command to purposefully create that situation, with
> some kind of --force option or after answering "yes" to a warning
> prompt).

"Never happen no matter what" is asking for a magic wand and unicorns.
 There are some things we can control, and some we can not.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUVOvCAAoJENRVrw2cjl5RRbUIAKTbN/lMw19lCjSMH9658ful
EZgqMkXa7sIO0lh43+BAnWkfrqIKPk49pxiFRKUgW1otFKQI2butpjRKypBKNmal
o6F444lwV9daUjOoYa79VxNPBxx7AUAshXNZpyu96uRQv7RLbI6qcA6Dggndp+Bm
+TAV5PBxEKrPsiXyIudIv0q7OoeSTQasU/9Ru5k2As5CLDa2JHj7sE1gohVbvVpz
Sy4GWTnfbFU++1ye5c9OQbpA1oeGfmyj5zl8AMr6aUDxaHqUhVOmv+WROH/OIgjf
9/iORt5+QcZl3BlE90mAh8KkWSemomZPWoojA5v2ITusuG1VMBMLOzHUCBl5CCU=
=Bq+T
-----END PGP SIGNATURE-----

[Teo (teo1978)]

> No, it does not. Installing grub to the wrong place because you
> manually chose it is not a bug.

Who talked about manually choosing?

[Teo (teo1978)]

> "Never happen no matter what" is asking for a magic wand and unicorns.

"No matter what" was a sloppy phrasing, agreed. I should have said "whenever it can be avoided". No need for magic wand or unicorns, just a few checks.
And here it definitlely can be avoided at least to some extend, while absolutely nothing is done to even attempt to avoid that.

> There are some things we can control, and some we can not.

And here, there are definitely things that can, and hence should, be controlled, and that are not being controlled, hence a bug.
Note that I'm always talking about Ubuntu as a whole; which part of it is responsible for doing right what is being done wrong, I don't know. It may be Grub, it may be the Grub packaging in Ubuntu, or it may be some other part of ubuntu.

Ubuntu is miserably failing to provide an easy or at least reliable way to install it in dual-boot on a system that has another OS, namely Windows 8. Following the instructions that are given during installations fails. Following the instructions that are given in the official docs fails. You're left alone either tinkering or using third party repair tools. And when you do and get it to work, a system upgrade on a machine that works breaks it. That's simply not an acceptable UX.
That's my experience. Other users have reported doing a bare fresh zero-tinkering install immediately resulting in a broken system, or doing a bare fresh zero-tinkering install which resulted in a working system which broke at some later dist-upgrade. That's something that should never happen, and here I really can say "no matter what".

Comments 55, 91, 137 report cases where absolutely no manual installation or third party tools were ever used.

[cogset (jackfog66)]

On 11/01/2014 06:20 AM, Teo wrote:
> Which confirms there's a bug somewhere.

No, it does not. Installing grub to the wrong place because you
manually chose it is not a bug. Installing grub to /dev/sda by
default when your computer actually boots from another drive is also
not a bug, because unfortunately, there simply is no way to detect
which drive the computer boots from due to the limitations of the pc
bios. If grub outright failed to install, then there *may* be a bug.
 The installer automatically files a bug report when this happens so
it can be investigated.

Did you have a look at this other bug https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1311247 ?
There has to be something wrong in Ubuntu 14.04 concerning grub,because in some fresh installations,after everything has finished normally and the OS has been apparently installed without errors,then the system simply won't boot at all,period.
The workaround has been installing grub to a dedicated boot partition,something I wouldn't call a normal installation procedure:I've never had to do that with any other Linux system so far,including previous Ubuntu releases.

[M. Sussman (mmsussman)]

Here is some information that might shed some light on the problem.
I am running Linux in a virtual machine (VM) using VirtualBox. I have a working 13.10 VM that boots using /boot on /sda1, and a number of other disks that are tied together using LVM. The /root, /home, etc. directories are all in the LVM. Linux is the only operating system. I took a tar copy of all the files associated with the 13.10 VM. Then:
1. I tried to upgrade to 14.04. The upgrade seemed to succeed, but would not boot with the dreaded grub_term_highlight_color missing message.
2. I took a tar copy of the VM with the failed upgrade. I still have this copy.
3. I used tar to restore the 13.10 VM
4. I used the recommended "sudo dpkg-reconfigure grub-pc" command. The message informed me that the disk that grub was originally installed to was no longer present. I believe this message is true. It also presented me with a list of disks to install grub to. There was no default chosen for me (I expected to find /dev/sda as default). If I hit OK without choosing a disk, it warned me that grub would not be installed. I went back to the list, chose /dev/sda and hit OK. It then did its job with "No error reported."
5. I then did the upgrade to 14.04. The upgraded system booted normally. SUCCESS!

My conclusion is that the upgrade process on my original system NEVER INSTALLED GRUB at all! When it did the equivalent of the dpkg-reconfigure grub-pc, it found that the original disk grub was installed to was missing (true) but then decided NOT to install grub anywhere. In comment 268, Philip Susi indicated this might be a bug, and I agree it is a bug in my situation.

I suggest that, at the end of the upgrade process, when the upgrader asks whether or not to remove obsolete packages, it should also warn the user that grub was never installed and give the user another chance to install it.

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/1/2014 11:13 AM, cogset wrote:
> Did you have a look at this other bug
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1311247 ?

You seem to have linked the wrong bug because that one doesn't say
anything at all like that.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUV5E0AAoJEI5FoCIzSKrwOlMH/0HdYji+dZpO1MW+HvLQOYTu
sA+MOG9phZ3MGBUj2Bp6tcc3dt0PRRNNx1DnJFDUWCZlfX/2awDy+fctHMyM0Cuo
qR8MpMyogMV/qDWg0suWr5vTT8wbimAn82TjQ1KJjBQRpOavfnOfONW14VdFjWic
37JQKnb7j9U1lN+R6VppwBqWoQwBLjhryIM4FE0p7Ejg/gddJ+zt94Rjp5Qvobdp
pf964ebBD/8+uGVAK3wORD9c4vhC6LOJ5rpNIE/TA4hMLkQ6Vn38rDUixMAxF6ls
miw6SfQ7GDL/t9yV187e0BcL5fTQPAy4O8FaeqQoBe9KDfd4447YxLWw7u9dVeY=
=EmpD
-----END PGP SIGNATURE-----

[M. Sussman (mmsussman)]

I guess I did not make myself clear in #272. When the upgrade to 14.04 from 13.10 failed the first time, the message I got on attempted boot was, "error: symbol 'grub_term_highlight_color' not found". That points to this bug. Bug 1311247 does not give that error.

[cogset (jackfog66)]

Sorry,the bug I've linked is about grub either breaking after an update to 14.04 (for some people) or not working right after a clean install of 14.04 (for some other folks,including me):I somehow assumed that it could be related to this one,although the error message is different.

[Zebulon (schalkbox)]

I just install Ubuntu 14.04.1 on a partition that previously had Ubuntu 13.10 on it. Now I can't access Windows or Ubuntu. All I get is the grub_term_highlight_color missing message. What should I do now?

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/25/2014 4:21 AM, Zebulon wrote:
> I just install Ubuntu 14.04.1 on a partition that previously had
> Ubuntu 13.10 on it. Now I can't access Windows or Ubuntu. All I get
> is the grub_term_highlight_color missing message. What should I do
> now?

You should file a new bug report and attach the files in
/var/log/installer from your hard drive.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUdLSkAAoJEI5FoCIzSKrwaIoIAJZf7MRIvrT1dXyWTfnB/a3g
In5AwXX2Qb5Rt0cHP7HKM0LWkGB71nWcdvpp6LHHgie55YpZwX7nWkVRMAdrphtL
fdSx8GziTLhYyHFcGpAXaBz4a2Z+1UfJVhG4NBXa6Wx65QSJRPOf6ZrWyikziRce
uDMioZarq75Phb79G1yR9wJupVQfqbyyOAGgmgJ7mSHCnvyNR5MECKQeu3ly65V0
NCe2hBFK10fp/Ct1ufTbkIawnR3Icc1iyW0gMfdPtz2i2l0cotv8nULosoeBLRuZ
7uE9fmTJrS1IP3VaFTMlvcZpfZ/smVzmBe5LOTQgi0iXZKUSN8WWurlDxrcuAkw=
=4vIu
-----END PGP SIGNATURE-----

[Teo (teo1978)]

So, I'm getting tired of always unchecking Grub from automatic updates just to be sure that my system won't break again at the next reboot, and I would also like to upgrade to Ubuntu 14.10, which I have been delaying so far for the same reason (and then, 15.04 must be almost out). As a remainder: I was one of the people whose working dual boot system was screwed up when upgrading from 13.10 to 14.04 (because of a "misconfigured system" according to Phillip Susi, which I doubt, but if it is the case, it was misconfigured because of some bug in the first place)

So, is this what I need to do in order to prevent my computer from being bricked again by an upgrade?
> dpkg-reconfigure grub-pc
Will this ensure that updating grub and upgrading to 14.10 won't screw things up again?

And then I guess that will ask me for some parameters, or to choose something. If so, what command should I run to figure out what my current perfectly working configuration of grub is and make sure it is preserved, and/or to figure out the correct answer to whatever dpkg-reconfigure prompts may show up?

[Phillip Susi (psusi)]

dpkg-reconfigure asks you which drive or drives you want grub to be installed to ( and reinstalled to during future upgrades ). If you only have one drive then the choice is simple. If you have more than one, then generally sda is the one your system boots from, but if you have reconfigured your bios to boot from another drive, then that is the drive you should use. If in doubt, it doesn't hurt anything to just install it to all of your drives.

[Stanislav German-Evtushenko (giner)]

This is a bug and easily reproducible:
1. Install Ubuntu 10.04 server
2. Upgrade to 12.04 server (reboot is okay)
3. Upgrade to 14.04 server (reboot fails with grub error)

We've had this issue for all systems which was upgraded from 10.04. Here is a work around which worked for us:
1. Install Ubuntu 10.04 server
2. Upgrade to 12.04 server (reboot is okay)
3. Upgrade to 14.04 server (do not reboot ! )
4. grub-install /dev/sda (reboot is okay)

[Dennis Olsson (cyberdo)]

Stanislav German-Evtushenko (giner): Actually, DO NOT DO #4, instead do (as suggested above):

# dpkg-reconfigure grub-pc

Choose sda to match your list above (or others or all drives if you want grub everywhere). This way it's safe(r) in case of future updates.

This will invoke the command "grub-install /dev/sda" automatically then and every time needed. The problem seems to be that this was not stored in config "back in the day".

[Coran (coranh)]

I've encountered the same problem. Is this an issue that won't be fixed?
I thought I had a pretty normal setup. Dual boot windows 7 and Ubuntu. Installed Windows first, then Ubuntu, used all default/recommended settings. Now left with a totally trashed bootloader for both OSes, and wasted best part of a day trying to fix it. Now resorting to reinstalling both OS. In future, a bright red warning, something along the lines of "Updating Grub may render your computer unbootable" would be handy, so its clear that unticking the Grub package upgrade might be a good idea.

Since I'm now reinstalling my entire system, what is a "normal" setup? Ie what setup will survive future Grub updates? Baring in mind I'm dual booting with windows, both on same HD.

[Gerald Krottendorfer (gerald-krottendorfer)]

Same Problem here....
My workarounf was to enter the startup mode by pressing F12 (Dell Inspirion) and boot from there. If not, I would see the "error: symbol 'grub_term_highlight_color" message from grub-rescue.
After a next update, instead of grub-rescue, I could only hear annoying beep sounds, occurring every 2 seconds (lasting for infinite time). I still was able to use the EFI-BIOS boot options to restart.
However, after my latest update, even the F12 Option to enter EFI Bios has been lost. All I got where the Beep's.

After several tries (pressing the on / of button several times, until F12 is displayed) , I may reach the boot menu.
I tried to redo the boot order with efibootmgr --- no success.
After the next startup, the boot order has been overwritten.

I tried Boot-repair --- no success.

Any idea what to do next?

Thank you in advance,
Gerald

[Gerald Krottendorfer (gerald-krottendorfer)]

Sorry, I forgot to mention: I am on an UEFI System.

-----------------------------------------------
sudo efibootmgr -v

BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0006,0000,2001
Boot0000* Ubuntu HD(2,800,fa000,7f78ccae-b336-4d04-8c9f-ef1151bf4bb0)File(\EFI\ubuntu\grubx64.efi)RC
Boot0001* UEFI Onboard LAN IPv4 ACPI(a0341d0,0)PCI(1c,0)PCI(0,0)MAC(74867a16a862,0)IPv4(0.0.0.0:0<->0.0.0.0:0,0, 0RC
Boot0002* UEFI Onboard LAN IPv6 ACPI(a0341d0,0)PCI(1c,0)PCI(0,0)MAC(74867a16a862,0)030d3c000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000RC
Boot0003* UEFI DVD1 PATH1 (HL-DT-ST DVD+-RW GT80N) ACPI(a0341d0,0)PCI(1f,2)03120a00020000000000CD-ROM(1,44,1680)RC
Boot0006* Windows Boot Manager HD(2,800,fa000,7f78ccae-b336-4d04-8c9f-ef1151bf4bb0)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...8................
Boot2001* EFI USB Device RC

------------------------------------------------------
change bootorder:
sudo efibootmgr -o 0000,2001,0006,0001,0002

==> after reboot, changed to old bootorder...

----------------------------------------------------
ls /boot/efi/EFI
Boot Dell Microsoft ubuntu

After boot-repair most of my grubx64.efi files are up to date:

I could find grubx64.efi files in:
/boot/efi/EFI/ubuntu /grubx64.efi --- date = up to date
/boot/efi/EFI/Boot/grubx64.efi: --- date = up to date
/boot/efi/EFI/Microsoft/Boot --- date = up to date
/boot/efi/EFI/Dell/Boot/grubx64.efi: --- date = Jul 25 2012 = 3 years old version

------------------------------------------------------

Tx,
Gerald

[teo1978 (teo8976)]

@cjwatson a year has passed since you said you had some idea about how to fix this. Any progress on that?

[teo1978 (teo8976)]

I want to try and run dpkg-reconfigure as suggested many times, so that I can finally install grub updates and also upgrade the distribution, without fear to brick my computer again due to this bug. Because it's clear that if I'm going to wait for the bug to be fixed it's going to be forever.

Now, first of all, @psusi et al talked about running "dpkg reconfigure grub-pc", but I don't seem to have grub-pc installed at all.

    $ apt --installed list |grep grub

    grub-common/trusty,now 2.02~beta2-9 amd64 [installed,upgradable to: 2.02~beta2-9ubuntu1.3]
    grub-efi-amd64/trusty,now 2.02~beta2-9 amd64 [installed,upgradable to: 2.02~beta2-9ubuntu1.3]
    grub-efi-amd64-bin/trusty,now 2.02~beta2-9 amd64 [installed,upgradable to: 2.02~beta2-9ubuntu1.3]
    grub-efi-amd64-signed/trusty,now 1.34+2.02~beta2-9 amd64 [installed,upgradable to: 1.34.4+2.02~beta2-9ubuntu1.3]
    grub2-common/trusty,now 2.02~beta2-9 amd64 [installed,upgradable to: 2.02~beta2-9ubuntu1.3]

So what is the exact package name against which I should run dpkg-reconfigure?

Second. I'm trying to figure out where the "good" (updated) copy of grub is installed, and where the "bad" (outdated) one is, because, if I understand correctly, I need to tell dpkg-reconfigure the place where the good one is (or both, as Psusi suggests would be harmless)

I have figured out that /dev/sda9 is mounted as "root filesystem". Am I right in assuming that /boot is a real, physical folder of that partiton?
There I've found a file /boot/grub/x86_64-efi/grub.efi, which contains the string grub_term_highlight_color
So, I guess that's the "bad" version of grub.

I seem to have only one physical harddisk /dev/sda.

So, is this correct: the "bad" copy of grub is installed on /dev/sda9, hence (??) the "good" one is almost certainly in the MBR? Does that mean that when prompted by dpkg-reconfigure, I should choose /dev/sda? (does that mean the MBR of that disk)?

[teo1978 (teo8976)]

Running
  sudo dpkg-reconfigure grub-efi-amd64

this is the first question I get and I am already lost

 │ The following Linux command line was extracted from /etc/default/grub or │
 │ the `kopt' parameter in GRUB Legacy's menu.lst. Please verify that it is │
 │ correct, and modify it if necessary. The command line is allowed to be │
 │ empty. │
 │ │
 │ Linux command line: │
 │ │
 │ <Ok> │

[teo1978 (teo8976)]

And finally it never asked me for the installation disk

[Phillip Susi (psusi)]

@Teo1978, you are using an EFI booting machine, so don't have grub-pc and the dpkg-reconfigure does not apply to you. IIRC, the problem on EFI is that if you have used grub-repair or whatever it was called, it makes a copy grubx64.efi and configures the firmware to boot that instead of the original, then when grub is upgraded, the copy is now stale. You can see which file your system is set to boot with sudo efibootmgr -v, and iirc, the copy was named /boot/efi/EFI/BOOT/Bootx64.efi, and the original is /boot/efi/EFI/Ubuntu/grubx64.efi.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Marcus Tomlinson (marcustomlinson)]

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.