>As Scott has argued, users don't choose disk encryption if their priority is >boot performance. >And users can always mark devices 'noauto' in /etc/crypttab, if they don't >want them >autostarted - if they *do* want them autostarted, it would be nice to do so >more reliably >than we do currently.
Just to emphasize on Karmic server, "more reliably" is really an understatement. It often takes 5 or more boots before the timing is right and the passphrase can be entered w/out hanging the console prior to getting cryptsetup working. Sometimes it boots w/out cryptsetup working - sometimes it hangs without fully booting - and just sometimes you can get the timing right and things will muddle thru and boot up. While it can be made to boot after enough proverbial reset buttom mashing - its really quite broken as is. I'd suggest that working on the "cold boot" scenario is FAR more pressing - make sure upstart dependancies force X to wait for cryptsetup (upstart is kinda new to me so apologies if I'm misstating things) and then just quietly fail if X is started for example if doing udev hot plug luks volumes. Waiting for a perfect "covers all bases" solution when the current situation is fundamentally broken on boot (from where it was in Jaunty) is something I know I'd at least like to see sooner than later. Thanks for listening! ;-D -- cryptsetup init scripts are redundant and can break the boot https://bugs.launchpad.net/bugs/473615 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
