Red Hat Bugzilla – Bug 1273684
fedup fails to properly handle firmware RAID
Last modified: 2016-07-19 14:55:54 EDT
Description of problem: fedup has the same problem as https://bugzilla.redhat.com/show_bug.cgi?id=1219264, where firmware RAID is not handled properly.
Version-Release number of selected component (if applicable):
How reproducible: very
Steps to Reproduce:
1. install f20 on working device with firmware RAID
2. upgrade to f22 using fedup
3. box fails to boot because filesystems on firmware RAID'd disks cannot be found
Actual results: box is unusable
Expected results: box would boot, filesystems would be mountable
Additional info: i have tried futzing with tune2fs, removing uuid lines from /etc/fstab in favor of /dev/mapper/blah lines to point to actual devices, etc but to no avail. additionally, /home and /tmp filesystems are missing entirely (/dev/mapper/vg_<name>-lv-home and /dev/mapper/vg_<name>-lv-tmp do not exist).
fedup is deprecated and has been replaced by "dnf-plugin-system-upgrade". Please update your system; the new package should replace the old one automatically.
The new package contains a (mostly) backward-compatible "fedup" replacement which should not have this problem.
dnf-plugin-system-upgrade is not available for Fedora 20, so it is not a viable alternative to fedup. the issue is not with the mechanism to download the new packages but is with anaconda working with firmware RAID.
Fedora 20 is EOL, so I really can't fix anything there.
Also, the upgrade process also doesn't involve anaconda at all, so.. that's not super-relevant to the problem here?
The best I can do is some general advice.. the cause of the problem is probably that the upgrade.img used by fedup doesn't know how to set up your RAID because it doesn't have your mdadm.conf, or the right drivers/firmware for your firmware raid, or something similar.
So if you can figure out how to set up your RAID manually from the dracut emergency shell, you can exit the shell and the upgrade should continue normally.
If you can't get that to work, there's other upgrade paths you can try:
Other than that, since both fedup and F20 are EOL'd.. there's really not anything I can *fix* here. Sorry I can't offer more help than that, but I don't really know the specifics of your system, and Bugzilla isn't really for individual tech support.
Best of luck getting your system upgraded, though.
i am not using mdadm. its all dmraid, straight out of the box, that anaconda does support for a fedora 20 install. the regression in anaconda for fedora 22 may be one thing (that should have stopped its release), but the fedup issue has nothing to do with driver support. it actually does see the dmraid firmware abstracted disk, but completely clobbers the physical disk UUIDs and the raid'd disk UUID, thereby hosing grub, etc causing the box to unusable.
heres is fedora's problem:
fedora 22 escaped QA with a major defect that is being pushed under the rug. the same or very similar type issue is affecting the in-place upgrade process. both outright fail to properly support firmware based raid. the net result is that i am out of compliance for versioning and am behind in patch levels, etc. i cannot build new, and i cannot upgrade back-rev builds.
given the high profile failures around ssl recently, this is not something to be taken lightly. how does one actually get fedora to work, given that build or upgrade are not options?
If it is dmraid, your softraid configuration is the same (obviously), it's an Anaconda bug not coping properly with softraid during the upgrade.
*** This bug has been marked as a duplicate of bug 1219264 ***
This doesn't actually seem to be a dupe of 1219264, really, it seems to be some kind of dmraid/kernel issue with assembling the user's Promise firmware RAID set which appeared between F20 and F22. Re-assigning to dmraid for now.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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
Thank you for reporting this bug and we are sorry it could not be fixed.