A lot of the commentary here is based on misunderstandings of the capabilities and constraints of a UEFI environment and what the actual goals of this project are, and I think miss the mark to a large degree. Lennart's written some more explicit criticism at https://lwn.net/Articles/981149/ and I think that's a much more interesting set of concerns.
I have to say I find Lennart's arguments quite unconvincing. As another person said, the vast majority of people just want default boot to the most recent kernel (which this proposal could do well). But then when it comes to the other points, yes I want to be able to reliably boot into other systems, but both systemd-boot and grub are notoriously bad at detecting other systems on disks (both use install-time detectio…
No more boot loader: Please use the kernel instead
391–400 of 460 posts
Re: No more boot loader: Please use the kernel instead
#392Earlier quoted context omitted.
He's saying the opposite: Host has integrated graphics, VM has dedicated GPU.
How can the host have integrated graphics, if integrated graphics don't exist? Per, Korhojoa, and my personal experience plenty of desktop CPUs simply don't have integrated GPUs. Consumer mainboards simply don't come with them at all. Consider my previous workstation CPU, top of the line a few years ago and no iGPU: https://www.amd.com/en/products/processors/desktops/ryzen/50... Integrated GPUs is a feature of server…
So you are contradicting yourself.
Re: No more boot loader: Please use the kernel instead
#393It's something you can do since a lot of years. I used to do so 10 years ago, when I've got the first motherboard with UEFI. But is it useful? It saves a minimal time in the boot sequence, but at what cost? The bootloader (being it grub, or something more simple as systemd-boot) is useful to me for a couple of reasons: - it allows to dual-boot with Windows easily: motherboard boot menu is often not easy to access, yo…
> - it allows to dual-boot with Windows easily: motherboard boot menu is often not easy to access, you need to perform some key combination in a short window, also modern bootloader save the last boot option such that if Windows reboots for an update Linux does not start Do people really dual boot a lot in 2024? It was a good use case when virtualization was slow but decades after the CPU started shipping with virtua…
My original plan was to do everything in a Windows VM, but there was too much of a performance hit for some of my purposes, and VMWare doesn't allow attaching physical disks or non-encrypted VMDKs to a Windows 11 VM, so it's actually easier to have a data drive that's accessible from both OSes with dual boot than it would be with a VM.[1] I'm still disappointed about that.
[1] Using HGFS to map a host path through to the VM is not an option because of how slow that is, especially when accessing large numbers of files.
Re: No more boot loader: Please use the kernel instead
#394Earlier quoted context omitted.
He's saying the opposite: Host has integrated graphics, VM has dedicated GPU.
How can the host have integrated graphics, if integrated graphics don't exist? Per, Korhojoa, and my personal experience plenty of desktop CPUs simply don't have integrated GPUs. Consumer mainboards simply don't come with them at all. Consider my previous workstation CPU, top of the line a few years ago and no iGPU: https://www.amd.com/en/products/processors/desktops/ryzen/50... Integrated GPUs is a feature of server…
Re: No more boot loader: Please use the kernel instead
#395Though generally I prefer the approach of "extend what we have with new features" over "rip out all out and start from scratch" so I spend my time mostly with the BSDs which don't jump full steam ahead into the whatever's the new thing.
Even though something like systemd is undoubtedly better in many things, I also have to wrap my head around it, see how to get at the logs, build those unit files etc. On the BSDs I don't have to bother with that and just keep working as I was and which was not broken for me.
The point is, something new doesn't only have to offer a tangible benefit for me to be worth it. It has to be such a big benefit for me that it offsets the hassle of getting my head around all the new stuff and most of the new Linux inventions fail at this.
Re: No more boot loader: Please use the kernel instead
#396I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really). > [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments. > Loaded by the EFI stub All the ta…
EFI stub is an existing kernel feature, not related to systemd-boot. Of course, everything can be wired together with systemd.
exactly like happened with systemd. all the complexity was ignored.. then bolted on. do you miss crontab -e?
Re: No more boot loader: Please use the kernel instead
#397I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really). > [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments. > Loaded by the EFI stub All the ta…
systemd-boot comes up in the Q&A at 29:50. (The main problem nmbl is trying to solve is code-duplication with the kernel and therefore security issue duplication, and just like grub or any of the alternatives, systemd-boot duplicates code that's already in the kernel. The security holes will exist in any case, but the goal is to reduce security hole duplication by reusing as much of the kernel as possible, rather tha…
> The lowest possible target for the rump kernel hypercall layer is firmware and hardware. This adaption would allow the use of anykernel drivers both in bootloaders and lightweight appliances. A typical firmware does not provide a thread scheduler, and this lack would either mandate limited driver support, i.e. running only drivers which do not create or rely on kernel threads, or the addition of a simple thread scheduler in the rump kernel hypervisor. If there is no need to run multiple isolated rump kernels, virtual memory support is not necessary.
Re: No more boot loader: Please use the kernel instead
#398Earlier quoted context omitted.
Does Windows not ensure that the UEFI boots back into Windows when it does an auto-reboot for updates? There's a UEFI variable called BootNext which Windows already knows how to use since the advanced startup options must be setting it to allow rebooting directly to the UEFI settings. Given that Windows tries to restore open windows to make it look like it didn't even reboot, I'm surprised they wouldn't make sure tha…
No, it doesn't. Even a sysprepped image of Windows (which thus runs Setup to install drivers and finalize the installation) doesn't change the boot order on UEFI machines. I think just the installer does this when you first install Windows.
Re: No more boot loader: Please use the kernel instead
#399Earlier quoted context omitted.
How can the host have integrated graphics, if integrated graphics don't exist? Per, Korhojoa, and my personal experience plenty of desktop CPUs simply don't have integrated GPUs. Consumer mainboards simply don't come with them at all. Consider my previous workstation CPU, top of the line a few years ago and no iGPU: https://www.amd.com/en/products/processors/desktops/ryzen/50... Integrated GPUs is a feature of server…
> and the g had an iGPU. So you are contradicting yourself.
Re: No more boot loader: Please use the kernel instead
#400relevant comments from Hector Martin over on Mastodon at https://social.treehouse.systems/@marcan/112754303893998372 > Reminder that not all platforms support or, indeed, can support kexec() sanely at all. Like ours. kexec() requires the ability to reset all peripheral state and that is impossible on Apple Silicon because firmware is loaded by earlier boot stages and cannot be re-loaded later to the reset state witho…
Sounds like Apple sorted itself out by themselves, while suffering from the limitation. So the correct response to this concern is "Okay. And? Apple will just sort itself out for themselves". I mean, what else can anyone do? Nothing because "but Apple?"