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
IDisable core dump
kernel.core_pattern = |/bin/false
FI think that deleting the file won't do anything, since file in
/usr/etc/ will take the advantageIok then edit /etc/sysctl.d/hardening.conf and change the kernel.core_pattern line to `
FThis one is the default for me:
II see, I will add a command to reenable debugging on our images in a few days. Just to simplify this process in the future.
Ai
echo '' | sudo teedA
A
Aif there is a file left afterwards it will be a miracle
Aits still going at 36%
Ait appears that 1/3 of the files in my VM were corrupted
Ai did do cursed stuff with it such as mounting the drive tho
Jya'll need to thread stuff like this, otherwise we'll lose it in the ether
Jand/or start a rechunk channel
Atheres are parallel github issue on secureblue
Athats cleaner
ISorry for the spam. I will start a thread next time. I was not aware that this is possible
F@antheas I think that guy in Rechunk issue uses dnf5 to install packages, as he symlinks it to
dnfFI don't know how much is that clean
