Bug 750480

Summary: Anaconda complains about wrong RAID metadata version for /boot
Product: [Fedora] Fedora Reporter: Andreas Wolf <awolf+redhat>
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: amk, anaconda-maint-list, ipilcher, jonathan, matzilla, mishu, pza, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-04 23:10:14 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:
Attachments:
Description Flags
/tmp/anaconda.log
none
/tmp/program.log
none
/tmp/storage.log
none
/tmp/syslog
none
mdadm output
none
storage.log with updates-750480.1.img
none
storage.log with updates-750480.2.img
none
anaconda.log with updates-750480.2.img none

Description Andreas Wolf 2011-11-01 09:46:44 UTC 
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.
Comment 1 David Lehman 2011-11-01 13:54:10 UTC 
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.
Comment 2 Andreas Wolf 2011-11-05 13:45:16 UTC 
Created attachment 531893 [details]
/tmp/anaconda.log
Comment 3 Andreas Wolf 2011-11-05 13:45:59 UTC 
Created attachment 531894 [details]
/tmp/program.log
Comment 4 Andreas Wolf 2011-11-05 13:46:24 UTC 
Created attachment 531895 [details]
/tmp/storage.log
Comment 5 Andreas Wolf 2011-11-05 13:46:47 UTC 
Created attachment 531896 [details]
/tmp/syslog
Comment 6 Andreas Wolf 2011-11-05 13:49:11 UTC 
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.
Comment 7 Andreas Wolf 2011-11-05 13:50:25 UTC 
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"
Comment 8 Andreas Wolf 2011-11-05 14:13:03 UTC 
Just an additional note: The very same RAID array works with Anaconda from the Fedora 15 netinstall ISO.
Comment 9 Ian Pilcher 2011-11-06 18:03:23 UTC 
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
Comment 10 Ian Pilcher 2011-11-06 18:12:28 UTC 
I just verified that mdadm -D also shows the metadata version as 0.90 when
run from a shell in the anaconda environment.
Comment 11 David Lehman 2011-11-07 14:30:49 UTC 
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.
Comment 12 Ian Pilcher 2011-11-07 14:53:56 UTC 
(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.
Comment 13 David Lehman 2011-11-07 15:22:45 UTC 
(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.
Comment 14 Ian Pilcher 2011-11-07 16:47:35 UTC 
Created attachment 532094 [details]
storage.log with updates-750480.1.img
Comment 15 David Lehman 2011-11-07 18:21:57 UTC 
I see what I did wrong there. New updates (.2) replaces old image:

  updates=http://dlehman.fedorapeople.org/updates-750480.2.img
Comment 16 Ian Pilcher 2011-11-07 18:39:28 UTC 
Created attachment 532115 [details]
storage.log with updates-750480.2.img

Still getting the same error.  New storage log attached.
Comment 17 Ian Pilcher 2011-11-07 18:40:47 UTC 
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.)
Comment 18 David Lehman 2011-11-08 17:36:09 UTC 
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
Comment 19 David Lehman 2011-11-08 19:30:20 UTC 
New updates available:

 updates=http://dlehman.fedorapeople.org/updates-750480.3.img

I tested this one.
Comment 20 Ian Pilcher 2011-11-08 21:25:17 UTC 
(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.
Comment 21 Ian Pilcher 2011-11-10 18:38:54 UTC 
(In reply to comment #19)
>  updates=http://dlehman.fedorapeople.org/updates-750480.3.img

Works for me.
Comment 22 Matthieu Araman 2011-11-12 22:00:30 UTC 
same pb here.
error message disappear and installation continue with 
(In reply to comment #19)
>  updates=http://dlehman.fedorapeople.org/updates-750480.3.img
Comment 23 Ian Pilcher 2011-12-22 17:02:33 UTC 
I am getting a 404 trying to retrieve http://dlehman.fedorapeople.org/updates-750480.3.img.
Comment 24 Ian Pilcher 2011-12-22 17:04:22 UTC 
(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
Comment 25 Phil Anderson 2011-12-24 02:04:53 UTC 
Thanks.  Fixed for me as well.
Comment 26 David Lehman 2012-10-04 23:10:14 UTC 
This was fixed for Fedora 17.