search

AsahiLinux / asahi-scripts

Miscellaneous admin scripts for the Asahi Linux reference distro
MIT License
46 stars 31 forks source link

sd-asahi hook: asahi hook that works with systemd (and some docs) #21

Closed b-crumb closed 1 year ago

b-crumb commented 1 year ago

Preface

For users (like me) who wish to use Asahi with the systemd hook, I propose the sd-asahi hook and related utilities to be added to asahi-scripts. I would like to also note that this hook has been tested, and works, with a LUKS setup (I am posting this from an sd-asahi setup).

This PR also contains a README.md file for the repository which mostly focuses on the aforementioned utilities and manually managing m1n1, it also mentions some installation related stuff in general.

Design considerations

The most important point is that if this PR is merged, the base asahi hook stays the default hook and way the distribution is used. The README mentions the necessary steps to actually activate the sd-asahi version. Per default though, the asahi-scripts package install will add the sd-asahi files to the filesystem, because sd-asahi does not, as mentioned, interfere with base, and does not require extra user behaviour when it comes to package management. This includes renaming the preset files, sd-asahi will account for it on uninstallation.

Furthermore, the behaviour of the sd-asahi hook can keep automatically up-to-date with the behaviour of the asahi hook, because during the make build, the contents of the asahi build & run hook are modified and concatenated into the sd-asahi install hook and the fwhooks script (which is used by the units), respectively. This means for regular changes, if changing modules as an example, that the maintainer does not have to concern himself with also keeping the sd-asahi utilities up-to-date. On the other hand, when it comes to changes which do sufficiently alter behaviour, the sd-asahi utilities do have to be maintained. The sd-asahi-build script is an ok indicator on what behaviour might break the utilities if not maintained.

How it works

The systemd units are simply the equivalent of the early and late hook of the asahi run hook, with ordering being handled by the targets which pulls (Requires) the services in. The services both use the same fwhooks script, which as the formerly mentioned concatenated logic. There is no changes to the earlyhook (here called early_load), but the latehook (late_mount) does implement the additional functionality of waiting for vendorfw and sysroot/lib to become available, due to the different and non-sequential (at least in the base hook sense) ordering of service activations and the fact that seemingly the initrd-fs.target does not actually imply sysroot is fully mounted.

Conan-Kudo commented 1 year ago

I'm pretty sure we intentionally don't use systemd units in initramfs. I originally thought about doing this when I wrote the dracut module, but decided not to because it complicates how the startup works and doesn't provide much value outside of initramfs anyway.

b-crumb commented 1 year ago

I'm pretty sure we intentionally don't use systemd units in initramfs. I originally thought about doing this when I wrote the dracut module, but decided not to because it complicates how the startup works and doesn't provide much value outside of initramfs anyway.

This is completely optional, from the users side, so I guess you suggest bloating. Maybe there could be an optional aur-like asahi repo, maybe I should just make a PKGBUILD and build this from my own branch and keep this updated on the AUR (I don't know whether the AUR cares about this not being pure-blooded x86_64)? My original reasoning:

  1. systemd boot worked with LUKS until firmware mounting was changed, then I made this to remediate the issue. I actually personally also agree that systemd should not be in kernel hooks, but I'm looking into why LUKS is not possible with base. Systemd resolved the issue more easily. I also don't see anyone working on resolving the base-LUKS issue but me for now, so this is the only thing that allows it to work.

  2. Someone might want to use it in future.

Conan-Kudo commented 1 year ago

It wasn't about bloating. It was about reliably getting things working early enough. I had serious trouble trying to get it to reliably handle this early enough through systemd services, so I ultimately decided not to do it that way.

b-crumb commented 1 year ago

It wasn't about bloating. It was about reliably getting things working early enough. I had serious trouble trying to get it to reliably handle this early enough through systemd services, so I ultimately decided not to do it that way.

Yeah I was about to edit my post because I felt that I expressed myself in a weird way. In any case, I will just leave this up for a little longer to get some other input if there will be some, but otherwise I will make a PKGBUILD from my own repo and suppose just follow upstream development.

EDIT: Also on reliability, I mean from my perspective this is reliable enough, also the intention isn't to make people think that this is "stable" in any way, I can write that out in the README with more clarity I guess.

The only thing is that systemd target thing. Why the services are being pulled in before mountpoints even though targets state otherwise - unknown - but "ok", a loop always works, does look a little ugly, but behaves how it should.

marcan commented 1 year ago

Can we unify this more with the non-systemd script? I'm not a huge fan of the sed hacks (plus the way it's done right now is not idempotent).

AIUI the systemd stuff overrides base, and runscripts from base are ignored. Conversely, systemd units would be ignored without systemd. Can we just merge all of this into the asahi hook and avoid the forking/sed/etc stuff that way? That would just make asahi compatible with both default and systemd setups.

b-crumb commented 1 year ago

Alright so, I thought about it once more:

  1. I don't think there is enough people I guess that need this exact combo.
  2. Kind of wanted to keep it separated because I actually don't like systemd containment in initrd myself but it's just working right now, I don't think it needs to be in scripts then I guess.
  3. I'd rather make the asahi hook work with LUKS and base natively if already touching.
  4. If I don't manage 3 I can come back with a more well designed solution for this.
  5. I will keep my repo available and rebuild, using my system as the reference, and using as the reference the notes which I will update hopefully today, such that people who want to deviate have sufficient resources to pull it off themselves.

So I'll just close this down and if you do want it for some reason then I can work on designing it more nicely, but I'd really like to have the asahi hook exclusively base compatible from my point of view.