Red Hat Bugzilla – Full Text Bug Listing
|Summary:||f16 upgrade with encrypted rootfs: "The root for the previously installed system was not found".|
|Product:||[Fedora] Fedora||Reporter:||Need Real Name <lsof>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||anaconda-maint-list, awilliam, hughsient, jonathan, lsof, rhughes, vanmeeuwen+fedora|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-10-18 08:45:23 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||727814|
Description Need Real Name 2011-09-27 04:21:01 EDT
Description of problem: preupgrade prompts for the passphrase for device sda2 twice, the second time fails since the loopback device loop1 is already in use. Installation then fails/exits. Version-Release number of selected component (if applicable): How reproducible: Every time. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Comment 1 Need Real Name 2011-09-27 04:23:30 EDT
Note this is not the same as bug 727814 since I am entering the correct passphrase (twice), not cancelling the dialogs.
Comment 2 Need Real Name 2011-10-03 05:29:41 EDT
Some more testing: * Pressing OK on the first dialog means that no root devices can be found, installation exits. No second prompt. * Pressing Cancel on the first dialog means that no root devices can be found, installation exits. No second prompt.
Comment 3 Need Real Name 2011-10-05 05:10:53 EDT
I see: INFO storage: set SELinux context for mountpoint /mnt/sysimage to system_u:object_r:mnt_t:s0 INFO storage: set SELinux context for mountpoint /mnt/sysimage to system_u:object_r:mnt_t:s0 WARN storage: mount of loop1 as ext4 failed! mounted failed: (32,'mount: /dev/loop1 already mounted or /mnt/sysimage busy') WARN storage: setup of vg_box-lv_root failed: luks_open failed for /dev/sda2 (luks-XXX) and: DEBUG kernel: SELinux: initialized (dev sda1, type ext3 uses xattr) and: 0 logical volume(s) in volume group "vg_box" now active. Just for info, I have one vg_box with an lv_root and an lv_swap.
Comment 4 Need Real Name 2011-10-06 07:12:39 EDT
Interestingly enough, switching to a console shell lets me show my volumes with lvdisplay, but the device mapper files are missing under /dev and /dev/mapper.
Comment 5 Need Real Name 2011-10-07 05:01:11 EDT
@Red Hat: there doesn't seem to be much of a response from you. I haven't had a reply at all yet. Should I keep updating this bug, or just stop?
Comment 6 Richard Hughes 2011-10-07 05:43:19 EDT
(In reply to comment #5) > @Red Hat: there doesn't seem to be much of a response from you. I prefer "Richard"... > I haven't had a > reply at all yet. Should I keep updating this bug, or just stop? Are you sure this is a preupgrade bug? I mean, preupgrade doesn't actually mount partitions, that's the job of anaconda after we've rebooted. Can you describe exactly what you've done and what you see please. Thanks.
Comment 7 Adam Williamson 2011-10-07 15:25:29 EDT
Discussed at 2011-10-07 NTH review meeting. This looks a lot like an anaconda issue, not a preupgrade issue. Moving to anaconda. We need more info on the disk layout used here and some anaconda logs to evaluate blocker status (and probably to fix the bug). thanks!
Comment 8 David Lehman 2011-10-07 15:33:56 EDT
(In reply to comment #0) > Description of problem: > preupgrade prompts for the passphrase for device sda2 twice, the second time > fails since the loopback device loop1 is already in use. The failure to set up the encrypted devices has absolutely nothing to do with loop1. Please attach the following logs individually, as type text/plain attachments: /tmp/anaconda.log /tmp/storage.log /tmp/program.log /tmp/syslog Thanks.
Comment 9 Need Real Name 2011-10-10 01:45:55 EDT
The lv devices are marked as "NOT AVAILABLE". Will attach files.
Comment 14 Need Real Name 2011-10-10 05:20:46 EDT
(In reply to comment #6) > Are you sure this is a preupgrade bug? I mean, preupgrade doesn't actually > mount partitions, that's the job of anaconda after we've rebooted. Sorry I didn't update the component. > Can you > describe exactly what you've done and what you see please. Thanks. From memory: I wait for the gui to start, and I am told to enter a passphrase. I enter it, and press enter. Then I get the dialog again. I enter the passphrase and press enter. Then it shows "Examining storage devices" and can't find anything to upgrade.
Comment 15 Need Real Name 2011-10-12 07:24:08 EDT
I've tried again today. The preupgrade directory lists a anaconda-16.20-1.fc16.x86_64.rpm, so I guess I'm using that. This time pvs shows no physical volumes found. So I rebooted and when I saw the passphrase dialog I switch consoles and tried: cryptsetup luksOpen /dev/sda2 sda2 pvscan vgchange -aly Then I switched back console and continued as usual. Unfortunately it failed as usual too. It finds no root filesystem to upgrade.
Comment 16 Need Real Name 2011-10-14 09:53:41 EDT
pvs is at least working again in 16.21. Still the same error though. Doesn't the failure to upgrade a luks installed system make this a candidate for a blocker?
Comment 17 Adam Williamson 2011-10-14 12:02:18 EDT
candidate, sure, but we need more info about exactly what's going wrong to be sure. I think I tested a basic encrypted upgrade for f15 -> f16 and it worked at beta.
Comment 18 Adam Williamson 2011-10-14 14:39:46 EDT
Discussed at 2011-10-14 NTH review meeting. Accepted as NTH as it's an install-time issue which can't be fixed post-release and has notable consequences. If anaconda team think this may have a wide impact we may also want to consider it as a blocker.
Comment 19 Need Real Name 2011-10-17 09:50:22 EDT
(In reply to comment #18) > If anaconda team think this may have a wide impact we may also > want to consider it as a blocker. Thanks. In the meantime I will try to keep testing the new anaconda versions via preupgrade as I notice them.
Comment 20 David Lehman 2011-10-17 10:53:45 EDT
(In reply to comment #14) > I wait for the gui to start, and I am told to enter a passphrase. I enter it, > and press enter. Then I get the dialog again. I enter the passphrase and press > enter. Please attach the output of the following command: cryptsetup luksDump /dev/sda2
Comment 21 Need Real Name 2011-10-18 05:04:46 EDT
# cryptsetup luksDump /dev/sda2 LUKS header information for /dev/sda2 Version: 1 Cipher name: aes Cipher mode: xts-plain Hash spec: sha1 Payload offset: 4040 MK bits: 512 MK digest: 0e 17 42 etc. MK salt: 56 00 2d etc. MK iterations: 10 UUID: xxxxxxxx-etc. Key Slot 0: DISABLED Key Slot 1: ENABLED Iterations: 160785 Salt: d8 2d bd etc. Key material offset: 512 AF stripes: 4000 Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED
Comment 22 David Lehman 2011-10-18 08:45:23 EDT
Your LUKS volume has the first keyslot disabled, which should be okay. However, there is a bug in pycryptsetup that seems to cause intermittent failures when trying to open a LUKS volume using any key other than the one in the primary slot. *** This bug has been marked as a duplicate of bug 728301 ***