From owner-freebsd-stable@FreeBSD.ORG Wed May 9 14:48:34 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 7CD9F106566C for ; Wed, 9 May 2012 14:48:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C16A98FC15 for ; Wed, 9 May 2012 14:48:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA24438; Wed, 09 May 2012 17:48:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SS8Br-000Njj-IB; Wed, 09 May 2012 17:48:31 +0300 Message-ID: <4FAA83BD.2030204@FreeBSD.org> Date: Wed, 09 May 2012 17:48:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alfred Bartsch References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> In-Reply-To: <4FAA5E70.7030508@dssgmbh.de> X-Enigmail-Version: 1.5pre 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: Wed, 09 May 2012 14:48:34 -0000 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. >>> 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. > -- Andriy Gapon