With ukis you have to sign all kernel parameters
With ukis you have to sign all kernel parameters
AAny user will use
AAnd the users can't change them afterwards
GHow could I test this in a custom image?
AUh have fun reading the systemd uki docs
AI only know what you have to do in theory
AIf secure boot is on the uki ignores the kernel parameters you pass to it
AAnd you have to make uki extensions that get conditionally loaded based on the device to change the kernel params
GDoes ostree/silverblue even support booting them?
SWhat's a bug? The tests I run on my repo use a bootc image. If they're passing, then you should be able to install a bootc image since installing is one of the tests
NYeah, I feel like I need to do some new testing as I feel like we aren't operating on current info.
APerhaps not generating them yet
ABut if you make them and make a grub config booting them should work
Rbumping this again since at least the "" removal needs to be merged https://github.com/ublue-os/config/pull/315
N@antheas @Kyle Gospo in the meeting early if we want to chat before Red Hat folks get in.
Asame link?
Nyes
MWe have bootc still on Bluefin.
Noh did it just get pulled from Main?
MYepp
NOK, so there is no issues with ISOs then, otherwise bluefin would be broken 
MYepp
Rdid fedora go ahead and drop fuse??
Roh
Rrpm-ostree 2024.7 shipped before fedora merged the patch to include fuse
RFYI @Kyle Gospo
Rfuse2 deprecation confirmed :clueless:
Rspeaking of rpm-ostree 2024.7, we now have --no-install-recommends available in rpm-ostree
Rtime for even smaller images?
K@RoyalOughtness https://github.com/ublue-os/main/pull/631
GitHub
fedora-silverblue/issue-tracker#589
K@Noel
Ksome approvals would be good
Rdo i have permission to reject the PR :clueless:
Kit's already fixed upstream
Ri know
Kthis just keeps us fixed while we wait for upstream to build
RGitHub
As of rpm-ostree 2024.7, this is available: coreos/rpm-ostree#4974
IHey can you explain to me what you expect to find? I wanted to try to improve this but I am not sure what you meant. Thx.
Auh i dont remember
Awhat we need now is simple
Afind out the file that causes the crash
Ato do that, you need debug symbols
IYes I am aware of that. I will try to find time for this. The other question: Are our build tags in some form strange or confusing? I do not know how they are supposed to look.
IWe did layer the debug symbols but it did not work. I will try it again this weekend.
Aturns out github was broken when i was checking it
Aand then ghcr died after a few hours
Rwhat are you going to try? layering debuginfo packages doesn't cause them to be loaded
II did not had time to think about this. I wanted to fork the repo and include the packages in the build itself. That would be my first try
Rby layering in the build? likely will be the same
R