Date: Thu, 20 Nov 2014 20:08:54 +0100 From: borjam@sarenet.es To: John Baldwin <jhb@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: BIOS booting from disks > 2TB Message-ID: <a68676a5c2ad1b45d787f216b3f41298@sarenet.es> In-Reply-To: <201411201110.45066.jhb@freebsd.org> 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> <201411201110.45066.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a68676a5c2ad1b45d787f216b3f41298>