Bug 984213 - fedup does not activate raids
fedup does not activate raids
Status: CLOSED DUPLICATE of bug 970580
Product: Fedora
Classification: Fedora
Component: fedup (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-13 12:57 EDT by udo
Modified: 2013-07-16 12:15 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-16 12:15:32 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 udo 2013-07-13 12:57:45 EDT
Description of problem: raid must be started to be able to decrypt the /dev/mapper/crypto thing that contains my lvms.


Version-Release number of selected component (if applicable):
fedup-0.7.3-5.fc17.noarch

How reproducible:
mount DVD at /mnt
`fedup --device /mnt --debuglog=/fedupdebug.log`
wait
see that fedup asks you to boot
then manually ad the luks thingie of the crupto disk to the grub conf line for fedup: rd.luks.uuid=luks-05(etc).
Only then boot.
See it boot a bit. Then it sits and after a too long while it gives a dracut shell.
Then I can manually start md0 and md1 and exit
Then it mounts the lvs, does the swap etc but does not install anything because something goes wrong but I am unable to read what as the long list of rpms that were not installed is zipping by.
After I boot I notice that the fedup entry is gone from grub. That is not nice when we have to retry a failed upgrade attempt.


Expected results:
A flawless, unproblematic upgrade.

Additional info:
Why did early upgrades start raid and doesn't fedup do so?
Why do we boot at all into some upgrade environment and why can't we run that stuff from runlevel 1?
What can I do so that fedup /does/ find the info of the working f17 system as it prepares the boot environment for the upgrade to f19? F17 boots fine, so why can't fedup?

Please help me help!
Comment 1 udo 2013-07-14 01:56:21 EDT
Again we run `fedup --device /mnt --debuglog=/fedupdebug.log`
Afterwards we add 'rd.luks.uuid=luks-058(etc)22  rd.auto=1' to the fedup grub config line.
We boot.
We see raid being assembled. (Whooo! Why not automagically was it was?)
We are asked for the crypto password.
We see lvms being accessed.
We are again asked for the crypto password. (Why?)
We see something fail (ungreen color that flashes by)
We see the load of failed rpm upgrades flash by (why?)
And finally it enters some final stage and sits there.
We reboot it manually after syncing and unmounting and again the Fedup grub entry is gone.

What is wrong?
Do we really expect this to work for a normal user which I do not consider myself?
When the setup of the installation allows to build certain setups and does so flawlessly, why then must the upgrade be so difficult?

As I asked before:
Why not `init 1` and then do the stuff? (saves all of these boot problems)
Comment 2 Will Woods 2013-07-16 12:15:32 EDT

*** 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.