Iyou want to follow the instructions here: https://github.com/secureblue/secureblue?tab=readme-ov-file#rebasing-recommended - and append "cosmic-main-userns-hardened" in the command
GitHub
Fedora Atomic images for GNOME, KDE Plasma, Bluefin, Sway, Cinnamon, Wayfire, River, and Hyprland with some hardening applied - secureblue/secureblue
Ai will point out that we might have slight CAP issues with rechunk
Aso you might need to do some AB testing of the images
Ai can give you a command that will spit the differences between t2 images
ISounds good.
IYou may need to wait until a new image is build to see the issue for yourself. If you rebase now you can not upgrade to a newer version. And the issue is only caused in rpm-ostree operations with hardened_malloc. You may not see any issue before the conditions are met. Conditions: rechunks + hardened_malloc + sys upgrade available
II can ask our main dev to force a rebuild after you have deployed the image to speed up this process.
IJust let me know
Ai can rebase to second to oldest
Aimage
Awell it dont boot
Agod damn it cosmic
Aanyway
I"cosmic-session" in terminal, only the newest build works fine on my end
Ayeah well cosmic
Arust
Ait is what it is
Arebasing to silverblue from cosmic
Abooting silverblue
IYou may try to rebase to my variant of cosmic instead: https://github.com/idnovic/secureblue-extended - It is based on the other image you just tried.
GitHub
Based on secureblue and extended with opinionated layered packages - idnovic/secureblue-extended
AGitHub
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.
Awhats going on in here
Awhere are the tags
ISorry I am not that familiar with the build process. We use blue build. I will investigate on the tags.
Ai cant even rebase to your image because of the dumb container policy
Aok wrote the policy by hand
IYes I am aware. This is something I want to change. It is on my todo.
Aits doing stuff
Aok its about to stage
Aand it crashed
IWhat base are you rebasing from ? silverblue hardened?
Ayes
IOK. You found the github thread. I posted a suggestion on how to change the malloc implementation at the top. Try the "light" variant. This may allow the rebase.
Ano its good
Ai found the error
Ahappens during ostree staging the commit
IOK. Can you pinpoint it? Is our build process responsible or what?
Aseems like the error about the assertion is the only one
IYou can try the light variant of our malloc, This may cause the issue to disappear. The normal variant enforces more malloc rules.
Astaging deployment... done
Aok
Aits after that
II tried to preppend debug environment variables for rpm-ostree but it did not tell me more useful information. Tell me if you need something. I do not know how to debug this further
Awould be good to have a coredump
Iok. Our hardening rules disable coredumps. Let me find out how to enable them. Give me a sec
IYou need to change the 3 files here to reenable it: https://github.com/search?q=repo%3Asecureblue%2Fsecureblue%20coredump&type=code
GitHub
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.
Acant get a core dump still
Ain dmesg
IJust edit this file https://github.com/secureblue/secureblue/blob/live/files/system/etc/sysctl.d/hardening.conf
GitHub
Fedora Atomic images for GNOME, KDE Plasma, Bluefin, Sway, Cinnamon, Wayfire, River, and Hyprland with some hardening applied - secureblue/secureblue
I