Bug 741538

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: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: anaconda-maint-list, awilliam, hughsient, jonathan, lsof, rhughes, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedNTH
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-18 12:45:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 727814    
Bug Blocks: 713566    
Attachments:
Description Flags
storage.log
none
anaconda.log
none
program.log
none
syslog none

Description Need Real Name 2011-09-27 08:21:01 UTC
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 08:23:30 UTC
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 09:29:41 UTC
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 09:10:53 UTC
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 11:12:39 UTC
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 09:01:11 UTC
@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 09:43:19 UTC
(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 19:25:29 UTC
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 19:33:56 UTC
(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 05:45:55 UTC
The lv devices are marked as "NOT AVAILABLE".

Will attach files.

Comment 10 Need Real Name 2011-10-10 05:46:28 UTC
Created attachment 527148 [details]
storage.log

Comment 11 Need Real Name 2011-10-10 05:46:54 UTC
Created attachment 527149 [details]
anaconda.log

Comment 12 Need Real Name 2011-10-10 05:47:07 UTC
Created attachment 527150 [details]
program.log

Comment 13 Need Real Name 2011-10-10 05:47:15 UTC
Created attachment 527151 [details]
syslog

Comment 14 Need Real Name 2011-10-10 09:20:46 UTC
(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 11:24:08 UTC
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 13:53:41 UTC
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 16:02:18 UTC
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 18:39:46 UTC
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 13:50:22 UTC
(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 14:53:45 UTC
(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 09:04:46 UTC
# 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 12:45:23 UTC
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 ***