Arch pkgbase initramfs naming

[AlphaLynx0]

Arch Linux kernel packages include a pkgbase file that identifies the package
name (e.g., "linux", "linux-lts"). Bootloaders typically expect initramfs files named
by this pkgbase value, not by kernel version.

This adds pkgbase support. When the pkgbase file exists, initramfs
files are generated using Arch naming conventions (initramfs-{pkgbase}.img).
When it doesn't exist, behavior is unchanged (ugrd-{kver}.cpio.xz).

Also, add install and remove hooks/scripts (I'll add these in the ugrd-git and ugrd AUR packages).

[desultory]

This flow for arch setups seems much better, the only concern I have is here:
https://github.com/desultory/ugrd/pull/385/files#diff-6c9f5734efc559854204b7faa234aa3fbacb50d2a674b1e60d877bf9da7b0711R328
and/or here:
https://github.com/desultory/ugrd/pull/385/files#diff-6c9f5734efc559854204b7faa234aa3fbacb50d2a674b1e60d877bf9da7b0711R377

If it's an arch system and is being run by the package manager, I think it should raise an exception if it can't determine the output file name

It would also be possible to simply turn this arch detection stuff into its own autodetect hook which runs after "get_kernel_version" so the out_file can be set there and nothing needs to be adjusted in the cpio module.

The "get_archive_name" function should only be run if the out_file is not already set, so the logic there is mostly for determining a sane name if nothing is set. This custom arch function doesn't necessarily have to be in the kmod module either.

Within reason, things should not be setting "out_file" if it's already set unless it's certain it should get a custom name. In the case of gentoo systems, installkernel passes the file name it wants as an arg and that's simply used without any "internal" logic. If the install script/hook can somehow pass this info, most of the custom logic for arch stuff could possibly be removed.

If possible, I'd lean towards a way for the file name to be determined in the hook. (no extra internal logic)
If that's not reasonable, I think any internal logic should try to determine if it's being run by a package manager, and if so, it can use info from that system to determine the best file name. By setting out_file directly, no adjustments should need to be made to the cpio module.

[AlphaLynx0]

The install hook and script should guarantee that an initramfs is generated at /boot/initramfs-{pkgbase}.img whenever the package manager installs/upgrades a kernel package. (NeedsTargets passes the list of triggers to the script, which are then parsed to get the pkgbase to use for out_file arg)

I think /boot/initramfs-{pkgbase}.img should the default out_file for Arch users, the same default that mkinitcpio and dracut have on Arch. Even if the user runs ugrd with no args.

It would also be possible to simply turn this arch detection stuff into its own autodetect hook which runs after "get_kernel_version" so the out_file can be set there and nothing needs to be adjusted in the cpio module.

I think I'd like that approach since it sounds like a more simple change, but I'm not sure where that would go. Could you point me to that?

[desultory]

The install hook and script should guarantee that an initramfs is generated at /boot/initramfs-{pkgbase}.img whenever the package manager installs/upgrades a kernel package. (NeedsTargets passes the list of triggers to the script, which are then parsed to get the pkgbase to use for out_file arg)

I think /boot/initramfs-{pkgbase}.img should the default out_file for Arch users, the same default that mkinitcpio and dracut have on Arch. Even if the user runs ugrd with no args.

It would also be possible to simply turn this arch detection stuff into its own autodetect hook which runs after "get_kernel_version" so the out_file can be set there and nothing needs to be adjusted in the cpio module.

I think I'd like that approach since it sounds like a more simple change, but I'm not sure where that would go. Could you point me to that?

Ah I see, this line alone should be enough:

ugrd --kver "$kver" "/boot/initramfs-${pkgbase}.img"

I'm not sure there is any need to adjust the ugrd code itself for the hook updates you made. The typo/doc fixes are still nice though

[AlphaLynx0]

I'm not sure there is any need to adjust the ugrd code itself for the hook updates you made. The typo/doc fixes are still nice though

I'd still like to make it the default when Arch users run ugrd directly. I think users coming from other initramfs generators will find it weird if they have to manually set it or copy it

[desultory]

I'm not sure there is any need to adjust the ugrd code itself for the hook updates you made. The typo/doc fixes are still nice though

I'd still like to make it the default when Arch users run ugrd directly. I think users coming from other initramfs generators will find it weird if they have to manually set it or copy it

this is kinda the intended behavior if it's run without args being supplied, just so important files are never overwritten if someone wants to test ugrd. If someone wants ugrd to overwrite a particular file all of the time, setting out_file in /etc/ugrd/config.toml (or passing an arg) should do that for them.

I can see the value in the kver determining bit working a different way to use package info instead of reading a kernel file, but that mechanism was mostly a crutch to handle the install hook not passing kver info (or the output file)

[AlphaLynx0]

this is kinda the intended behavior if it's run without args being supplied, just so important files are never overwritten if someone wants to test ugrd. If someone wants ugrd to overwrite a particular file all of the time, setting out_file in /etc/ugrd/config.toml (or passing an arg) should do that for them.

I think that how it currently cycles the old initramfs instead of overwriting:

INFO     | [0] Cycling file: /boot/initramfs_linux.img -> /boot/initramfs_linux.old

is a good way to handle that.

I can see the value in the kver determining bit working a different way to use package info instead of reading a kernel file, but that mechanism was mostly a crutch to handle the install hook not passing kver info (or the output file)

What do you mean?

[desultory]

this is kinda the intended behavior if it's run without args being supplied, just so important files are never overwritten if someone wants to test ugrd. If someone wants ugrd to overwrite a particular file all of the time, setting out_file in /etc/ugrd/config.toml (or passing an arg) should do that for them.

I think that how it currently cycles the old initramfs instead of overwriting:

INFO     | [0] Cycling file: /boot/initramfs_linux.img -> /boot/initramfs_linux.old

is a good way to handle that.

This behavior is defined by the cpio_rotate parameter in the cpio module. If it's set to 0, it should just replace the file.
https://github.com/desultory/ugrd/blob/2.1.0/src/ugrd/fs/cpio.py#L104-L111

The problem is that someone could run ugrd a few times to see if it works for their setup and end up cycling the old initramfs out of existence. This is probably unlikely but if someone was confused ran ugrd a few times, it would happen. Not that it's impossible to regenerate the old initramfs in most cases, but I like that it's entirely non-destructive unless you tell it to replace an "important" file, or the package manager does.

I can see the value in the kver determining bit working a different way to use package info instead of reading a kernel file, but that mechanism was mostly a crutch to handle the install hook not passing kver info (or the output file)

What do you mean?

I mean as long as the kernel install hook is setting the kver and output file name, ugrd itself doesn't need any internal logic. The current logic for arch setups is a bit of a hack to make things work without the hook providing that info. If there is going to be a hack used, I think it makes sense that it gets the kernel info from the package manager instead of reading files somewhat blindly to get that info.

In most cases, just running "ugrd" with no extra config is designed to not touch any boot files. The intended design is that this info is provided by the install script, and will fail if that info (mostly the kver) is not usable.

[AlphaLynx0]

In most cases, just running "ugrd" with no extra config is designed to not touch any boot files. The intended design is that this info is provided by the install script, and will fail if that info (mostly the kver) is not usable.

Ok, I'm fine with not touching boot files when run without args. Should I revert all the logic changes in cpio + kmod?

[desultory]

In most cases, just running "ugrd" with no extra config is designed to not touch any boot files. The intended design is that this info is provided by the install script, and will fail if that info (mostly the kver) is not usable.

Ok, I'm fine with not touching boot files when run without args. Should I revert all the logic changes in cpio + kmod?

yes, the hooks look good to me (i have not tested them yet because i don't have an up to date arch setup)

the typo fixes are nice but probably belong in another PR, I don't mind the adjustment to get the kver from pkgbuild, but I think the logic should be setup so it doesn't run if out_file is already set. I'd prioritize the hook so it can just get passed the correct kver/output file path "externally"

[AlphaLynx0]

Removed changes to cpio and kmod. cherry-picked typo fixes to a different branch. and squashed my changes to one clean commit.

I've tested the install and remove hook and they're working properly

[desultory]

Thank you very much, this looks good to me!