WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Request for ca-certificates  (Read 1136 times)

Offline andyj

  • Hero Member
  • *****
  • Posts: 1057
Re: Request for ca-certificates
« Reply #15 on: December 09, 2025, 06:26:49 PM »
... Maybe your setup needs entropy before the CRNG is initialized?

Take a look here: https://github.com/jirka-h/haveged/blob/master/README.md
I download and compiled haveged. I added it to my initrd and start it in /etc/init.d/rcS. Problem solved. It's about 130K so I wouldn't suggest it as a candidate for inclusion in vanilla TC. I don't know how this could be done as an extension unless it's loaded first and you hope it does it's thing before something needs it.

Offline Paul_123

  • Administrator
  • Hero Member
  • *****
  • Posts: 1458
Re: Request for ca-certificates
« Reply #16 on: December 09, 2025, 08:28:01 PM »
Most things that need random and entropy have wait mechanisms to make sure the kernel is ready. Obviously mktemp does not.

Do you see this line in dmesg?

[    0.000000] random: crng init done

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 12355
Re: Request for ca-certificates
« Reply #17 on: December 09, 2025, 09:00:48 PM »
Hi andyj
You beat me to it. I was going to suggest something similar. I was
going to suggest making a separate initrd containing:
Code: [Select]
/usr/sbin/haveged
/usr/lib/libhavege.so
# A modified rcS to start haveged
/etc/init.d/rcS
That way, instead of modifying initrd files, append this initrd to include
haveged and overwrite /etc/init.d/rcS with the modified version.

This way, you can add it to different Tinycore releases without modifying
multiple initrd files.

Offline andyj

  • Hero Member
  • *****
  • Posts: 1057
Re: Request for ca-certificates
« Reply #18 on: December 10, 2025, 07:33:13 AM »
Each of my VM's is set to PXE boot, and has it's own initrd that gets loaded after the stock rootfs. On the dhcp/bootp server I just update what I need and have a script to package them. The extension list is in that initrd as well so I only need generic CD images for 32 and 64 bit from an rsync of the distro. I add my extensions to the CD and test them before I submit them, which is the phase I'm in now. We went down this rabbit hole because apache wasn't starting as it was supposed to in bootlocal.sh because mod_ssl was failing.

I compiled haveged and it's library to be in /usr/local though, this is the way.

I do see this in boot.log without haveged:
Code: [Select]
[    1.269467] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.293151] /dev/sr0: Can't open blockdev
[    1.294042] /dev/sr0: Can't open blockdev
[    1.294748] /dev/sr0: Can't open blockdev
[    1.295841] /dev/sr0: Can't open blockdev
[    1.296532] /dev/sr0: Can't open blockdev
[    1.296875] ISO 9660 Extensions: Microsoft Joliet Level 3
[    1.296998] ISO 9660 Extensions: RRIP_1991A
[    3.724888] NET: Registered PF_VSOCK protocol family
[    5.104902] random: crng init done
[    5.311824] EXT4-fs (sda1): mounted filesystem ce42a570-e54e-4010-9b14-e02b129a550d r/w with ordered data mode. Quota mode: disabled.
[    5.312316] EXT4-fs (sda1): unmounting filesystem ce42a570-e54e-4010-9b14-e02b129a550d.
[    5.316685] EXT4-fs (sda1): mounted filesystem ce42a570-e54e-4010-9b14-e02b129a550d r/w with ordered data mode. Quota mode: disabled.
[    5.375203] NET: Registered PF_INET6 protocol family
[    5.402950] Segment Routing with IPv6
[    5.402958] RPL Segment Routing with IPv6
[    5.402982] In-situ OAM (IOAM) with IPv6
[    5.465971] xt_geoip: loading out-of-tree module taints kernel.
The crng init seems really late in the process, is this normal?

With haveged started in rcS, it happens sooner:
Code: [Select]
[    1.474509] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.504421] /dev/sr0: Can't open blockdev
[    1.506310] /dev/sr0: Can't open blockdev
[    1.507957] /dev/sr0: Can't open blockdev
[    1.509737] /dev/sr0: Can't open blockdev
[    1.511318] /dev/sr0: Can't open blockdev
[    1.512446] ISO 9660 Extensions: Microsoft Joliet Level 3
[    1.512642] ISO 9660 Extensions: RRIP_1991A
[    1.876732] random: crng init done
[    3.913323] NET: Registered PF_VSOCK protocol family
[    4.798729] EXT4-fs (sda1): mounted filesystem ce42a570-e54e-4010-9b14-e02b129a550d r/w with ordered data mode. Quota mode: disabled.
[    4.799448] EXT4-fs (sda1): unmounting filesystem ce42a570-e54e-4010-9b14-e02b129a550d.
[    4.805703] EXT4-fs (sda1): mounted filesystem ce42a570-e54e-4010-9b14-e02b129a550d r/w with ordered data mode. Quota mode: disabled.
[    4.871693] NET: Registered PF_INET6 protocol family
[    4.894712] Segment Routing with IPv6
[    4.894719] RPL Segment Routing with IPv6
[    4.894740] In-situ OAM (IOAM) with IPv6
[    4.964447] xt_geoip: loading out-of-tree module taints kernel.
This three-ish seconds seems to be enough to make a difference.

Offline Paul_123

  • Administrator
  • Hero Member
  • *****
  • Posts: 1458
Re: Request for ca-certificates
« Reply #19 on: December 10, 2025, 08:14:20 AM »
Without getting into the haveged entropy discussion, VM's are quite common in the server world, it seems odd that VM's would not pass hardware entropy to the Guest OS.

Would rngd find and use a hardware entropy device?

Offline patrikg

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 806
Re: Request for ca-certificates
« Reply #20 on: December 10, 2025, 08:47:19 AM »

Offline andyj

  • Hero Member
  • *****
  • Posts: 1057
Re: Request for ca-certificates
« Reply #21 on: December 10, 2025, 12:24:46 PM »
... VM's are quite common in the server world, it seems odd that VM's would not pass hardware entropy to the Guest OS.

Would rngd find and use a hardware entropy device?

As of ESXi 8 it can. But I'm using ESXi 6.7 on an AMD Steamroller which does not have a hardware generator, and is not supported under ESXi 8 anyway so it's just not going to happen anytime soon. If I had to guess I would say I'm probably not alone in this regard.