Grub(s), Multibooting, and Lilo is not a good mix

[bosco]

This will probably never be an issue for anyone else, but I could not repair my bootloader in a conventional manner today.

I was using Salix with grub2 multibooting, Salix, Debian, Xunbutu, and WIndows 7.

I have not used Xubuntu in a while, and it wanted to do a dist upgrade which I allowed. I was not happy with the results. I decided I wanted a KDE distro and installed PClinuxOS in its place. There was no option to not install Grub, so PClinuxOS installed Grub legacy. The install left me with Debian and PClinuxOS only for boot choices.

I used the Salix memory stick option to boot into Salix, installed Lilo hoping to have Lilo clear out the grub issue and give me Salix and Windows 7 as boot options, intending re-install Grub2 afterwords. Lilo apparently can not overwrite a Grub legacy loader. I was left with no boot loader at all. A reboot from my Salix memory stick gave me a Salix kernal panic.

Re-installing Salix, and grub 2 gave me everything, but PCLinuxOS would not load using either of the two PClinuxOS menu choices.

I am sure something I did or did not do was the issue. Probably the mbr became contaminated from to many writes. I don't know how many multiboot systems are here in the forum, but thought I would mention my experience of mixing grubs and throwing Lilo into the mix.

[gapan]

I know that grub can't fully replace lilo in the MBR, leaving it broken many times. Maybe lilo can't replace grub either, not sure about that. In any case I think the best way to proceed would be removing the previous bootloader completely and then trying to install a new one.

[Shador]

You can simply erase the bootloader section of the MBR with

Code: Select all

dd if=/dev/zero of=/dev/sda bs=440 count=1

But please be very careful with this command!!! Never ever specify a partition (e.g. /dev/sda1) for 'of=', this may lead to data loss.
For reference: http://en.wikipedia.org/wiki/Master_boot_record
As you can see from this page the first 440 bytes are resevered for the bootloader and should be safe to overwrite. The german entry is here way better because 440-444 shouldn't be zeroed out either, but they apparently can be without data loss.
Apart from the MBR grub (both) also stores data in the required post-MBR gap which is usually available for Windows compatibility. (check your fdisk -ul output) On GPT (http://en.wikipedia.org/wiki/GUID_Partition_Table) partitioned disk there's the much better bootloader partition, which allows the bootloader to store data more reliably.

However, I recommend whenever you install a new system avoid by all means installing their bootloader. Generating a configuration file can be useful though because grub2 tries to reuse them. So you might want to perform a installation of their bootloader though.
After the setup has finished, drop to console (or boot from a livecd) and mount the root partition of the OS whose bootloader you want to keep (e.g. Salix), if applicable the /boot partition too!
Then use chroot to switch to that system (notice you can't chroot to a 64bit system when running a 32bit kernel):

Code: Select all

chroot <mount point>

You are now working from within that system and (to reinstall grub2) use:

Code: Select all

grub-install <your harddisk>

usually grub-install /dev/sda
or when you are on salix and installed grub2 with sg2conf:

Code: Select all

sg2conf -r

I recommend you reboot afterwards to Salix and update your configuration file with 'update-grub' this should usually pick up any new OS and any generated grub.cfg, menu.lst or lilo.conf configuration file.

[bosco]

Thank you for your replies. I had forgotten about the dd command. I used dd last time I found myself in this situation. When I do this again I will follow your suggestion. Thanks again.

[pizux]

i get the same problem with my computer , seem that grub2 don't like my mbr , but grub works , so i forget about grub2 .

[JRD]

For grub2 to work, you first partition must follow the dos standard, i.e. starting at sector 63 (0-based)
You can check it with this command:

Code: Select all

parted /dev/sda 'unit s print'

if your disk device is /dev/sda for example.
If start < 63s on partition number 1, then grub2 will not work.

[Shador]

i get the same problem with my computer , seem that grub2 don't like my mbr , but grub works , so i forget about grub2 .

grub works because it uses blocklists on such layouts. Grub2 should support this feature, too, but I never got it working and it requires --force to be passed to grub-install.
Blocklists are unreliable, because it directly loads the hardcoded blocks containing the data from your boot partition (ignoring the filesystem) and there's no guarantee block positions don't change. The best example is defragmentation, where blocks are moved around the disk and some block loaded by grub possibly gets a new posiition and thus breaks your bootloader.
To circumvent this problem, you either have to install using a post-MBR gap or you reinstall grub everytime a block could have changed (e.g. you defragmented your partition). The second solution is still not save though, as there's no guarantee that the block won't get move for some other reason.
If we could replace that crappy MS-DOS legacy layout with GPT, there wasn't this problem anymore.