1

Changing grub with systemd boot

3 Likes
2

This only works for efi based systems, so no more support of legacy BIOS systems?

1 Like
3

we can have options like what we see in arch

4

We can’t test and support an infinite array of options in our main offerings. That’s also a confusing puzzle for end users.

But that’s not the end of things — you can make a Fedora Remix or even an official spin that implements these ideas.

2 Likes
5

Not a hard suggestion, but maybe an “advanced options” somewhere in the installer with options for bootloader selection and extra (if any) packages to be installed or removed

Just a thought I wanted to share

1 Like
6

we are discussing about removing xorg in 40 so we can have that also as now most systems are efi.

7

Yes, I’ve been cleaning up the install process for systemd-boot. If you grab the latest F39 everything/network ISO and put ‘inst.sdboot’ on the grub command line anaconda will install a systemd-boot system. Now, there is a gocha with the F39 image which will hopefully be fixed RSN, which is the btrfs subvolume parameter isn’t provided correctly, which will cause the machine to fail. So either install with XFS/ext4 or put rootflags=subvol=root on the systemd-boot/kernel command line on the first boot, then update the loader entries to persist it.

Now that said, there is a relatively long list of TODO’s before this should be exposed to the end users, including fixing lorax to understand it, fixing all the ostree install images, signing systemd-boot, assuring the UKI works, etc.

8 Likes
8

That is not the same thing as removing an entire working block of existing hardware, that in some peoples cases is very likely near impossible to replace.

1 Like
9

Will it not be usable with 39 then?

Just tried Installation in a VM (with inst.sdboot) and it didn’t work. The workstation iso had anaconda crash and server network iso didn’t boot.

10

The workstation image is a live image already installed with grub, there isn’t an easy way to change it over from anaconda short of moving 1/2 the /boot and /efi directories around, removing grub packages, etc. There is a PR that will disable it for F39 when running on live media.

If you want a systemd-boot based workstation, you should use the everything media and select the workstation package group.

Regarding server network install not booting, your talking about the fedora provided ISO? Because that sounds unrelated.

2 Likes
11

Regarding workstation, thank you. Will try with the full DVD and not live media

Regarding server, reading it back, there is some clarification needed: iso itself boots, but after installation using network iso, booting from HDD fails. And this is meant with inst.sdboot param.

12

Is the filesystem XFS or BTRFS? It should be XFS if your using a full server ISO, but if not, you will need rootflags=subvol=root to boot it until the patch from above lands.

13

It was ext4.

So, does it mean that inst.sdboot doesn’t work with network iso as well?

14

No, it should be working with the server images, do you know what it printed when it failed? Do you have secure boot enabled? If so it needs to be disabled because systemd-boot isn’t yet signed.

15

Not really sure what was printed, but I can try again and post screenshot of the problem if this would help.

Don’t remember for secure boot, I guess whatever is the default using boxes on gnome host.

16

I’m guessing its the same as virt-manager/libvirt which defaults it on. You might try going into the bios on the VM and disabling it.

17

You were right. The reason it didn’t work was secure boot. Once I disabled it, it worked fine. Thanks!

So, the summary is:

  • live media doesn’t work for systemd-boot installation, but full media or network iso works
  • secure boot is not supported
  • btrfs cannot be used ootb, manual adjustment needed until the bug with kernel params is solved. Ext4 and xfs work fine.

Few questions:

  • is secure boot planned for being ready for f39 ga?
  • is btrfs fix going to be included in anaconda for final iso?
  • is there going to be a migration plan (e.g. a package that would Format EFI partition, call systemd-boot --install or something, copy kernel to EFI partition and make a default loader)
  • what about bcachefs once it lands?
18

Short answers from my perspective:

1, No, the secure boot path has some existing complexities that need further work.
2, I hope so.
3, I’m not aware of any migration plans, it is still not really a complete feature and until that settles migration plans are liable to change as well (ex secure boot).
4. ? Should be a non issue? If you are concerned because of btrfs, that issue is hopefully a one-off btrfs problem rather than a generic filesystem problem with the way Anaconda provides (or didn’t in this case) rootfs parameters to the bootloader.

2 Likes
19

Great. Thank you for the replies. I kind of have a picture what to expect now.

20

Will fedora switch to systemd boot

4 Likes