Inittab parent directory not added to late_mounts when in seperate btrfs subvolume

[LunarMinus]

Ugrd seems to correctly find 'init' (for me in /usr/bin/init on OpenRC), which is in a btrfs subvolume (@usr), and adds that subvolume to late_mounts. But, OpenRC's init seems to require inittab and inittab.d/ in /etc, which for me are in a seperate btrfs subvolume (@etc). If the init fails to find these required files, it fails to boot.

Manually adding the @etc subvolume to late_mounts seems to have fixed it for me, but there doesn't seem to be any documentation on this.

[late_mounts.etc]
options = [ "rw", "noatime", "ssd", "space_cache=v2", "autodefrag", "subvol=260", "subvol=/@etc" ]
type = "btrfs"
uuid = "too lazy to type this"
destination = "/target_rootfs/etc"

Is documentation all that should be needed or should autodetect_init_mount take into account any other subvolumes that init requires?

[desultory]

I considered this, and may add it, relevant code is here:
https://github.com/desultory/ugrd/blob/main/src/ugrd/fs/mounts.py#L418

it's checking if the detected init binary is under a mount, and adds that so it can function.
I think it may be a bit simpler to do something like just add mounts for specifically /usr, /etc, and maybe others for this purpose.

If there were a GPT automounter not tied to systemd, that could possibly be used in the initramfs to handle mounts such as these.

The auto_mount logic could also probably be extended for "late mounts", so users could do like auto_late_mount = ["/etc"]

[LunarMinus]

I think it may be a bit simpler to do something like just add mounts for specifically /usr, /etc, and maybe others for this purpose.

That seems like the best option, but at that point, why not just late mount all subvolumes automatically in case of any unique configurations of subvolumes? Though I suppose that would be doing the job of fstab.

The auto_mount logic could also probably be extended for "late mounts", so users could do like auto_late_mount = ["/etc"]

I suppose that would be useful, but I only see, in any case, that late mounts are only needed to load the init binary, and autodetect_init_mount should automatically take care of this without additional manual configuration from the user.

Is there any case where the init binary for any system has dependencies outside of /etc and /usr? I'm not that familiar with systemd. If not, then

add mounts for specifically /usr, /etc

may be the best option

[desultory]

technically the current setup allows a user to define a custom init, and if that happens to be under a mountpoint, it adds that mountpoint to "late_mounts". I kinda like that it is able to do that, in case you have a really weird mount. I think this is really relevant because it tries to use that init target later, so things have to line up.

I may implement a way to automate the "late mounts" and can add that to the current autodetect_init_mounts function, I think that could make the most sense in general.

Like you mentioned, in general, most mounts are handled by the fstab and I want to avoid ugrd interfering with later mounts.

[desultory]

I did a bit of refactoring, I'm about to run some tests on a vm I have (it only has a /usr subvol), i just want to make sure there are no regressions, would you mind testing the latest dev branch?

[LunarMinus]

sure, ill get on that

[LunarMinus]

Its adding the usr subvolume to late_mounts but without the currently loaded options, which it was before. Is this because autodetect_init_mount got the options from it being mounted, and then copied them over to the configuration. It is also putting the usr subvolume in the /usr destination instead of /target_rootfs/usr. Is that meant to be happening?

[desultory]

Its adding the usr subvolume to late_mounts but without the currently loaded options, which it was before. Is this because autodetect_init_mount got the options from it being mounted, and then copied them over to the configuration. It is also putting the usr subvolume in the /usr destination instead of /target_rootfs/usr. Is that meant to be happening?

thanks for testing

I think I just fixed this, I had it reading from the wrong dict. There was also a regression in v2 which made it not actually add late_mounts to the init procedure, that should be fixed too

#219

[desultory]

Note, the PR doesn't add "auto_late_mounts" or similar, but should make the init mount detection use more or less the same procedure as any other mount detection, next I can make it just auto-attempt /usr and /etc

