Grub & installing/updating the Linux kernel

[gah789]

I am writing this partly in sadness and partly in irritation. I have just installed Linux Mint to try it out and now I am going to delete it. The problem is simple but apparently persistent in recent versions of Ubuntu and its derivatives. The source of the difficulty is that Grub and gparted cannot agree on parsing the order the hard disks under certain hardware configurations. (In my case it is caused by a Promise SATA controller, both in RAID and IDE mode that is treated as /dev/sda by the partitioner and as hd(2) by Grub.) This is a bug that has been reported many times but never sorted out. The consequence is that it is necessary to edit the menu.lst file used by the Grub boot process but which is created incorrectly by the Ubuntu/Mint installation. Sometimes it is also necessary to edit fstab as well.

That is manageable, but the mess is caused by the fact that Ubuntu and, I have now discovered, Linux Mint insist on rewriting menu.lst whenever they update the kernel. This is done behind the user's back. In the case of Ubuntu there are some other changes which often render the system unusable without significant repairs or reinstallation. In Mint I would have to re-edit menu.lst after every kernel update. Other distributions - eg OpenSuse - deal with this by creating symbolic links for vmlinuz and initrd, which mean that the menu.lst file is never touched.

It should be a cardinal rule that no installation is ever broken by the simple process of updating it. Yet that is exactly what Ubuntu & Linux Mint do. Ubuntu problems are more serious because of the way in which it falls over, but I regard the behaviour of Linux Mint as inexcusable, so it has to go. While I understand the desire to make matters as simple as possible for the majority of users, Linux developers ought to remember that the identification of hardware is far from reliable. If you are going to rely upon Grub as the boot loader, then you must ensure that anything and everything is compatible with it. A further consequence - again from painful experience - of not meeting this requirement is that installations often fail - on a variety of hardware - because the installation program fails to identify the correct location for Grub stages 1 and 1.5.

[Fred]

gah789,

I would have to agree with you about the difficulties with consistent identification of partitions. Actually it gets worse than you said. On some hardware combinations the use of hot plug usb storage devices will cause changes in the partition recognition. This of course can create even more problems.

Where your error occurs is in your assertion that this problem is limited to Ubuntu/Mint. It isn't. There are workarounds that different distros use but none are universal in solving the problem. They only work in some scenarios.

There are two solutions currently used for persistent partition identification. The first is UUID, which many, including Ubuntu/Mint, have chosen to use. This is workable up to a point but is very fragile and and not without problems. The other is LABEL which Red Hat and others use. LABEL is less fragile and more reliable than UUID, in my opinion.

Neither of these solutions is universally workable however. The fly in the ointment is grub. It is being worked on but the current versions of grub in use by the various distros all have the problem of inconsistent ID of partitions with a lot of the new hardware combinations.

I have had the best luck using LABEL throughout, including in the menu.lst. If you use root=LABEL=Root1 ,as an example, and change the options in menu.lst so it is persistent when updated, most of your problems will be solved. I will warn you this is not 100%, as it isn't with any other distro that I am aware of that uses grub.

Fred

[gah789]

Fred

I apologise if I did not make my point clearly. I accept that many other distributions have the same problem with Grub's identification of partitions - my personal experience of this extends to Mandriva & Fedora as well as OpenSuse. Further, you are correct about USB drives, etc.

However, for me the key issue is whether a distribution worsens the problem by rewriting menu.lst and other files without (a) giving a warning, and (b) providing an option to retain the original version, or at least (c) copying the old version of menu.lst into the new version and allow the user to edit the combined version before it is committed to disk. What should be avoided is the situation that I have encountered too frequently over the last 12 months with Ubuntu & Linux Mint by which an upgrade breaks a system that is working.

I have found that UUIDs (in Ubuntu and other distributions) are pretty fragile as you suggest. YAST under OpenSuse consistently gets things wrong for Grub, but at least their upgrades do not usually break a working system. In Ubuntu/Linux Mint part of the problem is caused by frequent changes in the kernel that is used (at least 4 in 6 months for Ubuntu version 8.04) - annoying also because VMware Server and the like have to be recompiled every time - and by reliance on the full version name for vmlinuz, etc for boot purposes.

Finally, you refer to changing the options in menu.lst so that it is persistent when updated. I have not come across an option that would prevent changes being made by an external program that rewrites the file. I would be grateful if you or someone else can provide further details.

G

[Fred]

gah789,

No apology necessary. Yes with frequent kernel updates, any house keeping chores are just multiplied. The only solution I have for you is to not upgrade the kernel except when you have a need to do so. If you need a feature or function that isn't in the old kernel. Just because a new kernel is available doesn't mean you have to upgrade.

As far as the menu.lst is concerned I have listed the parts below that you can change that will make your choice for the root label persistent. The changes from the original are in bold for emphasis only. If you aren't familiar with how to set labels on your partitions or modify your /etc/fstab file, you can search the forum for "Fred LABEL." I have a number of posts on the subject in different contexts. The Root1 label I am using below is just an example name. A label can consist of up to 15 characters. I would suggest letters and numbers only, no spaces. Some characters can get you in trouble in other contexts. The names are case sensitive.

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## 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=LABEL=Root1 ro

and

## ## End Default Options ##

title Linux Mint, kernel 2.6.24-19-generic
root (hd0,0)
kernel /boot/vmlinuz-2.6.24-19-generic root=LABEL=Root1 ro quiet splash
initrd /boot/initrd.img-2.6.24-19-generic

title Linux Mint, kernel 2.6.24-19-generic (recovery mode)
root (hd0,0)
kernel /boot/vmlinuz-2.6.24-19-generic root=LABEL=Root1 ro single
initrd /boot/initrd.img-2.6.24-19-generic

title Linux Mint, kernel memtest86+
root (hd0,0)
kernel /boot/memtest86+.bin

### END DEBIAN AUTOMAGIC KERNELS LIST

The changes above won't solve all your problems but it help considerably.

Fred

[Fred]

groot should already be set by default in Mint to the proper value. If it is not then yes, this should be done also.

Fred