Debian on Dell Kace M300

LeggoMyEggo,

> I saw a random blog post suggesting the SOC of
> this device might support sata port multiplication
> through it's single connector.

It should work. All Kirkwood SoC variations have this capability. Even the old GoFlex Net has SATA port multiplication.

The only issue is having the right cable. Most eSATA enclosures have eSATA connector. With this box, you would have a single 22-pin SATA connector to the outside.

So 22-pin SATA to eSATA cable is the right one.

On 2nd thought. If you dont care for power (eSATA the enclosure has own power source), then SATA-eSATA connector cable would be fine? is it?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 4 time(s). Last edit at 09/13/2019 08:24PM by bodhi.

FYI,

Regarding the SPI flash being protected and we had to unprotect it in u-boot.

I was little surprised that nobody has added this option to this Macronix mx25l4005a SPI flash in Linux. Perhaps because it is too old and end-of-life long ago so nobody cares :)

So I've patched the kernel to make it unprotected by default.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 09/14/2019 05:42PM by bodhi.

Dell Kace M300 Installation

There are 4 sections in this installation instruction. Sections A, C, and D are for installation with serial console. Sections B,C, and D are for installation without serial console. Note that the box case must be open in both methods.


A. Installation with serial console connected
B. Installation without serial console
C. Post Installation
D. Upgrade Kernel to utilize 2GB RAM (Deprecated)
E. U-Boot 2022.04-tld-1 for M300 (Optional)


Preparation and Prerequisite

Connect serial console.

See this excellent tutorial (external link) for a deep dive in the hardware and picture of serial console pinouts.

Otherwise, if you are in a hurry to connect serial console see this post and a couple post before that for serial console port pinouts.


A. Installation with serial console connected

1. Create the USB rootfs using Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2 following the instruction from the kernel/rootfs release thread. Better yet, use the latest bookworm rootfs in the release thread: Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2 (replace 5.2.9 with 6.5.7 in the instruction below)

Note: Step 4 in the rootfs installation is needed since we are booting with stock u-boot. It should look like:

cd /media/sdb1/boot
cp -a zImage-5.2.9-kirkwood-tld-1  zImage.fdt
cat dts/kirkwood-m300.dtb  >> zImage.fdt
mv uImage uImage.orig
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.2.9-kirkwood-tld-1 -d zImage.fdt  uImage
sync

2. After the USB rootfs preparation is done. Bring it to the M300 and plug in to the USB port in the back.

3. Power up, interrupt serial console and at the u-boot prompt.

3.a. Execute the following command to unprotect the SPI flash:

protect off all

3.b. And then execute the following commands to set up booting:

setenv kernel_config 'setenv mainlineLinux yes; setenv mtdparts mtdparts=spi0.0:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env); setenv load_uimage_addr 0x800000; setenv load_initrd_addr 0x02100000'
setenv load_uimage 'ext2load usb 0:1 $(load_uimage_addr) /boot/uImage'
setenv load_initrd 'ext2load usb 0:1 $(load_initrd_addr) /boot/uInitrd'
setenv set_bootargs_stock 'setenv mainlineLinux no; setenv bootargs_console console=ttyS0,115200 mtdparts=spi_flash:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env) root=LABEL=root rw'
setenv bootcmd_stock 'echo Booting stock ...; run bootcmd_ide'
setenv set_bootargs 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $(mtdparts) earlyprintk=serial'
setenv bootcmd_exec 'echo Booting Debian …; usb start; run load_uimage; run load_initrd; bootm $(load_uimage_addr) $(load_initrd_addr)'
setenv bootcmd 'run kernel_config; run set_bootargs; run bootcmd_exec; run set_bootargs_stock; run bootcmd_stock'

And then boot:

boot

4. Watch the serial console logging, the Debian prompt will appear when the box finishes booting. Login with root/root credential.

5. In Debian, modify the /etc/fw_config.env to enable access to u-boot envs.

echo "/dev/mtd1 0x0 00001000 0x00001000" > /etc/fw_env.config

6. Save the stock envs for sanity, and then set the booting envs permanently.

fw_printenv > /boot/m300_stock_envs.txt

