[Bug 1891817] Re: Raspberry Pi: u-boot hangs when (non-boot-related) USB disks are attached during boot

[Markus Dobel]

Thanks for the update. This hint (about dropping U-Boot) is actually
something I found elsewhere as well, and I can confirm that it works.

And if that's the way how the problem goes away for Ubuntu installs, I
would not even call it "won't fix". I don't need U-Boot, I just need a
system that boots reliably :)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to u-boot in Ubuntu.
https://bugs.launchpad.net/bugs/1891817

Title:
  Raspberry Pi: u-boot hangs when (non-boot-related) USB disks are
  attached during boot

Status in u-boot package in Ubuntu:
  Won't Fix

Bug description:
  I set up Ubuntu 20.04.1 (64bit) on a Raspberry PI 3B (not 3+).
  While having the complete OS on a SD card, I have two hard disks attached via USB. These disks are not bootable, and not required for booting, but somehow u-boot struggles to ignore them.

  On first boot (powering disks and pi simultaneously), u-boot fails to
  detect the disks in the first place, and boots straight from SD-card.
  When re-booting, and the disks are still powered, u-boot detects the
  disks and hangs directly after printing the following:

  ```
  Bus usb at 7e980000: scanning bus usb at 7e980000 for devices... 5 USB Device(s) found
     scanning usb for storage devices... 2 Storage Device(s) found
  ```

  Sometimes it continues to boot from SD card after waiting for a long
  time (multiple minutes), in these cases it prints (among other
  messages that pass too fast to record)

  ```
  *** Bad device size - usb 0 ***
  ```

  before continuing to boot from SD. But often it does not, but hangs
  forever after device detection. The only way to revive the system, is
  to switch off power from both PI and disks and switch it back on.
  While it "hangs", the activity LED of disk 1 flashes rapidly.

  I can also reproduce this on first boot already by adding e.g.

  ```
    boot_delay=10
  ```

  to userfg.txt. This gives the USB disks enough time to initialize, so
  u-boot detects them on first boot as well (and then fails to boot).

  Once booted, the kernel has no issues identifying and using the disks
  -- when the system is up, it runs stable, even under load, so I would
  rule out defective hardware or bad power.

  ### System info

  - Raspberry PI 3 (not 3+)
  - All updates applied using `apt-get full-upgrade`, otherwise fresh install
  - 2 WD RED disks in a USB dock (this one: https://www.amazon.de/gp/product/B075TZJMWW)
  - Raspberry Pi powered using the front 2A USB PD port of the dock, so I can switch them on together
  - The 2 disks are concatenated using LVM, having one VG with encrypted volumes (for data and swap) inside, so I would not expect u-boot to find anything useful on them.

  Output from (possibly) relevant commands:

  ```
  $ lsb_release -rd
  Description: Ubuntu 20.04.1 LTS
  Release: 20.04
  ```

  ```
  $ lsusb -tv
  /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
      ID 1d6b:0002 Linux Foundation 2.0 root hub
      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
          ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) SMC9514 Hub
          |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
              ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
          |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
              ID 05e3:0610 Genesys Logic, Inc. 4-port hub
              |__ Port 1: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
                  ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
  ```

  ```
  $ lsblk # without snap loop devices
  sda                8:0    0  3.7T  0 disk
  ├─backup-backup  253:0    0  8.2T  0 lvm
  │ └─backup-crypt 253:3    0  8.2T  0 crypt /mnt/backup
  └─backup-swap    253:1    0    2G  0 lvm
    └─swap-crypt   253:2    0    2G  0 crypt [SWAP]
  sdb                8:16   0  4.6T  0 disk
  ├─backup-backup  253:0    0  8.2T  0 lvm
  │ └─backup-crypt 253:3    0  8.2T  0 crypt /mnt/backup
  └─backup-swap    253:1    0    2G  0 lvm
    └─swap-crypt   253:2    0    2G  0 crypt [SWAP]
  mmcblk0          179:0    0  7.4G  0 disk
  ├─mmcblk0p1      179:1    0  256M  0 part  /boot/firmware
  └─mmcblk0p2      179:2    0  7.2G  0 part  /

  ```

  ### How to reproduce

  Unclear. Since I do not want to delete the data on the disks, and do
  not have other "free" disks at hand, I have little opportunity to
  experiment. It might be the USB to SATA controller chipset, LVM or the
  LUKS encrypted LVs that make u-boot fail, or something else.

  ### Expected behaviour

  I expect u-boot to fail fast on unpartitioned/encrypted/otherwise
  unreadable USB storage, and try the other boot sources immediately
  (and reliably).

  Guidance on how to make u-boot ignore any USB storage (as a
  workaround) would also be helpful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/1891817/+subscriptions