Re: Behaviour if GRUB_ENABLE_CRYPTODISK is unset?

[Andrey Borzenkov <arvidjaar@gmail.com>]

В Sat, 7 Dec 2013 13:27:26 +0000
Colin Watson <cjwatson@ubuntu.com> пишет:

> I'm carrying this old patch in Debian at the moment, which predates the
> addition of LUKS support to GRUB:
> 
> Index: b/util/grub-mkconfig_lib.in
> ===================================================================
> --- a/util/grub-mkconfig_lib.in
> +++ b/util/grub-mkconfig_lib.in
> @@ -130,6 +130,15 @@
>      esac
>    done
>  
> +  if dmsetup status $device 2>/dev/null | grep -q 'crypt[[:space:]]$'; then
> +    grub_warn \
> +      "$device is a crypto device, which GRUB cannot read directly.  Some" \
> +      "necessary modules may be missing from /boot/grub/grub.cfg.  You may" \
> +      "need to list them in GRUB_PRELOAD_MODULES in /etc/default/grub.  See" \
> +      "http://bugs.debian.org/542165 for details."
> +    return 0
> +  fi
> +
>    # Abstraction modules aren't auto-loaded.
>    abstraction="`"${grub_probe}" --device $@ --target=abstraction`"
>    for module in ${abstraction} ; do
> 
> Now, this is obviously wrong because it renders LUKS support mostly
> non-functional even if you have GRUB_ENABLE_CRYPTODISK=y, so I'd like to
> drop it, but that does mean that people who *don't* have
> GRUB_ENABLE_CRYPTODISK=y will once again see no hint of what to do.
> 
> I've never totally understood why GRUB_ENABLE_CRYPTODISK is optional to
> begin with; it seems like a bit of a "do you want things to work? [y/N]"
> option to me.  My preferred approach would be to delete the option.  If
> there's some reason we can't do that, perhaps it would be worth checking
> for whether it would have any effect if enabled, and if so print an
> explanatory warning?
> 

I think it came up recently and explanation was, in this case grub may
unintentionally end up to need more crypto devices than user expects and
thus waiting for passphrase on boot.

One reason it may happen is due to font handling. First, undocumented
GRUB_FONT which can theoretically point anywhere; second fallback
to /usr/share and similar if GRUB_FONT is not defined. So even if /boot
itself is unencrypted, you may suddenly pull in encrypted root.