Also, print out the saved envs to double check if the content of m300_stock_envs.txt look OK.

cat  /boot/m300_stock_envs.txt

Set the booting envs permanently:

fw_setenv kernel_config 'setenv mainlineLinux yes; setenv mtdparts mtdparts=spi0.0:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env); setenv load_uimage_addr 0x800000; setenv load_initrd_addr 0x02100000'
fw_setenv load_uimage 'ext2load usb 0:1 $(load_uimage_addr) /boot/uImage'
fw_setenv load_initrd 'ext2load usb 0:1 $(load_initrd_addr) /boot/uInitrd'
fw_setenv set_bootargs_stock 'setenv mainlineLinux no; setenv bootargs_console console=ttyS0,115200 mtdparts=spi_flash:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env) root=LABEL=root rw'
fw_setenv bootcmd_stock 'echo Booting stock ...; run bootcmd_ide'
fw_setenv set_bootargs 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $(mtdparts) earlyprintk=serial'
fw_setenv bootcmd_exec 'echo Booting Debian …; usb start; run load_uimage; run load_initrd; bootm $(load_uimage_addr) $(load_initrd_addr)'
fw_setenv bootcmd 'run kernel_config; run set_bootargs; run bootcmd_exec; run set_bootargs_stock; run bootcmd_stock'

7. Reboot and let the box boot automatically until finished. Log in through SSH using the host name, or find the dynamic IP that the router has assigned to this box (using scanning app such as Linux nmap or IOS Fing).

ssh root@debian.local

8. Done Section A installation.


B. Installation without serial console


1. Create the USB rootfs using Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2 following the instruction from the kernel/rootfs release thread:

Note: Step 4 in the rootfs installation is needed since we are booting with stock u-boot. It should look like:

cd /media/sdb1/boot
cp -a zImage-5.2.9-kirkwood-tld-1  zImage.fdt
cat dts/kirkwood-m300.dtb  >> zImage.fdt
mv uImage uImage.orig
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.2.9-kirkwood-tld-1 -d zImage.fdt  uImage
sync

2. Gain root and SSH access to the box

2.a. Hardware

- Open the box (remove 4 screws hidden behind the 4 plastic feet).
- Remove the SATA SSD module (remove 2 screws). See these 2 posts here for pictures of the box inside.
- Insert the SATA SDD module into another Linux box vacant SATA slot, or use an USB-SATA enclosure, or a USB-to-22-pin-SATA cable.

2.b. Software

Everything we do from this point on must be as root user, sudo will not work. Use "su -" or "sudo su" to become root first.

After the SATA SSD is attached to another Linux box, we will modify some files. There are 4 partitions on it. But we are only interested in the 2nd partition (stock root partition).

2.b.1. Mount the stock root partition in the SATA SSD (if it is not already aumounted)

Assuming the SSD was assigned as /dev/sdb in the host Linux box.

mkdir -p /tmp/root
mount -o noatime /dev/sdb2 /tmp/root

2.b.2. Change static IP

Modify the IP addresses in network interfaces file to make sure it will work in your network. Below, my network router is 192.168.0.1, and I want to use 192.168.0.241 for the static IP address of this M300 box. Please adjust the IP addresses to the appropriate numbers in your network environment.

nano /tmp/root/etc/network/interfaces

auto eth0
iface eth0 inet static
   address 192.168.0.241
   netmask 255.255.255.0
   gateway 192.168.0.1

2.b.3. Change root password in shadow file

nano /tmp/root/etc/shadow

The shadow file has several lines, and the 1st line contains the root password hash. Replace the 1st line with new password hash (root):

root:$6$rVwqZFj0$QjBDxlwbeE/2Wdu2.TtPylZMHQvB.sNnH/HNgy1i9t2xHJIJsn0bsOgPGxUDGeIE261Z7ECYhGUkpGHegjqGl1:18153:0:99999:7:::

2.b.4. Enable SSH

nano /tmp/root/etc/ssh/sshd_config

Comment out the 2 ListenAddress lines:

#ListenAddress ::1
#ListenAddress 127.0.0.1

2.b.5. Sync the SSD and remove it from your host Linux box

sync
umount /tmp/root

