Unable to access non-Ubuntu loaders from GRUB2 menu in Lucid

Not that I have any idea if this is an issue or not, but on those machines, was Windows shut down properly before you installed, or was Windows Hibernated?

I'm not sure, in cases of hibernation in Windows, that the partition is mountable, which may be an issue here. I'll try to recreate this though and see if I can get it to happen.

How exactly did you upgrade? Did you do it via network (do-release-upgrade or Update Manager) or did you do it with one of the ISO images (which one?)

Meh... I should amend that first sentence to say "Not that I have any idea if this is the cause of your issue or not,. . ."

Thanks for your speedy response, Jeff ! As a matter of fact, on both machines, Windows was completely shut down before I upgraded from Karmic to the respective Lucid betas. Both machines have two HDD, on one of which Windows OS, on the other of which Ubuntu is installed. To provide an example, here below the result of running «sudo fdisk -l» on my stationary box :

Disk /dev/sda: 250,1 GB, 250059350016 byte
255 huvuden, 63 sektorer/spår, 30401 cylindrar
Enheter = cylindrar av 16065 · 512 = 8225280 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Diskidentifierare: 0xcab10bee

    Enhet Start Början Slut Block Id System
/dev/sda1 * 1 14744 118431148+ 7 HPFS/NTFS
/dev/sda2 14745 29489 118439212+ 7 HPFS/NTFS
/dev/sda3 29490 30401 7325640 c W95 FAT32 (LBA)

Disk /dev/sdb: 250,1 GB, 250059350016 byte
255 huvuden, 63 sektorer/spår, 30401 cylindrar
Enheter = cylindrar av 16065 · 512 = 8225280 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Diskidentifierare: 0x480be465

    Enhet Start Början Slut Block Id System
/dev/sdb1 * 1 29649 238155561 83 Linux
/dev/sdb2 29650 30401 6040440 5 Utökad
/dev/sdb5 29650 30401 6040408+ 82 Linux växling / Solaris

As can be seen, two Windows OS (Windows 7 and Windows Server 2008) are listed on /dev/sda, but I haven't been able to access them since upgrading to Lucid beta 2....

The problem I describe here is similar, but not identical to that you described in bug #570765 ; it would be interesting to know if anyone else has seen this....

Henri

Same issue here after update from Karmic to Lucid. A FreeDOS partition is also affected.

Unfortunately, this bug remains unassigned. The affected package would seem to be grub2 rather than ubiquity, so I have now changed the bug description accordingly. Hope someone competent will take an interest in this matter as the bug does not seem to affect only my machines ; for my part, however, I should very much like to be able to access the OSs in question....

Henri

To save interested parties from the need to check out the link I provided in my initial posting above, here below /boot/grub/grub.cfg from my main box :

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default="0"
if [ ${prev_saved_entry} ]; then
  set saved_entry=${prev_saved_entry}
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z ${boot_once} ]; then
    saved_entry=${chosen}
    save_env saved_entry
  fi
}

function recordfail {
  set recordfail=1
  if [ -n ${have_grubenv} ]; then if [ -z ${boot_once} ]; then save_env recordfail; fi; fi
}
insmod ext2
set root='(hd1,1)'
search --no-floppy --fs-uuid --set bc560bbd-c79d-4e82-8dbd-677d3ed7af4a
if loadfont /usr/share/grub/unicode.pf2 ; then
  set gfxmode=640x480
  insmod gfxterm
  insmod vbe
  if terminal_output gfxterm ; then true ; else
    # For backward compatibility with versions of terminal.mod that don't
    # understand terminal_output
    terminal gfxterm
  fi
fi
insmod ext2
set root='(hd1,1)'
search --no-floppy --fs-uuid --set bc560bbd-c79d-4e82-8dbd-677d3ed7af4a
set locale_dir=($root)/boot/grub/locale
set lang=sv
insmod gettext
if [ ${recordfail} = 1 ]; then
  set timeout=-1
