#Don't change this comment - YaST2 identifier: Original name: none#
title Ubuntu 10.04 booting via symlinks
kernel (hd0,6)/vmlinuz root=/dev/disk/by-id/ata-ST9500325AS_6VE3ZHX6-part7 ro quiet splash
initrd (hd0,6)/initrd.img
for Ubuntu for some time. Can this symlinks-booting technique (with the appropriate partition numbers/names) be used for LinuxMint and/or Fedora ?
Currently, I have one PC with Ubuntu’s GRUB2 managing multiple distros (openSUSE 11.3 and 11.4, Ubuntu, Linux Mint and Fedora) with Windows 7. I would like to replace it with the openSUSE GRUB, and the Ubuntu, LinuxMint and Fedora are rarely used.
The above is exactly the technique needed. I have used Ubuntu’s GRUB2 on this PC for the exact techniques embodied in the above: updates to multiple distros without resorting to the symlinks technique. Since this machine is an Arrandale (Intel i5) with Ironlake (Intel GMA HD) graphics, it was important that the GRUB mechanism worked flawlessly. My earliest attempts with 11.3 Grub were not completely successful.
If I understand the procedure(s) outlined in the link, I must first download and install the updategrub procedure, write the openSUSE GRUB over the Ubuntu GRUB2, then run the updategrub. As a fallback, I have in place the procedures to rebuild the Ubuntu GRUB2, using the Ubuntu LiveCD and the grub-pc technique.
Has this technique been used with Windows 7 ? I am not doubting, as I have recovered Windows 7 booting.
I tried to describe what happens to the Grub menu on the openSUSE side after a kernel update int his post: updategrub for openSUSE Legacy Grub (not update-grub!) (same title as the above but it’s a different post). I posted a workaround. It’s not ideal though. The other solution is to remove everything below the openSUSE Grub entries and run updategrub again.
Yes, if that’s what you want. The order doesn’t matter. You can install openSUSE Grub in MBR, then run updategrub each time you need to refresh the Grub menu, basically after any kernel update. You can also keep Grub2 in MBR and chainload openSUSE Grub installed in a partition bootsector by default using a mininal timeout.
I’m not using Windows. But updategrub uses the same detection tool (os-prober) as its Ubuntu counterpart, so it will more likely find the same OSes.
Installed and tested updategrub. As I expressed earlier, this is exactly the functionality I needed. I had used Ubuntu’s GRUB2 almost solely for the update-grub facility, necessitating extra boots. After converting from GRUB2 to the openSUSE GRUB (aka “legacy”), updategrub provided the necessary entries for multiple distros. I ran updategrub with the “-l” option, and manually entered the suggested entries, as I did not wish to tempt fate twice in the same day. I will be testing the actual in situ update facility on my test box soon.
I did observe one unusual result with Fedora partitions:
Following boot entries could be added to Grub menu:
###Don't change this comment - YaST2 identifier: Original name: linuxmint###
title Linux Mint 9, 2.6.32-25-generic (/dev/sda12)
root (hd0,11)
kernel /boot/vmlinuz-2.6.32-25-generic root=UUID=36293347-78c8-4933-a6f8-3a80042dd61b ro quiet splash
initrd /boot/initrd.img-2.6.32-25-generic
###Don't change this comment - YaST2 identifier: Original name: fedora###
title
root (hd0,13)
kernel /boot/vmlinuz-2.6.35.13-91.fc14.i686 root=/dev/sda14
initrd /boot/initramfs-2.6.35.13-91.fc14.i686.img
###Don't change this comment - YaST2 identifier: Original name: fedora###
title
root (hd0,13)
kernel /boot/vmlinuz-2.6.35.13-92.fc14.i686 root=/dev/sda14
initrd /boot/initramfs-2.6.35.13-92.fc14.i686.img
###Don't change this comment - YaST2 identifier: Original name: suse###
title Desktop -- openSUSE 11.4 - 3.0.0-rc3-3
root (hd0,15)
kernel /boot/vmlinuz-3.0.0-rc3-3-desktop root=/dev/disk/by-id/ata-ST9500325AS_6VE3ZHX6-part16 resume=/dev/disk/by-id/ata-ST9500325AS_6VE3ZHX6-part18 splash=silent quiet showopts vga=0x317
initrd /boot/initrd-3.0.0-rc3-3-desktop
The Fedora partitions are recognized as Fedora (from the “Don’t change …” comments), but the generated entry is absent a title entry. This is not a serious problem, and I manually entered “Fedora”.
My compliments on updategrub.
(Note on the original post: using the symlinks facility does work satisfactorily with LinuxMint as with Ubuntu. The technique appears to work with Debian-based distros (see Multiboot Ubuntu, Debian, Mint and similar with Grub in openSUSE). It does not work with Fedora.)
I use updategrub in both ways with openSUSE and Fedora and don’t have this issue with Fedora entries. But I changed the titles of boot entries in Fedora Grub menu. Maybe that’s why. Could you please post the output of the following command:
linux-boot-prober /dev/sda14
Here’s what I have (my Fedora root partition being sda15) :
As you can see, the third field (separated by a colon) in* linux-boot-prober* output matches the title of the boot entrie in Fedora /boot/grub/grub.conf.
This machine has openSUSE 11.3 and Fedora 14. I don’t have Fedora and openSUSE 11.4 on the same machine yet. As soon as I do, I’ll pay attention and fix the bug if it’s in updategrub. linux-boot-prober is a shell script included in os-prober (I made the package available for openSUSE, it is installed with updategrub as a dependency).
I’m planning to install Fedora 15 when I have a minute (or better two).
The machine in question has openSUSE 11.3 and 11.4, Ubuntu 10.04 LTS 1, LinuxMint 9 (Isadora), Fedora 14 (“Laughlin”) and Windows 7. GRUB is (now) from openSUSE 11.3. I installed Fedora from a lead on resolving the Arrandale/Ironlake “black screen” problem. Of course F14 does not resolve this, so I just test each new F14 kernel. I may install F15 as time is available.
That’s what I suspected. The field which is expected to contain the title of the boot entry is empty. The problem lies in your /boot/grub/grub.conf on Fedora. I bet the kernel line entries ( kernel /boot/vmlinuz-xxxx ) are wrong. I just made a test: if I replace kernel /boot/vmlinuz-… with a kernel which doesn’t exist, I get an empty field as well. I don’t know why your Fedora Grub menu would be inconsistent, but this is probably what’s causing the problem here. At least, that’s how I was able to reproduce it.
I suspect that my Fedora install was set to not update its own grub, as I installed it preventing Fedora from writing the system grub. I shall check this, amend the Fedora bootloader options to write to the root partition. For the nonce, I will manually update the Fedora grub and retest.