Red Hat Bugzilla – Full Text Bug Listing
|Summary:||anaconda 184.108.40.206-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>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-04-22 03:55:05 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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 "/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 220.127.116.11-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-09 20:21:56 EDT
I think this hsould be fixed with anaconda-18.104.22.168. 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-22.214.171.124, and then I tried version 126.96.36.199 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 12:30:57 EDT
In the meantime anaconda 188.8.131.52 is out, but when trying it, I got same result as with 184.108.40.206. 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 220.127.116.11. 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 18.104.22.168 (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.