Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 981824 - fedup upgrade does not boot if root is an MD RAID partition
Summary: fedup upgrade does not boot if root is an MD RAID partition
Keywords:
Status: CLOSED DUPLICATE of bug 970580
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup-dracut
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-06 02:46 UTC by Alex G.
Modified: 2013-07-08 16:41 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-08 16:41:42 UTC
Type: Bug


Attachments (Terms of Use)

Description Alex G. 2013-07-06 02:46:49 UTC
Description of problem:
[21:38] <mrnuke> the fedup boot couldn't find my root partition as mdadm did not automatically scan/assembled it
[21:38] <mrnuke> when I told mdadm to scan and assembled, I couldn't tell which of my arrays was the one with root
[21:39] <mrnuke> and as most tools are unavailable in initramfs, I was stuck
[21:39] <mrnuke> no way to check
[21:39] <mrnuke> reboot with Ctrl-Alt-Del, and the fedup option is gone from the boot screen

Version-Release number of selected component (if applicable):
NA

How reproducible:
Only tried once

Steps to Reproduce:
1. fedup --network 19
2. reboot
3. select fedup
4. wait until dracut realizes it cannot boot and drops you to a shell

Actual results:
See above

Expected results:
I win the lottery.

Additional info:
root "/" partition is on an MD RAID array.

Comment 1 Roderick Taylor 2013-07-06 12:11:51 UTC
I also ran into this problem.

At the rescue console, I did the following to kick it back into gear:

1. My mdadm.conf was there in the initramfs. I inspected that to see what arrays were available with "cat /etc/mdadm.conf". 
2. For each of the listed /dev/mdn devices I did "mdadm --assemble /dev/mdn"
3. I then restarted systemd with "kill 1"
4. It continued with the upgrade until it said it was restarting the computer but it got stuck there.  I had to pull the power to restart it.

After reboot the new initramfs automatically assembled my arrays and it all seems to "work".  

For my upgrade attempt, the kernel parameters in grub for the "System Upgrade (fedup)" boot option included root=/dev/md1. This was set by fedup before reboot and was correct.

Comment 2 Michael Chapman 2013-07-07 12:54:44 UTC
I can confirm the behaviour described in the first comment.

I found that:

# mdadm --assemble --scan
# exit

was sufficient to continue booting.

Comment 3 Will Woods 2013-07-08 16:41:42 UTC

*** This bug has been marked as a duplicate of bug 970580 ***


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