Unable to boot Ubuntu server after update/upgrade

Bug #321603 reported by _sAm_
6
Affects Status Importance Assigned to Milestone
Ubuntu
Invalid
Undecided
Unassigned

Bug Description

OS: Ubuntu 8.04.1 Server

I updated the server with via ssh using sudo aptitude update && sudo aptitude safe-upgrade

Aptitude updated the server kernel from "2.6.24 -19 server" too "2.6.24-21 server". After the update/upgrade the server could not boot, and the error message "Grub error 17" was given.

Please notice that I have _not_ deleted any partitions, I have not changed menu.lst myself before this happend, there is no other OS on the PC, and I have not changed the sata connections at all.

To fix the problem I used a livecd and wrote this in a terminal:
sudo grub
find /boot/grub/stage1 The answer I got was: (hd3,1)
root (hd3,1)
setup (hd3) The answer I got was: /boot/grub/menu.lst Succeeded
quit

After rebooting the PC I got an new error: Error 22 No Such partition
Every kernels I tried from the menu.lst ended up with the same error.

Here is some information about the system(from running a livecd):
ubuntu@ubuntu:~$ sudo fdisk -l

Disk /dev/sda: 400.0 GB, 400088457216 bytes
255 heads, 63 sectors/track, 48641 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00018dcc

   Device Boot Start End Blocks Id System
/dev/sda1 1 48641 390708801 83 Linux

Disk /dev/sdb: 400.0 GB, 400088457216 bytes
255 heads, 63 sectors/track, 48641 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0330391b

   Device Boot Start End Blocks Id System
/dev/sdb1 1 48641 390708801 83 Linux

Disk /dev/sdc: 400.0 GB, 400088457216 bytes
255 heads, 63 sectors/track, 48641 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x4bfbc829

   Device Boot Start End Blocks Id System
/dev/sdc1 1 48641 390708801 83 Linux

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000e4f3e

   Device Boot Start End Blocks Id System
/dev/sdd1 1 243 1951866 82 Linux swap / Solaris
/dev/sdd2 * 244 1216 7815622+ 83 Linux
/dev/sdd3 1217 10966 78316875 83 Linux
/dev/sdd4 10967 121601 888675637+ 83 Linux

----------------------------- END
/ is stored on /dev/sdd2
/home i stored on /dev/sdd3

/dev/sdd4 is one LVM
The hard drives called /dev/sda1, /dev/sdb1 and /dev/sdc1 is one LVM.

Using the livecd I mounted / and opend /boot/grub/menu.lst, here you can see it:
title Ubuntu 8.04.1, kernel 2.6.24-21-server
root (hd0,1)
kernel /boot/vmlinuz-2.6.24-21-server root=UUID=569a949a-ff24-4e22-a095-bac416fadf60 ro quiet splash
initrd /boot/initrd.img-2.6.24-21-server
quiet

title Ubuntu 8.04.1, kernel 2.6.24-21-server (recovery mode)
root (hd0,1)
kernel /boot/vmlinuz-2.6.24-21-server root=UUID=569a949a-ff24-4e22-a095-bac416fadf60 ro single
initrd /boot/initrd.img-2.6.24-21-server

title Ubuntu 8.04.1, kernel 2.6.24-19-server
root (hd0,1)
kernel /boot/vmlinuz-2.6.24-19-server root=UUID=569a949a-ff24-4e22-a095-bac416fadf60 ro quiet splash
initrd /boot/initrd.img-2.6.24-19-server
quiet

title Ubuntu 8.04.1, kernel 2.6.24-19-server (recovery mode)
root (hd0,1)
kernel /boot/vmlinuz-2.6.24-19-server root=UUID=569a949a-ff24-4e22-a095-bac416fadf60 ro single
initrd /boot/initrd.img-2.6.24-19-server

title Ubuntu 8.04.1, memtest86+
root (hd0,1)
kernel /boot/memtest86+.bin
quiet

To fix the problem I changed manually every (hd0,1) too (hd3,1) in /boot/grub/menu.lst, and now the system works again.

Please ask if you want more information, and thank you for your time.

Revision history for this message
Paul Boddie (paul-boddie) wrote :

This bug seems to be similar to my own experiences, so I'm adding this comment to it.

After having my system upgraded yesterday (2009-01-30) using the package linux-image-2.6.22-16-generic_2.6.22-16.61_i386.deb, I found today that it was impossible to boot my computer. Upon selecting any entry in my grub boot menu, I got "Error 15: File not found".

I looked at the commands in the grub command editor (by pressing E in the boot menu screen) and saw that the "root" definition was incorrect and the "UUID" for the "kernel" definition was also incorrect. These are the definitions I saw:

root (hd0,5)
kernel /boot/vmlinuz-2.6.22-16-generic root=UUID=20ae8580-c8c7-4c16-a436-181b9e38a3a7 ro quiet splash
initrd /boot/initrd.img-2.6.22-16-generic

I worked around this by setting "root" to "(hd0,0)" and by replacing the "UUID=..." with "/dev/sda1", removing the "quiet" and "splash" options so that I could actually see what happens, rather than seeing the Kubuntu progress bar and then seeing absolutely no detail when switching to text mode.

Upon looking at /boot/grub, I saw that menu.lst and menu.lst~ were both updated yesterday and both were the same, so the update didn't preserve the old contents of menu.lst. I have now changed the contents of menu.lst back to what it was before.

I have recently switched hard disks in my computer, and the layout of the partitions is different to those on my previous disk (which did use "(hd0,5)" as the root partition, along with the "UUID" shown above). However, I made sure to change menu.lst to use the new, correct values, and I had successfully booted several times before this error occurred today.

It might be the case that some other file is used to retain details of the root partition and that the update scripts populate menu.lst with values from this other file, but it is very bad that the scripts just discard any existing copy of menu.lst, making an identical duplicate of the new, incorrect file, and if such special files with disk information then these should be documented somewhere.

Revision history for this message
Paul Boddie (paul-boddie) wrote :

Of course, the last part of my comment should read, "if such special files with disk information *exist* then these should be documented somewhere."

Revision history for this message
Obrouni (nick-fisk) wrote :

I believe the problem you are experiencing is that you have not updated the Automagic Kernels List in the grub config. Every time your kernel gets updated, it uses these settings to re-generate your list of kernels.

If you edit the Automagic Kernels List which is Located just above the list of kernels, it should solve your problem.

Note the list is meant to be hashed out, in that section double hashes form comments.

Revision history for this message
Paul Boddie (paul-boddie) wrote :

In my grub menu.lst file, the following line appears at the end of the file:

### END DEBIAN AUTOMAGIC KERNELS LIST

Thus all the title, root, kernel, initrd definitions appear above this comment. I looked at some old menu.lst files, and some of those do have definitions between the above comment and the end of the file, as well as definitions which are presumably within the "AUTOMAGIC KERNELS LIST" section.

What I am trying to discover is how (and why) the UUIDs were changed, and what I can do to avoid this happening again.

Revision history for this message
Obrouni (nick-fisk) wrote :

If you can attach your entire menu.lst we can probably see what has happened.

I'm guessing when you moved your disk from your old pc to the new one and changed the kernel entries, you didn't update the automagic bit, or it has gone missing some how.

I am then guessing a kernel update was installed which triggered a regeneration of the menu.lst and made it incorrect (although correct for your old pc)

Revision history for this message
Paul Boddie (paul-boddie) wrote :

Attached is my menu.lst file. Here is what I did:

1. I installed a new disk in my computer alongside my old disk.
2. I partitioned the new disk and formatted the partitions.
3. I mounted the new disk's partitions and copied files into them.
4. I edited the fstab on the new disk's root partition so that the UUIDs as reported by vol_id were correct.
5. I edited the menu.lst on the new disk to use the new disk's UUIDs.
6. I edited device.map, ran grub-install, and then restored device.map (since grub won't install on the new disk otherwise).
7. I then powered off, removed my old disk and made my new disk the primary disk.

After doing all this, I booted and was able to work normally until a kernel upgrade came along a few days later. I had powered off and on several times during this period.

The structure of my menu.lst file has remained the same throughout the switch from my old disk to my new disk, as far as I am aware, but I obviously changed the UUIDs as described above. I don't understand why the kernel upgrade overwrote menu.lst with old UUIDs which were no longer in the file.

It's possible I did something wrong. If so, the right way of doing an upgrade like this should be documented. I used the "how to" document here (using discretion and prior experience where LILO was mentioned instead of grub):

http://www.storm.ca/~yan/Hard-Disk-Upgrade.html

Revision history for this message
Obrouni (nick-fisk) wrote :

Hmmmm, everything looks good as far as I can see.

These two lines:-

# kopt=root=UUID=118bcea1-999a-4e47-a192-2cc5fb2982be ro

# groot=(hd0,0)

Are the ones that determine how grub will recreate the menu.lst when needed. You shouldn't run into this problem again and the menu.lst should stay the same.

Could you try running:-
sudo update-grub

Which will update your grub file like if you have just installed a new kernel. Check the menu.lst afterwards, if it all looks good then I think your problem is solved.

Revision history for this message
Paul Boddie (paul-boddie) wrote :

OK, I ran update-grub and it appears that no changes were made, so I suppose that the configuration is stable.

Thanks for the help and information!

Revision history for this message
blu Jay (gordon-hammond) wrote :

We are closing this bug report because it has not been updated for some time. Please reopen it if you have more information to submit, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in ubuntu:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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