From owner-freebsd-stable@FreeBSD.ORG Thu May 10 07:13:04 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E952106566B; Thu, 10 May 2012 07:13:04 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id D06A18FC08; Thu, 10 May 2012 07:13:03 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 0270E5C9BD; Thu, 10 May 2012 09:13:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id pDHG3BI2dQzi; Thu, 10 May 2012 09:13:01 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id C34465C9BB; Thu, 10 May 2012 09:13:01 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id BE0DB45087; Thu, 10 May 2012 09:13:01 +0200 (CEST) Message-ID: <4FAB6A7B.9050500@dssgmbh.de> Date: Thu, 10 May 2012 09:12:59 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FAA83BD.2030204@FreeBSD.org> In-Reply-To: <4FAA83BD.2030204@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 07:13:04 -0000 -----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@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-----