From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oNZxR-0001xE-2h for mharc-grub-devel@gnu.org; Mon, 15 Aug 2022 09:16:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNZx6-0001u1-JY for grub-devel@gnu.org; Mon, 15 Aug 2022 09:16:20 -0400 Received: from smtp-out1.suse.de ([2001:67c:2178:6::1c]:39588) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNZx4-0001Sk-PP for grub-devel@gnu.org; Mon, 15 Aug 2022 09:16:20 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id BB2A837426; Mon, 15 Aug 2022 13:16:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1660569375; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YiMypjFOBQI1PyAKuIl8L+2EQ+OQiw73+na5RrHcPn4=; b=DCjBEnXwIeOhcaKOsCV7YW2ZuPFpfm00x8Hg3TQzXmcvGU3CZO/MVKxPWOXpe0bxWEyAkS 3va7wjMsKf84F5klLqCkTHPwMazD7k/HKeL3tOn5H94mpQcF+CIcSVE2hqGqZvJkPGqYDy VxOZtZjwfhE5fZ2tPX/Jz1feUQqHHTA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1660569375; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YiMypjFOBQI1PyAKuIl8L+2EQ+OQiw73+na5RrHcPn4=; b=1fyu/bQi43ws6jnbOEnzRvEKGneev4TxK8PBZnK7uedU+zI/NMl0z3SCpXErzqhk4bbqoo MI09S4j4lkxWZfBw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A3F7D2C1C6; Mon, 15 Aug 2022 13:16:15 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 16060) id 843D46878; Mon, 15 Aug 2022 13:16:15 +0000 (UTC) Date: Mon, 15 Aug 2022 15:16:15 +0200 From: Raymund Will To: Daniel Kiper Cc: Robbie Harwood , grub-devel@gnu.org, John Jolly , Javier Martinez Canillas Subject: Re: [PATCH v2 1/1] Add support for grub-emu to kexec Linux menu entries Message-ID: <20220815131615.GA9135@suse.de> References: <20220719203934.319797-1-rharwood@redhat.com> <20220803152639.cne3dtxofhqakjqr@tomti.i.net-space.pl> <20220811180820.asy5a4h5rh3vfr4y@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220811180820.asy5a4h5rh3vfr4y@tomti.i.net-space.pl> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: pass client-ip=2001:67c:2178:6::1c; envelope-from=rw@suse.de; helo=smtp-out1.suse.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2022 13:16:26 -0000 Hi, please let me try to add a bit of context and explain three IMHO crucial points of the proposed patch. First, it is meant to work without any changes to config-files on 'linux'-systems, simply by calling `grub-emu --kexec`. And, called this way, it actually uses `systemctl kexec` exclusively to instruct `systemd` to perform the "kexec"-reboot in a sane and safe manner. Second, it only supports a very limited set of commands in `grub.cfg`, as `grub-emu` can not implement the full functionality of a firmware- loaded `grub` binary (like raw-device access) and it hinges massively on proper `kexec`-support from the machine/firmware, so unfortunately it won't be universally useful, Third, for use in a "pre-boot environment" (i.e. initrd/chroot), which has full control over it's state, but no (fully) working `systemd`, a call to `grub-emu --kexec --kexec` changes the behavior to allow a fall-forward to `kexec -e`. As a safe-guard for the adventurously minded `systemctl kexec` is still tried first! This third point describes the use-case the original patch-set was developed for and the second doesn't hurt (much) on the systems it is deployed/used in the field. But the first was found to be really useful, especially on machines, which can reliably `kexec`, but are dead slow through cold-boot (think "huge memory", "tons of devices") and/or have "exotic" console setups ("3215" anybody?). Note that, as the boot configuration (namely `grub.cfg`) wasn't changed, regular boot can't be affected by this short-cut (particularly, when `kexec` might have failed). Granted, the duplication of `--kexec` to signify "force it", might as well be spelled out as `--force-kexec` (or something similar). (But that change will provoke inconsistencies during an indefinite migration phase, where pre-boot images don't match binaries in the root filesystem, notably, when rollback snapshots come into play.) Config-overrides in `grub.cfg` in turn would be a nice addition, but are relatively expensive to implement, as they'd probably need to be parsed and split into an array for `grub_util_exec()`, right? But, please, still leave sane defaults in the binary, for out-of- the-box, no-config-changes-necessary usage, pretty please! Would it be possible to re-evaluate the proposed patch with this in mind? PS: in light of my statements above, the "description" of this patch definitely needs re-wording... Thanks, -- Raymund WILL rw@SUSE.de SUSE Software Solutions Germany GmbH, Frankenstr. 146, D-90461 Nuernberg Geschaeftsfuehrer: Ivo Totev, et al (HRB 36809, AG Nuernberg)