BIOS booting from disks > 2TB
jhb at freebsd.org
Thu Nov 20 17:57:07 UTC 2014
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
> 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
> 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?
More information about the freebsd-fs