From owner-freebsd-fs@FreeBSD.ORG Fri Feb 7 17:18:33 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 975871C9 for ; Fri, 7 Feb 2014 17:18:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D8021450 for ; Fri, 7 Feb 2014 17:18:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 92B4FB94B; Fri, 7 Feb 2014 12:18:32 -0500 (EST) From: John Baldwin To: Warren Block Subject: Re: amd64/186515: Doesn't boot with GPT when # of entries over than 128. Date: Fri, 7 Feb 2014 12:18:19 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201402061930.s16JU2Pi052495@freefall.freebsd.org> <52F4D4C9.3060902@yandex.ru> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402071218.19221.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 07 Feb 2014 12:18:32 -0500 (EST) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:18:33 -0000 On Friday, February 07, 2014 11:24:43 am Warren Block wrote: > On Fri, 7 Feb 2014, Andrey V. Elsukov wrote: > > > On 06.02.2014 23:30, John Baldwin wrote: > >> Using more entries to pad out the table isn't the normal way to handle 4k > >> alignment. You can just leave a gap before the start of freebsd-boot. Having > >> the sectors "free" vs having them contain zero'd GPT entries doesn't really > >> make a difference. One question is when does the boot break? Does it make it > >> into the loader and break trying to boot the kernel? Does it make it into > >> gptboot and break trying to load the loader? > > > > Hi John, > > > > this is gptboot's restriction. Look at the sys/boot/common/gpt.c. > > It is mentioned at the start of gptboot(8) under Implementation Notes, > too. > > Alignment of freebsd-boot is usually not very important. It is only > rarely written, and the bootcode is so small that it will probably not > take appreciably longer to read or write even when misaligned. > Filesystem partitions are where alignment really matters. We could at least emit an error message when this happens instead of blowing up. Ah, I think the problem is that gptboot tries to return from main() which it shouldn't do. This was introduced a while ago when the GPT code was rototilled. See if this patch forces an error and then drops to a prompt rather than a silent reboot: Index: sys/boot/i386/gptboot/gptboot.c =================================================================== --- sys/boot/i386/gptboot/gptboot.c (revision 261528) +++ sys/boot/i386/gptboot/gptboot.c (working copy) @@ -156,7 +156,7 @@ /* Process configuration file */ if (gptinit() != 0) - return (-1); + goto prompt; autoboot = 1; *cmd = '\0'; @@ -204,6 +204,7 @@ /* Present the user with the boot2 prompt. */ +prompt: for (;;) { if (!OPT_CHECK(RBX_QUIET)) { printf("\nFreeBSD/x86 boot\n" -- John Baldwin