2

I am booting a RPI3 B Plus via USB from an mSATA drive (using the Desktop Pi enclosure). This works fine. My kernel command-line uses the partition UUID to identify the root partition:

root=PARTUUID=xxx

When, at boot time, an additional USB stick is present (which is DOS-formatted and entirely empty)

  • if the second device is plugged in right below the boot disk (boot disk top-right USB port, if looked at from the outside, and second disk bottom-right), the device boots.
  • if the second device is plugged in on the left side (either top or bottom slot), the device does not boot. In this case, the green LED never even flashes once.

Why is that? Is it possible that the left USB ports are being consulted by the boot loader before the right ones, and the bootloader doesn't bother to look further if it already found a device even if it is not bootable? Because if I copy /boot/* to the root of the second USB device, it does boot again, even if plugged in on the left side.

If so, I'd consider that a bug. Or what am I getting wrong / should be doing differently?

Improve this question
11
  • run sudo blkid - does /dev/sda1 have the same PARTUUID as /dev/sda2 for example? If so, perhaps the boot process sees the PARTUUID "prefix" is correct on the first disk it sees (the USB disk) and figures the it has the right disk (makes sense to me) - do /dev/sda and /dev/sdb (i.e. the whole disk) have the same PTUUID? (run sudo blkid /dev/sda /dev/sdb to see this if it's not shown in the above command)
    – Jaromanda X
    Jul 30, 2018 at 0:21
  • Good thought, but no: all uuids are different.
    – Johannes Ernst
    Jul 30, 2018 at 0:25
  • what about PARTUUID's?
    – Jaromanda X
    Jul 30, 2018 at 0:31
  • I meant all kinds of UUIDs, including PARTUUIDs.
    – Johannes Ernst
    Jul 30, 2018 at 3:18
  • fair enough - does seem like a bug, doesn't it - or it could be designed that way - the first stage bootloader (which is stored in ROM on the SoC) is limited in size, perhaps it only tried to boot from the first USB drive it finds?
    – Jaromanda X
    Jul 30, 2018 at 3:33

1 Answer 1

Reset to default
1

There is nothing special about the FAT partition which contains the boot files, and the-loader is very basic. At that stage PARTUUID is irrelevant. AFAIK the first enumerated device is used.

You could use a SD Card with just the boot partition.

Improve this answer
6
  • Hmm, but why would the bootloader stop at the first encountered device that doesn't even have any files on it?
    – Johannes Ernst
    Jul 30, 2018 at 3:19
  • try even an SD card with just bootcode.bin on a FAT partition - see if that makes any difference
    – Jaromanda X
    Jul 30, 2018 at 3:46
  • @JohannesErnst Seems the bootloader has a fix build in sequence to look for an attached device and tries to boot from it. That's it. It will not scan all possible boot devices.
    – Ingo
    Jul 30, 2018 at 17:29
  • @ingo Do you have a pointer to the source code in question? Your reading of the code seems to conflict with JaromadaX's comment above.
    – Johannes Ernst
    Jul 30, 2018 at 22:38
  • @JohannesErnst I don't know much about the boot code but the code in question is embedded in the boot ROM and afaik not open source. Look at Boot flow how it works. There is no conflict: @Jaromanda X talks about a slot containing boot code and btw. the SD Card is always the first slot tested. If it contains a SD Card without bootcode.bin the RasPi will stuck. I'm talking about slots not containing boot code.
    – Ingo
    Jul 30, 2018 at 23:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.