[smolloy]

Just as a note for anyone else who might be trying this scheme.

Be careful with Ubuntu updates.

A recent update installed a new kernel, and, during the installation procedure, it over-wrote my menu.lst. Now that was my fault, since it asked me for permission to overwrite it, and I said yes (I'd forgotten that I had my own version of it), so on next reboot I was back on my old /dev/sda3 version of Ubuntu. Lucky I'd left that partition alone!!

Fixing it was easy -- I just had to edit menu.lst again. The kernel installation had made a backup at menu.lst~, so I could copy the relevant entries from there. If I had have wiped the /dev/sdsa3 partition with my original installation on it I would have had to use a liveCD to fix the new menu.lst.

So, if you follow this procedure, be aware that a kernel update can break things!

[Jonathan183]

Interesting ... did the update not retain the old kernel & old kernel boot options to allow you to boot with the old kernel & fix things that way? and did the kernel update put the new kernel in the right place?

[smolloy]

Since I did the update on my regular installation, it installed the kernel on my logical volume (just as it should), but it overwrote menu.lst and used the wrong root location. For some reason it "remembered" my original root location (which I hadn't deleted yet), and so tried to boot from there. Since the new kernel wasn't there, booting crashed.

On the next reboot, I chose the old kernel from the grub menu, and it booted properly -- but it booted to my old root partition. Once I figured that out, I edited menu.lst to point to the right place, and rebooted with the new kernel.

The lesson here is to pay attention to any questions the update manager asks you, and not just click OK because you're in a rush to get to bed and couldn't be bothered thinking about the question!

[bigtomrodney]

I'm really sorry I'm only seeing this thread, this is pretty interesting stuff. Tell me, when you copied your system over did you just use cp or did you go the tar or rsync route to preserve permissions? Or was it the case because root owned everything anyway that it didn't matter?

I had some fun migrating to LVM a year or so back and then again when installing Ubuntu as the livecd didn't support LVM.

[Jonathan183]

Originally Posted by smolloy

Since I did the update on my regular installation, it installed the kernel on my logical volume (just as it should), but it overwrote menu.lst and used the wrong root location. For some reason it "remembered" my original root location (which I hadn't deleted yet), and so tried to boot from there. Since the new kernel wasn't there, booting crashed.

On the next reboot, I chose the old kernel from the grub menu, and it booted properly -- but it booted to my old root partition. Once I figured that out, I edited menu.lst to point to the right place, and rebooted with the new kernel.

The lesson here is to pay attention to any questions the update manager asks you, and not just click OK because you're in a rush to get to bed and couldn't be bothered thinking about the question!

I just did the update myself ... it did not prompt me ... it just wrote the new menu.lst. I think the case for the defense is that the options it updated are in a section with just the Ubuntu entries ... starts with

## ## End Default Options ##
... and ends with ...
### END DEBIAN AUTOMAGIC KERNELS LIST

# This is a divider, added to separate ...

Originally Posted by bigtomrodney

Tell me, when you copied your system over did you just use cp or did you go the tar or rsync route to preserve permissions? Or was it the case because root owned everything anyway that it didn't matter?

If the first post in the thread is correct then cp -upr was used so I think permissions should have been preserved.

It looks as though anything in the grub menu.lst section is seen as fair game. Something I will keep in mind for future.

[smolloy]

Originally Posted by Jonathan183

I just did the update myself ... it did not prompt me ... it just wrote the new menu.lst. I think the case for the defense is that the options it updated are in a section with just the Ubuntu entries ... starts with

## ## End Default Options ##
... and ends with ...
### END DEBIAN AUTOMAGIC KERNELS LIST

# This is a divider, added to separate ...

So perhaps if I add my new options after the "DEBIAN AUTOMAGIC KERNELS" line it will be preserved on the next update?

Tell me, when you copied your system over did you just use cp or did you go the tar or rsync route to preserve permissions? Or was it the case because root owned everything anyway that it didn't matter?

As Jonathan183 said I used cp -pr as root from a liveCD. Seems like that was enough to adequately preserve permissions.

[Jonathan183]

It looks as though when you do an update to the kernel a script

/usr/sbin/update-grub

is called, don't ask how long it took to track this down instead of reading it in the menu.lst file comments!

This script will create a new menu.lst file from a template it has in the script if menu.lst does not exist. It will also replace the menu.lst files and wait for it ...

# Make sure we use the standard sorting order
LC_COLLATE=C
# Magic markers we use
start="### BEGIN AUTOMAGIC KERNELS LIST"
end="### END DEBIAN AUTOMAGIC KERNELS LIST"

startopt="## ## Start Default Options ##"
endopt="## ## End Default Options ##"

Grab a cup of coffee cos this script with comments is 1452 lines long:drown:. The script uses the war & peace in the menu.lst file comments to determine how it updates the file, extracts and replaces relevant parts etc. I think the old root was identified because you will have kopt set to it in the menu.lst file ... something like this

## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
##      kopt_2_6_8=root=/dev/hdc1 ro
##      kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=UUID=929c7eed-350b-4b3a-9c32-3c666480366e ro 

... I started working through the script ... looked back at the grub menu.lst file and the penny dropped by the way the magic marker lines are at about line 470 in the script.

[smolloy]

Wow! Great work Jonathan183!! Have a banana

That is indeed quite a long script. I really like the idea that it hides the setup code in the menu.lst comments -- quite ingenious! It looks like all I have to do is change kopt to point at the right drive, and everything will be fine on the next update.

Thanks again!

[Jonathan183]

I had one of those moments ... I just had to know how the dam thing worked. From my brief look at the code it seems to be expecting uuid references so I was going to go back and look at partitions I've resized and put the corrected uuid in menu.lst