FreeBSD 8 i386 gptboot corrupt - SOLVED

[Alfred Bartsch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 09.05.2012 16:48, schrieb Andriy Gapon:
> 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 differently.
>> 
>>> 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.
> 

I got this stupid idea of a "16k limit" during testing. It was
unobvious to me that the build process in a standard environment
(i386) simply produces invalid code.
In i386 (32-bit) hardware, we don't use zfs at all, so I can't tell
anything about gptzfsboot.
For now, modifying /sys/boot/i386/gptboot/Makefile completely solves
this actual build problem.

IMHO the compiler should always know perfectly well in which hardware
environment it runs and for which target environment it produces code.
So the build environment should be modified to fix this. I would
certainly give it a try, but unfortunately this is far beyond my
knowledge. :-(

>>>> 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 1.62.6.4 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 build.
>> 
>> 
>> Thank you for your fast and helpful response.
>> 
> 

- -- 
Alfred Bartsch
Data-Service GmbH
mailto:bartsch at dssgmbh.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ransACgkQ5QGe2JdVf3gwPgCglboYbXB4AIP/BXg+uyVf/CRN
DxIAnAly7qqasYixQBNMcZFoZllURLRv
=A/YX
-----END PGP SIGNATURE-----