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
KWhat the fuck
AIt's a Chad move
FIt builds successfully in my image using this method, but I wonder how much is it broken
he disables selinux after all
he disables selinux after all
KI'm thinking closed won't fix
Fwell, the system booted without errors in VM
Don't have sealert or setroubleshooter to analyze if there are some SELinux errors
Don't have sealert or setroubleshooter to analyze if there are some SELinux errors
FBut I rebased from the existing install, didn't use the ISO method
AHe's fixing it
AAfter all he was using cosmic the OCI way
FJust testing install of Steam RPM:
rpm-ostreednf5 handle it the same way, 183 packages to install & they both install it successfullyFat least how it looks like in logs
JJIT HAS BEGUN
NI thought we were done Jorge...
Jwe are done
Jonly maintenance remains
Ntrue true true
TFmaintenance is 80% of the work according to some researches
Nsomeone probably has archived an even earlier version of this.
RGitHub's pulled the plug again
R100% of their services offline
RYou gotta respect the tactic. Their GHA SLA for enterprise customers is based on number of workflows that fail.
Workflows can't fail if you can't invoke them through commits or the API to begin with
And you can't even see their SLA right now
https://github.com/customer-terms
Workflows can't fail if you can't invoke them through commits or the API to begin with
And you can't even see their SLA right now
https://github.com/customer-terms
RThat latest Cosmic issue... 
Users who do not want to use the base Flatpaks can do so by simply basing a custom image off Cosmic. They do not inherit the ISO from us.
Also could have explained what the real issue was.
Users who do not want to use the base Flatpaks can do so by simply basing a custom image off Cosmic. They do not inherit the ISO from us.
Also could have explained what the real issue was.
Jsorry just wasn't in the mood for the lip
RAll good. Just another instance of you can't please everyone.
