First, the USB boot problem: Didn't know that is has become broken. That's an unpleasant surprise. Sorry for harassing you about that.
Second, the GPT / GEOM problem: Very weird. To begin with, your da[01] device driver lines look pretty normal; both disks da0 and da1 are being recognized correctly. They are connected to a LSI logic SAS HBA (= disk controller); that comes from the "mpt0" being mentioned. That explains why their device names are "da" and not "ada": they are seen as SCSI devices by the FreeBSD kernel, with the LSI card providing a SCSI emulation of a native SATA disk.
OK, and this immediately brings up a mystery: If you look at the disks' part numbers, you see they are Hitachi HDN724040AL, which is a fine 4TB drive, a SATA desktop NAS model. It's trivial to find the spec for the drive at Hitachi's web site. Observe two important things: The disk is native SATA, and it has 4TB capacity. But: The OS doesn't know its size! Or to be more accurate: If you look at the capacity line, it has 0xFFFFFFFF = 4.2 billion sectors, or a capacity of 2TB. That immediately explains why GEOM complains: It tries to read the first copy of the GPT table (which is at the beginning of the disk), then it tries to read the second or backup copy (which is at the end). The "end" of the disk is about 2TB into a 4TB disk. My educated guess is that when GEOM tries to read the second copy, it gets invalid content (something that is not formatted as a GPT), and prints a generic message "corrupt or invalid". EDIT: I made a mistake in the original post, and calculated the reported capacity as 2PB, way too high.
So what do we learn from that: There is something wrong with your storage stock, somewhere between the disk and the FreeBSD kernel (including both), which makes it impossible to read the disk capacity. That's disturbing, because these are good quality disks, the LSI met is a fine controller, and FreeBSD isn't completely broken. Who is the culprit? Don't know, but my first guess is the LSI controller and its SCSI emulation.
Suggestions? Not many practical ones.
- On the Dell machine, do you happen to have any other ports you can plug these disks in? Maybe some SATA ports directly on the motherboard? Do you have a different SAS or SATA controller card that you can use instead? Instead of fixing the problem, just circumvent it.
- Check the firmware version of the drive and of your LSI card. On the drive, it is version A5E0; to find out whether that's current, you probably have to contact Hitachi tech support. Next question: Look at the "mpt" lines in your dmesg file, and find out the firmware version on your LSI card. If the FreeBSD mpt driver doesn't report the firmware version, then boot again, and go into the BIOS setup screen of the LSI controller. Then check whether it's up to date enough; that probably requires contacting LSI (now known as Broadcom, formerly as Avago) tech support. It might be a good idea to do firmware upgrades on the disk and the controller, but that's a very tall order for someone who doesn't have the tools ready.
- If the first two suggestions have failed (they probably will, as they are impractical): Try the following commands, to see what else works and doesn't with these disk drives. First
camcontrol identify and ... readcap, to see that a SCSI inquiry command makes it through to the drive unmolested, and to see what the storage stack thinks the capacity of the drive is. Then try reading the first little bit of the disk, which contains the first copy of the GPT, with dd if=/dev/daX of=/tmp/save.the.gpt bs=4096 count=64.
- The only real hope is that someone who is familiar with the FreeBSD mpt stack sees this discussion and comes up with a sensible suggestion.
