From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VpILQ-0006df-Tp for mharc-grub-devel@gnu.org; Sat, 07 Dec 2013 08:54:56 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpILK-0006dA-BB for grub-devel@gnu.org; Sat, 07 Dec 2013 08:54:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VpILE-00034I-Rd for grub-devel@gnu.org; Sat, 07 Dec 2013 08:54:50 -0500 Received: from mail-la0-x22e.google.com ([2a00:1450:4010:c03::22e]:38071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpILE-00033z-JB for grub-devel@gnu.org; Sat, 07 Dec 2013 08:54:44 -0500 Received: by mail-la0-f46.google.com with SMTP id eh20so707517lab.5 for ; Sat, 07 Dec 2013 05:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=19wTPLDuzJ3ClDzZnPIikiYIzSbkys//vh21E/LOIps=; b=E4izc/qu/MlxA9s4Hvhoay0r3YroxWqrGlCPdjMgR6ImaKzO3XHA9j4v4XI2DBTaP6 vkIHsjC/QoJDKVQkVlHUaXlNzQwELzQyjpH4jKbA6Y606kIq0IdDiNgrAVoCz2qHvWck W4v2ro2EU0NtbBbqn78vAz9VUcN9hEdlQ4qJYCAvILLnT2tqslfDyBMekRd5y9fY+upt iwv1PA60r3CWLX/Jm/uUa4MFR4uIixIzvB3I3tQh512vyKZAu02NWHrR+VzDeEnnMGAq +b3iIWbbdTEM94uCT7HSvmUwmVbqYHWbAtvzLyZKK3Pl8PYIe1y4u7UIlTWztkmJb6yr BrYw== X-Received: by 10.112.11.170 with SMTP id r10mr2143205lbb.23.1386424483296; Sat, 07 Dec 2013 05:54:43 -0800 (PST) Received: from opensuse.site (ppp91-76-134-134.pppoe.mtu-net.ru. [91.76.134.134]) by mx.google.com with ESMTPSA id n13sm2091980lbl.17.2013.12.07.05.54.42 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 07 Dec 2013 05:54:42 -0800 (PST) Date: Sat, 7 Dec 2013 17:54:41 +0400 From: Andrey Borzenkov To: grub-devel@gnu.org Subject: Re: Behaviour if GRUB_ENABLE_CRYPTODISK is unset? Message-ID: <20131207175442.5f797aba@opensuse.site> In-Reply-To: <20131207132726.GA28299@riva.ucam.org> References: <20131207132726.GA28299@riva.ucam.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.18; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22e X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 13:54:55 -0000 В Sat, 7 Dec 2013 13:27:26 +0000 Colin Watson пишет: > 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.