Add USB activity check prior to launching nwipe

[PartialVolume]

Add a USB activity check to delay the launch of nwipe, so that all USB storage devices are detected consistently.

At the moment nwipe launches immediately and often this is before devices on the usb bus have been detected.

Therefore in order to consistently detect USB devices ShredOS should prevent the launch of nwipe until the USB devices (if any) have initialised and the kernel sees no more activity from USB devices.

On the hardware I've examined USB device detection can take up to 5 seconds after the initial launch of the kernel. So my proposal is to add some code to the launch script that monitors kernel activity and when all USB activity has ceased, which is usually 3 to 5 seconds after the kernel starts then ShredOS will delay for a further 3 seconds and if there is still no USB activity during that 3 seconds then nwipe will launch.

This should provide consistent detection of USB devices on first launch without the user having to resort to a Control C in nwipe to see the USB devices.

An alternative method would be to have the drive selection window constantly check for changes. This would involve a lot more work due to the way nwipe was designed to detect and built the drive contexts when it first starts. It's something that it should do which would allow you to hotplug USB devices and see them appear and disappear from the drive selection window, however this feature would have to come after the secure erase feature.

I'll make the changes and put this feature (nwipe USB launch delay in the next pre-release.

[Nebuli1]

1. adding USB delay is a great idea, because autonuke for USB drives will work without using the keyboard. I think it is additionally worth introducing the idea you suggested and the --noshredos command or as ITJamie suggested --no-wipe-boot-drive. Excluding sda seems insufficient to me.

2. idea would allow to make automatic media cleaning stations - Autonukeshredos station :) I would love to build an automatic media cleaning station when connected to USB. I already have the components in my head:

MINI PC 30USD MangoPi mq-pro D1 RISC-V SBC board 512MB RAM with WiFi /30USD https://tinyurl.com/4svau3uy SATA 3.5/2.5 to USB ADAPTER /15.77USD https://tinyurl.com/282frpza NVME USB ADAPTER /21USD https://tinyurl.com/32t2y738

Everything will fit in the adapter case. possibly additionally a display about -$7 https://tinyurl.com/2ne3326y I could take the cleaning station with me everywhere.

[PartialVolume]

@Nebuli1 That MangoPi looks like a Chinese clone of a Raspberry Pi Zero. In the UK you can buy (as long as it's in stock that is ;-) a genuine RPI Zero W2 for £17, £5 cheaper than the clone. The Mango was £22 for me using that link.

I can see a couple of general & performance issues:

• USB performance: I've only seen one USB benchmark for a RPI Zero but the USB performance topped out at just under 40MB/s. Most spinning platter HDD's can write at 60 to 150MB/s so the USB performance could throttle speed.
• It's a RISC processor, so the current builds I upload would not work. An Arm processor build would need to be built, not a problem necessarily, but I've never built ShredOS for the Raspberry Pi, I don't know if anybody else has? Buildroot supports building for the ARM processor so in theory it should work.
• Display, there is a RPI display driver, I don't include that normally as obviously not used for a x86_64 or i586 system. The display driver would need to be included in the ARM build.
• Memory, 512MB should be OK, ShredOS's minimum requirement is 256MB CPU RAM so 512MB would give some extra space that would be mainly be used for disk caches.
• Processor performance, now this would be interesting to see, I know a RPI 4 (with 8GB) CPU RAM is very capable, I use one with a full XFCE desktop for streaming TV video from a TV stick on one USB port and out on the RJ45 ethernet. Not as speedy as your x86 platform by any stretch of the imagine but still quite remarkable when used with the right software, i.e not Chrome & YouTube that's for sure. But a zero doesn't have a RPI4's speed. Nwipe tends to get CPU intensive when it's random number generators are generating numbers at 60 Million a second. On a x86 platform that typically looks like 1 or 2% CPU usage. Of course the USB may already be limiting I/O speed down to 40MB/s but I would imagine the zero processor could well be at 100% usage and therefore causing another bottleneck, Might need a little heatsink stuck on the chip, like you can get for the RPI processor for when you are making it work really hard.
• The RPI4 firmware supports USB booting, I don't know if the Zero does or doesn't. Something to check.

In theory it would work but could take three times longer to wipe a disc than if you used a RPI4 with 2GB RAM. I guess it's a tradeoff, personally I would go with a RPI4 so that the disk I/O speeds via USB were comparable with the x86_64 platform. That would be a very nice little disk wiping device with a Raspberry Pi screen and a little mini keyboard. And importantly for me the drive would be the limiting factor for speed not the hardware it's running on. Not to mention a RPI4 uses a mere 5W of power compared to the power hungry x86 platform. A disk wiping house running with RPI instead of X86 would probably reduce their electricity usage 10 fold. I have a fairly modern i5 and that consumes 50W just when the processor is idling, doing nothing.

One of these days I may do a ARM build just to see whether the wipe I/O performance via USB is as good as I think it is.

[PartialVolume]

There is another advantage to a RPI4 I forgot to mention. Building for a very specific platform is so much easier as I only need to include some specific drivers, under the x86 platform where there is a plethora of drivers for all the different hardware chipsets. This would drastically reduce the size of ShredOS, which is currently at just under 170MB. AMD's DRM drivers alone take up 65MB, so I could see the ARM build boot faster and run in 128MB of memory and maybe only 20-30MB in size. (Just a guess though)

[PartialVolume]

Nice article from Tom's Hardware on advantage of RPI4 USB 3 with bench marks here.

This sums it up why a RPI4 would be the better wiping device rather than anything less capable like the RPI 3 or zero. Their benchmarks are just about reaching 240 MByte/s with a SSD on a USB adapter for sequential writes.

Pi4 benchmarks

[Nebuli1]

I thought mango has USB 3.0, and here only port is USB C ;( Very low transfer ;/. https://bret.dk/raspberry-pi-zero-vs-mangopi-mq-pro-benchmarks/

I purchased with a DELL WYSE ZX0 power supply for $15, it draws 15W. It has two sata ports, two USB 3.0 ports and 12V power, but for 12V I had to add a wire. I achieve about 400MB/s on it for a total of 4 connected drives. I will buy a display and just glue it to it. This will be my number 2 station :)

PS. Dell Wyse 3040 PC similar in size to RaspberyPI draws 3.3 watts in idle according to the manufacturer. I will look for similar PCs with SATA and higher performance.

[PartialVolume]

Nice 🙂, I see you can pick up a Wyse 3040 for about £20 on eBay. Think I might buy myself one of those for testing too.

[PartialVolume]

https://www.parkytowers.me.uk/thin/wyse/3040/ according to the article there is a 12v and 5v version both using the same plug which apparently can lead to a damaged unit if you plug 12v PSU into a 5v unit.

[PartialVolume]

Just bought a Wyse 3040 to have a play with. Worth buying a descent USB adapter that supports ata passthrough so ShredOS/nwipe can detect a hidden area on the disc and provide serial no. Info. See #128 if you've not already comes across it, for a few adapters that support this feature.

[Nebuli1]

ready station for fast disk reset. 12 V I connected through a quick connector. Totally looking forward to the new options :D

[PartialVolume]

Feature: USB activity check prior to launching nwipe added in commit https://github.com/PartialVolume/shredos.x86_64/commit/a044cc12bb9f9f59b72904fd3b8227863bb7586c

Pausing for USB to finishing initialising is now a feature in release v2023.08.2_25.0_x86-64_0.35.