else
  set timeout=5
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Ubuntu, med Linux 2.6.32-22-generic' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 insmod ext2
 set root='(hd1,1)'
 search --no-floppy --fs-uuid --set bc560bbd-c79d-4e82-8dbd-677d3ed7af4a
 linux /boot/vmlinuz-2.6.32-22-generic root=UUID=bc560bbd-c79d-4e82-8dbd-677d3ed7af4a ro quiet splash
 initrd /boot/initrd.img-2.6.32-22-generic
}
menuentry 'Ubuntu, med Linux 2.6.32-22-generic (återställningsläge)' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 insmod ext2
 set root='(hd1,1)'
 search --no-floppy --fs-uuid --set bc560bbd-c79d-4e82-8dbd-677d3ed7af4a
 echo 'Läser in Linux 2.6.32-22-generic ...'
 linux /boot/vmlinuz-2.6.32-22-generic root=UUID=bc560bbd-c79d-4e82-8dbd-677d3ed7af4a ro single
 echo 'Läser in initial ramdisk ...'
 initrd /boot/initrd.img-2.6.32-22-generic
}
menuentry 'Ubuntu, med Linux 2.6.32-21-generic' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 insmod ext2
 set root='(hd1,1)'
 search --no-floppy --fs-uuid --set bc560bbd-c79d-4e82-8dbd-677d3ed7af4a
 linux /boot/vmlinuz-2.6.32-21-generic root=UUID=bc560bbd-c79d-4e82-8dbd-677d3ed7af4a ro quiet splash
 initrd /boot/initrd.img-2.6.32-21-generic
}
menuentry 'Ubuntu, med Linux 2.6.32-21-generic (återställningsläge)' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 insmod ext2
 set root='(hd1,1)'
 search --no-floppy --fs-uuid --set bc560bbd-c79d-4e82-8dbd-677d3ed7af4a
 echo 'Läser in Linux 2.6.32-21-generic ...'
 linux ...