[LunarMinus]

👍 that seems all good

[desultory]

great, I just pushed some changes which should make it attempt to detect /var, /usr, and /etc explicitly.

It now "warns" if the mount is already detected, but this helps confirm validity

[LunarMinus]

That works, at least for setting late_mounts correctly. Although, I believe the change in the _autodetect_modules_lspci is causing ugrd to not build the firmware into the initramfs:
Skipping driver without module: /sys/bus/pci/drivers/(all drivers used on my system)
Should I open a separate issue?

[desultory]

I'll merge the late_mounts detection change, thanks for testing.

what firmware is it missing? the "skipping driver without module" should apply to any "driver" (listed in that dir) which does not have a module symlink (/sys/bus/pci/drivers/<driver>/module).

most PCI devices, like wireless, gpu, sound, etc. can be ignored in the initramfs, and loaded by the "real" init. If it's failing to find/pull firmware for a module which is absolutely necessary to boot, that's a problem.

the new detection method is much simpler but removes the need for the "real" lspci to be installed, which isn't installed by default on some distros. using lspci is more robust, but in testing, I've been able to detect most needed drivers looking at block device info, where lspci is kinda a quick and dirty guess of what may be needed, if nothing else finds it.

[LunarMinus]

For me, the /<driver>/module doesn't exist for any of my pci devices. I specifically need the radeon driver, since I have an old radeon gpu.
ChatGPT: The most common reason for not seeing a "/sys/bus/pci/drivers/<driver>/module" directory is that the driver is built into the kernel rather than loaded as a module.
If this is right, which I have built all my device drivers directly into the kernel, it doesn't create the module?

[desultory]

For me, the /<driver>/module doesn't exist for any of my pci devices. I specifically need the radeon driver, since I have an old radeon gpu. ChatGPT: The most common reason for not seeing a "/sys/bus/pci/drivers/<driver>/module" directory is that the driver is built into the kernel rather than loaded as a module. If this is right, which I have built all my device drivers directly into the kernel, it doesn't create the module?

what does modinfo <kmod name> say, and relevant stuff from lspci -k

in most cases ugrd tries to mask/ignore video drivers, but if you built it in, then the firmware is necessary, but if you built in video drivers it may make the most sense to build the firmware into your kernel too.

I'd recommend using a kmod if possible so the driver can be reloaded if ever needed.

[LunarMinus]

lspci.txt
radeon.txt

I also built the firmware directly into the kernel.

I'd recommend using a kmod if possible so the driver can be reloaded if ever needed.

Also when would the driver ever be need to be reloaded?

Oh I see, if the drivers and firmware are built into the kernel, then the initramfs wouldn't need to load the firmware?

[desultory]

lspci.txt radeon.txt

I also built the firmware directly into the kernel.

If you did this, you can ignore warnings/errors, it mostly tries to look for firmware on anything it thinks it should include (this includes this the lspci detection finds), so it sees it's builtin and looks for firmware too. This is part of way i generally try to mask video devices (with a toggle) since they can bring in a lot of unneeded junk

I'd recommend using a kmod if possible so the driver can be reloaded if ever needed.

Also when would the driver ever be need to be reloaded?

when it crashes lol

Oh I see, if the drivers and firmware are built into the kernel, then the initramfs wouldn't need to load the firmware?

Yeah, for builtin modules, i think it's best to build in the firmware anyways, i believe it may be able to use the initramfs as a firmware source, but it probably makes more sense to build in firmware if you're choosing to build in the module.

[desultory]

looking at this outcome, I think it may be "good" that the lspci detection here "ignores" builtin modules, but this could be somewhat confusing.

[LunarMinus]

looking at this outcome, I think it may be "good" that the lspci detection here "ignores" builtin modules, but this could be somewhat confusing.

Well, I guess it's not an issue. Thank you for working so fast to solve this.

[etc]

Stop tagging me.