Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 584596 - anaconda create 1.1 superblock on SW RAID1 device - which isn't recognized by grub
anaconda create 1.1 superblock on SW RAID1 device - which isn't recognized by...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
i386 Linux
low Severity high
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
http://fedoraproject.org/wiki/Common_...
: CommonBugs
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-21 20:01 EDT by Frantisek Hanzlik
Modified: 2010-04-23 10:05 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 585106 (view as bug list)
Environment:
Last Closed: 2010-04-23 03:37:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frantisek Hanzlik 2010-04-21 20:01:08 EDT
Description of problem:
When install Fedora 13 Rawhide on SW RAID1 md device, anaconda create this RAID1 device with 1.1 metadata style - which is not recognized by grub, and system is unbootable. Attempt to manualy install grub after boot from rescue CD fails: 
grub> root (hd0,0)
root (hd0,0)
 Filesystem type unknown, partition type 0xfd

Version-Release number of selected component (if applicable):
anaconda-13.37.2-1.fc13.i686

Additional info:
Somewhere was stated, GRUB v0.97 recognize only RAID1 md with 0.90 superblock.
Comment 1 Hans de Goede 2010-04-22 02:43:51 EDT
Hi Frantisek,

Thanks for reporting this, can you provide a bit more details about the attempted installation, to be specific I would like to know what the partition layout you created looked like.

Thanks,

Hans
Comment 2 Frantisek Hanzlik 2010-04-22 05:43:19 EDT
I attempt to install F13 rawhide to i686 system with 3 same SATA disks,
and I want:
(sda1=sda2=20GB)=20GB SW RAID1 md system device (/, ext4),
equal size 20GB sdc1 as swap,
(sda2=sdb2=sdc2=700GB)=1.4TB SW RAID5 md device (/home, ext4),
(sda3=sdb3=sdc3=750GB)=1.5TB SW RAID5 md device (/mnt/backup, ext4)

As I don't know how create this scenario with anaconda GUI (nor when it is possible with anaconda :), I had disks divided before I start installation.
Then I start installation, select custom disk dividion, leave my disk partitioning and create RAIDs, select their mountpoints, format requiring etc.
then select pkgs to install, and installation successfully went ahead. But system wasn't bootable. Boot from boot.iso CD in rescue mode was successful, all partitions was recognized and properly mounted. Inspecting MBR on sda/sdb, there wasn't no GRUB loader code (no GRUB/Geom/Hard Disk/Read/Error strings), thus anaconda wasn't able install bootloader - but installation produce no warning or error message, on screen nor in log - it's possibly not OK.
mdadm --detail /dev/mdX show that all RAIDs are version 1.1 - which, as far as I know, isn't supported by GRUB1.
Comment 3 Hans de Goede 2010-04-23 03:37:21 EDT
Hi,

Thanks for the info. It seems we have a bug were we use 1.1 metadata for / even if there is no separate /boot. I've committed a fix for this to our master branch, but I'm not sure it will get added to F-13 given that we're post beta.

If you do an install with a separate /boot anaconda should do the right thing and use 1.0 metadata for the /boot raidset.

Regards,

Hans
Comment 4 Frantisek Hanzlik 2010-04-23 05:01:33 EDT
I cp installed system to other partition, re-create RAID1 md on / fs with 0.90 superblock, format as ext4 and cp root FS back on them and it works (grub recognize md as ext2fs and is able setup loader).

But one things I should note: grubby (or whatever anaconda use for bootloader writing) should produce some warnings and/or mentioned this problem to log (my "/root/install.log" nor "/root/install.log.syslog" contains no nootice about it).
Also in generated "/boot/initramfs-..." was some buggy (which prevent pivot_root to real rootfs). But simple recreating initramfs with dracut in rescue mode solved this.

It'd be fine, when You could get solution to F13 final. Many thans!

Franta

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