How to use GRUB to install a second OS on an existing second partition?
December 17, 2010 8:27 PM Subscribe
Have an existing install of REDHAT on a first partition, I have created a second partition and am trying to use GRUB to install a second OS (happens to be another version of redhat). Please help, or ask for more details if needed. From the GRUB command line how do I make it install on a selected partition.
Response by poster: Agreed, GRUB doesn't seem capable of solving this issue. Other suggestions for installing 3 different versions of redhat on 3 partitions?
posted by samuel1613 at 9:13 PM on December 17, 2010
posted by samuel1613 at 9:13 PM on December 17, 2010
You probably don't want to do what you're trying to do. First, I'm assuming RHEL/CentOS and the old grub (Ubuntu uses grub-2 which is a different beast but works about the same).
If you did the default install as MBR for your first installation then grub is installed on /dev/hda (or /dev/sda). i.e. on the root of the disk itself and not in a partition (e.g. /dev/hda1). It is patched on install to find it's secondary files in /boot/grub/ of the first partition. What you want to do is edit your /boot/grub/grub.conf on your first installation and add an entry to have it point to your second installation.
Then when you reboot you'll see another menu entry allowing you to opt to boot your second installation.
Notes:
* grub numbers from 0. hd0 is your first hard disk, hd1 is your second hard disk. (hd0,0) is the first partition on your first hard disk, (hd0,1) is the second partition on your first hard disk.
* your kernel and initrd lines may be a bit different than mine...
* What you are doing here is using the existing grub that works for your first installation and just adding in an entry that describes your second installation.
* this is also how grub handles dual to windows, except the entry looks something like:
(If Windows were on the first partition.
Back in the old days, or if you used Windows a lot... You would leave the old DOS bootloader in the MBR and set the active-partition to either part1 (windows) or part2 (linux) and let the bios boot as normal. Then you would put grub on the part2 bootblock and it would load and then do its thing to load linux. Now you mostly just replace the MBR with grub and let it boot other OSs.
grub-2 works the same way, but the actual configuration is a bit harder, or easier (Ubuntu update-grub command will search the disk for recognizable OSs and make menu entries for all of them automagically).
posted by zengargoyle at 10:11 PM on December 17, 2010
If you did the default install as MBR for your first installation then grub is installed on /dev/hda (or /dev/sda). i.e. on the root of the disk itself and not in a partition (e.g. /dev/hda1). It is patched on install to find it's secondary files in /boot/grub/ of the first partition. What you want to do is edit your /boot/grub/grub.conf on your first installation and add an entry to have it point to your second installation.
# this first one should already be at the top of the file
title CentOS (2.6.18-194.26.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-194.26.1.el5 ro root=/dev/hda1 rhgb quiet
initrd /initrd-2.6.18-194.26.1.el5.img
# add one like this
title CentOS (2.6.18-194.26.1.el5) second partition!!!
root (hd0,1)
kernel /vmlinuz-2.6.18-194.26.1.el5 ro root=/dev/hda2 rhgb quiet
initrd /initrd-2.6.18-194.26.1.el5.img
Then when you reboot you'll see another menu entry allowing you to opt to boot your second installation.
Notes:
* grub numbers from 0. hd0 is your first hard disk, hd1 is your second hard disk. (hd0,0) is the first partition on your first hard disk, (hd0,1) is the second partition on your first hard disk.
* your kernel and initrd lines may be a bit different than mine...
* What you are doing here is using the existing grub that works for your first installation and just adding in an entry that describes your second installation.
* this is also how grub handles dual to windows, except the entry looks something like:
title Windows
root (hd0,0)
chainloader +1
boot
(If Windows were on the first partition.
Back in the old days, or if you used Windows a lot... You would leave the old DOS bootloader in the MBR and set the active-partition to either part1 (windows) or part2 (linux) and let the bios boot as normal. Then you would put grub on the part2 bootblock and it would load and then do its thing to load linux. Now you mostly just replace the MBR with grub and let it boot other OSs.
grub-2 works the same way, but the actual configuration is a bit harder, or easier (Ubuntu update-grub command will search the disk for recognizable OSs and make menu entries for all of them automagically).
posted by zengargoyle at 10:11 PM on December 17, 2010
Oh, if you *don't* have a separate /boot partition you want to put /boot/vmlinuz... and /boot/initrd...
I sorta mucked the examples cut-n-pasting from my LVM setup.
(a lot of old distros would make a symling in /boot (cd /boot ln -s . boot) so you could always leave the lines as /boot/vmlinuz and it would still work if you had a separate /boot and / or not)
posted by zengargoyle at 10:28 PM on December 17, 2010
I sorta mucked the examples cut-n-pasting from my LVM setup.
# if / is your only partition (partition 1, (hd0,0))
root (hd0,0)
kernel /boot/vmlinuz ... root=/dev/hda1
initrd /boot/initrd
# if you have separate /boot (hda1 (hd0,0)) and / (hda2 (hd0,1))
root (hd0,0)
kernel /vmlinuz ... root=/dev/hda2
initrd /initrd
(a lot of old distros would make a symling in /boot (cd /boot ln -s . boot) so you could always leave the lines as /boot/vmlinuz and it would still work if you had a separate /boot and / or not)
posted by zengargoyle at 10:28 PM on December 17, 2010
are you asking about installing the new OS to a new partition, or about installing GRUB to the new partition? and do you know if you're using GRUB 1 or GRUB 2?
Other suggestions for installing 3 different versions of redhat on 3 partitions?
a single instance of GRUB can boot multiple OSs, but you'll have to futz about with the partitioning and GRUB config to make it even slightly unsucky, and even then it'll still be annoying and brittle.
why do you need to have 3 different versions of the OS installed on one machine? is this something that could be solved by using a virtualisation environment like VirtualBox?
posted by russm at 10:31 PM on December 17, 2010
Other suggestions for installing 3 different versions of redhat on 3 partitions?
a single instance of GRUB can boot multiple OSs, but you'll have to futz about with the partitioning and GRUB config to make it even slightly unsucky, and even then it'll still be annoying and brittle.
why do you need to have 3 different versions of the OS installed on one machine? is this something that could be solved by using a virtualisation environment like VirtualBox?
posted by russm at 10:31 PM on December 17, 2010
You've got a few options here. But the option you almost definitely don't want is to share a /boot partition with lots of different Linux installs. Instead, have a boot partition per Linux install (it can be in / for each Linux install if you want), and configure your MBR GRUB to boot to each individual /boot partition.
Alternatively use virtualisation. I would.
posted by devnull at 4:56 AM on December 23, 2010
Alternatively use virtualisation. I would.
posted by devnull at 4:56 AM on December 23, 2010
Odd devnull, I would recommend the opposite. One /boot partition for all installations. The reason being that the GRUB bootloader (the MBR part of it) needs information from a real filesystem, the /boot contains kernels and such, /boot/grub has the various stage2, config, splashscreens, etc.
GRUB MBR is always going to be hard patched to load its stage2 and configuration from a specific (hdX,X)/grub/... filesystem. Once it loads the configuration it's then free to do things like pick a kernel, initrd, root_partition to continue with. Old time best practice is /boot on a separate partition that doesn't get auto-mounted to protect it from accidental mucking about with.
MBR: Gstage1 (partition table): rest of cyl0: Gstage1.5 (patched to 0,0 as root)
p1(0,0) hda1: kernel1, kernel2, initrds, grub/* (mounted as /boot)
p2(0,1) hda2: / filesystem for OS1 mounts /dev/hda1 on /boot noauto
p3(0,2) hda3: / filesystem for OS2 mounts /dev/hda1 on /boot noauto
p4(0,3) extended
p5(0,4) hda5: /home mounted by either OS
something like that. then you dont let your OS muck about with GRUB unless it's smart and normally kernel filenames are different enough to not collide.
Alternatively and maybe better with the newer automatic foo-foo distros would be to have a grub partition that you manage independently of the distros so they can think that they are managing everything but you're not really using their grub/grub.conf and using your own to load the kernels and boot.
I could blather on for ages about boot processes, I still remember the days when you just built a kernel and configured it with a root partition, compressed it, added a bootable decompression header to it and did "dd if=vmlinuz of=/dev/fd0" to create a rescue boot floppy. Short version, it's best to keep finding/loading of kernel separate from actual runtime filesystem concerns.
posted by zengargoyle at 12:11 PM on December 23, 2010
GRUB MBR is always going to be hard patched to load its stage2 and configuration from a specific (hdX,X)/grub/... filesystem. Once it loads the configuration it's then free to do things like pick a kernel, initrd, root_partition to continue with. Old time best practice is /boot on a separate partition that doesn't get auto-mounted to protect it from accidental mucking about with.
MBR: Gstage1 (partition table): rest of cyl0: Gstage1.5 (patched to 0,0 as root)
p1(0,0) hda1: kernel1, kernel2, initrds, grub/* (mounted as /boot)
p2(0,1) hda2: / filesystem for OS1 mounts /dev/hda1 on /boot noauto
p3(0,2) hda3: / filesystem for OS2 mounts /dev/hda1 on /boot noauto
p4(0,3) extended
p5(0,4) hda5: /home mounted by either OS
something like that. then you dont let your OS muck about with GRUB unless it's smart and normally kernel filenames are different enough to not collide.
#(hd0,0)/grub/grub.conf
...
title OS1
root(hd0,0)
kernel /kernel1 root=/dev/hda1
initrd /initrd1
title OS2
root (hd0,0)
kernel /kernel2 root=/dev/hda2
initrd /initrd2
Alternatively and maybe better with the newer automatic foo-foo distros would be to have a grub partition that you manage independently of the distros so they can think that they are managing everything but you're not really using their grub/grub.conf and using your own to load the kernels and boot.
I could blather on for ages about boot processes, I still remember the days when you just built a kernel and configured it with a root partition, compressed it, added a bootable decompression header to it and did "dd if=vmlinuz of=/dev/fd0" to create a rescue boot floppy. Short version, it's best to keep finding/loading of kernel separate from actual runtime filesystem concerns.
posted by zengargoyle at 12:11 PM on December 23, 2010
« Older Need a great appetizer recipe to win a contest | What kind of medicated chewing gum might a... Newer »
This thread is closed to new comments.
posted by dougrayrankin at 8:50 PM on December 17, 2010