Something puzzles me with regard to the grub bootloader.
I have a fairly long partition table that looks like this:
/dev/sda1: Windows C
/dev/sda5: Windows D
/dev/sda6: OpenSuSE 11.2
/dev/sda7: OpenSuSE home
/dev/sda8; Fedora 11
/dev/sda9: Fedora home
/dev/sda10: Mandriva 2009.1
/dev/sda11: Mandriva home
/dev/sda12: free ext3 partition
/dev/sda13: free ext3 partition
/dev/sda14 swap
The last distribution installed was OpenSuSE11.2 and the file menu.lst in its grub directory is the one that ‘rules’ the multiboot. During installation the MBR was chosen as the record to contain the bootloader (which is the default). Except for the swap and the OpenSuSE partitions, which are ext4, all partitions are ext3
Then I tried to install Ubuntu 9.10 on partition /dev/sda12 and its home directory on /dev/sda13. It did not work. No grub was installed on the Ubuntu boot directory and also no initrd was found to be there either. Worse was that after this failure the whole system did not want to boot again from HD but only from a CD or DVD.
I rebooted again with the OpenSuSE 11.2 DVD to inspect the system using the system repair option. This I found:
the MBR was intact (comparing it with a previously saved copy showed no differences)
all partitions were still there
the BIOS was intact with the HD as second boot device
4 intrd and vmlinuz were still in he boot directory of OpenSuSE and both were pointing to the right files
grub was also there and menu.lst was intact
So at first sight the system should boot but, as said, it did not. I could save the day by using the option ‘restore bootloader’ from the OpenSuSE DVD, after which the system booted normally again.
My question is: what damage can a failing Ubuntu installation do to the system that this happens? Does it by accident destroy some part of the bootloader that I do not know about?
Ubuntu uses grub 2 and it’s menu files are different.
If you have decided you want to keep re-install the suse grub, here is how.
If you have a Linux Live CD, boot from it and log in. Then open a console window and enter su and you will be at the command prompt with root powers and ready to proceed. If on the other hand you have the openSUSE install DVD, boot from it and on the first menu of options select the Rescue System option. That will start an elementary Linux Live operating system and bring you to the login prompt. Enter the username root and you will be at the command prompt with root powers and ready to proceed. Whichever way you started (the openSUSE install DVD or a Linux Live CD) when you are at the root command prompt, first you find the partition containing openSUSE’s bootloader. Then you reinstall Grub with a pointer to that partition. First find the openSUSE installation:
You enter this ---------------- grub
Computer returns like this ---- grub>
You enter this ---------------- find /boot/grub/menu.lst
Computer returns like this ---- (hd0,5)
Here, (hd0,5) is Grub’s pointer to my openSUSE installation. Your pointer will be different from my example (hd0,5). Substitute your values for my example (hd0,5). Now that you have the pointer, proceed like this:
You enter this ---------------- root (hd0,5)
Computer returns like this ---- Filesystem type is ext2fs, partition type 0x83
You enter this ---------------- setup (hd0)
You see several lines like this — Checking if /boot/grub/stage1 exists … yes Computer finally returns this-- Succeeded…Done
You enter this ---------------- quit
You enter this ---------------- reboot
Remember the references here (hd0,5) are just examples
At least you know where suse is and there will be other menu.lst refs that show in the ‘find’ because you have fedora and mandriva too.
Does it by accident destroy some part of the bootloader that I do not know about?
It could just ovewrite it if you forget to tell Ubuntu’s setup NOT to install Grub in MBR.
BTW if you managed to install Ubuntu after all, you should rather use Ubuntu’s Grub. You will save time with all your distros, since the version shipped with Ubuntu (Grub2) can update the Grub menus with a single command ( update-grub). So you won’t need to edit Grub menus after other distros kernel updates. It might have some problem with Mandriva’s boot entries, but it’s easy to fix.
Well, I think that the failing Ubuntu installation changed something in the boot or boot/grub directory of the OpenSuSE partition, so that at boot time the system found nothing there it could work with and as a consequence complained that there was no boot device at all. Pity that when fixing things with the OpenSuSE DVD, I forgot to make a snapshot of the boot and boot/grub directory in the OpenSuSE partition to see what was actually there.
What happened was that after all instalation preparations had been made, the moment where the systeem would tell something like “please take out the installation CD and reboot” never came. The system went right to the gnome desktop and in fact behaved as if I had chosen for the Ubuntu CD to act as a live CD in stead of doing an installation on HD. All HD directories were preceded by ‘/target’.
It could just ovewrite it if you forget to tell Ubuntu’s setup NOT to install Grub in MBR.
I normally ask the system to change the MBR and expect that MBR than to point to the boot/grub directory of the distribution that I am installing. But as said, that did not happen.
BTW if you managed to install Ubuntu after all, you should rather use Ubuntu’s Grub. You will save time with all your distros, since the version shipped with Ubuntu (Grub2) can update the Grub menus with a single command ( update-grub). So you won’t need to edit Grub menus after other distros kernel updates. It might have some problem with Mandriva’s boot entries, but it’s easy to fix.
At the moment I have an installation of Ubuntu on partition /dev/sda12 after having copied the missing initrd from the Ubuntu CD to the /boot directory of Ubuntu and adding an entry for Ubuntu in the menu.lst on the OpenSuSE partition.
Suppose I boot into Ubuntu, can I then simply use this update-grub command?
By the way: the problem with Mandriva entries I experiences before. How does one fix them?
There’s a lot to be said for using Generic boot code in MBR, and having the GRUB installs in respective /boot partitions.
I have seen issues with multiple “active” partitions. One possibility is that GRUB installed files in place that was unexpected, for example the extended partition, which might overlap with another spot.
Am planning to do a Kubuntu install for comparison reasons, will make note if it screws up my wonderfully tuned boot process said ironically
Everytime you run update-grub, it scans your harddrives for all Linux kernels (even of not mounted partitions !) and writes boot entries in its menu file, which is /boot/grub/grub.cfg in Grub2 (unlike /boot/grub/menu.lst in legacy Grub). I suspect that it just parses all /boo/grub/menu.lst it can find.
By the way: the problem with Mandriva entries I experiences before. How does one fix them?
Edit Mandriva’s /boot/grub/menu.lst and replace all entries starting with “Kernel (hdx,xx)/boot/vmlinuz …” with “Kernel /boot/vmlinuz …” The root partition is already specified in “root (hdx,xx)”. update-grub converts this entry correctly in Grub2 notation, but not the first one (which is redundant anyway). The consequence is a “file not found” error while trying to boot Mandriva.
This bug may be already fixed in version 1.98. But Ubuntu hasn’t updated 1.97 beta yet.
I used the OpenSuSE DVD with the repair option. I guess it does more or less the same thing as your approach when repairing the bootloader.
Is this an answer to you question?
I’ve just installed Kubuntu-9.10 (carefully) into 2 set aside partitions. The only thing was at one point I had to click on menu called “Advanced” in order to find options to avoid the MBR being over-written, and set to Ubu’s GRUB2 being installed in it’s /boot partition.
Kubuntu install and it has found some “kernels” with it’s osprobe, but it has made a right dogs dinner of it. Firstly I have way more kernels than the few items it has discovered, and secondly the actual boot files are in another partition.
It seems to have found a menu.lst file, or something similar and used that, to import “old” settings.
This is actually a relief, as the “kernel scan” feature as described would make GRUB2 completely unsuitable for development system.
I miss the ‘partition’ command which allows you to rewrite the partition table before booting. Allthough I use Grub2, I have to chainload legacy grub before booting some Unix … (the reason why I do so would be beyond the scope )
Since Grub2 seems to parse all /boot/grub/menu.lst it can find (as far as I’ve observed), it’s quite easy to trick it (for the best and for the worse).
I do occasionaly have some vesa issues after update-grube. It changes the value of the vga parameter to a ridiculously large resolution. I know this parameter is deprecated but still the fastest way to boot in the desired fb vesa mode.
That’s interesting. On the factory list there’s some discussion about boot loaders, and testing GRUB2.
Modular support for things like LVM, and work round of memory restrictions which cause trouble with ReiserFS for example would be desirable.
Have you any useful links which could help inform the discussion? AFAICS any of the proposed alternatives (like syslinux, lilo) are lacking in flexibility and features of GRUB & GRUB2.
Drawbacks to GRUB2 are configuration and difficulties for YaST2 Perl Bootloader
Hmmm, I can imagine that might help with tricking Windows to work round MS annoyance restrictions, but apart from wanting to get round the small libata SCSI imposed limit on number of partitions, I wonder why you would want to do anything so hairy.
Most sysadmins would hate having partition table re-written on every boot!
I wonder why you would want to do anything so hairy.
Most sysadmins would hate having partition table re-written on every boot!
Definitely! I must be the exception.
I do that to change the offset of Unix partitions, in order to share UFS slices between different BSD OS (NetBSD, openBSD, FreeBSD and DragonFly) since they all use a different disklabel (the Unix equivalent of a partition table) : Multi BSD Project
Actually, the good news is that this limit is gone on latest openSUSE and Ubuntu releases. I can see about 35 partitions on each SATA disk an mount all my BSD filesystems. Also The BSD disklabel support in the Linux kernel is much better than it used to be.
)