grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cryptodisk enabled returns to rescue prompt


From: westlake
Subject: Re: cryptodisk enabled returns to rescue prompt
Date: Sat, 07 Nov 2015 03:58:22 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0

actually the crypt would be internal inside the grub mbr that gets generated because even if i comment out cryptmount -u in grub.cfg and apply update-initramfs&&update-grub there's no effect(there still is a passphrase prompt), here the cryptsetup is taking effect prior the reading of grub.cfg..

it shouldn't also be hard to implement. afaik the lacking of documentation for using GRUB_ENABLE_CRYPTODISK='y' tells me this should be an area encouraging suggestion and feedback from those who are bothering to using it... It works but it can be improved. Here my main concern is a "grub rescue" shouldn't be showing up right after the first failed attempt.

thanks


On 07/11/15 02:28 AM, Andrei Borzenkov wrote:
07.11.2015 07:13, westlake пишет:
enabling GRUB_ENABLE_CRYPTODISK=y has crypt prompting only once on
bootup, is it possible to have an option with grub-install or another
option here with GRUB_EMABLE_CRYPTODISK so that the keypass prompts in a
loop? (a wrong passphrase typed brings the user to a grub rescue shell
and has to issue ctl-alt-delete which is imho not very presentable to

You need to just do

cryptomount -u xxxxxxxxxxx
normal

I am not convinced that being stuck in password entry loop is better.
May be a command that retries to execute embedded config and enter
normal may be useful.

staff) -- I understand this is all in mbr bootcode so I suppose the best
place to implement this would be when first generating the code in order
to keep it small.

it would be imho really great if this can be implemented

There was suggested patch that allowed multiple password entry attempts
for LUKS. It was a part of patch series that implemented other things.
May be it could be reconsidered if rebased to not depend on other changes.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]