FreeBSD 8 i386 gptboot corrupt - SOLVED
avg at FreeBSD.org
Wed May 9 14:48:34 UTC 2012
on 09/05/2012 15:09 Alfred Bartsch said the following:
> Am 09.05.2012 12:42, schrieb Andriy Gapon:
>> on 09/05/2012 12:29 Alfred Bartsch said the following:
>>> Hello, after migrating some of our older servers to FeeBSD 8.3-stable
>>> (cvsupped May 4th), they don't boot anymore after installing the new
>>> boot blocks with gpart. These servers either boot in an endless loop or
>>> stop in BTX loader, due to different hardware environments.
>>> This behavior is restricted to 32-bit servers (i386), all 64-bit
>>> servers (amd64) work without any problem, as expected.
>>> After some analyzing, it seems to me that the actual size of gptboot
>>> does matter (16723 bytes, >16kB). In amd64 environment (same source
>>> version) the actual size of /boot/gptboot is only 15443 bytes.
>> Weird. Both amd64 and i386 builds should produce the same binaries as
>> the boot code is built with -m32 -march=i386 on amd64. But I can
>> reproduce this, so it seems that the compilation is indeed done
>> Heh, it seems that it is -march=i386 flag that makes all the difference.
>> Maybe we should use this flag even when doing native i386 builds...
> after adding "-march=i386" to CFLAGS in Makefile everything looks ok
> (filesize: 15443, as you predicted), so I would opt for using this flag in
> the future.
>> Anyway, the pmbr code is supposed to read the whole content of a GPT boot
>> partition into memory (actually limited to 545KB), so 16KB limit should
>> not matter/exist. What size are your GPT boot partitions?
> They are all 64k (128 sectors), as recommended.
Strange. I wonder what kind of a problem you are running into.
E.g. I use gptzfsboot and its size is ~40KB and I do not having any problems.
>>> Since there is only one single Makefile for both architectures
>>> (/sys/boot/i386/gptboot/Makefile), some recent changes of CFLAGS seem
>>> to be responsible for this (Version 1.62 does work, Version 126.96.36.199
>>> does not).
>>> Is there any advice available to solve this (compiler) problem, or is
>>> at last /sbin/gpart the culprit?
>> You can always try to locally revert the commit that changed the CFLAGS,
>> but as I've said above there should not be any 16KB limit for GPT boot.
>> Or you can try to add -march=i386 to CFLAGS for your i386 boot block
> Thank you for your fast and helpful response.
More information about the freebsd-stable