Bug 8337

Summary:	After install from live iso image, asks for passphrase for unused encrypted filesystems.
Product:	Mageia	Reporter:	Dave Hodgins <davidwhodgins>
Component:	RPM Packages	Assignee:	Colin Guthrie <mageia>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	release_blocker	CC:	ennael1, mageia, matali, tmb
Version:	Cauldron
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:	3beta2
Source RPM:	dracut	CVE:
Status comment:
Bug Depends on:	9213
Bug Blocks:
Attachments:	dracut.log from live install and from inside installed system Portion of journalctl output.

Description Dave Hodgins 2012-12-09 04:54:14 CET

After installing from a live iso on an encrypted root (sda10), with
another encrypted file system, that is not used by the install (sda3),
both of which use the same passphrase, when the passphrase is entered,
both encrypted file systems are opened.  There is then a second prompt
for a passphrase (5 times). After either entering the passphrase, or
just pressing enter, there's a message that crypt_sda10 already exists.

Running dracut -f from the installed system fixes the problem.

Dave Hodgins 2012-12-09 04:54:33 CET

Whiteboard: (none) => 3beta1

Comment 1 Dave Hodgins 2012-12-09 04:55:59 CET

Created attachment 3218 [details]
dracut.log from live install and from inside installed system

Manuel Hiebel 2012-12-09 12:45:05 CET

Priority: Normal => release_blocker
CC: (none) => tmb

Comment 2 Colin Guthrie 2013-01-27 16:25:03 CET

Can you specify if these partitions are mentioned in /etc/crypttab? If so, does removing them from there, regenerating initrd (although possibly not required) and rebooting help the issue?

Comment 3 Colin Guthrie 2013-01-27 16:26:34 CET

Also this bug is reported against dracut, but is the question asked from dracut or the real filesystem. You can test this easily by booting with rd.break=prepivot on the kernel command line. If it asks you for the passphrase before you get a dracut shell, then it's in the initrd. If it only pops up after you've typed "exit" into the dracut shell, then it's happening on the real filesystem.

Comment 4 Dave Hodgins 2013-01-28 00:06:20 CET

Created attachment 3445 [details]
Portion of journalctl output.

Turns out it has nothing to do with unused encrypted file systems.

Do to some drive problems I had recently, my most recent tests have been
on a system where the only encrypted file system is for the root file
system being used.

After an install using any of the live iso images, on any boot into
the installed system, dracut asks for the password for the encrypted
file system, mounts it, then asks again (5 times), each time failing
to mount, as it's already mounted.  After pressing enter 5 times, the
boot continues normally.

This happens before dropping to the rd.break=pre-pivot shell.

It's fixed by running dracut -f, after booting into the system.

The attached output from journalctl shows the order that things are happening.

Comment 5 Manuel Hiebel 2013-02-03 13:45:34 CET

*** Bug 8913 has been marked as a duplicate of this bug. ***

CC: (none) => matali

Manuel Hiebel 2013-02-03 13:45:43 CET

Whiteboard: 3beta1 => 3beta2

Comment 6 mat ali 2013-03-10 18:39:32 CET

problem is solved this week too, i didn't changed anything, but I'm not asked for passphrase anymore. For me can the bug be closed.

Comment 7 Sander Lepik 2013-03-10 18:42:06 CET

Dave, can you confirm?

CC: (none) => sander.lepik

Comment 8 Dave Hodgins 2013-03-10 19:32:28 CET

No.  Installs done with the standard installer are ok, but not installs
done using the live iso, which are currently blocked by Bug 9213.

Depends on: (none) => 9213

Comment 9 mat ali 2013-03-11 09:35:28 CET

strange, i really didn't changed any config files... and i installed one month ago with the live iso ( i can't with install due to an ati proprietary driver's bug).

Comment 10 Anne Nicolas 2013-03-13 15:22:55 CET

What about this bug guys? Can we try to test it all from a new install and then close it if all is ok?

CC: (none) => ennael1

Comment 11 Dave Hodgins 2013-04-10 02:07:55 CEST

The fix for bug 9213 seems to have fixed this one too.

Status: NEW => RESOLVED
Resolution: (none) => FIXED