Bug 741538 - f16 upgrade with encrypted rootfs: "The root for the previously installed system was not found".
f16 upgrade with encrypted rootfs: "The root for the previously installed sys...
Status: CLOSED DUPLICATE of bug 728301
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
AcceptedNTH
:
Depends On: 727814
Blocks: F16-accepted/F16FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2011-09-27 04:21 EDT by Need Real Name
Modified: 2011-10-18 08:45 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-18 08:45:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
storage.log (73.41 KB, text/plain)
2011-10-10 01:46 EDT, Need Real Name
no flags Details
anaconda.log (6.14 KB, text/plain)
2011-10-10 01:46 EDT, Need Real Name
no flags Details
program.log (31.87 KB, text/plain)
2011-10-10 01:47 EDT, Need Real Name
no flags Details
syslog (129.90 KB, text/plain)
2011-10-10 01:47 EDT, Need Real Name
no flags Details

  None (edit)
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 10 Need Real Name 2011-10-10 01:46:28 EDT
Created attachment 527148 [details]
storage.log
Comment 11 Need Real Name 2011-10-10 01:46:54 EDT
Created attachment 527149 [details]
anaconda.log
Comment 12 Need Real Name 2011-10-10 01:47:07 EDT
Created attachment 527150 [details]
program.log
Comment 13 Need Real Name 2011-10-10 01:47:15 EDT
Created attachment 527151 [details]
syslog
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 ***

Note You need to log in before you can comment on or make changes to this bug.