|
Bugzilla – Full Text Bug Listing |
| Summary: | systemd does not ask a second time for (wrong) pass-phrase for decryption of the home partition | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.1 | Reporter: | Hendrik Woltersdorf <hendrikw> |
| Component: | Basesystem | Assignee: | Frederic Crozat <fcrozat> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | cobexer |
| Version: | Milestone 2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Hendrik Woltersdorf
2011-06-26 06:37:55 UTC
I am also not sure, that the pass-phrase I entered was actually wrong, because that happens far too often - and only with systemd, but not with sysvinit. One more test: My /etc/crypttab: cr_sda8 /dev/disk/by-id/ata-ST9500420AS_5VJ92AFR-part8 none none I replaced the last "none" with "tries=3". Then I see the "asking" (Please enter pass-phrase for ...) a second time, but the system does not wait for the answer and continues booting immediately. on two of my systems I get 0 tries to enter the password. the text that tells me to enter the password appears, but does not take input and does not delay the boot. thus after a few seconds the terminal on vt1 and the X server (with auto login) start. my /etc/crypttab looks similar, and I also use none none. I setup the test system as follows: clean installation in a vm. at the partitioning step i created the setup by hand. I created 3 primary partitions swap / and /home where /home is the encrypted partition. @Hendrik: what did you do differently that you managed to get one try for the password entry? I did nothing special differently. I use logical partitions on an older laptop. There I do a always clean install for these tests. could you test with latest Factory ? latest systemd should block correctly on passphrase request. Today I tested this with systemd-33-8.2.i586 and it did block correctly on passphrase request. So IMHO the problem is solved. excellent. closing as fixed |