BIOS booting from disks > 2TB

[John Baldwin]

On Thursday, November 20, 2014 4:50:24 am Borja Marcos wrote:
> 
> On Nov 20, 2014, at 10:38 AM, José María Alcaide wrote:
> 
> >  Can't work out which disk we are booting from.
> >  Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0:
> > 
> > is harmless (given that we actually want to boot from the first disk).
> > 
> > In fact I did another test: I installed FreeBSD on an 8 GB partition *using the MBR scheme instead of GPT*, and the system booted from the first 3 TB disk 
without any problem (and with four disks attached), despite of showing the same warning message.
> 
> So, that 0xffffffff might be a buffer overflow being triggered by a failed attempt to read the backup GPT table?

No.  Anytime the early boot stage doesn't like the drive the loader ends up
using a device number of -1.  It's not really an overflow, but an error
indicator.

> Let's assume that the BIOS is poorly implemented and it won't read beyond the 2 TB limit.

That would be really odd since EDD has existed and supported 64-bit LBAs since
1995.

> As far as  I know, booting from a MBR disk doesn't require reading anything but the "classic" partition table and the partition we
> are using. So, as long as the partition fits inside that 2 TB limit it should work, and it does.

Booting requires reading files like /boot/loader which can be anywhere on the
disk.  However, MBR partitions are limited to 32-bit LBAs, so your filesystem
is similarly limited.

> Booting from GPT, however, requires reading the end of the disk. Or is the backup copy of the partition table read if and only if
> there's some problem with the main one? 

Booting requires more than reading tables, it requires reading files and those
can be anywhere.

> Can BIOS be reporting a wrong size for the disk (after all we are assuming a dodgy BIOS) and making gptboot to cosider the
> table corrupt, hence causing it to try to read the backup copy?
> 
> Whatever, that 0xffffffff parameter (which should be something like 0x80) looks like a corrupted variable to me, which would mean
> we have some buffer overflow?

No, as I said above, it is an error indicator, not an overflow.

> Maybe I'll try to recompile the boot chain removing the backup reading and the sanity checks and see what happens.

Can you start with 'lsdev -v' at the loader prompt?

-- 
John Baldwin