Announcement

Collapse
No announcement yet.

Fedora May Make It Easier To Switch To systemd-boot, Making A GRUB-Free System

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

  • #51
    Originally posted by FeRD_NYC View Post

    Fun fact: I maintained a dual-boot Windows/Fedora laptop (BIOS booting) for a while that had the /boot partition formatted NTFS instead of ext4, so that I could access it from Windows as well as Linux. Primarily, that allowed me to edit the grubenv even when booted into Windows, so that I could (for example) tell the system "reboot into Linux" directly from Windows, rather than having to catch a boot prompt and select a different option.

    Grub2 (and either Grub4dos or Grub2Win — I can't remember which I used, on the Windows side) supported all that just fine, but every 6 months Fedora's stuff — which is built with a lot of assumptions regarding the boot setup — would freak out when upgrading the OS, and eventually it proved more trouble than it was worth so I gave up on the idea.

    The systemd-boot setup will have to contend with all of those same built-in assumptions, but if it's being done as an accepted Change Proposal then the devs will have the necessary backing to actually change things. (Which would also benefit users who want to continue to use Grub2, but in non-standard ways like I was.)
    what about terabyte's bootit UEFI or refind = and edit the text config boot file to change boot os or Plop Boot Manager Six (PBM6) ?
    Last edited by onlyLinuxLuvUBack; 25 June 2023, 01:35 PM. Reason: forgot plop boot manager 6

    Comment


    • #52
      Originally posted by kreijack View Post

      I use sd-boot, and for me it works flawless; the only thing that I miss is that this setup doesn't allow to have kernel and initrd in the /boot directory, and often I fill the ESP one and I had to empty it. This is annoying. Having a /boot in the root solved this issue (or the empty is less often required).
      It actually does. If you you set boot partition type according to BootLoaderSpec[1], then it would work fine.

      [1] https://freedesktop.org/wiki/Specifi...ootLoaderSpec/

      Comment


      • #53
        My Fedora system takes up 11.26 GB archinstall with systemd-boot takes up just above 14 GB. I know it's not an issue. But on a pure Linux system you only get nice menus + something you can set up by hand.

        Systemd-boot can really chew through a lot of disk space depending on what you're doing of cause.

        Comment


        • #54
          Originally posted by iavael View Post

          It actually does. If you you set boot partition type according to BootLoaderSpec[1], then it would work fine.

          [1] https://freedesktop.org/wiki/Specifi...ootLoaderSpec/
          In what a BootLoaderSpec directory would be different from a ESP ? The limits of sd-boot is that it is capable to see only what EFI is capable to see...
          And anyway my comments was about NOT having a separate /boot partition.

          Comment


          • #55
            Originally posted by kreijack View Post

            It is not a problem of sd-boot, but more of the infrastructure around that.
            I think that around grub there are scripts that automate the passage:
            - do a snapshot -> updated the grub.cfg

            But nothing prevent to do the same with sd-boot.

            I think that is the classic problem: until a distribution starts to used a tool, the infrastructure doesn't grow enough to satisfy the all needing. Godd or bad, this fedora choice will help the grows of the infrastructure.
            Yes, it will most likely help, but many distros support multiple architectures, while Grub supports almost everything, systemd boot doesn't, this is the main reason to still use Grub and this is the reason why Grub is default on almost all distributions. It's hard to replace something that works in all use cases with something as limiting as sb.​

            Comment


            • #56
              Originally posted by woddy View Post

              Yes, it will most likely help, but many distros support multiple architectures, while Grub supports almost everything, systemd boot doesn't, this is the main reason to still use Grub and this is the reason why Grub is default on almost all distributions. It's hard to replace something that works in all use cases with something as limiting as sb.​
              Today, is it really so ?

              ARM -> uboot or eufi
              RISCV -> uboot or uefi
              POWERPC -> yaboot
              MIPS -> I don't remeber :-)
              X86 -> UEFI from last ~10 years

              The point is that, with the exception of the X86 legacy bios systems (which are older than 10 years), all the other systems have bootloader quite advanced, with capability to understand filesystem. In these case grub2 is overkilling.

              Grub was great when the PC BIOS based where the majority. Now sd-boot (or a uboot or equivalent properly configured) are good enough.

              Of course for advanced users or case (like booting ext4 over raid over luks), grub2 is still a good choice. But for all other cases it is only "another OS" between UEFI and LINUX.

              The point is: in the past when the Bios was very... Basic grub2 was needed. Now when the EUFI allows things that grub2 cannot (like secure boot[*]), grub2 is becoming more a problem than an opportunity for the majority of the cases. So I understand that the wiliness of some distribution to get rid of the complexity of grub.



              -[*] Technically grub2 allow secure boot, but to me it seems only to increase the surface attack without providing any benefits.

              Comment


              • #57
                Originally posted by kreijack View Post

                Today, is it really so ?

                ARM -> uboot or eufi
                RISCV -> uboot or uefi
                POWERPC -> yaboot
                MIPS -> I don't remeber :-)
                X86 -> UEFI from last ~10 years

                The point is that, with the exception of the X86 legacy bios systems (which are older than 10 years), all the other systems have bootloader quite advanced, with capability to understand filesystem. In these case grub2 is overkilling.

                Grub was great when the PC BIOS based where the majority. Now sd-boot (or a uboot or equivalent properly configured) are good enough.

                Of course for advanced users or case (like booting ext4 over raid over luks), grub2 is still a good choice. But for all other cases it is only "another OS" between UEFI and LINUX.

                The point is: in the past when the Bios was very... Basic grub2 was needed. Now when the EUFI allows things that grub2 cannot (like secure boot[*]), grub2 is becoming more a problem than an opportunity for the majority of the cases. So I understand that the wiliness of some distribution to get rid of the complexity of grub.



                -[*] Technically grub2 allow secure boot, but to me it seems only to increase the surface attack without providing any benefits.
                You gave yourself the answer, listing the use cases where grub is still needed and there would be others. The fact that today most PCs are uefi doesn't mean anything, as there is a large fleet of hardware that is old bios, not to mention some stubborn users who want to use legacy mode. So yeah, unless you want to make a selection, grub is still needed.​

                Comment


                • #58
                  Originally posted by woddy View Post

                  As for systemd-boot, my problem with it is that I can't boot Btrfs snapshots, I don't know if that has changed today, but until a while ago it wasn't possible.
                  This is a big limitation for me.​
                  It works in OpenSUSE – see this https://www.youtube.com/watch?v=drgo6pvn5hI

                  Comment

                  Working...
                  X