Hacker News new | ask | show | jobs
by kaylynb 857 days ago
I really like Silverblue and run it on a couple of secondary machines (like in my workshop), but it’s still rough for anything off the beaten path.

The largest pain points for me:

- Any kernel modules. I know Ublue has images but I wish Red Hat would just have an official solution that doesn’t require hacky RPMs and such.

- Kernel cmdline args or any initramfs changes: can’t package in image and need to be applied manually. Maybe it’s possible to build a custom initramfs to distribute?

- Secure boot and enrolling moks is very annoying. My current workstation just uses sbctl to sign a UKI against custom keys and everything “just works”. This is part of why kernel modules are a pain in Silverblue too.

If you don’t care about kernel modules with secure boot it’s quite nice though. Practically zero maintenance.

2 comments

After working with these types of systems, I'm convinced we need a new type of package manager that works with overlays and merges package databases somehow. That way you can update the underlying image (at your own peril, maybe) and have the overlay package manager see the new versions. Constantly rebuilding everything when the underlying changes is a waste.
Nix?
AFAIK Nix wouldn't solve this as it has the same issue (/nix/var/nix/db). Here's a scenario to better illustrate:

I'm using systemd nspawn with my host root as a lowerdir overlay. In this container I install some packages not present on the host. The overlay upperdir now includes the new packages and the new package database. I upgrade my host, and now the nspawn package database is wildly out of date because overlay doesn't track line-level file changes.

OverlayFS is really handy but it causes a ton of churn from rebuilding everything.

The kernel modules problem really highlights why the push to do more in userspace in recent years increasingly makes sense. Hope to see more kernel changes to support this push.