Help with booting problem Rpi4 and Ssd

[DutchFlash]

Where can i download a older version of dietpi ?

Dietpi versie 6.26.3 give me errors.
Clean install op rpi4.
With the older versions, i had never problems before.

My problem with dietpi 6.26.3 I cant use a Ssd or Hd to boot dietpi.
RootFS on Sd card oke, but RootFS to ssd or hd then get error when booting up.



Give root password for maintenance
(or press Control-D to continue): _

When press control D, I get:

Give root password for maintenance
(or press Control-D to continue): Sulogin: cannot read /dev/tty1: Operation not permitted

Give root password for maintenance
(or press Control-D to continue): _

Please help me with this problem

p.s.
sorry for my english(i'am dutch)

DutchFlash

[DutchFlash]

Nobody can help me ?

[MichaIng]

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.

How did you transfer the roof partition?

[DutchFlash]

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.

How did you transfer the roof partition?

Roof partition ?

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.

p.s.

I leave the sd card in de rpi.

[MichaIng]

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/comm ... 798f839ad8
Changelog: https://github.com/MichaIng/DietPi/comm ... 3db8822d6e

[DutchFlash]

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/comm ... 798f839ad8
Changelog: https://github.com/MichaIng/DietPi/comm ... 3db8822d6e

No i press restarting after transferFS

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

p.s.
Tnx for the help...

[ZeroZorro]

hi, i experienced same problem.

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]

hi, i experienced same problem.

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

Hi,

I will give it a try, let you no how it's go.

No go,Wait 1 hour.
Cant log in with putty

I pull my hair out of my head

[DutchFlash]

Hi all,

I succeeded
Found something on another site.

https://www.raspberrypi.org/forums/view ... oot+to+usb

And it's works. Dont ask me how

You simply place the script in your home directory ('pi') and run it manually:

sudo ./usb-boot

And now RootFS is runnig on usb(ssd)

We happy again, raspberry pi 4 is up and running. Fs on usb(Ssd)

[MichaIng]

@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/view ... p?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.