Can't boot with artix 5.13.4-artix1-1 kernel and solus strata
 

Steps to reproduce:
1. Install artix linux (I used artix-plasma-runit-20210426-x86_64.iso), hijack it, and reboot.
2. Add solus strata and reboot
First issue, no grub theme, but possible to boot. screen 1
3. Update artix kernel to 5.13.4-artix1-1 and install e.g. zstd package with eopkg and reboot
Not possible to boot. screen 2a screen 2b
Probably it is caused by depmod trigger during eopkg it zstd

What Bedrock release are you on?

0.7.21

The GRUB theme issue indicated in your screen 1 isn't surprising. From GRUB's point of view, the local stratum is `bedrock`, which doesn't have `/usr/share/grub/themes/artix`. I haven't fully thought it through, but I suspect symlinking /bedrock/strata/bedrock/usr/share/grub to /bedrock/strata/hijacked/usr/share/grub might will make this just-work for most people most of the time, although it'll break if someone ever changes their bootloader stratum. If I can reproduce the issue I'll experiment with it and if nothing else document the situation.

What's shown in screen 2 looks like Bedrock can't modprobe necessary modules. I knew some distros were switching to zstd compression with Linux 5.13.X and released 0.7.21 explicitly with the aim of adding zstd-compressed module support. My hope was that you were on 0.7.20, and the issue would be trivially resolved with an upgrade. I'll see if I can reproduce this and dig into it when I get the chance.

I was able to reproduce the grub theme issue. My proposed fix does seem to work. I'll try to queue it up for 0.7.22beta2 and document the need to manually adjust the symlink if one changes which stratum provides grub.

I was also able to reproduce the module issue. I think you're right, it's depmod. Immediately after `eopkg it zstd`, I found `modules.dep` emptied. My first thought is to try to pin Bedrock's zstd-aware depmod and get it to override Solus' (and everyone else's); I'll give that a try in my next free moment. If that doesn't do it, I'll have to think about this one for a while.

I noticed if I reinstall fonconfig package which is installed during create solus strata causes the same problem.
screen 3a
screen 3b
Even install wget package breaks booting process too.
Seems it is not possible use solus strata with hijacked artix.

Thanks.

Great. Thank you.

I'm not very familiar with Solus, but it appears eopkg runs depmod on every package (re)install irrelevant of whether or not it owns the kernel or the package does anything with/to modules.

Pinning depmod didn't work. Presumably eopkg either sets its own `$PATH` or uses the path to its depmod rather than search the `$PATH`.

While it's not ideal, I think I have a fix that at least keeps the system bootable. When booting, Bedrock can detect the empty `modules.dep` and generate a good `modules.dep` with its zstd-aware `depmod`. Downsides to this solution include:

- Without manual intervention (e.g. running a ztsd-aware `depmod` manually) the system will not be able to load modules between running `eopkg it [...]` and rebooting.
- This will slightly slow rebooting after an `eopkg it` as Bedrock runs `depmod`.

but at least the system boots.

I have included both the above described GRUB theme fix and module handling fix in 0.7.22beta2. If you could try it out and confirm for me that it works as expected and resolves your difficulties here, I'd greatly appreciate it.

If you're installing fresh, you can use the beta installer from here: https://raw.githubusercontent.com/be...7beta/releases

or if you're fixing things in-place (e.g. with a backup kernel) instructions to update to the beta are here: https://bedrocklinux.org/0.7/beta-channel.html

I've checked pisi code (eopkg uses pisi) and seems that usysconf Solus tool is execute for upgrade, install and remove operations without any kernel module path condition. Seems that usysconf doesn't skip depmod if not necessary.
The same behaviour is for Solus live system. `eopkg it wget` causes triggering depmod.

Seems that usysconf doesn't check `$PATH` for execute depmod command.

That's right, not ideal, but the system boots.

I checked on VirtualBox. GRUB theme came back. Booting process freezes for a while when `eopkg it` was used during previous session, but it works as expected. Thank you.

You're welcome! Thanks for reporting it and working with me to find and confirm a fix. I'll be sure to include these changes we confirmed in beta in the next stable release.