Description of problem: In the partitioning screen, Anaconda complains about a wrong RAID metadata version number for /boot (0, 0.90 and 1.0 would work). I deleted and re-created the array after that (with mdadm --create --metadata 0.90). Still did not work; a reboot did not change anything. How reproducible: Only tried on my local desktop PC, don't know if this is reproducible on other hardware. Steps to Reproduce: 1. Try installing Fedora 16 with /boot on a RAID device. Actual results: The metadata version is not detected as compatible. Expected results: The metadata version should be detected as compatible.
Please attach the following logs from /tmp in the installer shell on tty2: /tmp/anaconda.log /tmp/storage.log /tmp/program.log /tmp/syslog Thanks.
Created attachment 531893 [details] /tmp/anaconda.log
Created attachment 531894 [details] /tmp/program.log
Created attachment 531895 [details] /tmp/storage.log
Created attachment 531896 [details] /tmp/syslog
Created attachment 531897 [details] mdadm output Output of "mdadm --detail" for the array in question. This clearly shows that it *is* an v0.90 array.
Uploaded the files asked for. The error message (translated back from German) is: "RAID arrays that contain '/boot filesystem' must have one of the following metadata versions: 0,0.90,1.0"
Just an additional note: The very same RAID array works with Anaconda from the Fedora 15 netinstall ISO.
I am seeing the same thing. Here is the output of mdadm -D on my /boot device (in Fedora 15): /dev/md0: Version : 0.90 Creation Time : Mon Mar 28 22:50:35 2011 Raid Level : raid1 Array Size : 530048 (517.71 MiB 542.77 MB) Used Dev Size : 530048 (517.71 MiB 542.77 MB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Sun Nov 6 11:51:47 2011 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : c8e0b967:e87610a3:5f2ebae2:146363c3 (local to host ian.icp.selfip.net) Events : 0.115 Number Major Minor RaidDevice State 0 8 3 0 active sync /dev/sda3 1 8 19 1 active sync /dev/sdb3
I just verified that mdadm -D also shows the metadata version as 0.90 when run from a shell in the anaconda environment.
Apparently our method for obtaining the metadata version of existing v0 arrays does not work. I have uploaded an F16 updates image (against anaconda-16.25) with a proposed fix, which you can test by adding the following to your boot command line: updates=http://dlehman.fedorapeople.org/updates-750480.1.img Please share your results.
(In reply to comment #11) > > updates=http://dlehman.fedorapeople.org/updates-750480.1.img > > Please share your results. No joy. I am still getting the error message.
(In reply to comment #12) > (In reply to comment #11) > > > > updates=http://dlehman.fedorapeople.org/updates-750480.1.img > > > > Please share your results. > > No joy. I am still getting the error message. Please attach storage.log so I can see what might have gone wrong.
Created attachment 532094 [details] storage.log with updates-750480.1.img
I see what I did wrong there. New updates (.2) replaces old image: updates=http://dlehman.fedorapeople.org/updates-750480.2.img
Created attachment 532115 [details] storage.log with updates-750480.2.img Still getting the same error. New storage log attached.
Created attachment 532117 [details] anaconda.log with updates-750480.2.img anaconda.log just to prove that I really did use the updated img file. (I had to check myself.)
Ok, the root cause for this is that mdadm --examine --brief outputs the metadata version, but only for v1 arrays. This means there is no reliable way to obtain the metadata version for an array that is not already active. Once the array is active you can look in the udev info for MD_METADATA but the way anaconda works this method requires us to make a special backtrack to update md arrays' metadata version. I filed a bug about the inconsistency in mdadm: bug 752156
New updates available: updates=http://dlehman.fedorapeople.org/updates-750480.3.img I tested this one.
(In reply to comment #19) > New updates available: > > updates=http://dlehman.fedorapeople.org/updates-750480.3.img > > I tested this one. I am currently travelling. I will test this one when I get home on Thursday.
(In reply to comment #19) > updates=http://dlehman.fedorapeople.org/updates-750480.3.img Works for me.
same pb here. error message disappear and installation continue with (In reply to comment #19) > updates=http://dlehman.fedorapeople.org/updates-750480.3.img
I am getting a 404 trying to retrieve http://dlehman.fedorapeople.org/updates-750480.3.img.
(In reply to comment #23) > I am getting a 404 trying to retrieve > http://dlehman.fedorapeople.org/updates-750480.3.img. Looks like it's now at http://dlehman.fedorapeople.org/updates/updates-750480.3.img
Thanks. Fixed for me as well.
This was fixed for Fedora 17.