Bug 441770 - anaconda in rescue mode doesn't recognize SW RAID1 rootfs
anaconda in rescue mode doesn't recognize SW RAID1 rootfs
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: 442444 (view as bug list)
Depends On:
Blocks: F9Blocker
  Show dependency treegraph
Reported: 2008-04-09 18:26 EDT by Frantisek Hanzlik
Modified: 2008-04-22 03:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-22 03:55:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Frantisek Hanzlik 2008-04-09 18:26:58 EDT
Description of problem:
I was cloning F9 installation (actualizet to 7-Apr-08 packages) from
single SATA disc to two SW RAID1 partitions on two SATA disc - root on
/dev/md0 (20GB; sda1,sdb1), /dev/md1 mounted to /home (400GB; sda3,sdb3),
sda2 and sdb2 was two swap partitions. After copying source disc (cp -ax, in
fact /home was empty because there wasn't users other than root) I adjust
title Fedora (2.6.25-0.204.rc8.git4.fc9) GUI
	root (hd0,0)
	kernel /boot/vmlinuz-2.6.25-0.204.rc8.git4.fc9.i686 ro root=/dev/md0 5
	initrd /boot/initrd-2.6.25-0.204.rc8.git4.fc9.i686.img

and "/etc/fstab":
/dev/md0                /                       ext3    defaults        1 1
/dev/md1                /home                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sdb2         swap                    swap    defaults        0 0
LABEL=SWAP-sda2         swap                    swap    defaults        0 0

and then detach source disc and reboot from rescue CD (images/boot.iso) so I can
built initramdisk. But anaconda wasn't able find root filesystem, althougt
both md0 and md1 was recognized, assembled and fully operational.
When I then manualy mount /dev/md0 to /mnt/sysimage, /proc, /dev, /sys to
appropriate /mnt/sysimage/XX and then chroot to /mnt/sysimage and create new
initrd, system was right now and able itself boot and work. (Grub was already
installed, on md0/md1 was Fedora 8 previously)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:
Rescue CD doesn't recognize installed system

Expected results:
Anaconda should recognize and mount system on SW RAID.

Additional info:
I don't know if usage "/dev/md0" at kernel cmdline in grub.conf is in Fedora9
still recommended, as well as its usage in /etc/fstab (maybe now is preferred
identification by "LABEL=" or "UUID=" keywords).
As well as I don't know whether anaconda test content of "/etc/blkid/blkid.tab"
or not - filesystems on RAID1 wasn't formated (I only delete all Fedora 8 files,
 then md0/md1 UUIDs and labels stayed original from F8). And after cloning
blkid.tab was from source single SATA drive. But I thing this isn't problem on
previous versions of Fedora.
Comment 1 Jeremy Katz 2008-04-09 20:21:56 EDT
I think this hsould be fixed with anaconda-  Can you try with a later
rawhide or the preview release the end of this week?
Comment 2 Frantisek Hanzlik 2008-04-11 12:11:32 EDT
I not catch anaconda-, and then I tried version from 10-Apr-08.
I did new Fedora installation with same configuration (sda1+sdb1=md0 RAID1,
sda2 and sdb2 are swaps and sda3+sdb3=md1 RAID1), then verify it is bootable.
I find that in grub.conf is at "kernel .." line raid referenced as
root=UUID=bla_bla_uuid, while in fstab as /dev/md0.
If I then boot from rescue CD (boot.iso dated 10-Apr) to rescue mode, I finished
without luck:

screen1 says:
-Rescue -
An error occured trying to mount some
or all of your system. Some of it may
be mounted under /mnt/sysimage.

on screen3:
INFO    : starting raid device md0
INFO    : mdadm -E /dev/sda1
INFO    : mdadm -A --uuid=445e0bfb:xX*xX:8fe3441b --super-minor=0 /dev/md0
INFO    : going to mount md0 on /mnt/sysimage as ext3
ERROR   : <type 'exceptions.AttributeError'>: 'str' object has no attribute

From screen2 console, /proc/mdadm says both md0 and md1 are running, md0 is
mounted in /mnt/sysimage, md1 isn't mounted.

Comment 3 Frantisek Hanzlik 2008-04-11 12:30:57 EDT
In the meantime anaconda is out, but when trying it, I got same result
as with No matter when in grub.conf is root referenced as
root=/dev/md0 or as root=UUID=bla_bla_uuid

Franta Hanzlik
Comment 4 Jeremy Katz 2008-04-16 22:53:39 EDT
*** Bug 442444 has been marked as a duplicate of this bug. ***
Comment 5 Jeremy Katz 2008-04-17 00:44:27 EDT
Fixed in git
Comment 6 Will Woods 2008-04-21 17:31:54 EDT
This works for me with anaconda Can you try again with boot.iso from
today's rawhide?
Comment 7 Frantisek Hanzlik 2008-04-22 03:37:00 EDT
OK, I just confirm that anaconda (21-Apr-2008) rightly recognised md0
as rootfs, md1 as /home, and mounted both correctly on /mnt/sysimage resp.
/mnt/sysimage/home. /dev, /dev/pts, /proc, /sys and /selinux were mounted into
relevant /mnt/sysimage/XX too, and then system was fully functional: Bug is away.

Note You need to log in before you can comment on or make changes to this bug.