12 ms·

It'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 minima

• michaelmrose 2y ago
  The suggested system would use bootnext to allow you to boot to windows. You could also put something in front of it like reEFInd
• ec109685 2y ago
  Just because the boot loader is using Linux, it doesn’t prevent an alternative OS from being booted into, so there is nothing fundamentally stopping all of grub’s features from working in this new scheme.
  • jchw 2y ago
    It is a bit more complex, though. Quoting "nmbl: we don’t need a bootloader" from last month[1]: > - Possibility to chainload from Linux while using Secure / Trusted boot: Dual-booting, although not supported on RHEL, is important for Fedora. While there are attempts to kexec any PE binary, our plan is to set BootNext and then reset, which will preserve the chain of trust that originates in firmware, while not interfering with other bootloaders. It could be seen as an advantage to do chainloading by setting BootNext and resetting. I think Windows even does this now. However, it certainly is a different approach with more moving parts (e.g. the firmware has to not interfere or do anything stupid, harder than you'd hope) and it's definitely slower. It'd be ideal if both options were on the table (being able to `kexec` arbitrary UEFI PE binaries) but I can't imagine kexec'ing random UEFI binaries will ever be ideal. It took long enough to really feel like kexec'ing other Linux kernels was somewhat reliable. [1]: https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need-a-bootloader/ https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need...
    • bityard 2y ago
      Let's say I have a dual-boot system with two totally independent OSes, Systems A and B. It is powered down. I want to boot into System B but the EFI is configured to boot into System A by default. Am I correct in understanding that the offered solution here is to first boot into System A, find some well-hidden EFI configuration utility (which varies from OS to OS, if it even exists), and then tell EFI to boot into System B on the next reboot? If so, that's a pretty terrible experience.
      • superb_dev 2y ago
        Presumably nmbl would show you a menu to select the which OS start if you’re dual booting. You wouldn’t have to manually set some UEFI variable
      • jchw 2y ago
        Sort of, except it's automated. Basically, System A's kernel boots. But, instead of immediately loading the System A userland, it loads a boot menu of systems that it reads from UEFI NVRAM and presents it to the user. So you select System B from the list, the menu sets BootNext in NVRAM and issues a reboot. In practice, the main UX difference is that it takes a bit longer and you'll see the UEFI vendor splash screen again after selecting the boot option. I'm not a user of Windows anymore but I seem to recall Windows doing something quite similar, where it had a boot menu that felt suspiciously like it was inside of Windows, and to actually change the boot target, it had to reboot.
        • derefr 2y ago
          > instead of immediately loading the System A userland I mean, it kind of is loading the System A userland. At least the initramfs of it. AFAICT in the proposal the bootloader would now be a regular userland program living in the initramfs. I get the impression that the eventual goal would be to make this bootloader program into the "init(8) but for the initramfs phase of boot" — i.e. rather than there being a tool like update-grub that calls mkinitramfs, feeding it a shell-script GRUB generated (which then becomes the /init of the initramfs); instead, there'd be a tooling package you'd install that's related to the kernel itself, where you call e.g. kernel-update(8) and that would call mkinitramfs — and the /init shoved inside it would be this bootloader. This bootloader would then be running for the whole initramfs phase of boot, "owning" the whole bootstrap process. What the architecture is at that point, I'm less clear on. I think either way, this initramfs userland, through this bootloader program, will now handle both the cases of "acting like a bootloader" and "acting like the rest of initramfs-based boot up to pivot-root." That could mean one monolithic binary, or an init daemon and a hierarchy of services (systemd: now in your bootloader), or just a pile of shell scripts like GRUB gives you, just now written by Redhat.
• nerdponx 2y ago
  rEFInd is the magic tool here. Personally I still use GRUB for all of the reasons you stated above. But rEFInd + kernel gets you pretty close.
  • zekica 2y ago
    rEFInd is great! I wish they just updated the default theme to something nicer.
  • smeg_it 2y ago
    I've used gummiboot before systemd ate it; and I've used rEFInd. Mainly, I just followed the excellent documentation @ https://www.rodsbooks.com/ https://www.rodsbooks.com/; that's also how I first familiarized myself with UEFI (Thanks Rod!). My brain has leaked all the information I understood (unfortunately). Is rEFInd still active? Is there a gummiboot fork (besides systemd)? Personally, I kind of hate Redhat calling itself that now, it's IBM. You can tell because all of the online knowledge from the community on their websites are now pay-walled. RIP Redhat (CentOS) (I'll miss you) P.S. Thanks Rocky Linux (and others like it)
• throwway120385 2y ago
  If you embed an x86 system somewhere then you might find yourself not wanting to use GRUB because you don't want to display any boot options anywhere other than the Linux kernel. The EFI stub is really handy for this use case. And on platforms where UBoot is common UBoot supports EFI which makes GRUB superfluous in those cases. Many of the Linux systems I support don't have displays and EFI is supported through UBoot. In those cases you're using a character-based console of some sort like RS232. A lot of those GRUB options could also be solved by embedding a simple pre-boot system in an initial ramdisk to display options, which maintains all of the advantages of not using GRUB and also gives you the ability to make your boot selection. The only thing GRUB is doing here is allowing you to select which kernel to chain-load, and you can probably do the same thing in initramfs too through some kind of kernel API that is disabled after pivot root.
  • Sesse__ 2y ago
    I must admit that on U-Boot platforms, I use U-Boot EFI to load grub-efi, so that I can have a non-terrible bootloader…
  • cool_beanz 2y ago
    I just have two kernels with two boot options in BIOS. I just hit F11 at boot time and choose a BIOS boot option for either kernel. Of-course, you need to add the entries in UEFI, either from UEFI shell either with some tool (efibootmgr). This scheme also supports secure booting and silent booting. The stubs are signed after being generated.
• Denvercoder9 2y ago
  What kind of machines are people using that entering the UEFI boot menu is difficult? On all three of mine I just press F10 during the first 5 or seconds the vendor logo shows, and I end up in a nice menu where I could select Windows, other kernels, memtest, or the EFI shell or setup.
  • mjg59 2y ago
    One easy way to meet Microsoft's boot time requirements is to skip input device enumeration, so there's a lot of machines meeting the Windows sticker requirements where entering the firmware either requires a bunch of failed boots or getting far enough into the boot process that you can be offered an opportunity to reboot into the setup menu.
    • Denvercoder9 2y ago
      Huh, today I learned. I'll consider myself lucky I didn't come across one of these machines yet.
      • Sakos 2y ago
        I've encountered way too many of these and I hate them with all my being.
      • p_l 2y ago
        If you want to have (legit) "Designed for Windows" and similar certification, you need to have an option to disable "fast boot" as well as option to enable it. The fast boot involves skipping a bunch of slower pathways using saved knowledge of minimal set of devices to bring up to boot the OS in happy path, and only reset to "slow path" if it fails. In fast boot, you're often unable to hit the button to enter the menu and at most get to it through windows "reboot to firmware" option.
    • Dwedit 2y ago
      I have a system where you need to hold down power when turning on the PC to get out of "Quick Boot" mode, and get the ability to get to the bios screen. It's a Sandy-Bridge-era Intel motherboard.
• yjftsjthsd-h 2y ago
  If I'm understanding correctly, it might help to point out that in spite of the title they are proposing a bootloader, which can still let you modify the cmdline, boot to other OSs, etc. It's just that the bootloader is itself using the Linux kernel so it can do things like read all Linux filesystems for "free" without having to rewrite filesystem drivers.
  • garaetjjte 2y ago
    It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.
    • TylerE 2y ago
      Theoretically, couldn't it just write to a "boot this image next time" field (is the legacy MBR area available?) and trigger a reboot?
      • adtac 2y ago
        The target image would need to reset that field so that a second reboot puts you back into the bootloader because otherwise you'll be stuck booting that image forever.
        • rcxdude 2y ago
          The image doesn't need to do it, that's how UEFI bootnext works: the firmware resets the flag before it loads the image.
      • garaetjjte 2y ago
        Well you could change default boot entry in efivars, but if you're relying on firmware for that why not use firmware provided boot menu anyway?
      • Arch-TK 2y ago
        The boot disk isn't guaranteed to be writable.
• zozbot234 2y ago
  > - it allows to edit the cmdline of the kernel to recover a system that does not boot, e.g. start in single user mode. That can really save your day if you don't have on hand an USB stick and another PC to flash it You can use the UEFI shell for this. It's kind of a replacement for the old MS-DOG command line.
• Dalewyn 2y ago
  >it allows to dual-boot with Windows easily Windows Boot Manager can chainload into any arbitrary bit of code if you point it where it needs to hand off. It's a feature that goes back to Windows NT (NTLDR) supporting dual boot for Windows 9x, but it can be repurposed to boot anything you would like so long as it can execute on its own merit. eg: Boot into Windows Boot Manager and, instead of booting Windows, it can hand off control to GRUB or systemd-boot to boot Linux.
  • fuzzfactor 2y ago
    >Windows Boot Manager can chainload into any arbitrary bit of code if you point it where it needs to hand off. With the NT6 bootloader this appears to be limited to operating only in BIOS mode using bootmgr.exe. The traditional chainloading is still possible by pointing to a binary file which is a copy of a valid partition bootsector, whether it is a Microsoft bootsector or not. The equalent BCD for UEFI mode uses bootmgr.efi (instead of bootmgr.exe), and does not seem to be capable of chainloading even when there is an equivalent BOOTSECTOR bootentry on the NT6 multiboot menu. It would be good to see an example of the NT6 bootloader successfully handling UEFI multibooting which includes starting Linux from the EXTx partition it is installed on. Still works perfectly in BIOS since early NT, but in UEFI not so much.
• 1vuio0pswjnm7 2y ago
  As much as I generally detest indirection, for me a bootloader is a necessity; I need the flexibity to boot different OS kernels. AFAIK, UEFI offers no such flexibility. NetBSD's bootloader is best for me. UEFI seems like an OS unto itself. A command line, some utilties and network connectivity (UNIX-like textmode environment) is, with few exceptions, 100% of what I need from a computer. To me, UEFI seems potentially quite useful. But not as a replacement for a bootloader.
  • sholladay 2y ago
    > I need the flexibity to boot different OS kernels. AFAIK, UEFI offers no such flexibility. Isn’t this how Apple’s Bootcamp works (at least on Intel based Macs)?
  • cool_beanz 2y ago
    >I need the flexibity to boot different OS kernels. AFAIK, UEFI offers no such flexibility. Yes it does, I use it with two kernels, just have different entry for each stub in UEFI. Whenever I want to boot the non-default kernel I just hit F11 (for BIOS boot menu, on my motherboard) and choose the boot option. You just need to add the boot options in UEFI, pointing to the corresponding EFI files. They also have the kernel command line parameters baked into them and you can set your desired ones (silent boot whatever).
    • 1vuio0pswjnm7 2y ago
      Thank you.
      • fuzzfactor 2y ago
        You can also craft a text file named startup.nsh, and if present in the root (or ~nearby) of the FAT32 EFI partition, on bootup its UEFI commands will be executed rather than the default firmware selection. If a motherboard doesn't have enough UEFI commands in its built-in Shell (or has no built-in Shell at all), you'll want to include your own Shell.efi file right there along with any startup.nsh you might decide to deploy. This can also be good for USB booting where the removable USB device is in regular MBR layout rather than GPT-style-partitioning. Whether or not the whole USB drive is FAT32 or not, as long as there is a proper EFI folder in a UEFI-recognizable filesystem, you can boot to any other OS on any other filesystem, depending only on the contents of the EFI folder. Unless there is a startup.nsh for the UEFI to follow instead, then you might not even need an EFI folder. As intended. Boot floppies still work as designed too. Startup.nsh is more commonly expected to contain reference to an EFI folder that is present on some recognizable filesystem, rather than work as a lone soldier though. GPT-layout partitions are not supposed to be necessary either, it's only needed when you want more partitions than legacy BIOS will handle, or partitions that are too huge for MBR representation. Now any alternative to GRUB would by necessity have to perform more pleasingly on legacy-compatible systems where UEFI is not enabled also, or it will remain a less-effective alternative. Once a geek is smart enough to handle both BIOS & UEFI, the more I would be able to trust their UEFI solution.
• ziml77 2y ago
  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 that the reboot actually goes back into Windows.
  • joe5150 2y ago
    Not in my experience. For my typical dual boot situation where Grub is installed as the bootloader, I have to update the Grub settings like so to allow Windows updates to go smoothly: GRUB_DEFAULT=saved GRUB_SAVEDEFAULT=true
    • lproven 2y ago
      I am not certain about this, but I think that these options no longer work on UEFI machines. GRUB does not have control over what options are presented if GRUB isn't the selected bootloader. This stuff is BIOS-only.
      • ndiddy 2y ago
        I have this working on a UEFI system. You select your Linux drive in the UEFI configuration (so the computer always boots into GRUB) and then GRUB will boot into Linux or Windows depending on the last saved option.
        • lproven 2y ago
          Sure, but whether that GRUB entry is remembered as the default is up to the UEFI not GRUB. If you pick another entry GRUB is powerless to effect it.
          • ndiddy 2y ago
            The GRUB_DEFAULT and GRUB_SAVE_DEFAULT settings don't affect the UEFI settings, they only affect the default boot option in GRUB's boot menu. From the UEFI configuration perspective, the boot option never changes and it's always set as the drive with GRUB installed on it.
• 29athrowaway 2y ago
  I need a bootloader that automatically deletes Windows partitions upon detection. And is also themed like XBill.
• radium3d 2y ago
  I dual boot Win/Arch easily with EFISTUB setup. It's super quick to boot to a usb stick of arch if I need to edit anything with the configuration in an "emergency" situation as well. https://wiki.archlinux.org/title/EFISTUB https://wiki.archlinux.org/title/EFISTUB
• eru 2y ago
  You left out the most important reason I went back to using grub: some motherboards have dodgy UEFI support, and having an extra layer of indirection seems to be more robust sometime for some reason.
• Timber-6539 2y ago
  > - it allows to edit the cmdline of the kernel to recover a system that does not boot, e.g. start in single user mode. That can really save your day if you don't have on hand an USB stick and another PC to flash it This is an indication of bad admin choice. The kernel defaults should not corrupt the boot process and if you add further experimental flags for testing you ought to have a recovery mechanism in place beforehand.
• herewulf 2y ago
  It allows you to enter your passphrase to unlock your Linux LUKS partition before you even get a menu to chainload Windows. At least this is what an Arch Linux derivative (Artix) system of mine does, amusingly. It sort of gives an observer the impression that it's an encrypted Windows system on boot.
• account42 2y ago
  > 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 Hardly a problem in my experience - just hold down the key while booting. And dual booting is rarely needed anyway and generally just a pita. Just always boot into your preferred OS and virtualize the other one when you really need it. > also modern bootloader save the last boot option such that if Windows reboots for an update Linux does not start You can change the EFI boot entries including priority from the OS, e.g. via efibootmgr under Linux. Should be easy to setup each OS to make itself the default on boot if that's really what you want. > it allows to edit the cmdline of the kernel to recover a system that does not boot, e.g. start in single user mode. That can really save your day if you don't have on hand an USB stick and another PC to flash it All motherboards I have used had an EFI shell that you can use to run EFI programs such as the Linux kernel with efistub with whatever command-line options you want. > it allows you to choose between multiple kernels and initrd images easily, again for recovery purposes EFI can have many boot entries too. > it has a voice for entering the UEFI setup menu What does "a voice" here mean? Or you meant "a choice"? Either way, same as with the boot menu you can just hold down the key while booting IME. > it allows you to boot any other EFI application, such as memtest, or efi shell. Most UEFI firmwares doesn't have a menu to do so. In my experience the EFI shell has always been accessible without a bootloader.
  • littlecranky67 2y ago
    > And dual booting is rarely needed anyway and generally just a pita. Just always boot into your preferred OS and virtualize the other one when you really need it. I've been dual-booting linux since the kernel 2.2.x era and being able to do it was a major driver to migrate away from windows. It is super important for onboarding of new users that can't yet get rid of windows fully - mostly because of gaming (yes proton is nice, but anything competive that uses anti-cheat won't work yet is the majority share of gaming). And that is the reason I still boot into Windows on my dual-boot machine: Gaming. For me that windows is just a glorified bootloader into GoG or Steam, yet desperately needed and virtualization won't solve anything here.
    • 2y ago
• prmoustache 2y ago
  > - 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 virtualization extensions there is virtually zero overhead in using VM nowadays and it is much more convenient than rebooting and losing all your open applications just to start one on another OS. > - it allows you to boot any other EFI application, such as memtest, or efi shell. Most UEFI firmwares doesn't have a menu to do so. How many times in a decade are you running memtest? Getting to UEFI firmware or booting another OS/drive is just a matter of holding one key on my thinkpad. I would just simply not buy and bad hardware that doesn't allow me to do that. Vote with you wallet damit. I would also argue that you can perfectly have grub sitting alongside a direct boot to kernel in an UEFI setup. There are many other bootloaders than grub and users are still free to use them instead of what the distro is shipping. UEFI basically allows you to have as many bootloader as you have space on that small fat partition.
  • messe 2y ago
    > Do people really dual boot a lot in 2024? Yes, there are still use cases for it. The state of GPU virtualisation, for example, is a spectrum from doesn't exist/sucks to only affordable for enterprise customers. So unless you have a second graphics card to do pass through with, if you want to use your GPU under both OSes then you almost always have to dual boot (yes, there are other options like running Linux headless, but it's not even remotely easier to set up than dual boot)
    • prmoustache 2y ago
      Most mainboards comes with an integrated gpu though? If you use that one for the host OS, it is easy to pass the discrete through no?
      • korhojoa 2y ago
        Consumer motherboards haven't had gpus for a while now (IPMI usually comes with one, so servers do), they're built in to the CPU (if they are, not all cpus have them). These can't usually be easily allocated to a vm.
• notorandit 2y ago
  Maybe it is time to re-think the entire hardware boot process and ditch the BIOS altogether.
  • lproven 2y ago
    It probably was, but UEFI was not a good answer. I'd have preferred CoreBoot or OpenFirmware, but the PC industry was too slow to move and let Intel -- still smarting from Microsoft forcing it to adopt AMD's 64-bit x86 extensions -- take control of the firmware.
    • surajrmal 2y ago
      The problem with all of the alternatives is that they aren't friendly for alternative OS. They mostly operate on a fork model, so upstreaming support for an OS doesn't mean everyone using that bootloader will support your OS. You either need to pretend to be Linux with a sort of boot shim, or build and flash a custom bootloader with support, which might be non trivial if you cannot get access to the forked bootloader's code. UEFI is just a standard interface, not an implementation of a bootloader. This enables multiple UEFI compliant implementations as well as an easy way for OS to support all UEFI based bootloaders without needing to coordinate with the owner of the bootloader. While I'm sure most would agree the UEFI interface may not be ideal, it has a lot of industry momentum, and is therefore probably the best option to get behind. There are a lot of players in this space (mostly hardware vendors) and coordinating anything is very difficult and takes a very long time.
      • lproven 2y ago
        Both the suggestions I gave were designed and built to be FOSS and work with any OS. UEFI is more restrictive -- and tightly controlled by large industry vendors, not the community -- than either of them. So, no, I totally disagree on all points.
        • p_l 2y ago
          OpenFirmware is similar level of complexity as UEFI, to be quite honest, and lacks certain mechanisms that were designed into ACPI (and inherited by UEFI) precisely to support multiple different operating systems without requiring the OS to be have specialty drivers for every little bit. Sure, in the happy path, you can depend on OpenFirmware giving you parameters like locations and addresses and "this device is compatible with X so you can use its driver", but it still requires that you have the specific driver the device is compatible with, and a new hardware release was often incompatible with older versions of OSes because, unlike ACPI, you can't encode information like "Hey, I'm compatible with interface X version Y" => "here's limited functionality because your driver is not updated for interface X version Y+1 but the computer will work". Instead you had special "hardware support releases" to get the OS to boot at all. CoreBoot and uboot by itself provide even less support. They might have open source, but they provide effectively closed platform to the end user. UEFI is in practice less restrictive because I only have to program to the interface, and in absence of gross bugs, I can expect things to work - whether it's a boot-time driver to support my super-duper-special storage add-in card, or a custom OS that I want to be available for normal people to try out by running on their random home PC. Hell, if Linux kernel people didn't tell they would no longer accept "platform definition" patches, you probably still wouldn't have FDT used on ARM with uboot.
• dheera 2y ago
  > it allows to edit the cmdline of the kernel to recover a system Except they've made it increasingly harder to do this over the years. Nowadays you have to guess when it is on the magic 1 second of "GRUB time" before it starts loading and then smack all the F keys and ESC key and DEL key at the same time with both hands and both feet because there is nothing on the screen that tells you which key it actually is. All while your monitor blanks out for 3 seconds trying to figure out what HDMI mode it is using, hoping that after those 3 seconds are over that you smacked the right key at the right time. And then you accidentally get into the BIOS instead of the GRUB. It used to be a nice long 10 seconds with a selection menu and clearly indicated keyboard shortcuts at the bottom, and you could press ENTER to skip the 10 second delay. That was a much better experience. If you're in front of the computer and care about boot time, you hit enter. If you're not in front of the computer, the 10 seconds don't matter. I know you can add the delay back, I just wish the defaults were better.
• markandrewj 2y ago
  It is bold of RedHat to claim this is 'their solution'. UEFI has already been used for years to boot without grub. Some examples, MacOS, HP-UX, or systemd-boot via UEFI.