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.
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:
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
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
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 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?
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
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.
@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?