Red Hat Bugzilla – Bug 645953
anaconda offers bad disks for second OS
Last modified: 2010-10-27 17:52:47 EDT
Description of problem:
I just installed F14 on i686 HW, two physical disks with GPT, divided as:
md0:raid1 (sda2,sdb2) ext4 in /
md1:raid1 (sda3,sdb3) ext4 in /mnt/os2
md2:raid1 (sda4,sdb4) ext4 in /home
md3:raid1 (sda5,sdb5) ext4 in /mnt/backup
On bootloader screen, I have in (sorry for liberal translation from cs_CZ :) "OS list for Grub" area rightly one line "Implicit Fedora /dev/md0".
But when I click "Add", in new "Image" window with "Name" and "Device" fields,
as devices for other OS offers only sda1 (swap!), sdb1 (swap!), sda2 (raid member!) and sdb2 (raid member!). Nothing else, which is probably bad.
Reason why I want specify second OS here is, that I want install other Fedora distro to /dev/md1 latterly, which will have grub installed from it. And as I think Grub still not recognize raid1 v1.1/1.2 superblock and anaconda probably create (excepting bootable partitions) v1.1 raid1 devices, I wanted force 0.90 or 1.0 (now seems as Fedora Grub recognize v1.0 format, right?) now in install stage, without needs for recreate md1 lately.
Maybe, enabling select md version, could be solution too.
Version-Release number of selected component (if applicable):
Our dual boot handling for !Windows is lacking. In general you have to setup any kind of Linux dual boot manually.
When creating /boot on a separate raid partition anaconda *does* use v0.9 metadata (at the end of the partition so GRUB will work). But / partitions use the default metadata version.
What I've done in the past is create a 'common' /boot partition that I use for all the installs, remembering to back it up before install, just in case it gets wiped, and editing it after the install so that everything can be booted.
This method does not work if you want to dual boot with systems using grub2 (like Ubuntu). I don't have a solution for this case, and am open to suggestions :)
On several F14 installation with SW md RAIDs I did recently, all without /boot partition and with /boot on root fs (RAID1, usually md0), anaconda was create v1.0 metadata on / fs and v1.1 on others. And booting is fine - thus it seems as grub1 now understand v1.0 RAID1s too, not only v0.9 as some time ago (only notice to Your previous comment about md metadata x GRUB).
I was never using /boot partition, as I didn't want too many partition (with old and crappy dos extended/logical stuff). But as from F13 I use merely GPT on i686, more partition isn't problem, and /boot partitions is very satisfactory solution for me - all I want is have two partitions for two different (Fedora) systems - one for production system (e.g. F12 or older now), second for intending new system (F14 now). Other /home and data partitions I want common for both of them. My goal is minimize possible timeouts after system upgrades, mainly when third-party SW or some myself /not in Fedora/ compiled packages not work as expected - then isn't problem switch to old stable system, and adjust new distro problems later.
Thus, as I don't need dual boot with non-Fedora distros, I will switch to common /boot partition as You suggest above. Thanks.
Actually, GRUB has no knowledge of RAID. The difference is where the metadata is written. If its at the end of the partition grub sees it as ext3 (or whatever). If the metadata is at the start, as it is with v1.1, grub can't find the filesystem.
And to clarify, anaconda uses metadata v1.0 for /boot/ partitions.
I'm going to dupe this to the bug about dual booting. Hopefully we can figure out a way to make this a better experience.
*** This bug has been marked as a duplicate of bug 580176 ***