mkosi-initrd: Install libseccomp explicitly #3915
Conversation
It might become a Recommends of systemd in the future in distribution packages but we should make sure it is available in the initrd regardless.
|
Could you also add libblkid ? |
Hmm, may not be necessary. Not sure. I found several issues in the systemd PR. |
We install util-linux for the tools so the libraries will be pulled in automatically |
|
Yeah I'm wondering if libseccomp is a good idea actually and whether we shouldn't make it an explicit dep.of the udev package. |
|
So these should probably be deps of the actual packages, going to close this for now |
|
I actually agree, I think it makes sense to keep libseccomp out of the initrd. I think for long running services it is very useful to lock things down via libseccomp, but by definition the initrd's services are not like that, hence I think it's more valuable to keep things small and avoid it. |
My latest revision in https://src.fedoraproject.org/rpms/systemd/pull-request/212#request_diff actually adds the dep to the systemd package, since we have so many services with syscall filters, which means it will end up in the initrd as well. But the library is super minimal and doesn't pull in any other deps, so I don't actually think it hurts. We'd get way more benefit from optimizing the hwdb or such. |
|
For Debian/Ubuntu I prefer not to make it a hard dep - to allow building very minimal images. But I think it should be in the default initrd here, as it's possible for some services like storage daemons to run from the initrd to the main system and they might (should?) use sandboxing https://systemd.io/ROOT_STORAGE_DAEMONS/ so I'll open a separate pr only for ubuntu/debian |
Let's do everywhere or nowhere. We can just list it explicitly for the initrd as well even if some packages will also add it. |
|
ok do you prefer to reopen this then? |
5 participants
It might become a Recommends of systemd in the future in distribution packages but we should make sure it is available in the initrd regardless.