I agree, there are more and mroe reports on this bug around. For some people there is a workaround by fixing the MBR with testdisk (as decsribed here: http://sourceforge.net/apps/mediawiki/bootinfoscript/index.php?title=Boot_Problems:Boot_Sector). However this does not work for me. BTW I can mount the Windows partition from Lucid and data seem to be fine there.

The issue came up when performing a network upgrade to Lucid LTS from Karmic on May 1st. Lucid runs fine but other OSs won't boot despite being listet in Grub's menu. I therefore agree that it's not bug https://bugs.launchpad.net/bugs/570765.

I also attach my grub.cfg for comparison.

I experienced this same problem, with two harddrives installed (one with windows only and one with ubuntu and some ntfs storage space) after an upgrade to 10.04 through the update manager i could see windows 7 in the grub listing however it would not boot, i got the blinking cursor screen. The workaround linked to by Takkat (see post #7) worked for me as well and I am now able to boot as normal, actually faster than it did before with the grub update now installed and successfully working. Thanks for finding the workaround Takkat!!

Takkat, thank you very much indeed ! The Sourceforge testdisk app did the trick for me on both my Ubuntu computers - when I came to «Boot», I was informed that the «Boot sector» was not identical to the «Backup boot sector». When this anomaly had been corrected and I exited, I found that I could boot into the respective Windows loaders. Wonderful ! Obviously the problem was due to a change in the MBR-sector which in turn had been caused by the upgrade. So even if, with Takkat's kind help, I have now been able to correct the problem, I still deem this a significant bug in need of crunching - users with multi-boot installations who upgrade from Karmic to Lucid should not be faced with this problem ! Hope the GRUB2 developers agree !...

Henri

@Wetson, @Henri: your're welcome.

Unfortunately on my system testdisk says that backup and boot sectors are identical thus refusing to correct the problem. No idea of how this broken MBR found it's way to the backup. I definitely did nothing else before trying testdisk. It seems I need to rebuild the MBR from the Windows Disk now.

As Henri pointed out this bug should be of great concern to the developers. It was always a great difference to Windows that Ubuntu respects other OSs.

Ironic, Takkat, that the procedure you suggested that was so helpful to Westson and myself, didn't suffice to help you ! In any event, we are agreed that this is something which the developers would be advised to look at closely....

Henri

To add to troubles: Fixing the MBR using bootfix from the Windows-CD resulted in a totally corrupted partition table. Too bad as /home was on the same hard disk. Luckily using testdisk I was able to restore the partitions.

However Windows still won't boot from GRUB2.

Hi

I think this has something to do with the bug, I just send in: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/573858

@Maik Messerschmidt:
Thank you for pointing at this. I am not sure if it matters here, because swap is and was always fine and devices were not renamed during the upgrade process.

Hope that all those affected by this bug do indeed click the «This bug affects you» button, so that developers will realise that this bug deserves to be taken seriously....

Henri

As from this thread in the german ubuntu forum:
http://forum.ubuntuusers.de/topic/windows-7-bootet-nach-ubuntu-update-nicht/
there is evidence that this is not really a bug from grub but from the way the installer performs the upgrade.

If Grub2 is already installed on your system:
 * keep the current version of grub rather than choose the maintainer's version.
 * if you manually install Grub take care not to install grub to the Windows partition. In that case Windows will fail to start.

Maybe this issue is related to bug #508173, fixed today

But note, Takkat, that the Sourceforge testdisk app did in fact solve the problem I describe in this thread, whereas it didn't resolve yours. Has the latter now been resolved after the update to GRUB2 (1.98-1ubuntu6) ?...

Henri

@Henri: no my problem is not really solved. It appears that I accidentally installed grub in the Windows partition. This eventually messed up the MBR/Partition block. So far we were unable to restore it indicating that some additional problem exists, maybe unrelated to grub. The Grub update would not be able to do anything as it only affects the way how grub is installed during an update (i.e. not asking when grub resides in one partition only). It's definitely not a bug in grub but rather in the way the installer misleads us to install grub in wrong places.

This problem also affects 32-bit upgrades from Karmic to Lucid (release). The testdisk solution works fine though.

Thanks for posting, mgcarley ! It's a pity that this bug, which certainly affects more than three users (!) has not yet been assigned, and that the problem and its relatively simple solution (for most of us) is not mentioned on the Lucid release-notes page (http://sourceforge.net/apps/mediawiki/bootinfoscript/index.php?title=Boot_Problems:Boot_Sector)....

Henri

My recent report is likely a duplicate of this:

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

I'll also mention that there. I also subscribed to this bug and marked "effects me too", even though it's only effected me as far as having to help dozens of people get things straightened out ;^)

It's something that clearly must be addressed.

If subscribers of this bug would be so kind please mark mine that it effects you too, and also subscribe to it, no comment necessary. I expect the two to be merged at some point soon.

@ M Henri Day, I just realized we've crossed paths before:

http://ubuntuforums.org/showpost.php?p=9020807&postcount=385

I'm kansasnoob on the forums, at that time I'd not yet discovered this:

http://sourceforge.net/apps/mediawiki/bootinfoscript/index.php?title=Boot_Problems:Boot_Sector

Apologies for the idle chit-chat but that confirms how long we've been battling this.

Hopefully this can be addressed immediately after UDS.

Hullo Erick and thanks for posting ! Interesting to see that you also include a Swedish reference ! I'm hoping that enough people will sign off on being affected by this problem so that the developers will take it seriously - if we want, as I do, «every-day users» to consider Ubuntu as an alternative to Windows, we have to make sure that this sort of thing works directly out of the box, without users being forced to work-arounds, even relatively simple ones like the testdisk solution....

Henri

this installer have to take care of the ubuntu partition installation and install grub on it, nowhere else. Cant understand the actual design dropping the newcomers and others too into breakages with this crappy comment: "if you dont known where to install grub, install it everywhere" AWESOME

Agree with you dino99 ; that comment is a doozy ! Helpful to the nth degree !...

Henri

I have the same problem -- the misleading update tricked me into installing grub into the partitions.
This is on a new system that has only windows xp home and a recovery partition.
ultimatebootcd has a utliity called GUJIN which shows you the bootloaders -- both say GRUB
I have tried to boot from a windows XP CD to get into a recovery console to no avail!!!! (windows apparently thinks there is a virus upon seeing GRUB2)
Tried another utility MBRWORK to reset the MBR to normal but GUJIN still reports GRUB for both partitions
Not sure if it doesn't work or Grub2 installs itself more deeply in ways I have yet figured out!!!
I have already also tried the TestDisk program to reverse the damage...in my case it said the backup one was bad and only allowed for REBUILD -- so I tried that..it now reports them as the same -- the same WRONG one
I have no way to even run the recovery partition to reinstall XP and I cannot run XP recovery console .... new systems come without backup disks or installers as well.

This is a MAJOR problem.....yes the updater was apparently talking about disks but it gave a selection for all the existing partitions which was very misleading and ultimately lead to the damage.

Any help is much appreciated. Thanks!!!

by the way I should mention that the XP CD disk upon booting gotos STOP: and gives a location
I do believe it thinks there is a virus due to the odd thing its seeing i.e. 'grub2' and halts
Others have reported being able to use the XP CD disk to boot and repair startup but I have had no such luck

you can see my trials and tribulations over here http://ubuntuforums.org/showthread.php?p=9383155 if interested.

does anyone have any idea how one could manually get rid of the grub2 from the partitions and also what it was doing when it installed grub2 that was so odd.....it kept saying not recommended

also i may add that i used gparted off a bootable cd and deleted the ubuntu/xubuntu partitions and reabsorbed them into the xp partition (no issues) -- i then reinstalled ubuntu on a small 10gig newly created partition and grub installed fine and sees both the windows xp and the vista bootloader (for recovery partition, have no idea why that uses vista to install xp but go figure) -- yet it still won't boot......i have tried the other utilities i mentioned above to repair the MBR but they didn't seem to work out as Gajiin still see's GRUB in each of these....

maybe one could use a disk editor to manually enter the hex code back where it belongs??? thereby overwriting GRUB2 --

i have not used LILO but what if i install ubuntu then download lilo...would it possibly be able to fix what grub damaged by chance??? doubt it but perhaps....

all help appreciated. thanks again

sharing info between forums ----

i finally got a xp w/ recovery console cd to boot...the STOP problem did have to do with the fact that the XP was so old ..what was going on was the controller for the HD was AHCI, i switched that in BIOS to IDE and success the CD booted (apparently able to see the drive in that mode and thus not crashing)...got to recovery command line...used fixboot/fixmbr and got a normal nt-xp loader where grub was on C (win xp drive)

used ultimatebootcd to mbrwork to switch active partition and did the same thing to the vista recovery... cause it still showed GRUB in GujN -- tried bootrec /fixmbr from vista recovery console but that still shows as nt/xp-loader bootrec /fixboot does not see any active installations which is probably correct because this is only a recovery CD so it won't rewrite the loader for vista which I believe must be different than nt-xp loader since vista uses a registry type table to boot and not the ntldr loader -- still learning and reading on this.

there WAS previously a splash screen before GRUB2 did its damage that said press f5 for recovery
i have no idea how this was implemented....still trying to figure it out

in the meantime i have windows XP booted so thats a relief

will still keep hacking away at the rest. thanks everyone very much!!!

does anybody know if you can start anything in VISTA from windows xp? could I set it up as another windows os (the recovery software) in the boot.ini??? it would be a way to get back to default and accomplish the same thing right?

Adding my voice to the grub2 boot issues after installing Lucid.

1. As above, the grub2 install script automatically overwrote the boot sector of sda1 (XP) on install. Had to use Testdisk to restore the backup.

2. It also failed to detect the presence of Puppy in /dev/sda8 by itself. However, it did parse a previous menu.lst on /dev/sda6 which contained a hand crafted entry correctly pointing to Puppy on /dev/sda8, but then reassigned it to /dev/sda6.

Takkat, thanks a million!! I was desperate, you have saved me so much time and trouble! I followed your advice and in 5 minutes everything is back to normal! I can use XP and Ubuntu!
Thank you, thank you!

Dino99, just what does this status change from «Confirmed» to «Incomplete» mean ?...

Henri

It doesn't mean anything.

Well, that was was 5 years ago ....
and that report have lost all meaning