Bug 984213
Summary: | fedup does not activate raids | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | udo <udovdh> |
Component: | fedup | Assignee: | Will Woods <wwoods> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | tflink, wwoods |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-07-16 16:15:32 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
udo
2013-07-13 16:57:45 UTC
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) *** This bug has been marked as a duplicate of bug 970580 *** |