all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Stoiko Ivanov <s.ivanov@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC pve-kernel-meta 0/5] unify boot-mode config
Date: Wed, 2 Feb 2022 15:42:07 +0100	[thread overview]
Message-ID: <18120399-2922-0da2-d6ef-a2d52f10e91a@proxmox.com> (raw)
In-Reply-To: <20220202152855.040d20c1@rosa.proxmox.com>

On 02.02.22 15:28, Stoiko Ivanov wrote:
> On Wed, 2 Feb 2022 10:03:05 +0100
> Thomas Lamprecht <t.lamprecht@proxmox.com> 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.




      reply	other threads:[~2022-02-02 14:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01 22:03 Stoiko Ivanov
2022-02-01 22:03 ` [pve-devel] [RFC pve-kernel-meta 1/5] rename pve-efiboot-manual-kernels to proxmox-boot-manual-kernels Stoiko Ivanov
2022-02-01 22:03 ` [pve-devel] [RFC pve-kernel-meta 2/5] proxmox-boot: add reinit subcommand Stoiko Ivanov
2022-02-01 22:03 ` [pve-devel] [RFC pve-kernel-meta 3/5] proxmox-boot: keep EFI and legacy bootloaders in sync Stoiko Ivanov
2022-02-01 22:03 ` [pve-devel] [RFC pve-kernel-meta 4/5] proxmox-boot: use grub for UEFI boot Stoiko Ivanov
2022-02-01 22:03 ` [pve-devel] [RFC pve-kernel-meta 5/5] proxmox-boot: install grub in esp/EFI/BOOT/BOOTX64.EFI Stoiko Ivanov
2022-02-02  9:03 ` [pve-devel] [RFC pve-kernel-meta 0/5] unify boot-mode config Thomas Lamprecht
2022-02-02 14:28   ` Stoiko Ivanov
2022-02-02 14:42     ` Thomas Lamprecht [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18120399-2922-0da2-d6ef-a2d52f10e91a@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=s.ivanov@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal