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

Bug #1289977 reported by Mathias Dietrich on 2014-03-09
712
This bug affects 147 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
High
Unassigned

Bug Description

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)

Mathias Dietrich (theghost) wrote :
summary: Ubuntu 14.04 Update breaks grub, resulting in "error: symbol
- 'grub_term_highlight_color' not found" error
+ 'grub_term_highlight_color' not found"
Peng (pengwg) wrote :

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) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Confirmed
Changed in grub2 (Ubuntu):
importance: Undecided → Critical
Tamás Pénzes (penzes-tamas) wrote :

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) wrote :

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) wrote :

How do I fix it?

Phillip Susi (psusi) wrote :

What does debconf-show grub-pc say?

Mathias Dietrich (theghost) wrote :

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

Phillip Susi (psusi) on 2014-04-05
Changed in grub2 (Ubuntu):
status: Confirmed → Incomplete
Peng (pengwg) wrote :

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) wrote :

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.

Changed in grub2 (Ubuntu):
status: Incomplete → Invalid
Tamás Pénzes (penzes-tamas) wrote :

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

Changed in grub2 (Ubuntu):
status: Invalid → Confirmed
Phillip Susi (psusi) wrote :

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

Changed in grub2 (Ubuntu):
status: Confirmed → Incomplete
Tamás Pénzes (penzes-tamas) wrote :

$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) wrote :

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.

Changed in grub2 (Ubuntu):
importance: Critical → High
Nikon (neck-varentsov) wrote :

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) wrote :

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

Phillip Susi (psusi) on 2014-04-15
Changed in grub2 (Ubuntu):
status: Incomplete → Invalid

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

Changed in grub2 (Ubuntu):
status: Invalid → Confirmed
Gannet (ken20001) wrote :

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) wrote :

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) wrote :

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

Mukil Elango (mukilane) wrote :

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) wrote :

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) wrote :

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.

Changed in grub2 (Ubuntu):
status: Confirmed → Invalid
René (rene-f83) wrote :

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) wrote :

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) wrote :

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) wrote :

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?

Phillip Susi (psusi) wrote :

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.

_dan_ (dan-void) wrote :

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.

Changed in grub2 (Ubuntu):
status: Invalid → New
status: New → Confirmed
Bzzz (da-bzzz) wrote :

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

Phillip Susi (psusi) wrote :

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.

Changed in grub2 (Ubuntu):
status: Confirmed → Invalid

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) wrote :

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.

Swarog (swarogdark) on 2014-04-19
Changed in grub2 (Ubuntu):
status: Invalid → Confirmed
Douglas Fink (doug1654) wrote :

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) wrote :

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) wrote :

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.

Changed in ubuntu-release-upgrader (Ubuntu):
status: New → Confirmed
Phillip Susi (psusi) on 2014-04-21
no longer affects: ubuntu-release-upgrader (Ubuntu)
Phillip Susi (psusi) on 2014-04-21
Changed in grub2 (Ubuntu):
status: Confirmed → Invalid
Changed in grub2 (Ubuntu):
status: Invalid → Confirmed
Phillip Susi (psusi) on 2014-04-21
Changed in grub2 (Ubuntu):
status: Confirmed → Invalid
sjampoo (missreemer) on 2014-04-22
Changed in grub2 (Ubuntu):
status: Invalid → Confirmed
Phillip Susi (psusi) on 2014-04-22
Changed in grub2 (Ubuntu):
status: Confirmed → Invalid
_dan_ (dan-void) on 2014-04-22
Changed in grub2 (Ubuntu):
status: Invalid → Confirmed
Phillip Susi (psusi) on 2014-04-22
Changed in grub2 (Ubuntu):
status: Confirmed → Invalid
Tamale (uictamale) on 2014-04-24
Changed in grub2 (Ubuntu):
status: Invalid → Confirmed
Phillip Susi (psusi) on 2014-04-29
Changed in grub2 (Ubuntu):
status: Confirmed → Incomplete
Changed in ubuntu-release-upgrader (Ubuntu):
status: New → Confirmed
Phillip Susi (psusi) on 2014-04-29
affects: ubuntu-release-upgrader → ubuntu-release-upgrader (Ubuntu)
no longer affects: ubuntu-release-upgrader (Ubuntu)
teo1978 (teo8976) on 2014-05-24
Changed in grub2 (Ubuntu):
status: Incomplete → Confirmed
Phillip Susi (psusi) on 2014-05-25
Changed in grub2 (Ubuntu):
status: Confirmed → Opinion
Tamale (uictamale) on 2014-05-26
Changed in grub2 (Ubuntu):
status: Opinion → Confirmed
Phillip Susi (psusi) on 2014-05-26
Changed in grub2 (Ubuntu):
status: Confirmed → Won't Fix
Colin Watson (cjwatson) on 2014-05-29
Changed in grub2 (Ubuntu):
status: Won't Fix → Triaged
201 comments hidden view all 281 comments
DonQuichote (xubuntu-w-p) wrote :

@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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

RJ White (rj-j) wrote :

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.

Download full text (10.2 KiB)

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

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

Phillip Susi (psusi) wrote :

-----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) wrote :

> 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) wrote :

-----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) wrote :

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) wrote :

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.

Mathias Dietrich (theghost) 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...

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) wrote :

@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) wrote :

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

Mathias Dietrich (theghost) wrote :

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) wrote :

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) wrote :

> 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) wrote :

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

Phillip Susi (psusi) wrote :

-----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) wrote :

> 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) wrote :

-----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) wrote :

> 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) wrote :

> "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) wrote :

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) wrote :

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) wrote :

-----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) wrote :

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) wrote :

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

Phillip Susi (psusi) wrote :

-----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) wrote :

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) wrote :

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)

Dennis Olsson (cyberdo) wrote :

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

Displaying first 40 and last 40 comments. View all 281 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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