RockPro64 moving DietPi root over to external USB drive

I followed the tutorial found here: Setting up an Odroid HC1 with DietPi and How to move the rootfs to an external HDD - YouTube for the Odroid

Which gets down to the main task starting at about 17 minutes in.

It seems pretty close to the RockPro64, but not quite the same. And it is not the same as would work for an actual Raspberry Pi board.

There is no “boot.ini” file to edit with the RockPro64, for example, nor is there a cmdline.txt file. That setenv variable seems to be found in “ArmbianEnv.txt” or the “boot.cmd” files. Editing both with the UUID for the external USB drive doesn’t seem to work on reboot.

I formatted the external USB drive into /mnt/sda1 = rootfs and /mnt/sda2 = data. I can do everything the YouTube tutorial sets out except that editing “ArmbianEnv.txt” or “boot.cmd” files with the UUID for the external USB drive doesn’t seem to work. If anyone has made this to work with either the RockPort64 board or the Quartz board, how did you go about re-pointing to the external USB? What file or files did you edit and how?

I have copied over all the root files to /mnt/rootfs. I have swapped out the UUID pointer for that of the external USB in the two files mentioned above. I have also edited the /etc/fstab file. But no go on reboot.

Thanks. If there is an up-to-date tutorial on how to do this for the RockPort64 board, all I need is the pointer to it.

1 Like

Hi, in dietpiEnv.txt you should edit rootdev=UUID= and add rootdelay=10 to consoleargs= before console=.
Unfotunately images doesn’t have separate boot partition, so you must do something like this in your /etc/fstab:

UUID=XXX / ext4 noatime,lazytime,rw 0 1
UUID=XXX /mnt/sdcard ext4 noatime,lazytime,rw 0 1
/mnt/sdcard/boot /boot none bind 0 0

I use this on my Odroid HC2. Only one downside is that you must never use dietpi-drive_manager again, because it will mess up your manually edited fstab :frowning:

1 Like

Something we are aware of :roll_eyes:

Add rootdelay=10 to extraargs= instead, as it’s not related to console output, but practically it doesn’t matter.

Only one downside is that you must never use dietpi-drive_manager again, because it will mess up your manually edited fstab :frowning:

Since bind mounts are left untouched, it should work? Or does the x-systemd.automount on /mnt/sdcard cause issues?

In theory, the SD card partition could be also erased aside of /boot and then /boot content moved to the filesystem’s root. Then it can be made a native /boot mount without bind mount. I’m thinking of this as a solution to reimplement into dietpi-drive_manager, for SBCs which do not support USB boot OOTB.

I like rootdelay beside roowait, no another reason :slight_smile:

You are right, it’s booting OK…

1 Like

I do not see a “dietpiEnv.txt” file in /boot/ – or in /boot/dietpi. There is an “armbianEnv.txt” file that has UUID values in /boot/. Is this the same thing? Or am I looking in the wrong directory?

@Wilford888 Maybe you have older version of dietpi? Because if i download image now from website it contains “dietpiEnv.txt”.

I think it should work even with “armbianEnv.txt”.

I found this,which should clearify which file is used on which image type.

	# New mainline kernel U-Boot images with dietpiEnv.txt
	# Armbian uses armbianEnv.txt instead which requires different syntax
	# Sparky SBC uEnv.txt has been renamed to uenv.txt, lets support both variants

So use the file you can find on your boot partition :slight_smile:

Thank you. I will try that.

No luck. “armbianEnv.txt” I changed to (with correct UUID for sda1 (rootfs)) and correct UUID for sd card:

UUID=XXX / ext4 noatime,lazytime,rw 0 1
UUID=XXX /mnt/sdcard ext4 noatime,lazytime,rw 0 1
/mnt/sdcard/boot /boot none bind 0 0

I edited the /etc/fstab file on the USB drive (following old tutorial write-up). Does not reboot – connection just times out.

I appreciate the help. Any other ideas? I feel like I am close to getting this working, but not there.

armbianEnv.txt is used on older images, dietpiEnv.txt on the recent images which are now (nearly) all generated with our own build script from scratch, using debootstrap and own boot configs, instead of running the installer on top of an existing Armbian image. But generally both work the same. One difference: armbianEnv.txt has no consoleargs= but console= setting which takes just display/serial/both values and generates the consoleargs variable in boot.scr from it.

Hehe yes, in resulting cmdline this look indeed better.

I was just wondering whether rootdelay=X is redundant with rootwait (which waits infinitely for the root device to become available), but it isn’t exactly the same: Linux-Kernel Archive: Re: [PATCH] init: make rootdelay=N consistent with rootwait behaviour
So still good to keep this in mind when facing issues with rootfs on USB drive.

@Wilford888
If there is nothing visible on attached screen, a serial console should give a hint where and why it fails to boot. Do you have a UART adapter?