It fails to mount the boot partition from SDcard. Note that you cannot remove it, as long as root partition is on external drive only, and RPi4 does not support USB boot anyway currently.
I do Transfer RootFS to this drive , Then i choice the drive(sda5).And after a few second it’s copie from sd to ssd.
I did this always with previous vesions and that works fine.
I have an idea what might be the issue. With v6.22 we made a change to not forcefully reboot the system after moving the rootfs, but give user the choice whether to reboot now or later. But actually that was not thought through, since other mount options can lead to fstab rewrite which then writes back the old (currently active) rootfs entry. In such case cmdline.txt has the new rootfs entry while fstab has the old one which most likely causes some issue when systemd wants to remount it.
Is it probably the case the you skipped reboot first after moving rootfs?
If so do you have an external Linux system to mount the external drive to? If so edit the etc/fstab on that drive and adjust the root mount entry so that mount source is:
PARTUUID=<PARTUUID_of_that_partition>.
To get the PARTUUID: lsblk -no PARTUUID /dev/sda1 (with /dev/sda1 being the external rootfs partition)
This should match the entry in cmdline.txt from SDcard boot partition as well.
The fstab entry could then e.g. look like this:
PARTUUID=a277a2ba-02 / ext4 noatime,lazytime 0 1
The cmdline.txt contains matching:
root=PARTUUID=a277a2ba-02
I just reverted the change from v6.22, so a reboot is now forced again once RootFS transfer has finished: https://github.com/MichaIng/DietPi/commit/b79bb9e3de863bfb7d01c69b6f3a5f798f839ad8
Changelog: https://github.com/MichaIng/DietPi/commit/482ed82e754f3cdcc20ba2cbdc4b183db8822d6e
And i have no external linux system, I can’t figure this out, this goes too far for me.
I’am a NEWBIE
Can i get a link(url) for a older dietpi version ? that will help me.
If not then i must look for a other os then
Or i wait on dietpi 6.27/6.28 ? Maby there will be a solution
Fresh install on RPI4, dietpi-update, and reboot direct after moving RootFS
First nothing at all, but cause i was not nearby device i left it alone.
After 1 hour i logged in again (don’t ask me why) and low and behold: i could log in with putty again!
So maybe you can give it another try ?
/etc/fstab and /boot/cmdline.txt seem to have the right PARTUUID
I can see with dietpi-drive manager that mount target is ‘/’ and mount source is on /dev/sda1
Also i can see that it says:
dev/mmcblk0p2 | ext4 | Not mounted
I dont know if that is like it should be…but will wait to reboot again after i got home
DutchFlash
Thanks for sharing. For now I can’t see a difference between the methods the script uses and dietpi-drive_manager uses. Will run some tests and check more closely .
EDIT: I have an idea!
Since you formated the one partition only instead of the whole drive, which partition table did it have? I am not sure if GPT partition table is supported by the RPi4 bootloader. With RPi3 it seems to be possible though: https://www.raspberrypi.org/forums/viewtopic.php?t=205418
The usb-boot script clears and recreates the partition table for the whole drive with fdisk, hence it will be MBR by default. When using dietpi-drive_manager to be failsafe, select Format Mode: Drive and Partition Type: MBR. Probably it was not required on previous RPi models but RPi4 came with a vast bootloader rewrite (now stored on an internal EEPROM), hence even that it is newer, possibly it still lacks some features. Futher investigation required if a fresh MBR partition table fails as well.
DutchFlash
I have an idea, after reviewing usb-boot and our script/method!
Since you formated the one partition only instead of the whole drive, which partition table did it have? I am not sure if GPT partition table is supported by the RPi4 bootloader. With RPi3 it seems to be [EDIT: NOT!] possible: https://www.raspberrypi.org/forums/viewtopic.php?t=205418
The usb-boot script clears and recreates the partition table for the whole drive with fdisk, hence it will be MBR by default. When using dietpi-drive_manager to be failsafe, select Format Mode: Drive and Partition Type: MBR. The RPi4 comes with a vast bootloader rewrite (now stored on an internal EEPROM), hence even that it is newer, but possibly it still lacks this features. Futher investigation required if a fresh MBR partition table fails as well.
Okay it seems to need to add this info to our script + set default entries accordingly:
.
