Announcement

Collapse
No announcement yet.

Systemd Lands Support For "XBOOTLDR" Extended Boot Loader

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    I like the general idea, but I'm pretty sure no distro (apart from Fedora) is going to give a shit.

    Meanwhile, I do that with Refind (i.e. have a single "bootloader" type of thing that distros DO NOT touch)

    Comment


    • #42
      I prefer using refind and grub, just modifying a couple lines when I build a new kernel, and copy paste to other machines. Don't really need an init system to manage booting or logging. Don't care for people who chase oblivion either. The Unix philosophy works because it respects the nature of logic, SystemD respects RedHat's profit margins and market share.

      Comment


      • #43
        As others have pointed out, you don't need to constantly update your e.g. grub config if you keep the same name for updated kernels (and a fallback). And even if you did I don't see how XBOOTLDR (why is it in caps? it's not an acronym) would be any different - you'd still need to update your boot config each time, in would just be "easier". But seeing as distros that need to update boot configs will automate that as part of you package upgrade process it really doesn't matter. It's more about homogenising they way we config our system so it's the same as everything else, which meh whatever I don't really care.

        Don't get me wrong there are some features which seem genuinely useful and I would like to use, but this thread has bought rEFInd Boot Manager to my attention which seems to have those features already. I'll certainly be giving rEFInd a try out so thanks for everyone who has mentioned it!

        Comment


        • #44
          Originally posted by Danny3 View Post
          It would be awesome if this can be then used by Linux desktop environments to create a more complex restart menu like:
          -Restart into Linux (same distro)
          -Restart into Windows (or other operating system)
          Or even more complex like my Lineage OS has on my phone
          - Restart into System (same operating system)
          - Restart into Recovery mode
          - Restart into Download mode
          I don't know what Recovery and Download mode equivalent for Linux would be, but in any case the "Restart into Windows" for me would be very helpful.
          Can you not use efibootmgr?

          Code:
          efibootmgr -n 4
          which would select the fourth boot option on next boot

          source

          Comment


          • #45
            Originally posted by Murple View Post
            As others have pointed out, you don't need to constantly update your e.g. grub config if you keep the same name for updated kernels (and a fallback). And even if you did I don't see how XBOOTLDR (why is it in caps? it's not an acronym) would be any different - you'd still need to update your boot config each time, in would just be "easier". But seeing as distros that need to update boot configs will automate that as part of you package upgrade process it really doesn't matter. It's more about homogenising they way we config our system so it's the same as everything else, which meh whatever I don't really care.

            Don't get me wrong there are some features which seem genuinely useful and I would like to use, but this thread has bought rEFInd Boot Manager to my attention which seems to have those features already. I'll certainly be giving rEFInd a try out so thanks for everyone who has mentioned it!
            XBOOTLDR is dropping files into /etc/apt/sources.list.d while the current bootloader situation is requiring knowledge of how to safely edit /etc/apt/sources.list from every package or tool that wants to add a new source.

            I still haven't upgraded to a UEFI-based motherboard, so I'm not sure what downsides they're trying to avoid by not just using the UEFI boot menu, but the whole point is so that individual bootloader menu entries can be installed and configured without risk of stepping on each other's toes.

            Comment


            • #46
              Originally posted by pcxmac View Post
              The Unix philosophy works because it respects the nature of logic, SystemD respects RedHat's profit margins and market share.
              I get the impression you either misunderstand what the UNIX philosophy actually is or misunderstand what systemd is.

              For systemd, might I suggest this video? ("The Tragedy of systemd" from linux.conf.au 2019)

              For the UNIX philosophy, here's how it was stated back in 1978 before others started reinterpreting it:

              1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
              2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
              3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
              4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
              systemd, the project, is a collection of small tools, so it's compliant on that front and, as that video explains, the split between /etc/inittab (which can respawn things) and the init scripts (which handle more complex tasks) is an artifact of a system design when there weren't really any long-running daemons other than getty and inetd.

              The only real "must be used together" aspect is that the systemd developers aggressively take advantage of APIs that nobody is willing to maintain comparable alternative providers for.
              Last edited by ssokolow; 02 March 2019, 05:21 AM.

              Comment


              • #47
                Originally posted by Murple View Post
                As others have pointed out, you don't need to constantly update your e.g. grub config if you keep the same name for updated kernels (and a fallback).
                That's one of the reasons I think GRUB is a prehistoric piece of shit.
                rEFInd does not need you to keep the same name of the kernel as by default it re-scans every boot and will find new kernels and their initramfs on its own. (You can of course disable this and have it use a static config if you so choose, you can limit the folders it does this scan in, and so on)

                So for example on OpenSUSE where they don't overwrite kernels like that on upgrade I just disabled the "Bootloader" in Yast GUI and everything works fine without any further modification.

                So far the only distro that isn't working by default is Solus, and you have to boot into their bootloader first.

                Don't get me wrong there are some features which seem genuinely useful and I would like to use, but this thread has bought rEFInd Boot Manager to my attention which seems to have those features already. I'll certainly be giving rEFInd a try out so thanks for everyone who has mentioned it!
                It's theme support and GUI is also something you would expect in the 21st century, this is the theme I use https://github.com/bobafetthotmail/refind-theme-regular
                Its filesystem support is the same as GRUB as there is a project here http://efi.akeo.ie/ that splits the GRUB filesystem support as standalone drivers you can load in rEFInd or Clover (another EFI boot manager). Use only the drivers you need as for each driver you add it will slow down boot as it is scanning for that filesystem.

                Also, I rename the rEFInd folder into /EFI/BOOT (the default folder for the fallback bootloader), and renamed the refind efi binary into the default UEFI bootloader fallback name http://www.rodsbooks.com/refind/inst....html#fallback

                So I don't need to touch efivars at all, when I clone the drive or do other stuff, I only set the UEFI to "boot this drive as UEFI" and everything works, similarly to how it worked back then in BIOS times.

                Comment


                • #48
                  And unapproved post for Murple above

                  Comment


                  • #49
                    Originally posted by ssokolow View Post

                    ...but the whole point is so that individual bootloader menu entries can be installed and configured without risk of stepping on each other's toes.
                    Just like existing EFI boot managers right?

                    Edit: sorry I now realise you referring to drop in folders rather than single config file. Yep, but it relies on every OS getting on board with this standard?

                    Edit edit: yeah so I really don't read others posts properly sorry
                    Last edited by Murple; 02 March 2019, 06:03 AM.

                    Comment


                    • #50
                      Originally posted by starshipeleven View Post
                      And unapproved post for Murple above
                      What do you mean?

                      Comment

                      Working...
                      X