I've also been affected by this bug. I'm on a MacBook Pro, dualboot with OS X. There is a single HDD split in several partitions. Kubuntu is installed on /dev/sda3 and boots in BIOS mode from ReFit (Kubuntu cannot boot in EFI mode on this laptop). OS X is on /dev/sda2. The bug appeared after the upgrade from 13.10.
Things I tried that did not help:
- I could not boot into Kubuntu from the grub rescue prompt. Grub displayed errors saying that commands "linux" and "initrd" were unknown. Trying "insmod linux" resulted in the same error "symbol 'grub_term_highlight_color' not found".
- Boot-Repair-Disk did not help. I used the latest standalone image (i.e. I did not install it under Ubuntu Live CD). The repair process failed with an error, here are a couple of logs:
- Running "dpkg-reconfigure grub-pc". I did that after I booted into Kubuntu 14.04 Live CD and created a chroot environment as described in comment #27. The command executed successfully but the problem stayed the same.
- Purging and re-installing "grub*" packages. After purging I made sure to delete /boost/grub with all its contents. I did this from chroot as well.
- Running "grub-install --boot-directory/boot -v -recheck /dev/sda3 --force". Basically, a similar command is executed during grub packages installation, so no surprise here.
What actually helped:
As I mentioned, Kubuntu is installed on /dev/sda3. Grub boot loader was also installed on that partition. I did not install the boot loader to MBR (/dev/sda), and it worked with 13.10. However, after the upgrade and attempts to fix the problem I tried to purge/reinstall grub packages and selected to install the boot manager to MBR (/dev/sda). After that the next boot succeeded.
This may be a result of weird behavior of ReFit as I was convinced it would use the /dev/sda3 boot record. I don't know what boot loader was in MBR before I reinstalled grub that last time.
So my final solution is:
1. Boot in Kubuntu 14.04 Live CD. I had to actually use DVD, my MacBook Pro doesn't boot in BIOS mode from USB sticks.
2. Mount the HDD and create a chroot command prompt as described in comment #27.
3. Purge grub packages: apt-get remove --purge 'grub*'
4. Remove any leftovers: rm -rf /boot/grub
5. Install grub packages: apt-get install grub-pc
6. When it asks where to install the boot loader I chose /dev/sda. It also offered /dev/sda3, I didn't select it this time, but in previous attempts I did try it. Maybe it's safer to install it on all partitions.
7. Reboot.
Bottom line: you have to know or at least guess which boot record is used by your BIOS and/or higher level boot loader, such as ReFit in my case. Otherwise the part of grub in the boot record is out of sync with the installed part in /boot/grub which results in problems like this.
PS: Regarding the bug treatment. It is obvious that it affects a lot of people. Closing it as Invalid is nonsense, the problem exists. Arguably, it may not be an easy one to fix, but you can't pretend it isn't there. I'm sad to say I can't imagine such treatment on MS or Apple part.
I've also been affected by this bug. I'm on a MacBook Pro, dualboot with OS X. There is a single HDD split in several partitions. Kubuntu is installed on /dev/sda3 and boots in BIOS mode from ReFit (Kubuntu cannot boot in EFI mode on this laptop). OS X is on /dev/sda2. The bug appeared after the upgrade from 13.10.
Things I tried that did not help:
- I could not boot into Kubuntu from the grub rescue prompt. Grub displayed errors saying that commands "linux" and "initrd" were unknown. Trying "insmod linux" resulted in the same error "symbol 'grub_term_ highlight_ color' not found".
- Boot-Repair-Disk did not help. I used the latest standalone image (i.e. I did not install it under Ubuntu Live CD). The repair process failed with an error, here are a couple of logs:
http:// paste.ubuntu. com/7457286/ paste.ubuntu. com/7457303/
http://
- Running "dpkg-reconfigure grub-pc". I did that after I booted into Kubuntu 14.04 Live CD and created a chroot environment as described in comment #27. The command executed successfully but the problem stayed the same.
- Purging and re-installing "grub*" packages. After purging I made sure to delete /boost/grub with all its contents. I did this from chroot as well.
- Running "grub-install --boot- directory/ boot -v -recheck /dev/sda3 --force". Basically, a similar command is executed during grub packages installation, so no surprise here.
What actually helped:
As I mentioned, Kubuntu is installed on /dev/sda3. Grub boot loader was also installed on that partition. I did not install the boot loader to MBR (/dev/sda), and it worked with 13.10. However, after the upgrade and attempts to fix the problem I tried to purge/reinstall grub packages and selected to install the boot manager to MBR (/dev/sda). After that the next boot succeeded.
This may be a result of weird behavior of ReFit as I was convinced it would use the /dev/sda3 boot record. I don't know what boot loader was in MBR before I reinstalled grub that last time.
So my final solution is:
1. Boot in Kubuntu 14.04 Live CD. I had to actually use DVD, my MacBook Pro doesn't boot in BIOS mode from USB sticks.
2. Mount the HDD and create a chroot command prompt as described in comment #27.
3. Purge grub packages: apt-get remove --purge 'grub*'
4. Remove any leftovers: rm -rf /boot/grub
5. Install grub packages: apt-get install grub-pc
6. When it asks where to install the boot loader I chose /dev/sda. It also offered /dev/sda3, I didn't select it this time, but in previous attempts I did try it. Maybe it's safer to install it on all partitions.
7. Reboot.
Bottom line: you have to know or at least guess which boot record is used by your BIOS and/or higher level boot loader, such as ReFit in my case. Otherwise the part of grub in the boot record is out of sync with the installed part in /boot/grub which results in problems like this.
PS: Regarding the bug treatment. It is obvious that it affects a lot of people. Closing it as Invalid is nonsense, the problem exists. Arguably, it may not be an easy one to fix, but you can't pretend it isn't there. I'm sad to say I can't imagine such treatment on MS or Apple part.