3. Reinstall the SATA SSD into the M300 box again.

4. Power up, and wait a few minutes for the box to finish booting and SSH into stock OS using root/root credential

ssh root@192.168.0.241

5. Set u-boot envs in stock OS to boot new Debian rootfs

After login into stock OS,

fw_setenv kernel_config 'setenv mainlineLinux yes; setenv mtdparts mtdparts=spi0.0:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env); setenv load_uimage_addr 0x800000; setenv load_initrd_addr 0x02100000'
fw_setenv load_uimage 'ext2load usb 0:1 $(load_uimage_addr) /boot/uImage'
fw_setenv load_initrd 'ext2load usb 0:1 $(load_initrd_addr) /boot/uInitrd'
fw_setenv set_bootargs_stock 'setenv mainlineLinux no; setenv bootargs_console console=ttyS0,115200 mtdparts=spi_flash:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env) root=LABEL=root rw'
fw_setenv bootcmd_stock 'echo Booting stock ...; run bootcmd_ide'
fw_setenv set_bootargs 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $(mtdparts) earlyprintk=serial'
fw_setenv bootcmd_exec 'echo Booting Debian …; usb start; run load_uimage; run load_initrd; bootm $(load_uimage_addr) $(load_initrd_addr)'
fw_setenv bootcmd 'run kernel_config; run set_bootargs; run bootcmd_exec; run set_bootargs_stock; run bootcmd_stock'

6. Plug in the new Debian rootfs (created in step 1) to the USB port in the back.

7. Reboot

sync
shutdown -r now

8. Let the box boot automatically until finished. Log in through SSH using the Debian host name, or find the dynamic IP that the router has assigned to this box (using scanning app such as Linux nmap or IOS Fing).

ssh root@debian.local

9. In Debian, modify the /etc/fw_config.env to enable access to u-boot envs.

echo "/dev/mtd1 0x0 00001000 0x00001000" > /etc/fw_env.config

Save the envs for sanity:

fw_printenv > /boot/m300_envs.txt

10. Done Section B installation.


C. Post Installation

After login into Debian, see Note1 of the rootfs Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2 installation instruction for further set up to secure your box.


D. Upgrade Kernel to utilize 2GB RAM (deprecated)

The rootfs Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2 has kernel linux-5.2.9-kirkwood-tld-1 runnning it it. And this kernel is only capable of utilizing 768MB RAM.

If the later/latest rootfs (eg. Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2) is used for installation, the kernel in it already utilizes 2GB RAM.

E. U-Boot 2022.04-tld-1 for M300 (Optional)

After the box is running to your satisfaction. Consider installing new u-boot.

See new u-boot installation and binary here


=====

Note: I will upload another kernel version that unprotect the SPI flash automatically after boot. This will be very useful for users who have chosen the Installation methodd B.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 3 time(s). Last edit at 02/24/2024 02:45PM by bodhi.

I've revised the installation instruction to add section B (see the last post right above).

And also edited the original Section A (serial console) to adjust the stock bootargs setup. Section A is basically unchanged.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 09/15/2019 06:43PM by bodhi.

Nice. I have another M300 on the way and this will be a concise way to get it set up. Thanks for the instructions.

mikeh49 Wrote:
-------------------------------------------------------
> Nice. I have another M300 on the way and this
> will be a concise way to get it set up. Thanks
> for the instructions.

Yep, picked up another one as well. Still in the box, but I’ll easily find a use for it. Wonder how long before sources for these dry up. :)

> Yep, picked up another one as well. Still in the
> box, but I’ll easily find a use for it. Wonder
> how long before sources for these dry up. :)

Unless words get out that we can run this $US 15 box with the latest Linux kernel and use a 2Ghz CPU with 2GB RAM :) I'd doubt that it will dry up.

However, too bad that they are only available in the US, so it will not be as popular like other Kirkwood boxes. Costs a lot of $ to ship it to the other side of the pond.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 09/16/2019 12:51AM by bodhi.

Bodhi should give us a latest uboot for the M300 to make it perfect. :-)

David,

I expected somebody will wonder about this :) the stock uboot limitation annoyed me too!

