hey @Bob_Prendergast or @cshipman - what drives are you using successfully (and USB2 or 3)? Looking for consensus here...
USB3 - WD - My Passport 2TB External USB 3.0
Iām using USB 3, 1TB drive. Everything is running great.
interesting. Same brand as @tmm1 and i are trying, but the smaller, self-powered model.
WDBYVG0020B model?
This one from Best Buy:
WD - My Passport 2TB External USB 3.0 Portable Hard Drive with Hardware Encryption (Latest Model) - Black
Model: WDBYVG0020BBK-WESN
SKU: 6356887
I am running into the same issue. Boots then black screen. Using a Seagate 6TB external drive. @tmm1 - seems to be what you are seeing with your 12TB drive.
I was able to get the screen working and can see the errors. The OS is not booting because of some sort of issue in the u-boot bootloader. The bootloader is capable of network boot, which is why ping is working.
1 Like
Hmmmm - that GUID partition table makes me think of my earlier statement. I'm wondering if a lower-level format / redo as an MBR prior to the image application might change this.
Worth a shot, but I am not convinced.
Might be a bug related to the size of the drive. Its interesting that Capacity was reported as not available for my 12TB.
Found a reference of a u-boot issue on any drives larger than 2TB: https://forum.doozan.com/read.php?3,93799
Or perhaps @hancox is right after all, because I also see this referenced:
If you have problem with u-boot recognizing the 3TB or greater HDD, look at your partition table. It is best to wipe it first.
Plugged my newly flashed drive into a linux box. It complains about the alternative GPT (as expected), but nothing about the primary one:
[1204544.029514] scsi 3:0:0:0: Direct-Access WD Elements 25A3 1030 PQ: 0 ANSI: 6
[1204544.031107] sd 3:0:0:0: [sdb] Spinning up disk...
[1204545.042215] .................ready
[1204561.255808] sd 3:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
[1204561.255937] sd 3:0:0:0: [sdb] 23437705216 512-byte logical blocks: (12.0 TB/10.9 TiB)
[1204561.255939] sd 3:0:0:0: [sdb] 4096-byte physical blocks
[1204561.256165] sd 3:0:0:0: [sdb] Write Protect is off
[1204561.256168] sd 3:0:0:0: [sdb] Mode Sense: 47 00 10 08
[1204561.256388] sd 3:0:0:0: [sdb] No Caching mode page found
[1204561.256391] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[1204561.305825] GPT:Primary header thinks Alt. header is not at the end of the disk.
[1204561.305828] GPT:20971519 != 23437705215
[1204561.305830] GPT:Alternate GPT header not at the end of the disk.
[1204561.305831] GPT:20971519 != 23437705215
[1204561.305832] GPT: Use GNU Parted to correct GPT errors.
[1204561.305853] sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9
[1204561.308320] sd 3:0:0:0: [sdb] Attached SCSI disk
I used parted to fix the errors:
(parted) print
Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of
the space (an extra 23416733696 blocks) or continue with the current setting?
Fix/Ignore? Fix
Model: WD Elements 25A3 (scsi)
Disk /dev/sdb: 12.0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: pmbr_boot
Number Start End Size File system Name Flags
1 1049kB 34.6MB 33.6MB fat16 hassos-boot msftres
2 34.6MB 59.8MB 25.2MB ext4 hassos-kernel0
3 59.8MB 328MB 268MB hassos-system0
4 328MB 353MB 25.2MB hassos-kernel1
5 353MB 622MB 268MB hassos-system1
6 622MB 630MB 8389kB hassos-bootstate
7 630MB 731MB 101MB ext4 hassos-overlay
8 731MB 9321MB 8590MB ext4 hassos-data
9 9321MB 9858MB 537MB DVR msftdata
Except that screwed up the first fat partition somehow and the rpi bootloader fails with "Unable to read partition as FAT"
i tried some MBR/GPT work from my windows box prior to re-imaging, same issue (although honestly it's so quick the error may be different)
I'm a little hamstrung by my pi being dead for the moment, so can't play with formatting like you can. 
Stupid q - wouldn't you want to "ignore" the error above, at least to test? We don't need the "real" space in question yet. Since it eventually ends up as exFAT, i would even let it continue on the small volumes, for now, and then you could "grow" it after the install runs. Just a thought...
OR
the image could just format / write for a 2TB drive to start, and then expect the end user (for now) to grow the 2TB to whatever TB manually, post install. Not ideal, but better than a black screen (and buys time for a fix)
What you're describing is how things currently work. The img file has less than 10GB in partitions defined, and the last partition is grown to fill the disk on the first boot.
Right - my point is - remove the automated grow (or cap it at 2TB, but i think a removal would be safer for now). Get the disk to the point where it's viable, and can be grown less problematically.
The grow stuff happens much later, after the OS boots and our scripts run. The OS is not even booting yet, because of a bug in the bootloader. Apparently this is a common LBA issue which affects almost every operating system and bootloader, including barebox and even Windows. Workarounds exist and the proper one needs to be found and applied for this specific situation.
Got it.
The one thing i haven't tried is having a base MBR at first (i.e. formatting the 4TB drive as a 2TB MBR, prior to applying the image). Kills all birds as it caps at 2TB. Shot in the dark, but let's see.
The image contains a GPT so I don't think you can do anything before flashing that would make a difference.
I found that uboot is not compiled with 64bit support, and thus only supports drives under 2TB. I am trying to recompile it now.
yeah i agree - it doesn't make sense, but willing to try anything
good to hear on uboot - waiting with baited breath, as it sounds like the right fix!
No luck unfortunately. However it looks like that "capacity not available" is related. It doesn't know the size of the disk, and then gets confused because the first partition seems to start after the end of the disk (0).