Date: Thu, 20 Nov 2014 11:10:44 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-fs@freebsd.org Subject: Re: BIOS booting from disks > 2TB Message-ID: <201411201110.45066.jhb@freebsd.org> In-Reply-To: <7CAD9C0C-E793-4DA8-8ED0-AAB01C77F52C@sarenet.es> References: <17A2AC72-AD70-480A-9BAC-9CC8EAFD572F@we.lc.ehu.es> <D91EAD51-2B6B-41E6-891E-575153409745@we.lc.ehu.es> <7CAD9C0C-E793-4DA8-8ED0-AAB01C77F52C@sarenet.es>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, November 20, 2014 4:50:24 am Borja Marcos wrote: >=20 > On Nov 20, 2014, at 10:38 AM, Jos=E9 Mar=EDa Alcaide wrote: >=20 > > Can't work out which disk we are booting from. > > Guessed BIOS device 0xffffffff not found by probes, defaulting to disk= 0: > >=20 > > is harmless (given that we actually want to boot from the first disk). > >=20 > > In fact I did another test: I installed FreeBSD on an 8 GB partition *u= sing the MBR scheme instead of GPT*, and the system booted from the first 3= TB disk=20 without any problem (and with four disks attached), despite of showing the = same warning message. >=20 > So, that 0xffffffff might be a buffer overflow being triggered by a faile= d 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 si= nce 1995. > As far as I know, booting from a MBR disk doesn't require reading anythi= ng but the "classic" partition table and the partition we > are using. So, as long as the partition fits inside that 2 TB limit it sh= ould work, and it does. Booting requires reading files like /boot/loader which can be anywhere on t= he disk. However, MBR partitions are limited to 32-bit LBAs, so your filesyst= em is similarly limited. > Booting from GPT, however, requires reading the end of the disk. Or is th= e backup copy of the partition table read if and only if > there's some problem with the main one?=20 Booting requires more than reading tables, it requires reading files and th= ose can be anywhere. > Can BIOS be reporting a wrong size for the disk (after all we are assumin= g a dodgy BIOS) and making gptboot to cosider the > table corrupt, hence causing it to try to read the backup copy? >=20 > 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 an= d the sanity checks and see what happens. Can you start with 'lsdev -v' at the loader prompt? =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201411201110.45066.jhb>