SSD boot problem

[PIOTA89]

Creating a bug report/issue

Required Information

Please see attached screenhot for further details

• Power supply used | (EG: 5V 1A RAVpower)

Additional Information (if applicable)

• Dietpi 64 bit for raspberry pi with installed ultra leight weight desktop and nginx server.
• Was the software title installed freshly or updated/migrated?
  First the software was installed and it was working very well. After a first reboot of the device, the error occurs.
  After approxminately 6 minutes, the login screen is there and i can login and start the ultra light weight desktop with the
  startx command.
• Can this issue be replicated on a fresh installation of DietPi?
  No, the error occurs after a reboot of dietpi 64 bit.

• Bug report ID | echo $G_HW_UUID

Steps to reproduce

1. Install dietpi 64 bit for raspberry pi on a 128 GB SSD, with the LXDE desktop. I used a raspberry 4 with 4 GB RAM with external 128 GB SSD plugged in usb 3.0 port.
2. After the installation, install nginx and reboot the device.
3. The error occurs. But after 5-6 minutes, the login screen showed up and i was able to login.

Expected behaviour

• Faster reboot and showing login screen without error message.

Actual behaviour

• Please see above description and have a look at the attached screenhots.

[Joulinar]

Hi,

many thanks for your report. Looks like your system has issues to boot from SSD as you are running in some time out, resulting in the extrem long boot time you are facing.

Some question on this

1. are you facing the same behaviour with the stable 32bit image?
2. can you check system behaviour if your SSD is plugged into USB2 port
3. did you flashed the image directly to the SSD?
4. can you provide dmesg -l emerg,alert,crit,err once login (pls try to use SSH connection for this, to be able to copy the output instead of doing screen prints)
5. did you use external power on the SSD or is it powered by the RPi only?

[PIOTA89]

Hello,
1: I didn't try a 32 bit image.
2: Very interesting, i tried with usb2 port, and it works perfectly without errors, or long boot time.
3: I flashed the image directly with balenaetcher to the ssd.
4: please see attached screenshot.
5: The ssd is without external power supply.

[MichaIng]

What is snapd? Interesting when searching it, the first results are about users reporting that it fails and hangs boot 😄:

• https://forum.snapcraft.io/t/snapd-service-delays-startup-in-ubuntu-18-04-with-4-15-0-24/6205/4
• https://askubuntu.com/questions/1048737/failed-to-start-snappy-daemon

So it's this Ubuntu-originated Docker-like snap container daemon, right? However the cause of your issues is most likely:

5: The ssd is without external power supply.

The USB ports are not designed to power external 2,5" HDDs. They get undervolted, causing various issues up to data loss. So you either need to use a USB stick only, or attach the SSD via docking station with dedicated power supply.

That is true for all SBCs btw, for RPi you find it documented here: https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md
It's a max of 1.2A (=6W) shared across all USB ports. E.g. my 2,5" SSD takes only 4-5W but considering peaks, especially on startup, and fluctuations in voltage, and then you might plug something else into another USB port, you see that it is veeery close, definitely not something a production system can rely on.

I regularly see other hardware parts of SBCs producing failures as well when the USB ports leach too much power, so let's continue investigating the issue with snapd and time sync when you have sorted the USB power.

[Joulinar]

I guess this could be something to try as well? #3754 (comment)

[PIOTA89]

I don't really think that the boot problem is related to power supply. I plugged in power supply for my ssd and it only doesn't work on usb 3.0. I tested again on usb port 2.0 also with power supply, and it works quiet perfect.
Please see the attached screenshot for the usb 3.0 ssd boot problem with power supply.

[MichaIng]

Ah okay, didn't think about the UAS issue, worth to give it a try. About power: If it works stable with the UAS blacklist quirk, we found the issue, but I highly recommend to keep the drive attached with external power supply. There are USB devices where under-voltage is not a drama, but when it's the root file system itself, I'd not risk that 😉.

[PIOTA89]

I hope you can fix the issue - would appreciate that. Thanks for the info with power supply, you are right. I use my ssd now only with attached power supply. 👌

[MichaIng]

I hope you can fix the issue - would appreciate that.

This is nothing that we can fix. The official RPi kernel has UAS enabled by default for USB-attached drives on RPi 4, but not all drives support it, or at least certain firmware versions do not. UAS then needs to be disabled for the particular drives. The link by Joulinar basically explains how: #3754 (comment)
First thing is to find out the ID if the drive:

lsmod

[PIOTA89]

I understand now. Thanks. I tested again with a newer ssd on usb 3.0 port and it works perfect. I think you can close the issue.
;)

[Joulinar]

ok I'm going to close this. Feel free to reopen if needed.

[MichaIng]

