Robin Laing wrote: > On 01/21/2010 08:32 AM, Ed Greshko wrote: > >> Dr. Michael J. Chudobiak wrote: >> >>> On 01/21/2010 09:40 AM, Bryn M. Reeves wrote: >>> >>> >>>>> From: >>>>> https://fedoraproject.org/wiki/Dracut/Options#crypto_LUKS >>>>> >>>>> Pass: rd_NO_LUKS to your kernel boot line. >>>>> > > >> What happens if you normally want a particular uuid to be activated on >> boot...but there is a power fail and restore at 3am? Wouldn't you still >> be stuck with a system waiting for the password when what you may want >> would be for the system to come up without that device? Wouldn't a >> rd_LUKS_timeout=<X seconds> make sense? >> >> >> > > If a drive is encrypted, where do you expect to get the password from? > The keyboard via a person entering it... > I am just curious because I have started to encrypt my drives and I have > to enter the password on each boot. It is to ensure that the system > cannot be accessed unless the password is entered. > > Maybe my concept of encrypted partitions is different than yours. > > No, it isn't. But, you may have missed the beginning of the thread? The OP has some external encrypted disks that are not critical to system operation. Other functions of the system are critical. The system is configured to reboot when power is restored after a power failure. If the system is unattended and an encrypted disk is attached the boot process will wait for forever for the password until it proceeds. I think you can see the issue should this happen at 3AM Saturday.... The suggestion of rd_LUKS_timeout=<X seconds> would allow the boot to proceed *without* the encrypted disk being mounted. -- When you surround an army, leave an outlet free. Do not press a desperate foe too hard. --The Art of War by Sun Tzu Chapter VII: Maneuvering
Attachment:
signature.asc
Description: OpenPGP digital signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines