USB boot fails if the GPT contains no basic data or EFI partitions #130
Comments
|
Excellent, first NET_CONSOLE report. I think this is the gold standard in bug reports. If you can dump the partition table via gdisk that would be useful. A slightly better XHCI_DEBUG would be 0x1f to show everything except the TRBs but 0x7F for everything would also be fine. It looks as though it didn't find what it thought was a usable partition and carried on looking for the next disk. A HDMI diagnostic would probably help here GPT 448904efc4fa451089061e1f33446f5f 000000001 074706daf num-partitions 128 entry-size 128 |
|
I see. So the boot failure is due to my unusual partitioning, not the bridge chip. That's actually a relief, since it is meant to be one of the better ones. The disks are part of a mirrored OpenZFS pool, which is probably not a common setup on the Pi. They were created by telling ZFS to create a mirrored pool using the entire disks, leaving it up to the |
ghost
changed the title
|
The bootloader and start.elf only know how to read FAT16/FAT32. If you can create a small FAT partition within the GPT to store those files then it should boot ok, unless the boot partition is on a different drive? |
The boot and root partitions are on a different drive, which I left disconnected when I did that trace, as the problem occurs whether the boot&root drive is attached or not. The problem is the bootloader getting stuck and not progressing past examining the drive formatted using the I've confirmed the same behaviour with a drive from another OpenZFS pool in a different model of enclosure directly attached to the Pi 4. |
|
@andrum99 Not directly-related to this bug report, but does that setup boot okay from USB MSD on a Pi3 B+? |
|
Another disk from an OpenZFS pool in a different model of enclosure with a different bridge: pi@pi4b2sd:~ $ sudo blkid pi@pi4b2sd:~ $ sudo gdisk -l /dev/sda Partition table scan: Found valid GPT with protective MBR; using GPT. Number Start (sector) End (sector) Size Code Name XHCI_DEBUG=0x1f netconsole log: OpenZFS-whole-disk-pool.pcapng.gz Screenshot:
@timg236 - when you say:
How do I get the Pi to do that? |
I have no idea - I stopped using USB MSD boot on the Pi 3 due to finding it easier to use SD card boot, and also SD boot and root seemed to be faster than with the hard disks I was using. Do you want me to try that? The only Pi 3B+ I have is running my DNS and DHCP server (Pi-hole) so it's a bit annoying to fiddle with, but I can if required. (I don't have SSDs to connect to the Pi - just some old 2.5" laptop hard disks, and the pair of 3.5" 1TB drives I previously used as direct attached backup drives on my laptop (which now make up an OpenZFS pool on a Pi 4B 4GB running Ubuntu). I've moved the primary backup of my laptop to the cloud, as it is easier to do off-site backups, and I now have a 10Mbps upstream broadband connection, which makes it vaguely viable). |
You can't, but once I've figured out what's going on an indicator to say no valid partitions on this disk would probably be a good idea. I think the issue is that there's a problem exiting from the scanning GPT partitions state if there are no valid EFI partitions. Please could you confirm that if you just connect the boot drive then finds and loads start.elf? |
|
|
Ooops, pressed the wrong button! GPT has never been supported in start.elf until now so not too worried about Pi3 GPT. I tested a USB pen-drive with MBR primary partition will boot on both a Pi3B+ and a Pi4 |
Ah, I see. I've very little clue about GPT / EFI, beyond it being the successor to MBR (and Sun's VTOC).
Yes - just tried it and it boots fine with just the boot drive attached (with or without USB mouse and keyboard). (The working boot drive in this case happens to be in the same model of enclosure with the same bridge chip - 174c:1153 = ASM1153E. As you identified, the bridge chip seems to be irrelevant - it's the partitioning on the disk that seems to be the problem). |
I was merely curious. Please don't bother unless Tim asks you to :) |
The working USB MSD boot (and root) disk is MBR only - it's created by the SD Card Copier in Raspbian, based on a working SD card. (Verified with gdisk). |
|
I think I see the issue (from code inspection). This should fix it, or possibly complain then explode but it will indicate if my hypothesis is vaguely correct I don't have a GPT setup and need to head off now, thanks for the detailed information |
That bootloader firmware has fixed it. Unmodified (i.e. without changing the embedded config) I get:
then after a short delay:
Which appears to actually be 10000 milliseconds. The bootloader then correctly continues to attempt booting as intended (in this case 0xf41). I can hotplug an SD card or the bootable hard disk and it will boot from either. Powering up or rebooting with the problem hard disk, and a bootable hard disk and/or bootable SD card also works correctly. Many thanks 😁 |
|
To check this wasn't due to a problem with the particular setup I had on my NAS when I created these OpenZFS pools, I checked the behaviour of the 2020-05-15 bootloader (i.e. USB MSD beta) with a whole disk OpenZFS pool on a USB stick which was created in Ubuntu 20.04 amd64 on the Pi 4. (My other pools were created on Raspbian with the 64-bit Raspbian kernel, building ZFS as an out of tree module and some other tweaking per https://github.com/andrum99/zfs-for-pi). (openzfs/zfs#489 suggested that the particular setup I had when I created the pools, which I don't have running now, may have been the cause of the problem). The behaviour is identical with the pool created on Ubuntu 20.04 amd64 on Pi 4 - the 2020-05-15 bootloader gets stuck on that LUN. With the fixed bootloader from the above message (2020-05-21), the bootloader works as expected, as with the other pools. |
timg236
changed the title
* Resolve: USB boot fails if the GPT contains no basic data or EFI partitions #130 * Resolve: Fix default BOOT_ORDER in mass storage beta #129 * Resolve: Add support for booting from a "superfloppy" disk #120 * Resolve: USB MSD timeout message - incorrect units #131 * Resolve: Recognize efi partition (0xef) as a valid boot #126 * The HDMI diagnostics screen now displays the most significant bytes of the SHA-256 of the config.txt file.
|
This should be fixed by e87bc4d The binaries are available in this release which can be flashed using the Raspberry Pi Imager |
Confirmed - LGTM. |
Describe the bug
With a Startech 3.5inch HDD enclosure (S3510BMU33) attached to a Pi 4, I cannot get it to boot from USB MSD. If one or more of these enclosures is attached at boot time, boot appears to stop when the bootloader tries to talk to this device. I have two of these enclosures, each with different brand of hard disk in them - both show the same problem.
To Reproduce
Steps to reproduce the behavior:
Configure Pi 4 for USB MSD boot per the instructions at https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=274595#p1663644, leaving the SD card slot empty, and BOOT_ORDER=0xf41.
Attach at least one Startech S3510BMU33 hard disk enclosure to the Pi 4 and power it up using its own PSU.
Attach HDMI screen to the Pi 4 so you can see what is happening.
Apply power to Pi 4.
Observe bootloader output on HDMI screen.
Expected behaviour
Pi 4 should try each SD card boot, fail, try eachUSB device in turn looking for a bootable device, fail to find a bootable USB device and continue in a loop from SD card boot again.
Screenshots
Pi 4 gets stuck at the point shown in the screenshot, although it is still sending out trace packets over the network so it does appear to still be running OK, not hung.
Bootloader version and configuration
Bootloader configuration:
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
BOOT_ORDER=0xf41
SD_BOOT_MAX_RETRIES=1
USB_MSD_BOOT_MAX_RETRIES=1
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
XHCI_DEBUG=0x23
NETCONSOLE=6665@169.254.1.1/eth0,6666@/
Bootloader version:
May 15 2020 11:05:52
version 23a9f59b85f5a81bb2eec455e064ef9905216322 (release)
timestamp 1589537152
USB boot (please complete the following information):
sudo lsusb -vvv output:
lsusb-vvv.txt.gz
Netconsole boot trace:
Startech-S3510BMU33-hdd-enclosure-w-hdd.pcapng.gz
Additional context
Problem occurs whether there is a usable USB MSD boot device attached or not (i.e. one that has been prepared and verified to boot the Pi 4 successfully). Problem does not occur with SD card boot, since the boot order is set to do SD card boot first. I would expect it to fail if it was the other way around, since the whole boot process stops, although the trace shows that the bootloader is still running and sending trace packets out over the network.
The network trace is done with the enclosure connected to a USB 3 hub. I have tried it with a USB 2.0 hub and it shows the same problem.
I have attempted to activate XHCI_DEBUG bits 5, 1 and 0, using the setting 0x23. I may have got that wrong.
The text was updated successfully, but these errors were encountered: