From owner-freebsd-fs@FreeBSD.ORG Thu Nov 20 19:08:59 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 531FB662; Thu, 20 Nov 2014 19:08:59 +0000 (UTC) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.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 102BBC52; Thu, 20 Nov 2014 19:08:58 +0000 (UTC) Received: from www.saremail.com (unknown [194.30.0.100]) by proxypop04.sare.net (Postfix) with ESMTPSA id CFFA59DE4D4; Thu, 20 Nov 2014 20:08:54 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 20 Nov 2014 20:08:54 +0100 From: borjam@sarenet.es To: John Baldwin Subject: Re: BIOS booting from disks > 2TB In-Reply-To: <201411201110.45066.jhb@freebsd.org> References: <17A2AC72-AD70-480A-9BAC-9CC8EAFD572F@we.lc.ehu.es> <7CAD9C0C-E793-4DA8-8ED0-AAB01C77F52C@sarenet.es> <201411201110.45066.jhb@freebsd.org> Message-ID: X-Sender: borjam@sarenet.es User-Agent: Saremail/0.8 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 19:08:59 -0000 El 20.11.2014 17:10, John Baldwin escribió: >> 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. Oh, sorry. Understood. >> 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. Don't underestimate the terrific capability for surrealism of some peecee makers... ;) >> 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. As a matter of fact, I tried creating a MBR partition table and it worked. It just fails with the GPT. >> 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. Yes, I understand they can be anywhere of course. > >> 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. I stand corrected :) > Can you start with 'lsdev -v' at the loader prompt? Sure! cd devices: disk devices: disk0: BIOS drive C: pxe devices: ls doesn't see anything. I assume that ls disk0:/ should have worked, right? I tried setting root_disk_unit to 0, 1, 2... and ls doesn't see anything. I must admit, to my shame (I was a member of the Forth Interest Group 20 years ago!) that I am completely lost with the loader. For me it's always been a matter of install and forget ;) Borja.