+++ This bug was initially created as a clone of Bug #1156614 +++ Testing Fedora 21 Beta RC1 Server x86_64 DVD install to an Intel firmware RAID set (RAID-0), with https://dlehman.fedorapeople.org/updates/updates-1156534.2.img to avoid bug #1156534. The installation completes successfully, but the installed system fails to boot. It fails because it can't mount /boot. /etc/fstab has this: /dev/md/Volume0_0p1 /boot (normal options) but what actually exists in /dev/md is: /dev/md/imsm0 -> ../md127 /dev/md/Volume0 -> ../md126 /dev/md/Volume0p1 -> ../md126p1 /dev/md/Volume0p2 -> ../md126p2 note, Volume0, not Volume0_0. /etc/mdadm.conf has this: # mdadm.conf written out by anaconda MAILADDR root AUTO +imsm +1.x -all ARRAY /dev/md/Volume0_0 UUID=4786ac39-ee6f-1bea-4821-6193be13503b ARRAY /dev/md/imsm0 UUID=213b64a5-0337-c96b-f87c-2c75dfd16a99 If I reboot and check in the anaconda environment, then within anaconda the entries in /dev/md are indeed Volume0_0, Volume0_0p1 and Volume0_0p2. So they have different names in the anaconda environment vs. the booted system, but I'm not sure why. --- Additional comment from Adam Williamson (Red Hat) on 2014-10-24 12:09:05 PDT --- Proposing as a Beta blocker per fw RAID criterion: "The installer must be able to detect and install to hardware or firmware RAID storage devices." https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Hardware_and_firmware_RAID --- Additional comment from Adam Williamson (Red Hat) on 2014-10-24 12:21:18 PDT --- for the record, the earlier bug that dlehman's update is for is https://bugzilla.redhat.com/show_bug.cgi?id=1156354 (6354, not 6534). --- Additional comment from David Lehman on 2014-10-24 12:25:48 PDT --- I think the problem boils down to the following: when auto-assembling the array during installer boot, it gets the '_0' suffix since there is no hostname set (and probably no homehost in the fwraid superblock, either). When we reboot after installation, the array is again auto-assembled, but this time is treated as local (no '_0' suffix). Doug (or Jes), can you explain this a bit further so I can have enough information to find a way to make the names match across reboot? --- Additional comment from Adam Williamson (Red Hat) on 2014-10-24 13:56:39 PDT --- dlehman provided a further updates image: https://dlehman.fedorapeople.org/updates/updates-1156534.4.img which includes his proposed fix for #1156354 and a fix for this bug. It doesn't change the fact that the set is 'Volume0_0' in anaconda but 'Volume0' on the installed system, but it identifies the /boot partition by UUID rather than by /dev/md partition node name when writing /etc/fstab . That approach does solve the problem at least in my test scenario: for the first time on F21, with this updates.img on top of Beta RC1, I can install to an fwraid set and boot the installed system. I'm not gonna pretend I can evaluate whether this approach might cause other problems somehow, but I can say at least that it fixes my test case. --- Additional comment from Kamil Páral on 2014-10-27 05:09:33 PDT --- I can confirm this bug also on my fwraid machine (same symptoms), and the linked updates.img fixes the problem for me as well. --- Additional comment from Doug Ledford on 2014-10-27 07:53:35 PDT --- The best way to make sure this isn't an issue during install is to simply turn off the HOMEHOST checking during install. A simple mdadm.conf file in the install image that has these two lines would do the trick: AUTO -all HOMEHOST <any> --- Additional comment from Adam Williamson (Red Hat) on 2014-10-27 12:04:25 PDT --- Discussed at 2014-10-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-27/f21-blocker-review.2014-10-27-16.01.log.txt . Accepted as a blocker per criterion cited in c#2. --- Additional comment from bcl on 2014-10-28 08:18:06 PDT --- The plan here is to: 1. Add a mdadm.conf to /usr/share/anaconda/ 2. Have lorax move this to /etc/ in the rootfs 3. Live spins will move this into place in %post I'll handle this for anaconda and lorax using this bug and clone it for spin-kickstarts.
Created attachment 951480 [details] patch Instead of copying from Anaconda I decided it was better for the build tools to do their own customizing. Here's a patch that should be applied to each ks where livesys is setup.
This bug doesn't need to have blocker status. The issues are sufficiently mitigated by other fixes for 21 Beta purposes.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
AFAICS the 'proper fix' for this wound up being in lorax and the spin-kickstarts change was considerd wrong, so this should probably be closed notabug - bcl, wdyt?
Looks like the right fix was to use "HOMEHOST <ignore>" which made it into Lorax, but nothing was done for the spins. Is this still an issue with live?
I did all my software RAID testing for F23 with non-live images, I think :/ I'll try and find a bit of time to look at it today.
I just did an F23 install to firmware RAID with a live image and it worked. The obvious difference is that a UUID is used as the mount point for /boot now, not a /dev/md path, which would obviously avoid the problem. I don't know if there are still any paths on which anaconda would write a /dev/md* path to /etc/fstab , and if so, if they're still broken...
OK, so I tested an install using standard partitions and that works too; anaconda uses UUIDs not /dev/md paths for all partitions, and the installed system boots. Still, the mismatch is still *there*, as you can see on the custom partitioning screen: anaconda displays the partitions as 'Volume0_0p1', 'Volume0_0p2' etc etc, but on the installed system, they're 'Volume0p1', 'Volume0p2' etc etc. Right now I can't find a case where it's causing a problem, but anaconda definitely still sees them as Volume0_0 while they're Volume0 on the installed system. So, not sure if we should close this or not; I leave it up to you.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.