yep thats possible. You can use the SD card to host the boot partition and your USB device will contain the RootFS (incl user data)
Steps to be done:
- copy all your user data back to SD card using dietpi-drive_manager, to get the original status
- un-mount the USB device
- do a reboot to check if all working fine
- do a full backup of your SD card
- boot your system up, it should now running on SD card fully, while USB device is not mounted
- go to dietpi-drive_manager
- select the unmounted USB device
- select Transfer RootFS
- now read the following instruction carefully and confirm
- format your USB device
- last chance to cancel
- once done, you will be ask to select a mount point like /mnt/usb. This is just temporary
- as soon as the device is mounted, Drive Manager will stop all processes and start to copy your entire RootFS
- time for a coffee
- you will be ask to reboot your device once completed
- during reboot you might see some services failing like MariaDB. This is happening because Drive Manager missed to copy /mnt/dietpi_userdata
- don’t worry, let’s fix it
- go to dietpi-drive_manager
- select the unused partition /dev/mmcblk0p2 on your SD card
- mount the partition as /mnt/sd2
- exit Drive Manager
- change directory to cd /mnt/sd2/mnt
- let’s copy the missing data cp -p -r * /mnt/
- reboot your system
- now everything should working fine
If you encounter any issues on this, restore your backup to SD card
MichaIng
Is there a reason why Drive Manager is not copying dietpi_userdata during RootFS relocation?
Not really, probably because it is assumed to be on external drive. However as well the rsync does not exclude all tmpfs, most importantly /DietPi is synced as well.
I’ll clean this up by mounting the root partition to a temporary mount point and rsync the files from there. AFAIK rsync itself has an option to sync only files from the same drives, probably one to skip mounts automatically even when from same drive e.g. bind mounts. Much cleaner than excluding only known mounts and /mnt/* (which includes dietpi_userdata).
on my test, /mnt/ themselves was copied to my USB stick but without sub directories /mnt/*. Could that be because I mounted the USB device to /mnt/ before?? At least this was the offer of Drive Manager. Maybe I will some test later the day to have the USB device mounted somewhere else before moving RootFS
Thanks @Joulinar. I’m glad to give this a try, but I’m curious about a couple of things I hope you might clarify.
- “let’s copy the missing data cp -p -r dietpi_userdata /mnt/” - so the USB SSD will exist at / and the default location for userdata becomes /mnt/ right?
- Right now I’m using a 32GB SD card for boot/rootfs and it seems like it would be a waste just for booting the Pi 3b. Would it be reasonable/possible to also have boot from the USB? If so, what does that process look like vs. the one you so nicely outlined? and I understand a one time setting change is required on the Pi, but I don’t understand if that means it will only be bootable from USB afterward, or if SD boot is still possible? What are other consequences of making the USB boot setting change?
- as @MichaIng mentions “However as well the rsync does not exclude all tmpfs, most importantly /DietPi is synced as well.” - is there something I should do differently from the instrucitons to not sync more than what is needed? such as wait for a DietPi update with the new “transfer rootfs” script?
Following the instructions from Joulinar will work. Yes you can also boot the RPi 3 from USB. Is it 3+ or non-plus model?
Cool. I have the non plus model. Just 3b
some USB Boot information and how to activate
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
btw you could move boot partition to a much smaler SD card as well
Thanks. I had read through that article on USB booting, but what I still don’t understand is if I set the one time programmable memory to enable booting from USB, can I still boot from SD if I wanted to (not saying that I would). I’m a little spooked by the OTP aspect since I have no experience with this sort of thing. I’m guessing it just allows USB boot, but does not kill SD boot capabilities.
Also if I plan to have everything on my USB SSD (boot and rootfs) does the process of getting there look something like this?
- add program_usb_boot_mode=1 to the end of /boot/config.txt
- reboot
- copy userdata back to my SD card so everything is on the SD
- create an image of my SD card on my Mac
- burn the image onto my USB SSD
- plug the USB SSD into my Pi 3b, boot
- done!?
Will there be any issues with the SD and USB drive UUIDs being different? I would also plan to remove the old USB SSD from the Drive manager and FSTAB entries before trying to use it as the boot/rootfs drive (it was previously my backup and userdata drive).
Last question, can I use a samba shared drive as the location for my dietpi backups, or is that not possible because of permissions/ownership limitations for network shares?
unfortunately I’m not able to answer the question as I have a 3B+ only where USB boot is working ootb.
But I would expect to have both working once activated. But it might be better to verify and have this question raised on RPi Board. Just in case.
Yep if you swap from SD to USB, you need to adjust UUIDs within /etc/fstab
Recommendation would be to start with a clean install in our SSD to avoid issues or side effects
I found some answers in the Raspberry forums here - https://www.raspberrypi.org/forums/viewtopic.php?t=175630
Looks like booting from SD is still a possibility, so I’ll plan to move forward with setting the OTP memory to allow USB booting on my Pi 3b.
I wouldn’t have a problem updating UUIDs in the /etc/fstab, but since you mention it would be recommended to start from a clean install, would that mean reinstalling and reconfiguring every program I’m running? Is there no clean way to keep what I’ve got? Would restoring from a backup to a fresh install on the USB SSD be better than trying to migrated to the USB SSD from the SD?
I’m currently running:
- Plex
- Nextcloud
- PiHole
- VPN
well you could give it a try to change UUIDs in the /etc/fstab. if it’s not working, you still would have the SD as backup.
Sounds good. I’ll try it out and post the results. Appreciate all the help!
Here’s how it all went down.
- added program_usb_boot_mode=1 to the end of /boot/config.txt
- rebooted
- copied userdata back to my SD card so everything is on the SD
- copied userdata back to my SD card so everything is on the SD
- created an image of my SD card on my Mac
- burned the image onto my USB SSD
- reviewed /etc/fstab - since I burned the SD images to the USB, the PARTUUID numbers were the same - no change required
- pluged the USB SSD into my Pi 3b and powered on
Unfortunately nothing happened after that. The Pi didn’t boot off the USB at all and the lights on the USB>SSD adapter never even blinked.
I’m not sure why. I know some SSDs are not compatible, but everything here seemed to be set up properly. More info on this further down.
Thinking I’d go for the next best setup I did the following:
- removed the USB SSD
- inserted the SD card
- booted just fine
- formatted the USB SSD
- used Drive-Manager to transfer RootFS to the USB SSD
- manually transferred user-data from the SD ext4 partition to the USB SSD
- rebooted and everything works
I somewhat foolisly didn’t run vcgencmd otp_dump | grep 17: after setting the USB boot option in config.txt, because I did check the config.txt file and saw the option was appended properly before rebooting. However now when I run the vcgencmd command it doesn’t give me the output of 3020000a and instead outputs 1020000a, indicating that the USB boot option failed to be set in the OTP memory. If that’s the case, that explains one reason why USB booting would have failed. When I look at /boot/config.txt the program_usb_boot_mode=1 is no longer there 
. I suppose I could do the following to try it again.
- make a new backup of the boot only SD card
- restore the old full OS SD card image to the SD card
- boot off the SD card
- try to set the USB boot parameter again
- confirm it is set
- copy RootFS to the USB SSD again
- try booting again
I also have a 1GB SD card that I’d be fine using for the boot drive. How would I go about copying the current boot drive over to it? I assume I’d again need to change FSTAB (or maybe I could create an image of the current boot SD which should be small now, and restore it to a smaller SD … or would it image the full 32GB of my card. I’ve used PiShrink before to get image sizes down and downgrade cards, but not sure that works with a boot partition only on Dietpi.) Maybe putting both SD cards in as external storage on a different Pi would allow me to rsync the boot drive and then just update FSTAB on the USB SSD to use the new SD card’s boot partition UUID. Decisions decisions.
Quoting myself here:
I somewhat foolisly didn’t run vcgencmd otp_dump | grep 17: after setting the USB boot option in config.txt, because I did check the config.txt file and saw the option was appended properly before rebooting. However now when I run the vcgencmd command it doesn’t give me the output of 3020000a and instead outputs 1020000a, indicating that the USB boot option failed to be set in the OTP memory. If that’s the case, that explains one reason why USB booting would have failed. When I look at /boot/config.txt the program_usb_boot_mode=1 is no longer there > 
I didn’t realize the USB boot option should be set in DietPi-Config > Advanced Options. I had tried editing /boot/config.txt as mentioned in the Raspberry Pi forum post. Once I used the DietPi-Config option and rebooted the USB option was set successfully. Now to try again and see if USB boot can work.
You can add the setting manually add well but read the notes at the beginning of the file: /boot/dietpi.txt is moved to tmpfs at /DietPi/dietpi.txt and back on shutdown. Hence /boot/dietpi.txt is overwritten and /DietPi/dietpi.txt must be edited instead.
However we’ll change this behaviour with next version. Too much confusion and changes are lost in case of power loss.
Got it. Thanks for clarifying.
Update on my progress:
After successfully setting the USB boot option in the OTP memory, I once again flashed my full SD card backup (which contained rootfs/userdata/boot) onto my USB SSD. After removing the SD card and plugging in only the USB SSD, this time it successfully booted! Very exciting to see.
However since the SSD was now seen to have a capacity of ~30GB (same as the SD did) I decided to use the Drive-Manager tool to expand the root partition. It claimed to have succeeded and prompted me to reboot, which I did. The system didn’t come back online afterward. I’m not home at the moment so can’t unplug/replug to see if it comes back up. Just wanted to note/share that experience here. I’ll post again if things are resolved after a hard restart.
Hard rebooted (unplugged and replugged power) and my Pi will not boot up after the rootfs partion expasion via Drive-Manager.
I restored the USB SSD using the image for the SD card and it booted up just fine again. Any input on ways to expand the file system without it failing to boot after, or thoughts on why it’s failing would be much appreciated. I’ll see if I can find info on the interwebz too, or explore the Drive-Manager expansion script to get a better idea of what it’s doing.
maybe you could have a look to this tool
https://gparted.org/liveusb.php