From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id ED392608C6 for ; Wed, 2 Feb 2022 15:42:08 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E063E1DC7C for ; Wed, 2 Feb 2022 15:42:08 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 1DF0B1DC71 for ; Wed, 2 Feb 2022 15:42:08 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id E5F5546CF7 for ; Wed, 2 Feb 2022 15:42:07 +0100 (CET) Message-ID: <18120399-2922-0da2-d6ef-a2d52f10e91a@proxmox.com> Date: Wed, 2 Feb 2022 15:42:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0 Content-Language: en-US To: Stoiko Ivanov Cc: Proxmox VE development discussion References: <20220201220331.3491615-1-s.ivanov@proxmox.com> <897a7e1f-929f-24cc-41af-dcbf1158102c@proxmox.com> <20220202152855.040d20c1@rosa.proxmox.com> From: Thomas Lamprecht In-Reply-To: <20220202152855.040d20c1@rosa.proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.061 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [RFC pve-kernel-meta 0/5] unify boot-mode config X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 14:42:09 -0000 On 02.02.22 15:28, Stoiko Ivanov wrote: > On Wed, 2 Feb 2022 10:03:05 +0100 > Thomas Lamprecht wrote: > >> On 01.02.22 23:03, Stoiko Ivanov wrote: >>> patch 3 drops systemd-boot and uses grub for both boot-modes, hopefully >>> unifying the boot-experience and causing less confusion (currently I suggest >>> to look at the screen while booting to find out which boot-loader is used) >>> >>> (Sadly systemd-boot (which I would prefer, justifiably) >>> won't get support for legacy boot) >>> >> The thing is, non-uefi systems will become more rare anyhow, so why >> bother with that? The simplicity of systemd-boot is worth the few (?) >> confusion - I mean what exactly is there confusing anyway, if most relevant >> actions can be handled through our tool anyway? >> >> I'm not definitive yet, but currently rather tending to NACK that. > Thanks for the feedback! > > Hmm - I do see your point - motivation was that it felt like a logical > next step after adapting the config of systemd-boot to get the images > from where grub needs them to have the system bootable in both modes - > and having a single place to configure the boot-loader (kernel cmdline, > pinning) seemed sensible (and less code in p-b-t should correlate with > less bugs in p-b-t). No, IMO the next logical step is to rather use systemd-boot for all EFI-booted setups, not only ZFS - makes not much sense to have switched explicitly to systemd-boot only to switch back again, grub has a real complexity cost that only can be argued for in non-UEFI systems. Also, we already have the code and it already works well for all setups we know of, further the scope of proxmox-boot-tool is rather small anyway, with that in mind I'd really hope not to expect much bugs from that part, nor would I think that there'll be much dropped - efi and legacy boot is different enough anyway. > > Add to that my biased view (a few forum-threads where people did not know > which boot loader they used - e.g. [0,1,2] vs. the silent majority, who > either does not need it, or knows it) that most users expect > /etc/default/grub to be the place for editing the kernel commandline > (following the blog/forum/website posts only mentioning this) Yeah I do not see that in a relevant amount of times, iff it's a documentation problem, and if you want to make it more simpler the answer is a p-b-t command that allows to set and reset it centrally. Some people will always ask or have trouble either way. > > But OTOH I was a bit hesitant as well (since it would mean that the > blog/forum/website posts of the past 2 years would now become 'wrong' and > cause even more confusion). Also (quite biased as well) - there are quite > a few threads with grub failing to boot vs. none that I'm aware of, where > systemd-boot fails. Yeah switching around will definitively produce much more confusion than it solves, there are no technical advantages either. > > So - no hard feelings from my side either - I was curios if it would work > as a POC > I mean, why wouldn't it? ^^ > On a side-note - I just learned that grub in efi-mode works fine (without > explicit configuration) over a serial terminal (a use-case I need for > myself ;) systemd's does too here, at least qm terminal worked with both since I can remember.