2

I have a raspi 3 with two attached external usb storages. A smaller ssd with the system (fat32/ext4) and a large hd (xfs) with data. My cmdline.txt tells the system from which UUID to boot from and it works flawlessly - until I plug in the data disk, which somehow always takes precedence over the ssd. There is no system on it, no boot directory or partiton, nor did I detect any boot flags in fdisk. Just a single partiton with some directories in it. Of course the system cannot boot from it, so I get a black screen and nothing happens.

What could be the cause of this?

Selected partition 1
         Device: /dev/sdb1
          Start: 2048
            End: 11721043967
        Sectors: 11721041920
           Size: 5.5T
           Type: Linux filesystem
      Type-UUID: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
           UUID: F75C0B98-31E6-43C3-800B-235CD25AEAEF
           Name: media

sudo cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=2c192fba-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
pi@raspberrypi

label: gpt
label-id: 4107ECD0-9D0D-4660-A66B-7B2138C2E0FF
device: /dev/sdb
unit: sectors
first-lba: 34
last-lba: 11721045133

/dev/sdb1 : start=        2048, size= 11721041920, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=F75C0B98-31E6-43C3-800B-235CD25AEAEF, name="media"

sudo blkid
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="F661-303B" TYPE="vfat" PARTUUID="2c192fba-01"
/dev/sda2: LABEL="rootfs" UUID="8d008fde-f12a-47f7-8519-197ea707d3d4" TYPE="ext4" PARTUUID="2c192fba-02"
/dev/sdb1: LABEL="media" UUID="fa96f617-b3a4-46bc-ac52-029829f37616" TYPE="xfs" PARTLABEL="media" PARTUUID="f75c0b98-31e6-43c3-800b-235cd25aeaef"
Improve this question
7
  • In cmdlin you have PARTUUID=2c192fba-02 - is that your OS partition or a hang over? Linux ignores boot flags AFAIK. Check 'data' drive does not have a bootcode.bin on it. Full sequence is documented raspberrypi.org/documentation/hardware/raspberrypi/bootmodes - it may help a bit.
    – user115418
    Commented Nov 30, 2020 at 1:08
  • @Andyroo, I added the output from blkid to the post. It is the os partition and there is no boot image whatsoever on the data disk.
    – Jan
    Commented Nov 30, 2020 at 11:19
  • 2
    @Andyroo Even if there were a bootcode.bin, the Pi wouldn't magically boot from XFS.
    – Dmitry Grigoryev
    Commented Nov 30, 2020 at 16:13
  • "Of course the system cannot boot from it, so I get a black screen and nothing happens." If that's all that happens, that "it" (the kernel) is trying to boot from the other disk sounds more like hypothesis than a known. The kernel provides a lot of output before the point where it tries to mount the root filesystem -- which raises another point: If the kernel is booting at all, then it is booting from the correct drive because that's the only place where it could be. What all this sounds more like is that the kernel is not being booted at all...
    – goldilocks ♦
    Commented Nov 30, 2020 at 19:21
  • 1
    ...In which case worrying about device names and cmdline.txt is a waste of time. Sorry I don't have any suggestions for you beyond that.
    – goldilocks ♦
    Commented Nov 30, 2020 at 19:22

1 Answer 1

Reset to default
1

Disregard what I have written before. @goldilocks is right: your Pi apparently never gets past the bootcode, and you have no configuration options for that. Perhaps plugging the drives in different USB sockets would help the bootcode to find the right one. Another idea worth a try is to plug the data SDD through a hub, so that there's only one drive (the system SSD) connected directly to the USB host.

Other than that, there's nothing you can do short of reporting a bug to the Pi Foundation and hope they'll fix the bootcode eventually. If the issue prevents the Pi from finding your bootcode.bin in the first place, there will be no fix.

--- old answer ---

Try using a conventional names, i.e. /dev/sda2, and if that doesn't work, try /dev/sdb2. Note that kernel parameters have nothing to do with actual device names in /dev, the similarity in naming is purely conventional, and it's possible for a device named sda by the bootloader to become sdb later on.

Another option is to find out the minor/major numbers with ls -l /dev/sda2, and use those numbers in kernel command line as in root=/dev/0x1122 (assuming major=17 (0x11) and minor=34 (0x22))

Improve this answer
2
  • 2
    Based on the OP's description, the kernel isn't even being loaded.
    – goldilocks ♦
    Commented Nov 30, 2020 at 19:22
  • 1
    @Dmitry Unfortunately, different plugging arrangements don't change the outcome. I did not try using an adapter, because I really want to avoid any more cables - there are way to many there already (and I doubt it will make any difference).
    – Jan
    Commented Dec 16, 2020 at 13:38

Your Answer

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

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