From owner-freebsd-fs@FreeBSD.ORG Thu Nov 20 09:50:37 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AE4C889 for ; Thu, 20 Nov 2014 09:50:37 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9DA4CD1 for ; Thu, 20 Nov 2014 09:50:35 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPSA id 3369B9DD957; Thu, 20 Nov 2014 10:50:26 +0100 (CET) Subject: Re: BIOS booting from disks > 2TB Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Borja Marcos In-Reply-To: Date: Thu, 20 Nov 2014 10:50:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7CAD9C0C-E793-4DA8-8ED0-AAB01C77F52C@sarenet.es> References: <17A2AC72-AD70-480A-9BAC-9CC8EAFD572F@we.lc.ehu.es> <546DA321.8050403@jrv.org> To: =?iso-8859-1?Q?Jos=E9_Mar=EDa_Alcaide?= X-Mailer: Apple Mail (2.1283) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 09:50:37 -0000 On Nov 20, 2014, at 10:38 AM, Jos=E9 Mar=EDa Alcaide wrote: > Can't work out which disk we are booting from. > Guessed BIOS device 0xffffffff not found by probes, defaulting to = disk0: >=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 = *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? Let's assume that the BIOS is poorly implemented and it won't read = beyond the 2 TB limit. 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 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?=20 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? Maybe I'll try to recompile the boot chain removing the backup reading = and the sanity checks and see what happens. Borja.