Hi. I just upgraded to Kicksecure 18. It looks amazing! Well done guys!
However I have many issues that I’ll list below:
Other than these few things I’ve noticed, it is all in all pretty good!
Cheers guys, I hope these problems can be fixed soon 
Moderation comment: Edited to address only 1 issue.
1 issue = 1 forum thread please.
These are very different issues and will create a mess if discussed in the same forum thread. So I’ll just focus on the first one.
“No longer works” is very vague. How do you conclude that it does no works?
Proper bug report as per Sample Bug Report required.
But as for ram-wipe. let me wild guess… You’re used to seeing lots of output (by sdmem) during shut down but cannot see that anymore?
No. That’s invalid methodology. ram-wipe nowadays works differently and more efficiently. There is no more need to use sdmem.
Related ram-wipe user documentation:
Related ram-wipe developer documentation:
Ah ok thanks, yeah I’m a novice user and am only used to seeing a bunch of stars generate. So you reckon it still works? I’m just not sure what I’m looking for with ram-wipe.
Thanks
Oh! Also it doesn’t say when I start up my laptop that ram-wipe is on. You know when you start up your laptop and ram-wipe would usually indicate it’s running. Now I’m not getting any indicator that it’s running.
Indeed. I removed that. There are no more visual indicators during boot. Updated wiki chapter Boot Printout just now.
But that reminds me… [1]
Thanks to third-party security audit, ram-wipe security-audit by 3MDEB in 2025, this can be labeled Reasonable Security.
[1] It could be very hard for laymen users to confirm functionality. There is one thing you might be able to see. → Shutdown Printout
But these messages will probably appear so fast and the reboot/shutdown is so fast that most people probably will have no reasonable chance to read these messages. One simple “trick” could be to video record the shutdown process with camera and then watch/pause the recording.
For Advanced Users, at least a basic review using a serial console is possible. There are some pointers here: ram-wipe Functionality Testing
Otherwise if messages are appearing too fast, developers can for example locally inject sleep commands into the code or inject opening a debug shell.
Full review can be done by developers / expert. The test methodology had been fully documented during the 3MDEB security-misc audit.
Related:
I installed grub‑live and ram‑wipe on Debian 13 with dracut. The live mode works perfectly, but ram‑wipe only works in persistent mode. There are no messages indicating a successful launch of ram‑wipe.sh after exiting the live mode. Are there any nuances I may have missed, and what should I pay attention to? How can I check the logs when live mode is turned off (all data destroyed)? I added sleep 10 , but no additional messages appeared after shutdowning live mode.
Re-Generate dracut Initrd required.
Very interesting reading even though my skills are far from enough to fully understand everything.
But I have a question about the 3MDEB last article:
If i follow well the sketch, when the RAM disk is loaded, the init process is starting followed by dracut. The a condition is tested wiperam == skip.
If such condition in the code exits, it means ram-wipe can be deactivated. If that so, how, without reviewing the code, we can make sure the function is operating?
A computer is a walking if condition / conditional. There are uncounted (probably hundreds of thousands or millions) of conditionals involved in all aspects of a computer.
ram-wipe is just “a small glue” to activate init_on_free=1, which is a kernel feature and activating a feature of dracut (another massive, complicated project, not nearly as complex as the kernel) that helps unmoutning the encrypted root disk during the shutdown. That kernel feature is disabled by default. We have to trust that this feature (its activation and its actual functionality) is OK and won’t break in future versions going unnoticed.
It would theoretically be more secure if wiping the RAM was a default feature of the Linux kernel and if no code existed to disable it. But due to the organisational background of Linux and Open Source this is highly unlikely to happen. To read more about that organisational background, see:
The maximum we can reasonably accomplish with available resources is Reasonable Security / Practical Security.
without reviewing the code
Quote:
Performing system audits is beyond the reach of non-technical users.
Read more here:
Related:
Thanks @Patrick for your detailed answer, very much appreciated!