II do not believe that hardened_malloc is the issue. Because our non rechunked images work fine. And hardened_malloc just enforces certain malloc related rules.
FYou can make a Discord thread to make discussion in 1 place
Afor some reason i apepar to have ran out of ram so i cant start my vm
Aand im too bothered to reboot it seems
IIS this only possible for new messages or can I mark and move the already send messages to a thread?
A7 day vivaldi memory leak goes brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
FI'm not sure if messages can be moved
IYou can just post further messages to our issue report here: https://github.com/secureblue/secureblue/issues/369 - It is the simplest solution until we know more. Thank you for taking time to debug this
GitHub
Describe the bug On the cosmic-main-hardened and cosmic-main-userns-hardened images (and probably nvidia images too), rpm-ostree can't write new deployments. Attempting to install or uninstall ...
Agive me a rebase command
Aam confused
Aim rebasing to his image
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.
