I tried to make the Pi4 boot from ssd using this instruction. https://www.tomshardware.com/news/boot-raspberry-pi-from-usb,39782.html
It didn’t work. blue led is flashing on the usb3 to sata adapter but doesn’t stop.
Wrong adapter?
Please try it with a fresh image. Use Rufus (in case you use a Windows system) to flash the image in dd mode to SSD directly. The new Rufus version allows to select an USB attached SSD or HDD as well, not just SDcards and USB flash drives.
I would unplug the SDcard then and plug USB drive only. Then plug power/boot. Our fstab and cmdline.txt entries contain the PARTUUID of the partitions as mount sources, so it should work without changing anything, compared to /dev/mmcblk0p1|2 like entries, like mentioned in the guide, since PARTUUIDs should be applied to the SSD partitions as well when flashing.
Have a screen attached, so you see the exact error or last output in case it does not work, so we can see what is required additionally.
Ah yeah, they dropped HDMI port 
. I still do not understand the step with dual HDMI, I mean how many users use an SBC for regular desktop work, and then even some kinda work where you need two screens? However OOT 
.
will report back when i can attach a screen. What i noticed however is that IF there is no SD card attached, no power is send to the usb-port (lights on the usb2sata adapter don’t light up) I am still wondering if my adapter isn’t the problem. Will test with a usb-stick as wel…
ps: same thing, a usb3-stick is not detected/activated at boot (in a usb3 port on the pi4)
Found the answer myself:
How long after the release of ownCloud 10.03 can we expect a working version on DietPi?
@cpp I used Opera to open the link (and then i was able to download it) In IE and Chrome it didn’t work.
lpw
Dammit, they just released v10.3 one day (today) after we released v6.26: https://owncloud.org/download/
Hmm, I will post some instructions later, respectively create a PR, so you guys can download an updated dietpi-software version which allows ownCloud install on RPi Buster images. Timing 
…
cpp
We will not ship an RPi image on that basis. This would mean a huge overread and rework to get it done correctly. Instead we will ship RPi 64bit images as fast as official Raspbian 64bit is released, but this might take still a while.
Ok, i get it, though I didn’t understand how stable/complete is this image, wondering if I should simply wait for an official dietpi release that works for rpi4 or go ahead with this one
The RPI4 still doesn’t support native USB boot, you must use the cmdline.txt of a sdcard to boot on an usb device.
here’s the correct to usb boot guide tomshardware should have write (but for official DIETPI, FOLLOW THE EASY EASY EASY EASY way MichaIng suggests below this comment) :
burn the image on a sd and then on the sdd.
insert and the sd, plug the usb ssd.
you will so boot on the sd, do a fast minimal conf.
blkid to see the partuuid of your usb ssd (you can use /dev/sd also, but if you connect a second usb device, you are not sure which one will get the sd"a", and maybe your boot drive will be sd"b", and so the cmdline.txt will address it wrongly).
with your partuuid, modify the /boot/cmdline.txt to get root=PARTUUID=xxxxxx-xx (for example, my ssd drive has root=PARTUUID=f4455faa-02 (and it contains PARTUUID=f4455faa-01 which is the boot (but still useless) partition, and PARTUUID=f4455faa-03 which is an exfat partition I share through samba, but that i could easily access by usb on a mac or a windows if the rpi is off)).
mount /dev/sda2 /mnt
nano /mnt/etc/fstab
reboot
modify the fstab as you need, here’s mine for example :
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=f4455faa-02 / auto defaults,noatime,rw 0 1
/dev/mmcblk0p1 /boot auto defaults,noatime,rw 0 1
PARTUUID=f4455faa-03 /media/share auto defaults,noatime,rw 0 1
/dev/mmcblk0p2 /media/sdcard2 auto defaults,noatime,rw 0 1
LABEL=SSD1TB /media/SSD1TB/ auto defaults,nofail,noatime,rw 0 1
as you can see, my ssd is well mounted on / and /media/share (my share), 1st sd card partition (“BOOT”) on /boot , I also the 2nd on /media/sdcard2. I also mount my bigger drive to share it.
I have to apologize, I said that the bluetooth was working, but it’s wrong, the dietpi-config see it, claims it’s on, but it’s not true, as debian didn’t have the pi-bluetooth or the brcm_patchram_plus , it has to be manually attached and this doesn’t work as well as it should, I’m right now looking how to compile the brcm_patchram_plus as an arm64 and then will provide you with it (and update the img).
another point if you want to use a desktop environememt, as I can see, the dtoverlay=vc4-fkms-v3d & max_framebuffers=2 MUST be disable to allow the xserver to display something else than the mouse pointer. must be a driver issue.
As my knowledge is still very limited (I’m a *nix noob), I will not look about this vc4-fkms-v3d issue, after looking for a BT fix, I will more look on what the uBoot support of the RPI4 could offer (maybe to make a native usb boot, I little bit worry about the delay for this from the RPI Fundation… they will address this only after bring the net boot to the rpi4… (how many rpi are net booting comparing to how many people want a fast usb storage ? I don’t understand how they are working, maybe I’m missing a lot of background about them…))
EDIT : I corrected mistake i did when wrote the code about editing the cmdline of the usb drive (sorry for that, my brain is working too much last days).
EDIT 2 : ahahhahahaahah I just had a look to the article from tomshardware 
That guy smoked weeds before writing it I think ^^
“Network and USB boot
Support for these additional bootmodes will be added in the future via optional bootloader updates. The current schedule is to release network boot first, then USB boot.”
the good guide is here :
EDIT 2 : the first partition you have on your usb drive with my experimental dietpi debian arm64 (the fat32 containing many useless for now boot files) should be “deleted” to avoid wrong manipulation, but its space should kept as free space in the partition scheme in case of you would like to just create a new fat32 and copy to it the content of /boot (from the sdcard) when the rpi4 will be ready to boot usb natively (it’s only 200mb of space).
I also just finished to convert a september raspbian system to dietpi, and then ask it to use the kernel8 (aarch64), ram read perf are still here but we lose some CPU perf :
│ - CPU Performance : Duration = 8.86 seconds (lower is faster) │
│ - CPU Temp : Idle = 37'c | Full load = 43'c │
│ - RootFS : Write = 7 MiB/s | Read = 10 MiB/s │
│ - RAM : Write = 401 MiB/s | Read = 1252 MiB/s │
In that case, the system is what they call 64 bits kernel with 32 bits userland
ThAnEb
If indeed RPi4 only boots from SDcard, then NEVER mount the 1st partition of the SSD (PARTUUID=f4455faa-01) to /boot or anywhere else, at best do never create this on external drive in the first place. All bootloader/kernel/dtoverlay/boot settings/configs/versions will be loaded from SDcard but written back to SSD then. So user does some settings changes or updates the kernel/firmware packages and then wonders why nothing changes since the Pi loads things still from the untouched SDcard. Even worse, kernel and /lib/modules/ will not match anymore after upgrades, hence kernel can crash, corrupt data or even deny to boot and when reporting some bug, it is nearly impossible for us to imaging THIS as error source.
I had a user once with exactly this situation and it wasted a lot of time and nerves 
.
So, please do not follow the above guide, but:
Use dietpi-drive_manager, select the SSD or partition you want to use as new root partition and select “Transfer RootFS”. This will clone the root partition only and automatically does required changes to cmdline and fstab.
EDIT: Ah you found that out as well already 
. Yeah as said, things can become much worse then just non-working dietpi-config, and things are much easier to apply correctly via dietpi-drive_manager 
.
I will have the luck to test your walkthrough…
I just made a “test” this afternoon (I’m on UMT+7), i burn a fresh raspbian and convert it to dietpi… and let the usb drive connected… and now, after few hours to play with the bluetooth on raspbian, i putted my other sd who should just launch the usb mount… and the fat32 (boot) and ext4 (/) from the usb drive are just EMPTY (the 3rd partition, my extfat share is still here with its content)… I didn’t mount or open these partitions during all the time I spent to play with raspbian and then dietpi on raspbian, so… I suspect something happened with the diepi script, i already saw the /boot content being entirely delete when i was PREP script the kali 64bits…
ThAnEb
Not sure how this Kali image is build up, using it is always on your own risk and I have no insights about how well this works with DietPi at all. Our RPi Buster image on the other hand works just fine on RPi4.
I am thankful for any tests with 3rd-party arm64 images, but just want to make clear here what is experimental and what is officially supported by us .
Not sure about the modifications you did to DietPi-PREP to allow it installing DietPi on Kali image, since it by default, when RPi is selected, will set default Raspbian + RPi firmware repo sources which are not arm64, hence will not work on the Kali image. I can only imagine that some firmware update then purged /boot, but as said, no insights.
At the end, I didn’t modify the PREP script to install it on kali, i just modified the /etc/os-release to make it match the debian buster, then, following your advice, i choose the generic install.
However, the last Dietpi img i shared here is based a pure debian arm64 + kernel8 from raspbian github .
The debian was made with bootstrap, then clone and apply at their good place the rpi firmware files (booted and checked) on a 1GB usb key, and finally execute the PREP script and then dd of the key.
I’m unable to find the “Transfer RootFS”
ThAnEb
Ah okay, when selecting “Generic device”, then the RootFS Transfer option should not be shown in dietpi-drive_manager, since this is only for detected RPi and Odroid devices where we verified that it works well.
So in this case you need to do it manually, however as mentioned, at best do not even create a FAT partition on the SSD to keep things clean, only create a ext4 partition to clone SDcard/image ext4/root partition to and edit cmdline.txt+fstab root (/) mount only, while leaving /boot mount from SDcard as it is.
let me know if you are able to use my Experimental img with your ssd… I had to re-install the system on mine, and i run into a kernel panic when try to boot through usb… so i had to make a fresh debian install again (but i scripted that, so if you have issue, i can easily give you the script, have gparted the usb target, then copy past the script into a root terminal, press enter maybe 8 times, type 2 the wished debian user password, adjust the fstab and reboot ^^ ).
ho, and my script include the dropbear install, so you not need to care about receiving the micro hdmi cable to use it 
lpw
I just created a PR to allow ownCloud install with PHP7.3 due to recent release: https://github.com/MichaIng/DietPi/pull/3169
After updating to DietPi v6.26, please try:
wget https://raw.githubusercontent.com/MichaIng/DietPi/owncloud/dietpi/dietpi-software -O /DietPi/dietpi/dietpi-software
This should allow you to install ownCloud on RPi1/Zero and Buster-based systems via dietpi-software.
I will keep this branch active until v6.27 release, since it does not contain any other changes yet, hence is safe to use on v6.26.
I did a clean install ( official dietpi ) and transfered the Userdate to SSD. I got lots of errors at reboot (see attachements) It seems that the Pi4 now boots into save mode.
Photos.zip (4.53 MB)
you went with the official dietpi img or my experimental (debian) one ?
I putted a first commented version of the script I made to largely automate creation of a debian arm64 for rpi on a external drive (for now it’s targeting sda2, so be sure to have only one external drive connected), if you want to use it, it’s a simple copy paste into a terminal, few “enter” hits, one password to choose and one " ./buildcontinue.sh " to enter
after the reboot, you can install DietPi with the
bash -c "$(curl -sSL https://raw.githubusercontent.com/MichaIng/DietPi/master/PREP_SYSTEM_FOR_DIETPI.sh)"
I wanted to improve the script with arguments and drives/partitions detection and choices options, but my family doesn’t help me to have enough free time to improve my bash knowledge to go as fast as I would like ^^