From owner-freebsd-stable@FreeBSD.ORG Wed May 9 10:42:30 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85107106564A; Wed, 9 May 2012 10:42:30 +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 A0FF68FC14; Wed, 9 May 2012 10:42:29 +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 NAA22898; Wed, 09 May 2012 13:42:27 +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 1SS4Lj-000NcW-2a; Wed, 09 May 2012 13:42:27 +0300 Message-ID: <4FAA4A11.808@FreeBSD.org> Date: Wed, 09 May 2012 13:42:25 +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> In-Reply-To: <4FAA3912.3030801@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 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 10:42:30 -0000 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... 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? > 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. -- Andriy Gapon