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:
Note this is not the same as bug 727814 since I am entering the correct passphrase (twice), not cancelling the dialogs.
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.
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.
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.
@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?
(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.
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!
(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.
The lv devices are marked as "NOT AVAILABLE". Will attach files.
Created attachment 527148 [details] storage.log
Created attachment 527149 [details] anaconda.log
Created attachment 527150 [details] program.log
Created attachment 527151 [details] syslog
(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.
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.
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?
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.
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.
(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.
(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
# 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
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 ***