If I have a few days gap in my upcoming consulting contract renewal, I'd might be able to get that done (or at least a usable version with GPT and netconsole).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I forgot one more topic: WOL.

This box SoC is the same as the Zyxel NSA325 and NSA310S, so it should work likewise. I've tried a couple etherwake but it does not seem to work.

Update:

I have just reliazed that we have not looked into poweroff! it does work now. But the shutdown kills all power to the box.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 09/16/2019 05:03PM by bodhi.

Neal,

> Oops had already run the script before I saw your
> post!
>
> GPIO41 gave this error as did GPIO6:
>
> /scripts/test_gpio: 8: echo: echo: I/O error
>
> It doesn't seem to have hurt anything!
>
> Anyway, it looks like GPIO37 turns the LED orange
> and GPIO38 turns it white. Not sure how to make
> it blink.
>
> root@Gilrain:/sys/class/gpio# echo 0 >
> gpio37/value # turn orange led on
> root@Gilrain:/sys/class/gpio# echo 1 >
> gpio37/value # turn orange led off
> root@Gilrain:/sys/class/gpio# echo 0 >
> gpio38/value # turn white led on
> root@Gilrain:/sys/class/gpio# echo 1 >
> gpio38/value # turn white led off
>

When you run this script did you let it cycle through all GPIOs? i.e further than the LED GPIOs 37 and and 38?

GPIO 41 is actually the RESET

So I'm wondering that this box even has a GPIO for poweroff if indeed you have tried all GPIOs and did not see the box power down.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------

>
> When you run this script did you let it cycle
> through all GPIOs? i.e further than the LED GPIOs
> 37 and and 38?

Yes

>
> GPIO 41 is actually the RESET
>
> So I'm wondering that this box even has a GPIO for
> poweroff if indeed you have tried all GPIOs and
> did not see the box power down.


Did you get GPIO 41 to actually reset it? Because I wonder if the script was calling it correctly for that function given that it produced an I/O error. Also recall that GPIO 6 produced the same I/O error, so is that possibly the poweroff GPIO?

EDIT: Now that I went back and manually tried to export GPIO6 and GPIO41 I see that the export didn't even work, so nothing actually got written to those GPIO:

 echo 6 > /sys/class/gpio/export
-bash: echo: write error: Unknown error 524

 echo 41 > /sys/class/gpio/export
-bash: echo: write error: Device or resource busy

Neal



Edited 1 time(s). Last edit at 09/17/2019 11:29AM by nwestfal.

Neal,

> Did you get GPIO 41 to actually reset it?

I actually tried using 41 for Poweroff in the DTS. That how I observed the behavior: the box reset at the end of kernel booting, before rootfs is mounted. I got the signal reversed (Active High).

> EDIT: Now that I went back and manually tried to
> export GPIO6 and GPIO41

In stock OS or in Debian?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

A bit off topic, but I need some advice from the community. I plan to use the M300 as a music server with an internal SSD. There will be a 8GB root file system partition with the remainder of the 120GB drive a second partition for the music files. Should this second partition be ext3 or ext4? Does it even make a difference?

I use a Windows box for preparing the music files, tagging, etc so now I need to transfer them to the server. I'm guessing Samba is the way to do this. Is there something better? It would be used only occasionally, and blazing speed is not needed.

Thanks for the advice.

Mike,

> A bit off topic, but I need some advice from the
> community. I plan to use the M300 as a music
> server with an internal SSD. There will be a 8GB
> root file system partition with the remainder of
> the 120GB drive a second partition for the music
> files. Should this second partition be ext3 or
> ext4? Does it even make a difference?

Either should be fine. Since it is data partition, I would use Ext4 (a little more efficient). But if you plan to to access it when in rescue (stock OS) then use Ext3.

>
> I use a Windows box for preparing the music files,
> tagging, etc so now I need to transfer them to the
> server. I'm guessing Samba is the way to do this.
> Is there something better? It would be used only
> occasionally, and blazing speed is not needed.
>

Yes Samba is fine. Make it simpler since it is Windows native.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Neal,

> > Did you get GPIO 41 to actually reset it?
>

You can only see the reset is 41 while in stock OS.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

