Behaviour if GRUB_ENABLE_CRYPTODISK is unset?

* Behaviour if GRUB_ENABLE_CRYPTODISK is unset?
@ 2013-12-07 13:27 Colin Watson
  2013-12-07 13:49 ` Vladimir 'φ-coder/phcoder' Serbinenko
  2013-12-07 13:54 ` Andrey Borzenkov
  0 siblings, 2 replies; 8+ messages in thread
From: Colin Watson @ 2013-12-07 13:27 UTC (permalink / raw)
  To: grub-devel

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?

Thanks,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]


^ permalink raw reply	[flat|nested] 8+ messages in thread