POSSIBLE EXPLANATION OF initramfs VS init.d BEHAVIOR: initramfs=no console under usplash init.d=active console under usplash
The right fix is to fix askpass.c so that no matter how you use cryptsetup the passphrase is secure. The bug doesn't exist with a start- of-boot passphrase call now, but what if the boot sequence changes in the future to put an active console under usplash in the initramfs? I experimented with a simple, hardcoded script using usplash_write INPUTENTER that worked for initramfs passphrase entry, to allow a swap partition on an LVM volume to give encrypted hibernation. Then, of course, I found cryptsetup already handles this fine as released-but what about possible future boot sequences? What source package contains the source code for the askpass.c binary? I wanted to give this a try but never found the source of askpass.c -- usplash prevents passwords from being not echoed on the console https://bugs.launchpad.net/bugs/55159 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs