4 ms·

Systemd-boot (aka gummiboot) ist completely separate from the systemd init system. It can boot any EFI-compatible OS, even Windows.

by fsh 7y ago

imglorp 7y ago
Maybe it stick with the gummiboot name instead of inciting that other riot.
Izkata 7y ago
In that case, why was it merged in at all?
- pengaru 7y ago
  Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository? It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general.
  - ghostpepper 7y ago
    Are there actually a lot of shared components between systemd (the init system), systemd-boot, and systemd-(everything else in systemd)?
    - pengaru 7y ago
      I haven't audited systemd-boot specifically but just look at bootctl.c's "" includes [0], those come from the systemd source tree, and very little is in the src/boot/ subdir. Consider the fact that the project is all relatively low-level C code without any external bloaty dependency like glib bringing simple data structures like linked lists and hash tables to the party. There's heaps of useful stuff in-tree, and its being maintained as a whole and kept in sync, in a similar style to the kernel. Poke around [1] [2] [3] for some idea of what's there. [0] https://github.com/systemd/systemd/blob/master/src/boot/bootctl.c#L15 https://github.com/systemd/systemd/blob/master/src/boot/boot... [1] https://github.com/systemd/systemd/tree/master/src/basic https://github.com/systemd/systemd/tree/master/src/basic [2] https://github.com/systemd/systemd/tree/master/src/libsystemd https://github.com/systemd/systemd/tree/master/src/libsystem... [3] https://github.com/systemd/systemd/tree/master/src/shared https://github.com/systemd/systemd/tree/master/src/shared
  - danellis 7y ago
    Which components are shared between userland and the UEFI environment?
    - qqssccfftt 7y ago
      Whatever magic is powering the ability to just run ``systemctl kexec`` and have it automatically reboot into the same kernel you selected at boot without going through UEFI again.
      - yjftsjthsd-h 7y ago
        kexec works fine if you invoke it directly and tell it what kernel+initrd to use, regardless of bootloader; if anything, I'd consider it a failing that systemd can't manage to control a kexec without controlling the bootloader as well
    - pengaru 7y ago
      I don't really understand what you're asking. Edit: Do you mean the component that actually implements the boot loader? I'm not sure if there's any sharing there at this time, it's probably largely as-is from the gummiboot import. This isn't an area I've worked on personally, but you can poke around if you want: https://github.com/systemd/systemd/tree/master/src/boot/efi https://github.com/systemd/systemd/tree/master/src/boot/efi
  - AnthonyMouse 7y ago
    > Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository? I think this is the exact reason why the people who hate it, hate it. You put everything together like that and it encourages mutual interdependencies. It becomes an ordeal to make a thing to replace a part of systemd that isn't in that repository because they could break any interface at any time and easily update their own version of it everywhere while breaking yours. Worse, even if your version of a thing systemd does doesn't depend on other parts of systemd, other parts of systemd start to depend on the systemd version of what your program does, which pushes people to use it instead of yours. It somehow feels like something old school Microsoft would do. > It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general. That's because drivers inherently are tightly coupled to kernel interfaces. And drivers are special because hardware never really ceases to exist. The drivers for some 100Mbps network card from 1997 from a defunct vendor still work, and you want them to still work, but the only changes that will ever get made to them is updating them to use newer kernel interfaces as they change. In other words, you don't have a third party who is going to release a newer version anyway and can use that as an opportunity to switch to the newer interfaces. The only reason to modify most of the existing legacy drivers is to switch to newer kernel interfaces, which has to be done for most all of them if you're ever going to remove the old interfaces, which gives the kernel developers the largest incentive to be the ones to do it. It's also uncommon to have multiple independent third party open source drivers for the same piece of hardware, so having more-and-better competing third party driver implementations was not a thing that was going to happen in the alternative. Naturally this doesn't apply to most other system components, which benefit from being modular and having clean stable interfaces between them and the opportunity for third party developers to establish a new implementation if the existing ones don't suit them.
  - Brian_K_White 7y ago
    You can't describe all this tight-coupling, and at the same time still claim it's fully separate.
- sedatk 7y ago
  I think systemd will eventually become a standalone operating system.
  - BenjiWiebe 7y ago
    I'd run it.
- inshadows 7y ago
  So that Lennart gets commit rights and veto power, obviously.
- nickik 7y ago
  Why is BSD one project? Sometimes people like to put lots of software in the same repo.
BasicObject 7y ago
So you're saying I can pull an SSD with a working Windows 10 installation from another computer and plug it into a GNU/Linux system running systemd-boot and it will boot Windows 10? (Ignoring any potential driver issues that may arise from the difference in hardware and [most likely] violating the Microsoft EULA)
- osamagirl69 7y ago
  I am not sure why you would want to start with an install of windows from a different machine, but yes booting to a different hard drive has been supported for a long time. You just chainload to the windows boot manager on the other disk, I think that if you point bootctl at the new disk it will even add an appropriate entry for you automatically.
  - yrro 7y ago
    > You just chainload to the windows boot manager on the other disk Isn't this impossible with bitlocker?

Systemd-boot (aka gummiboot) ist completely separate from the systemd init system. It can boot any EFI-compatible OS, even Windows.

by fsh 7y ago

Systemd-boot (aka gummiboot) ist completely separate from the systemd init system. It can boot any EFI-compatible OS, even Windows.

imglorp 7y ago

Maybe it stick with the gummiboot name instead of inciting that other riot.

Izkata 7y ago

In that case, why was it merged in at all?

pengaru 7y ago
Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository? It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general.
- ghostpepper 7y ago
  Are there actually a lot of shared components between systemd (the init system), systemd-boot, and systemd-(everything else in systemd)?
  - pengaru 7y ago
    I haven't audited systemd-boot specifically but just look at bootctl.c's "" includes [0], those come from the systemd source tree, and very little is in the src/boot/ subdir. Consider the fact that the project is all relatively low-level C code without any external bloaty dependency like glib bringing simple data structures like linked lists and hash tables to the party. There's heaps of useful stuff in-tree, and its being maintained as a whole and kept in sync, in a similar style to the kernel. Poke around [1] [2] [3] for some idea of what's there. [0] https://github.com/systemd/systemd/blob/master/src/boot/bootctl.c#L15 https://github.com/systemd/systemd/blob/master/src/boot/boot... [1] https://github.com/systemd/systemd/tree/master/src/basic https://github.com/systemd/systemd/tree/master/src/basic [2] https://github.com/systemd/systemd/tree/master/src/libsystemd https://github.com/systemd/systemd/tree/master/src/libsystem... [3] https://github.com/systemd/systemd/tree/master/src/shared https://github.com/systemd/systemd/tree/master/src/shared
- danellis 7y ago
  Which components are shared between userland and the UEFI environment?
  - qqssccfftt 7y ago
    Whatever magic is powering the ability to just run ``systemctl kexec`` and have it automatically reboot into the same kernel you selected at boot without going through UEFI again.
    - yjftsjthsd-h 7y ago
      kexec works fine if you invoke it directly and tell it what kernel+initrd to use, regardless of bootloader; if anything, I'd consider it a failing that systemd can't manage to control a kexec without controlling the bootloader as well
  - pengaru 7y ago
    I don't really understand what you're asking. Edit: Do you mean the component that actually implements the boot loader? I'm not sure if there's any sharing there at this time, it's probably largely as-is from the gummiboot import. This isn't an area I've worked on personally, but you can poke around if you want: https://github.com/systemd/systemd/tree/master/src/boot/efi https://github.com/systemd/systemd/tree/master/src/boot/efi
- AnthonyMouse 7y ago
  > Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository? I think this is the exact reason why the people who hate it, hate it. You put everything together like that and it encourages mutual interdependencies. It becomes an ordeal to make a thing to replace a part of systemd that isn't in that repository because they could break any interface at any time and easily update their own version of it everywhere while breaking yours. Worse, even if your version of a thing systemd does doesn't depend on other parts of systemd, other parts of systemd start to depend on the systemd version of what your program does, which pushes people to use it instead of yours. It somehow feels like something old school Microsoft would do. > It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general. That's because drivers inherently are tightly coupled to kernel interfaces. And drivers are special because hardware never really ceases to exist. The drivers for some 100Mbps network card from 1997 from a defunct vendor still work, and you want them to still work, but the only changes that will ever get made to them is updating them to use newer kernel interfaces as they change. In other words, you don't have a third party who is going to release a newer version anyway and can use that as an opportunity to switch to the newer interfaces. The only reason to modify most of the existing legacy drivers is to switch to newer kernel interfaces, which has to be done for most all of them if you're ever going to remove the old interfaces, which gives the kernel developers the largest incentive to be the ones to do it. It's also uncommon to have multiple independent third party open source drivers for the same piece of hardware, so having more-and-better competing third party driver implementations was not a thing that was going to happen in the alternative. Naturally this doesn't apply to most other system components, which benefit from being modular and having clean stable interfaces between them and the opportunity for third party developers to establish a new implementation if the existing ones don't suit them.
- Brian_K_White 7y ago
  You can't describe all this tight-coupling, and at the same time still claim it's fully separate.
sedatk 7y ago
I think systemd will eventually become a standalone operating system.
- BenjiWiebe 7y ago
  I'd run it.
inshadows 7y ago
So that Lennart gets commit rights and veto power, obviously.
nickik 7y ago
Why is BSD one project? Sometimes people like to put lots of software in the same repo.

BasicObject 7y ago

So you're saying I can pull an SSD with a working Windows 10 installation from another computer and plug it into a GNU/Linux system running systemd-boot and it will boot Windows 10? (Ignoring any potential driver issues that may arise from the difference in hardware and [most likely] violating the Microsoft EULA)

osamagirl69 7y ago
I am not sure why you would want to start with an install of windows from a different machine, but yes booting to a different hard drive has been supported for a long time. You just chainload to the windows boot manager on the other disk, I think that if you point bootctl at the new disk it will even add an appropriate entry for you automatically.
- yrro 7y ago
  > You just chainload to the windows boot manager on the other disk Isn't this impossible with bitlocker?