Bug 1273684 - fedup fails to properly handle firmware RAID
fedup fails to properly handle firmware RAID
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: dmraid (Show other bugs)
22
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-20 22:01 EDT by bpk678
Modified: 2016-07-19 14:55 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 14:55:54 EDT
Type: Bug
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 bpk678 2015-10-20 22:01:25 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).
Comment 1 Will Woods 2015-10-28 12:25:51 EDT
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.
Comment 2 bpk678 2015-10-28 17:11:10 EDT
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.
Comment 3 Will Woods 2015-10-29 16:58:04 EDT
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:
https://fedoraproject.org/wiki/Upgrading

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.
Comment 4 bpk678 2015-10-29 20:09:59 EDT
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?
Comment 6 Heinz Mauelshagen 2016-02-29 10:53:55 EST
If it is dmraid, your softraid configuration is the same (obviously), it's an Anaconda bug not coping properly with softraid during the upgrade.
Comment 7 David Shea 2016-02-29 11:05:39 EST

*** This bug has been marked as a duplicate of bug 1219264 ***
Comment 8 Adam Williamson 2016-07-04 10:53:01 EDT
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.
Comment 10 Fedora End Of Life 2016-07-19 14:55:54 EDT
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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