Just to make it clear: It is no big deal to fix support for the other SSD, not using UAS has no significant downsides, and it is default on all RPi models prior to RPi 4. UAS has been added to the kernel not for UAS support itself but because the module ships a list of other USB quirks/info required for a certain drive type (have to digging to find the issue on RPi GitHub). On prior RPi models UAS is not used at all (hence no such issues) since they use a different USB driver (dwc-otg) that does not support UAS while RPi 4 by default loads the dwc2 driver, which supports scatter-gather, another method required for UAS. This can be even chosen via config.txt dtoverlay=dwc2/dtoverlay=dwc-otg.

Ah and now I remember the other obvious solution, even simpler and more consequent than adding the USB quirk:

echo -e 'blacklist uas\nblacklist sg' > /etc/modprobe.d/disable_uas.conf

This disables the UAS kernel module and scatter-gather, which is then obsolete.

[billouetaudrey]

Hi, for me, on USB3, Dietpi don't boot
On USB2 no issue

I have this issue :

I already try to do this without know what I do, lmao

echo -e 'blacklist uas\nblacklist sg' > /etc/modprobe.d/disable_uas.conf

[MichaIng]

Hmm, if it works on one port but not on the other, it's not UAS causing the issue here. It looks like the the drive is not detected at all as it hangs at firmware stage. Does the USB drive have a dedicated power supply or is it a USB stick only?

[billouetaudrey]

Yes, it's work on USB 2 only
On USB 3, it's not detect ( when I boot on SDcard )
It's a USB Stick ;)

[MichaIng]

Is anything else detected on that USB port? And could you paste the following when booted from SD card and having the USB stick attached?

fdisk -l
lsblk
lsusb

[billouetaudrey]

• SSD

Boot to SSD.txt

• SDCARD + SSD on USB2

USB2.txt

• SDCARD + SSD on USB3

USB3.txt

[MichaIng]

Okay, with this particular chip, issues seem to be known:

Bus 001 Device 011: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

• USB3.0 to SATA adapter causes problems raspberrypi/linux#3070

You said you ran echo -e 'blacklist uas\nblacklist sg' > /etc/modprobe.d/disable_uas.conf just to assure, can you paste back the file content: cat /etc/modprobe.d/disable_uas.conf

And since you have a lot of USB drives attached, actually it's better to disable UAS only for this single device:

• Add usb-storage.quirks=152d:0578:u to /boot/cmdline.txt (space-separated to the other entries, of course).
• Would be interesting to know, if the modprobe option above is correct but does not solve the issue, but the quirk does.
• However, finally remove the modprobe blacklist: rm /etc/modprobe.d/disable_uas.conf

[billouetaudrey]

dietpi@raspberrypi:~$ cat /etc/modprobe.d/disable_uas.conf
blacklist uas
blacklist sg

[MichaIng]

Btw, as a general background for related issues: https://www.raspberrypi.org/forums/viewtopic.php?t=245931

Your kernel is up-to-date, isn't it? uname -r
And EEPROM USB firmware? rpi-eeprom-update -a

[billouetaudrey]

dietpi@raspberrypi:~$ uname -r
5.4.72-v7l+

dietpi@raspberrypi:~$ sudo rpi-eeprom-update -a
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: jeudi 3 septembre 2020, 12:11:43 (UTC+0000) (1599135103)
LATEST: jeudi 3 septembre 2020, 12:11:43 (UTC+0000) (1599135103)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000138a1

[billouetaudrey]

Let me try this https://www.raspberrypi.org/forums/viewtopic.php?t=245931 ;)

Thanks again !

[MichaIng]

Okay, that is all fine, so let's see if the USB quirk on cmdline works, see last part of my post above with the entry forget: #3858 (comment)

Another idea, did you try to detach all other USB devices to rule out power-related issues?

[billouetaudrey]

When I do dmesg with SSD on USB 3 :

[ 168.701250] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 173.021253] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 177.571233] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 181.911225] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 181.911632] usb usb2-port1: attempt power cycle
[ 186.591258] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 190.931225] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 190.931629] usb usb2-port1: unable to enumerate USB device

[billouetaudrey]

Another idea, did you try to detach all other USB devices to rule out power-related issues?

Yes I do ;)

[billouetaudrey]

dietpi@raspberrypi:~$ sudo cat /boot/cmdline.txt
usb-storage.quirks=152d:0578:u console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet net.ifnames=0

;)

Btw it's ok, maybe it's my USB 3.0 case ;)

[MichaIng]

Jep, so if with this USB quirk and the affected drive attached as only USB device it still does not work, I'm also out of ideas.

And indeed those kernel errors look like the issue is on an earlier level than UAS. So switching cable or case/docking station could be tested.

[billouetaudrey]

Jep, so if with this USB quirk and the affected drive attached as only USB device it still does not work, I'm also out of ideas.

And indeed those kernel errors look like the issue is on an earlier level than UAS. So switching cable or case/docking station could be tested.

Ok thanks for ur help ;)