Bug 441770

Summary:	anaconda 11.4.0.66-1.i386 in rescue mode doesn't recognize SW RAID1 rootfs
Product:	[Fedora] Fedora	Reporter:	Frantisek Hanzlik <franta>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	wwoods
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-04-22 07:55:05 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	235706

Description Frantisek Hanzlik 2008-04-09 22:26:58 UTC

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
"/boot/grub/grub.conf":
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):
anaconda 11.4.0.66-1.i386

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
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-10 00:21:56 UTC

I think this hsould be fixed with anaconda-11.4.0.67.  Can you try with a later
rawhide or the preview release the end of this week?

Comment 2 Frantisek Hanzlik 2008-04-11 16:11:32 UTC

I not catch anaconda-11.4.0.67, and then I tried version 11.4.0.70 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
'getDevice'

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

FH

Comment 3 Frantisek Hanzlik 2008-04-11 16:30:57 UTC

In the meantime anaconda 11.4.0.71 is out, but when trying it, I got same result
as with 11.4.0.70. 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-17 02:53:39 UTC

*** Bug 442444 has been marked as a duplicate of this bug. ***

Comment 5 Jeremy Katz 2008-04-17 04:44:27 UTC

Fixed in git

Comment 6 Will Woods 2008-04-21 21:31:54 UTC

This works for me with anaconda 11.4.0.74. Can you try again with boot.iso from
today's rawhide?

Comment 7 Frantisek Hanzlik 2008-04-22 07:37:00 UTC

OK, I just confirm that anaconda 11.4.0.74 (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.