[Top][All Lists]

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

Behaviour if GRUB_ENABLE_CRYPTODISK is unset?

From: Colin Watson
Subject: Behaviour if GRUB_ENABLE_CRYPTODISK is unset?
Date: Sat, 7 Dec 2013 13:27:26 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

I'm carrying this old patch in Debian at the moment, which predates the
addition of LUKS support to GRUB:

Index: b/util/
--- a/util/
+++ b/util/
@@ -130,6 +130,15 @@
+  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" \
+      " 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?


Colin Watson                                       address@hidden

reply via email to

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