An "interesting" development after I copied my 5.2.9 buster filesystem from USB to the internal flash card (partitioned 4GB rootfs, remainder data). Booting now stalls for about 2 minutes, usually after the starting the sshd service. The serial log got lost today, but contains "urandom warnings". A little research came up with this:

https://unix.stackexchange.com/questions/461425/debian-testing-takes-a-long-time-to-load-crng-init-done

Seems to be a kernel problem.

Only seems to cause a slow boot, but strange that it occurs with the internal drive, and not with USB. And, I've used 2 different USBs with no delay, one buster and one jessie, both with the 5.3.9-tld-2 kernel.

I can capture the serial log if needed.

Try installing haveged. That’s what i’ve ended up doing on my armada370 systems

Mike,

> warnings". A little research came up with this:
>
> https://unix.stackexchange.com/questions/461425/debian-testing-takes-a-long-time-to-load-crng-init-done
>
> Seems to be a kernel problem.

I did not see this in one of my boxes which run kernel 5.2.9 from SATA rootfs.

> I can capture the serial log if needed.

Yes.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I also did not see this urandom slowdown on the Thecus N2350

Linux tldDebian 5.2.9-mvebu-tld-1 #1 SMP PREEMPT Mon Aug 19 12:47:39 PDT 2019 armv7l GNU/Linux

root@tldDebian:~# cat /etc/debian_version
10.0

[   26.264707] fuse: init (API version 7.31)
[   32.063152] random: crng init done
[   33.421951] Adding 8191996k swap on /swapfile1.  Priority:-2 extents:170 across:33709716k FS

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 09/17/2019 10:28PM by bodhi.

Here's the relevant part of the log, 35 to 145 seconds:

