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

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.

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

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.

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

How do I fix it?

What does debconf-show grub-pc say?

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

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

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.

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...

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

$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

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.

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"

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

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.

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

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.

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.

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

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"

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.

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.

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)

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'

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.

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.

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?

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

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.

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.

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...

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).

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.

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.

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.

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.

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

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.

@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?

-----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-----

> 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.

-----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-----

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.

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.

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...

@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.

-----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-----

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.

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?

> 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?

-----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-----

@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.

-----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-----

> 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").

-----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-----

> No, it does not. Installing grub to the wrong place because you
> manually chose it is not a bug.

Who talked about manually choosing?

> "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.

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.

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.

-----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-----

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.

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.

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?

-----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-----

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?

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.

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)

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".

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.

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

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

@cjwatson a year has passed since you said you had some idea about how to fix this. Any progress on that?

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)?

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> │

And finally it never asked me for the installation disk

@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.

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.

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.