Thanks for the info -- for documentation sake in the mailing list im
going to add some comments and answer some of my own questions. I
decided to just jump headfirst as I didnt really have any data i needed
to keep anyway...
I created the following:
Distros are rhel5.1 x64 and fc9 x64
/boot as the physical partition which is shared
1 physical volume on the only other partition on the disk - this is
shared between both distros
1 swap lv for each (under above pv)
1 root lv for each (under above pv)
1 shared lv (under above pv)
These existed already and had backup data on them:
1 existing pv from laptop hd module
5 exising lv from above pv
1. So far no issues whatsoever with sharing /boot, though its worth
mentioning FC9 doesnt appear to account for an grub already existing.
Basically you have to manually add the grub.conf lines that correspond
to your other distro (rhel5.1 for me). I am not sharing any other
partitions right now except for some generic data ones, no issues.
2. Any existing VGs I had showed up as 'inactive'. Suprisingly I've
never come across this in all my years with lvm -- 'sudo vgchange -a y
VolGroup_$NAME' brought it back to active, then I could mount. I
suppose this is the equiv. of vxvol start X. Other than that, no
issues. I haven't tried hibernation yet, but I did notice my 2nd distro
install (FC9) did use BOTH swaps and put an entry in fstab. I removed
this for 'good measure'.
Chris Snook wrote:
Chris Snook wrote:
John Priddy wrote:
So I would like to have rhel5 and fc9 coexisting on the same
physical disk. My questions/concerns are as follows:
1. Is there any issue with sharing the /boot mountpoint/partition
between both?
2. I haven't worked a lot with shuffling around VGs, but how about
sharing lvm volumes in general? If I create some generic (not root)
lvm volume and lay down an ext3 filesystem in FC9 should I expect
any problems when trying to mount the same in RHEL5? Is there any
issue I should be aware of regarding differing versions of lvm? Is
it worth while/possible to share the swap volume -- lets say I put
the computer into hibernate in FC9, then later on I boot up into
RHEL5, whats the worst thats going to happen?
3. Anyone else out there doing something like this that has any
additional advice?
Thanks
John
It works, but it can be a pain in the ass. Personally, I prefer to
have separate /boot partitions, and chainload them from the first
one, which holds the oldest distro. That way, if a new distro adds
features that are incompatible with an older bootloader, each OS is
still being loaded by its own bootloader. The only catch is that you
have to be careful and make sure that when installing the non-primary
distros that you put the bootloader on the /boot partition, not on
the MBR.
Anaconda makes it very easy to create a chainload entry pointing to
another partition. I usually leave a few GB of space free so I can
create extra /boot partitions at will, and put all the rest in LVM.
-- Chris
I realized I didn't really directly answer questions #1 and #2.
1) I can't think of any specifically for RHEL5/F9, but I've had
problems sharing /boot between distros in the past. The nastiest one
is dual-booting x86_32 and x86_64 when the distros don't include the
arch in the kernel and initrd filenames. Might as well set yourself
up for chainloading now, so you don't have to worry about these sorts
of problems if you decide to add a distro that has such a problem.
2) Anything needed to boot the system should probably not be
shared. Sharing /home is fine and even encouraged. The system will
actually set itself up to share swap automatically unless you tell it
not to, which could cause hibernation problems. You can rectify that
by forcing each distro to use a distinct swap partition, and check
/etc/fstab post-install to make sure it didn't auto-add the other
one. If you're not doing hibernation, sharing swap is perfectly fine.
As for LVM versions, anything running a 2.6 kernel will use LVM2 and
be compatible, so you won't have problems unless you try to share with
a very old distro. Just put it all in one VG for simplicity.
-- Chris
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
