@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 ^^
https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md
“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 :
https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/
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
https://github.com/thaneb/Debian-SystemBuilderRPI/blob/master/autobuild.sh
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 ^^
@ ThAnEb, I will have to redownload the experimental dietpi-img but it’s hard! (link/site doesn’t work always, even if i allow flash/ads/cookies/everything)
ps: downloaded with edge this time. Don’t know why i have to use a different browser every time (?)
ps2: Moving userdata to ssd worked (reboot went fine) using dietpi-menu.
ps3: i am installing smb/nfs/syncthing and homeassistant now…
Sorry for the issue you encountering with 1fichier, i never had any issue with them for dl (from France, Switzerland or Thailand), but i will look for an alternative file holster tomorrow for make it more smooth. A good alternative (that can be also a good way to learn more about debian distrib) , may be to look the script i putted on github and other maybe adapt it for specific needs or installation, at the end you dl almost the same amount of data, but you start to know how to make your own debian kitchen ^^
EDIT : I just change the usb adapter used for my “rootfs” ssd, and it was not booting… thanks to its led activity status, I saw that it was late to switch on, so I moved the drive to a self powered usb 3.0 hub, and of course, it boots without any issue.
So, have to know that depending on the usb adapter used, a self powered hub may be required to allow the boot.
Hey guys, just a suggestion:
Probably is is beneficial to discuss the RPi x64 topic in a separate thread here or GitHub issue? I really like to collect experiences, especially since an x64 kernel is now officially integrated into the new RPi Buster firmware packages. Any testing and error collection should be helpful to report back to RPi developers, and by this help to have a soon Raspbian x64 release with stabilised firmware.
In this thread, where it was about RPi4 support with regular x32 Raspbian, it is probably confusing for others, reading it?
Ok, I got the point, sorry, i will look where it would be the most relevant to speak about that, sorry for the mess here 
Sorry MichaIng.
Will stick with pure DietPi for now…
As said, I don’t want to break any testing with this, as IMO x64 should become default for SBCs quickly as well, and its somehow a mess that already RPi2 PBC 1.2 actually has an ARMv8 (x64) capable CPU but Raspbian is compiled for ARMv6 (armv6hf).
So playing with the new x64 kernel totally makes sense, but a separate thread allows better tracking, not disturbed by other posts that are related to RPi4 in general (as of topic).
Just to mention:
On DietPi v6.26.3, booting from ssd (rootfs) works if the ssd (on a usb to sata cable) is on a powered-usb-hub.
Syncthing can be installed but no lamp-stack is installed automatic.