Hello everyone, it is not the first time that i use kicksecure on USB and so far I never had any problem, neither in live version nor in persistent version, but, I changed to a more modern pc and now i find this problem. “RDSEED32 is broken, disabling corresponding CPUID bit”.
The screen simply goes black and doesn’t respond anymore or stays with the pront / and doesn’t respond anymore, according to google primarily affecting recent AMD Ryzen processors (Zen 5/9000 series), i have a new AMD ryzen 7 98003D, maybe this is the problem.
I’ve used all the kicksecure menus, added clearcpuid=rdseed also editing the boot, updated my ASUS bios Version 3854 2026/04/23 These were all tips i saw about this problem online, but, none of them seem to have an effect.
The installation was as always, ISO installed on empty USB both tested with belana etcher and rufus, it is not the problem, I usually install the permanent version on USB, but, I can’t use even the second option of the kicksecure menu.
I have a PRIME B650M-A WIFI II, and i use Transcend USB JetFlash 920. Thanks all, and help me please.
What do you mean? I also tried to use Tails and it doesn’t work for me either, could it be that it’s some BIOS option? Something that prevents booting from USB?
The truth is that it has me a little out of the game, that on some PCs these systems work on USB and on others they do not work at all.
I mean, if you download Debian 13 (not a Debian derivative like Kicksecure or Tails), flash it to a USB drive, and try to boot it, does it boot? If not, can you make it boot? If so, do whatever you did to make it boot, and do that to Kicksecure. (The forums here are primarily for figuring out Kicksecure-specific issues. There are usually better forums for issues that plague all of Linux in general, like the “freezing system due to broken RDSEED32” issue.)
I listened to you, I installed a live version of debian 13 on USB and it worked perfectly, no problems, I tried kicksecure again, but, without success, debian 13 also jumps with the error “RDSEED32 is broken, disabling corresponding CPUID bit”, but, system boot continues smoothly. I tried many configurations with the boot options that the bios has, without success saddly, I’m running out of ideas. Thanks for the help, I don’t know what else to try.
I highly suggest avoiding this brand from personal first hand bad experiences with this brand. Not be a shill but, stick to Sandisk, PNY, and Samsung since they develop most of flash memory market. Maybe would add Kingston but their flash drives I have read issues before not their SSD’s. I don’t think USB is the issue here but just an FYI.
The “RDSEED32 is broken, disabling corresponding CPUID bit” message is a known Linux kernel detection of a hardware flaw in AMD Zen 5 processors (like your Ryzen 7 9800X3D). This affects 16/32-bit RDSEED instructions used for hardware random number generation.
Can you edit the grub command boot options line when you boot and add rdseed=0?
Others you could try clearcpuid=rdseed or clearcpuid=2096
Is your goal for installation if yes I would absolutely make sure you do firmware upgrades if you can get that far sudo apt update && sudo apt install --no-install-recommends linux-firmware firmware-amd-graphics
OK, if Debian 13 works, then this is likely Kicksecure-specific.
Could you try this for me please:
Boot from a Kicksecure 18 live USB.
When the GRUB menu appears, hover over the “sysmaint” boot entry, then press the e key.
Move your cursor down to the line that starts with linux /vmlinuz..., then press the End key to move to the end of the line.
Press and hold Backspace until everything in this line has been deleted except for the ro parameter and everything before it. You want the line to look like linux /vmlinuz-... root=UUID=... ro at the end.
Press Ctrl+X.
Does this boot? If so, there’s a kernel parameter in our hardening configuration that is probably causing the freeze.
Thanks for the answers exfil and arraybolt3, I’m going to be away from home for a few days, as soon as i return, I’ll put your contributions into practice, for the last thing i could see before i left, if you use virtualbox, the error “RDSEED32 is broken, disabling corresponding CPUID bit” appears as well, but, it loads without problems, so that error does not prevent the system from booting, So i understand that it’s something about booting on US, as soon as i get home i’ll report again, thanks for your help so far.
I came back, I tried to do it as you explained it to me, it didn’t start, I upload capture of the error, then I tried to do it again, in case I had made a mistake, but, I didn’t see root=UUID= ro again, I also share capture, I must be very clumsy. The first time I saw the linux /vmlinuz… root=UUID=… until the ro very clearly, but, after the restart, I haven’t seen those parameters again, it’s as if they have changed, I don’t know, maybe I’m blind and you do see them, thank you.
Argh, the instructions I gave you were for an installed system, I forgot you were using the live ISO. In this scenario, you want to remove all of the kernel parameters up to and excluding the rd.live.squashimg=filesystem.squashfs. This will leave the command line looking more like linux rd.live.overlay.overlayfs=1 boot=live components splash live-config.hostname=localhost rd.live.image root=live:CDLABEL=kicksecure rd.live.dir=live rd.live.squashimg=filesystem.squashfs.
Yes, exactly, the idea was to install the permanent version on my other USB, as far as I know is the only way to do it, you can’t install kicksecure all at once on USB without going through the live. Still with black screen with flashing cursor, they didn’t see any error when boot with this command lines.
If removing those parameters didn’t help, then the issue is more likely being triggered a sysctl or similar. Unfortunately this can be very difficult to debug without extensive knowledge of how the system works under the hood. Some options you could try:
Install Debian 13, then distribution-morph to Kicksecure as described here:
The system is likely to become unbootable again once distribution morphing is complete if a hardening setting is triggering this, but at least that would give you a fully installed Kicksecure system, and you could then attempt to modify configuration files such as those under /usr/lib/sysctl.d to see if disabling various features fixes the system.
Install Kicksecure on a different computer, then move the installation disk to the new system. This will likely come with more issues than distribution morphing in this scenario.
Alternatively, if you have a different computer that Kicksecure does boot on, you might consider just using that.