Multibooting live isos with grub2 -- why are fedora/red hat derivatives making things hard?
With the help of linux forums and especially the pendrivelinux.com site (booting linux isos with grub2) I have been able to create a usb drive with over twenty utilities and linux distributions. Recently I was toying with fedora 17/18. Although I can boot fedora live isos 16/17/18 from a usb thumb drive, I have not been successful at setting up fedora so that it is persistent (i.e., keeping any changes made to the system like adding applications).
While playing around with fedora, I decided to try my hand at fedora/red hat derivatives like CentOS and Scientific Linux 6.3. By extracting the contents of the iso (# mount -o /path-to-iso /mnt) to a directory inside of the "boot" directory of the grub2-enabled drive and then placing a copy of the appropriate vmlinuz and initrd files (they are in the isolinux directory in the iso) inside of the same directory that I initially created (Scientific6.3), you can boot the CentOS 6.3 or the Scientific Linux 6.3 iso PROVIDED that you are using the August 24th (2012) version. Here is a copy of my grub.cfg menu entry (I'm including the entries for fedora 16 and 18 so that you can see how similar the process is):
menuentry "Scientific6.3-Live-Desktop ISO" {
linux /boot/Scientific6.3/vmlinuz0 initrd=initrd0.img root=live:LABEL=MultiBootUS live_dir=/boot/Scientific6.3/LiveOS rootfstype=auto liveimg ro quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 splash --
initrd /boot/Scientific6.3/initrd0.img
}
menuentry "Fedora-18-64bit-Live-Desktop ISO" {
linux /boot/Fedora18/vmlinuz0 initrd=initrd0.img root=live:LABEL=MultiBootUS live_dir=/boot/Fedora18/LiveOS rootfstype=auto persistent rw rd.live.image rd.live.overlay quiet rhgb rd.luks=0 rd.md=0 rd.dm=0
initrd /boot/Fedora18/initrd0.img
}
menuentry "Fedora-16-i686-Live-Desktop ISO" {
linux /boot/fedora16-i686/vmlinuz0 root=live:LABEL=MultiBootUS live_dir=/boot/fedora16-i686/LiveOS persistent rw rootfstype=vfat ro liveimg quiet rhgb rd.luks=0 rd.md=0 rd.md=0 rd.dm=0
initrd /boot/fedora16-i686/initrd0.img
}
As I indicated above, if you use a Scientific Linux 6.3 iso that came out recently (Dec 24, 2012), you will invariably get a kernel panic when you try to boot. You can, however, (with a little tinkering) easily boot the newest edition of Fedora (18). Why on Earth do CentOS and Scientific developers go out of their way to make it impossible to boot their newest isos (even the same version) via grub2 while Fedora does not put up any such road-blocks?
While playing around with fedora, I decided to try my hand at fedora/red hat derivatives like CentOS and Scientific Linux 6.3. By extracting the contents of the iso (# mount -o /path-to-iso /mnt) to a directory inside of the "boot" directory of the grub2-enabled drive and then placing a copy of the appropriate vmlinuz and initrd files (they are in the isolinux directory in the iso) inside of the same directory that I initially created (Scientific6.3), you can boot the CentOS 6.3 or the Scientific Linux 6.3 iso PROVIDED that you are using the August 24th (2012) version. Here is a copy of my grub.cfg menu entry (I'm including the entries for fedora 16 and 18 so that you can see how similar the process is):
menuentry "Scientific6.3-Live-Desktop ISO" {
linux /boot/Scientific6.3/vmlinuz0 initrd=initrd0.img root=live:LABEL=MultiBootUS live_dir=/boot/Scientific6.3/LiveOS rootfstype=auto liveimg ro quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 splash --
initrd /boot/Scientific6.3/initrd0.img
}
menuentry "Fedora-18-64bit-Live-Desktop ISO" {
linux /boot/Fedora18/vmlinuz0 initrd=initrd0.img root=live:LABEL=MultiBootUS live_dir=/boot/Fedora18/LiveOS rootfstype=auto persistent rw rd.live.image rd.live.overlay quiet rhgb rd.luks=0 rd.md=0 rd.dm=0
initrd /boot/Fedora18/initrd0.img
}
menuentry "Fedora-16-i686-Live-Desktop ISO" {
linux /boot/fedora16-i686/vmlinuz0 root=live:LABEL=MultiBootUS live_dir=/boot/fedora16-i686/LiveOS persistent rw rootfstype=vfat ro liveimg quiet rhgb rd.luks=0 rd.md=0 rd.md=0 rd.dm=0
initrd /boot/fedora16-i686/initrd0.img
}
As I indicated above, if you use a Scientific Linux 6.3 iso that came out recently (Dec 24, 2012), you will invariably get a kernel panic when you try to boot. You can, however, (with a little tinkering) easily boot the newest edition of Fedora (18). Why on Earth do CentOS and Scientific developers go out of their way to make it impossible to boot their newest isos (even the same version) via grub2 while Fedora does not put up any such road-blocks?
Total Comments 0