NOTE: In its current state its not likely to handle multiboot and maybe other issues. This is an early state hack of @dalto s work at best…there be dragons here
Hey Everyone, its been a while
Ive had a lot going on these past couple months with almost being homeless lol but ive started working on some ideas for things to make EOS better for myself and others.
Recently Ive moved to using systemd-boot as it seems to be a touch faster boot time vs grub for me with minimal changes to the setup vs grub
This is a set of hooks to automate the creation of systemd boot entries. This is a modification of
I had to tweak it to work properly on EOS and it should work with only changing the “ENTRY_ROOT=” for regular Arch. This set of hooks assumes you followed the Arch Wiki for systemd-boot https://wiki.archlinux.org/index.php/Systemd-boot
Current bugs are
If you remove the base Arch kernel (you shouldnt do this anyway) it will wipe all of your systemd-boot entries. Ive yet to figure out how to fix this
Currently havent figured out how to change the default boot option automatically to the latest installed kernel. You can do it via terminal by using “sudo sdboot-manage default” and it will ask you which conf file should be the default
You tell me, Id like this to end up pretty universal
There were a few reasons I created systemd-boot-manager at the time
Manjaro had constantly changing kernel names since the kernel version was embedded into the kernel name
I was trying to create an experience as close to possible as the way grub is managed
I wanted an easy way to setup systemd-boot that could be automated in Manjaro Architect.
The reasons I have never championed it’s use on Arch are:
Arch doesn’t have changing kernel names like Manjaro so this is a lot of complexity to add for not much additional functionality
The kernel pattern matching stuff is likely to break if you are multi-booting distros
Since creating systemd-boot-manager, systemd-boot created a built-in method for doing this called kernel-install. I am in the process of testing a solution for EndeavourOS which fully automates the use of kernel-install. It should be ready soon.
If you are planning to maintain this for general use(as opposed to your personal use), there are some things you should be aware of
It needs ongoing maintenance since anything that changes the options line in a non-static way needs to be accounted for manually. This is most commonly a change with filesystems and/or encryption. This means you need to acquire a working knowledge of all that if you don’t already have it.
To properly test it requires a large investment in time since there are so many different filesystem and encryption combinations
It essential to have working knowledge of the whole script, since changes to one section can have unintended consequences. Most of the contributions I get need to be reworked by the authors because they have failed to understand the whole scope and inadvertently broken something else.
I took a quick look at what you did and have some specific comments
The reason removing the vmlinuz-linux kernel removes all the entries is because it has a shared root with all the other kernels. That doesn’t happen in Manjaro so you will need to modify that section to be more specific.
You removed the lines that set $kernelpath but you are still using the variable. The reason it is important is because many systemd-boot users keep the kernel/initramfs in subdirectories to better enable multi-booting.
Setting the pattern matching to vmlinuz-* is likely to cause problems if anyone is multi-booting. You may pull the kernels from other distros in.
All that kernel name parsing and reassembly can be simplified on Arch
The description/name/variant can be found with ${kernel#vmlinuz-}
The name of initramfs should always be "initramfs-${kernel#vmlinuz-}.img"
Hey thanks for the good criticism, and i would like to try and make it a more general option for creating systemd-boot entries, likely just Arch specific though but I havent thought about it.
Im learning about encryption/filesystems but am in no way and expert and wont claim to be.
I was actually looking to setup VMs for some testing to try and do this
Ive been creating separate scripts based on each section to test and try and make sure i get whats going on throughout the original.
Thanks again for the criticism and information, its been noted thoroughly
The bigger issue is going to be getting the time to do all of the testing Im working on 3 other projects too atm so I added a note at the top that this is a hack at best of your work so people can be aware this be dragons
made some adjustments based on feedback from @dalto (thanks a bunch), removed the systemd update hook as i want this to be just for entries and theres a perfectly good hook for that already.
Still working on bug #1, need to make the removal more specific
note: was running into an issue with initramfs line having a . at the beginning, currently it ignores the leading . but this may be a bad idea
note 2: This will likely be rendered pointless by what dalto is working on and his will probably be much better than my hack job of his old scripts
The grub-btrfs package places a snapshots entry in your list of bootable entries in grub. I’ve never actually selected one, but I presume it contains a sublist of all my current snapshots.
From a brief internet search, I’m guessing this functionality still isn’t possible with systemd-boot.
I am not sure that would be possible in systemd-boot. It is a much less complicated thing than grub. It doesn’t have submenus.
You could create entries for the snapshots but it would multiply them out. In other words, if you had two kernels and created entries for the last 5 snapshots you would have a list of 20 things.
Yeah this atm at least seems a bit outside of what systemd-boot can do in a nice way. It would likely balloon your entries significantly and be a mess with how it is now but possibly in the future.
Systemd-boot is supposed to be pretty dead simple which it does well and why i use it, but as for doing things like what youre looking at id probably stick to grub
This hasnt been replied to in a bit but i wanted to add a tip for those of us that do you systemd-boot.
Originally I had been working on a script to let me easily change the default boot entry in the loader.conf, but after looking into sd-boot a bit i found that making the script is completely unnecessary as sd-boot can handle this all on its own.
Normally it will automatically select which kernel to boot based on the current default title when it was setup and then use whatever is the newest kernel/highest version number kernel for that automatically. This means when installing custom kernels just add higher versioning to it and itll be used before default arch/distro kernel.
Now if you want to change your default its very simple. when booting stop at the bootloader menu by pressing space bar. Then select the entry you wish to be default and press D. This will select that entry as the default boot option for sd-boot with NO SCRIPT REQUIRED
If i wouldve taken the time to look at sd-boot i couldve saved myself some time testing and duplicating a feature that it already had, but at least i learned some things.
This works as long as your entry and version names are static. However, if they aren’t, it will no longer be selected once your kernel is updated.
I use a different trick. The default value in loader.conf accepts wildcards. So you can usually set a string that will boot the latest version of the kernel you want. Some thing like *zen.conf could be used to boot the latest zen kernel.
I dont use zen but does it use a different title besides “Arch Linux” and weird versioning in the conf file? So far for me I havent had any issues with TKG kernel once figuring this out but I also obviously dont cover all use cases.
The fact that loader also accepts wildcards can also make this convenient using your method.
Im working on 3 other projects too atm so I added a note at the top that this is a hack at best of your work so people can be aware this be dragons
)