Quote

Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon[ 35.342548][ T1466] random: avahi-daemon: uninitialized urandom read (4 bytes read)
[ ok .
[....] Starting NFS common utilities: statd idmapd[ ok .
[....] Not starting NFS kernel daemon: no exports. ...[warn (warning).
[....] Starting NTP server: ntpd[ ok .
[....] Starting OpenBSD Secure Shell server: sshd[ 145.060196][ C0] random: crng init done
[ 145.064323][ C0] random: 1 urandom warning(s) missed due to ratelimiting
[ ok .

Entire minicom capture attached. Ignore the logitech media server stuff.



Edited 1 time(s). Last edit at 09/17/2019 10:38PM by mikeh49.

Mike,

I think you should do what 1000001101000 has suggested (that's what the stackexchange answer suggested too).

Quote

> Try installing haveged. That’s what i’ve ended
> up doing on my armada370 systems

But first try this experiment . Do you have a USB you can attach to the box during boot to see if the kernel will get from the USB enough data to feed the rng?

I'll have to boot the basic rootfs on the SSD and see what's going on. I suspect that there is not enough "noise" on the SSD rootfs for crng to generate randoms.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 09/18/2019 06:29AM by bodhi.

I just installed 5.2.9 on my M300. Great work as always bodhi!

I have two questions:
1) Is the other 270M or so of RAM unavailable?

Stock:

             total       used       free     shared    buffers     cached
Mem:       2074580     192664    1881916          0       6000      76316

5.2.9:

              total        used        free      shared  buff/cache   available
Mem:        1804532       18088     1453096         308      333348     1762908

2) Is there any advantage to using a USB flash drive for the root file system? I think I'd prefer to wipe the internal SSD and use it and not have anything sticking out of the back. :-)

Thanks for all you do, bodhi!
-JT

JT,

> I just installed 5.2.9 on my M300. Great work as
> always bodhi!

Cool!

> I have two questions:
> 1) Is the other 270M or so of RAM unavailable?

They are not available. We would need to use HighMem in kernel config to see all 2GB, but that's too buggy for Kirkwood. Note that I did not do any thing extra other than using config option already provided by the mainline kernel. So that's what we got by default (the safe choice).

> 2) Is there any advantage to using a USB flash
> drive for the root file system? I think I'd
> prefer to wipe the internal SSD and use it and not
> have anything sticking out of the back. :-)

I would use the internal SSD, too, and do rsync backup to a USB thumb drive before each Debian or kernel upgrade, and periodically. I would treat it like a USB flash drive and take precaution to avoid wearing it out (we dont know yet if it has wear leveling).

I like to use USB drive for rootfs to make it easier to do backup, cloning and fixing problems. But I do take precaution like others and I've suggested in the Wiki thread.

Flash drives issues 

How to prolong the life of your rootfs USB thumb drive 
Overprovisioning A Flash Drive?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:

> You can only see the reset is 41 while in stock
> OS.

Okay. Yeah I did the test in Debian, not in stock. I'm still curious about GPIO 6 though...

Neal

Who knew all this random stuff was going on! I can see why it stalls at the ssl start as it needs a random number for seeding, I guess. From the Arch wiki:

Quote

If you are not sure, whether you need haveged, run:

# cat /proc/sys/kernel/random/entropy_avail

This command shows you how much entropy your server has collected. If it is rather low (<1000), you should probably install haveged. Otherwise cryptographic applications will block until there is enough entropy available, which eg. could result in slow wlan speed, if your server is a Software access point.

You should use this command again to verify how much haveged boosted your entropy pool after the installation.

Entropy on the M300 with internal flash disk is 54, this morning. A PogoPro running on USB is 144. The Pro takes a long time (couple minutes) to get the wifi up, this may be a factor.

And I was taught that entropy is always increasing.

I'll do the test with the USB and then try Haveged.

Do you guys work with this stuff ?

My understanding is most cpu's have a built-in entropy source but these were determined to be potentially insecure around the same time as all the meltdown/spectre stuff was being discovered. Sometime around 4.17 they started disabling them by default.

This has given me a few headaches since rather than use/provide a rootfs tar like Bohdi I provide a modified Debian Installer image for some devices. Unfortunately, within the installer it hangs at ssh-key generation if it takes more than a few seconds for some reason. I've resolved the issue there by basically embedding haveged and starting it right after boot within the installer and then adding haveged as one of the packages that gets installed.

I haven't looked into trying to re-enable the cpu rng yet, mainly because I mostly work with the vanilla Debian kernel. That might be something for bohdi to consider though.

Thanks, good info. Does haveged get itself linked in so that it runs during boot such that the random number is available when ssl starts? I suppose so, otherwise what would be the point.

Yeah, the package creates a service that runs early enough to sidestep the problem.

With a random Fat32 USB with a bunch of files on it, here is the relevant part of the boot:

Quote

[....] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon[ 38.745960][ T1469] random: avahi-daemon:)
. ok
[....] Starting NFS common utilities: statd idmapd. ok
[....] Not starting NFS kernel daemon: no exports. ... (warning).
[....] Starting NTP server: ntpd. ok
[....] Starting OpenBSD Secure Shell server: sshd[ 67.598811][ C0] random: crng init done
[ 67.602932][ C0] random: 1 urandom warning(s) missed due to ratelimiting
. ok

38 to 67 seconds this time, so faster.

root@Dell-M300:~# cat /proc/sys/kernel/random/entropy_avail                                        
240

240 compared to 54 following boot without the USB.

Haveged coming up...

After install of haveged, no reboot...

root@Dell-M300:~# cat /proc/sys/kernel/random/entropy_avail                                        
2487

Reboot with haveged...

Quote

[....] Starting system message bus: dbus[ 35.194154][ T1443] random: dbus-daemon: uninitialized )
[ 35.217489][ T1443] random: dbus-daemon: uninitialized urandom read (12 bytes read)
. ok
[....] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon[ 35.333689][ T1466] random: avahi-daemon:)
. ok
[....] Starting entropy daemon: haveged. ok
[....] Starting NFS common utilities: statd idmapd. ok
[....] Not starting NFS kernel daemon: no exports. ... (warning).
[....] Starting NTP server: ntpd. ok
[....] Starting OpenBSD Secure Shell server: sshd[ 37.672715][ T1495] random: crng init done
[ 37.677085][ T1495] random: 1 urandom warning(s) missed due to ratelimiting
. ok

Now 2 secs. Good enough for me.

After reboot...

root@Dell-M300:~# cat /proc/sys/kernel/random/entropy_avail                                        
2099

Something for the wiki for folks booting from sata/ssd or whatever?