DietPi-Drive_Manager | Add UAS blacklist control

[davidjmorin]

Move to file system does not work. Pi does not boot at all.

[davidjmorin]

This is a fresh install of dietpi on rp4. No installed programs. I then went to dietpi-drive_manager to move FS to SSD. Formatted correctly and upon reboot this is all I see.

[Joulinar]

Hi,

Many thanks for your message. The 2nd screen message is normal and can be ignored. Pls can you let us know which file system you moved to SSD?

[MichaIng]

For better debugging please enable more boot logs by removing the quite flag from cmdline.txt, if you have access to the SD card boot partition from external system.

And although we want to investigate and in case fix the issue, generally on RPi3+ and up I recommend to flash the image completely and directly to the USB drive, so you have full USB boot and do not need to copy data from the running system.

---

The rpi-eeprom-update btw is an unrelated known issue and fix is on the way: raspberrypi/rpi-eeprom#216
Simply do apt install bsdmainutils once the boot issue itself has been fixed.

[davidjmorin]

Ok so I have it booted now. Process I used was to first boot rpi4 with official raspberry image. Do all the updates and install new eeprom. Removed SD card and the imaged ssd usb with diet pi. Plugged into USB3 and it did not boot at all for a while. Then booted in emergency mode. I moved usb to usb2 and it booted up fine. Seems USB3 does not work. This is a 4gb version.

I also tried this on multiple pis with different ports with same result.

[mrbluecoat]

So is booting dietpi from a USB 3.1 drive not supported? I was thinking of doing something like this myself.

[davidjmorin]

So is booting dietpi from a USB 3.1 drive not supported? I was thinking of doing something like this myself.

No it is supported. Just follow those steps unless you have already setup rasbian to do it. After I did these steps it works flawlessly. Except soft reboots do not work.

1: Flash rasbian
2: boot pi with image and do all the latest updates. Update eeprom
3: flash dietpi to USB drive
4: Plug in drive to a USB2 port. Let it load. This can take a while. Just wait.
5: Update cmdline.txt with quirks. I used this usb-storage.quirks=0080:a001:u
Hint: 152d:1651, YOu can get this by running lsusb and getting the USB drives product ID and ID

Bus 002 Device 002: ID 0080:a001
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 152d:1561 Seagate RSS LLC
Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

6: Now shutdown and insert your drive into USB3.
7: Should be all set.

root@DietPi:~# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   4.6T  0 disk
└─sda1   8:1    0   4.6T  0 part /media/USB2_5TB
sdb      8:16   0 232.9G  0 disk
├─sdb1   8:17   0   256M  0 part /boot
└─sdb2   8:18   0 232.6G  0 part /

[MichaIng]

Again a Seagate drive that requires a UAS blacklisting, I think this can be added statically to the RPi kernel, else er can apply this via modprobe config.
I remember a similar case for x86_64, probably we can simply apply it for all devices. Let me re-open the issue to not forget about applying this.

[MichaIng]

Issue reported at RPi kernel repo: raspberrypi/linux#3855
I could not reliably find out how/where to add this to the source code directly, let's see if there is a more efficient way of sending a PR directly in the future.

[MichaIng]

Okay RPi devs do not maintain or care UAS blacklists. Also a good argument is that firmware updates (respectively controllers with same ID but shipped with newer firmware) might provide UAS support for drives, then the blacklist is rendered obsolete and the quirk decreases performance, hence it is practically not possible to have a blacklist that is always right.

What we might want to do instead:

• Add option to disable UAS, if it is a kernel module (on RPi it is!).
• Add an option to add a UAS blacklist quirk for an attached drive if we have a reliable way to alter the cmdline (RPi, x86, Odroids at least).