This is not quite fixed, yet. I encounter the following issues : * the startup scripts do not always succed in correctly unlocking the keyslot. Looks like sometimes the keyboard input does not get to the password reader but to something else. * And if you can switch to console 8 unfortunately one can even see the password typed in the first console where the luks password was asked; This is not ok first because the password does not get where it should get, and second because it creates a security risk as anyone could press (ctrl)-alt-f8 and see the password for the encrypted disk(s). * if cryptdisks is enabled, all other services should depend on cryptdisks, nothing should continue until the user either correctly unlocks all the encrypted volumes OR he cancels the operation or he fails the password for the numtries parameter in crypttab. NOW, for example gdm starts anyway. Needless to say, this create an issue when you are trying to enter the cryptovolumes password and then gdm takes over the screen and the keyboard. * The tty's on the other side seem to wait for the cryptdisks. This creates the following issue : If you did not manage to properly enter the password, after gdm started you could try to switch back to console 1 and retry to enter the password. However, because of how the dependencies are made, you are presented with a blank screen. If you press enter a few times, eventually the startup sequence completes (i think it actually terminates cryptdisks init script) and so the other services get to be started (getty for ex).
-- cryptsetup devices not mounted on boot https://bugs.launchpad.net/bugs/430496 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
