Need help with SSD boot

I am new to RPi and Dietpi. So please bear with me.
I purchased a Argon One M.2 case for my RPi4 and a Kingston Kingston A400 240G Internal SSD M.2 2280 SA400M8/240G.

I have a RPi4 Model B, using Dietpi v6.34.0
I have been able to run Dietpi from the SD card. I was able to transfer FS to the SSD card. But I can not get it to boot from the SSD card.
It seems to attempt to boot to SSD when I move past the initial screen, but it fails to boot from USB 2 or USB 3.

When I connect the M.2 to my PC, I can see it, but I can’t see the files in File Explorer, windows 10.
I have researched how to make it boot from the SSD, but nothing seems to make it happen.
Can someone direct me to a step by step on how that can happen, please??

I appreciate any help I can get.


Version 6.34 is stone age. Pls use last image from our website. As well, try to flash the image to SSD directly. At least on a USB connected disk, this should allow USB boot ootb on a RPI 4.

On Windows, you are not able to see any files except boot folder. Because the major part is ext4 file system. And windows is not able to read this.

Well v6.34.0 might be stone age, but my image was made to run a digital dash. It has been modified to do run software for tuning an engine.
I tried to use the latest image and could not get it to work anything close to what I have. I have no idea what was changed in the image to make it do what it does.
In raspian I can figure out how to edit files to make things happen. But I haven’t been able to figure out how to do that in Dietpi.

I can see all the files on the SD card and I was hoping to open old and new and compare, but I get errors for drive duplicate ID’s, so I can’t view files from each SD card to compare them.

So I have gone around and around, and not getting anywhere. I was hoping to speed up the boot up process with the Argon M.2 drive.

As I said, I attempted to open the latest image, first boot and setup went down hill very fast. What I ended up with looked nothing like what I have with the old image.

The guy that created the original image has moved on to other platforms and isn’t available to help.

I will keep trying.

DietPi is using the very same configuration files as Raspberry OS. Especially this old image has been built out of Raspberry OS as base image.

Ok… I’ll keep trying.


I found this link:

And proceeded to follow the instructions.
I verified I have buster, I backed up the system.
I attempted to Change the package sources and that is where it stopped following the procedure.
I entered all the commands and attempted to get it to update. I got a response of certificate is not trusted.

Am I on the right track? It would be nice if I can update my present version to the new one, instead of trying to modify the the latest image to fit my needs.

I also took a look at the files in the /etc/apt/sources.list.d
and found only one file raspi.list
Not sure what I am suppose to see…
Thanks for any help.

Can you please show the output of:

apt update  
cat /etc/apt/sources.list.d/raspi.list
cat /etc/apt/sources.list

Because I am not on the Pi4, the only good way, that I know of, is to take pictures of the response I get from those commands.
First time I am uploading pics. Hoping they are not too large a file… etc.

Thanks for your help!!

There was no possibility to connect via SSH?

Your system time is completely out of sync and would need to be updated first

/boot/dietpi/func/run_ntpd 1

Thank You… Joulinar!!

I was able to configure SSH and it sure makes this much easier!!

I am in the process of upgrading it now. Hoping it works out!

SSH is activated on DietPi by default. Usually there is no need to configure anything. :thinking:

I had to add dropbear, to get it to communicate. This image has been modified to attempt to get the Tuning software to boot as fast as possible.
I have been doing upgrades until it removes the Wicd-daemon and then it stops.
Here is what the last few lines are…

Unpacking libpolkit-gobject-1-0:armhf (0.105-31+rpt1+deb11u1) over (0.105-25) ...
(Reading database ... 53511 files and directories currently installed.)
Removing python-talloc:armhf (2.1.14-2) ...
Removing wicd (1.7.4+tb2-6) ...
Removing wicd-gtk (1.7.4+tb2-6) ...
Removing python-smbus:armhf (4.1-1) ...
Removing wicd-daemon (1.7.4+tb2-6) ...

Progress: [ 36%] [####################......................................]

Wicd is what it uses to go on the wifi.
I am not sure what is normal for the wifi software???

I burned a copy of what I had to the M.2 card and removed the SD card and it booted from the SSD. So that is one accomplishment.
Now it spends more than a minute waiting for postboot activity before It moves forward to open… I would like to find a way to get rid of that, if possible.

That’s the recommended way to boot from external disk

You mean you like to speed up boot brocess?

Yes, that is the reason I wanted to try the M.2.
The original image was modified by a guy that knows what he’s doing. He trimmed Dietpi down and removed everything unnecessary, being used as a dashboard. Main goal was fastest boot time.
His version will boot in 20s or so. Then the tuning software takes a minute to load.
If I could get that to work with the M.2, I am confident it would speed the process.

Thanks for your help!!

well, a regular DietPi system will boot in less than 15 sec, even using a SD card.

You could try to check what is taking that long.

systemd-analyze critical-chain

Ok. Here is what I found after running the script.

root@DietPi:~# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character. @4.416s
└─ @4.415s
  └─dropbear.service @4.358s +55ms
    └─dietpi-boot.service @4.110s +234ms
      └─ @4.103s
        └─ifup@wlan0.service @3.937s
          └─ @3.934s
            └─dietpi-preboot.service @2.738s +1.194s
              └─dietpi-ramdisk.service @2.524s +209ms
                └─ @2.491s
                  └─ @2.491s
                    └─dbus.socket @2.491s
                      └─ @2.490s
                        └─systemd-update-utmp.service @2.459s +30ms
                          └─systemd-tmpfiles-setup.service @2.412s +43ms
                            └─ @2.405s
                              └─boot.mount @2.174s +228ms
                                └─systemd-fsck@dev-disk-by\x2dpartuuid-6c586e13\x2d01.service @2.009s +162ms
                                  └─dev-disk-by\x2dpartuuid-6c586e13\x2d01.device @1.994s

No idea what it means. It takes more than a minute to finish booting after power up.

I will try a fresh Dietpi image and see how long it takes to boot. I tried it once, but found my Rpi4 B has the older chip in it… At least that is what it shows when I look at the specs…

I am flashing a Armv7 SD card now to see how it goes.

Thanks for staying with me on this!

I rearranged your post. Now it is way better readable. For me it looks, your system was ready very quickly. Where do you see it is taking more than a minute?

Following will show the whole boot time.


I spent the afternoon creating a new, latest and greatest Image.
I had trouble with the new SD cards I purchased. Same as the old ones but they would fail a flash. So I used a 64mg SD card that was purchased a year ago… That worked.

So after initial start/setup and configuring LXDE and auto log in… I did a shut down and started my timer when I turned on the power to the Rpi. It booted and logged in and started LXDE. That took a total of 47 seconds.

Here is what I found.

root@DietPi:~# systemd-analyze
Startup finished in 1.186s (kernel) + 24.605s (userspace) = 25.791s reached after 24.577s in userspace

So that is what I want to speed up.
For use as a dash, I don’t always need wifi or ssh. So I think the previous guy shut off everything not necessary, to speed up the process of getting to the Tuning software.
Of which, I have not figured out how to install.

Any suggestions on how to speed it up… Would be appreciated!!

Thank You

is showing the critical path of activities contributing to the boot time. But this is just the time for the system to get ready. It did not include anything like the LXDE desktop.