From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 20:49:35 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51F59761; Mon, 6 Oct 2014 20:49:35 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B58F83A; Mon, 6 Oct 2014 20:49:32 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E495FB96B; Mon, 6 Oct 2014 16:49:30 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, nathanw@freebsd.org Subject: Re: Media image names - Document & rationalise. Date: Mon, 06 Oct 2014 16:34:49 -0400 Message-ID: <88376822.lFZdKxbhSR@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <201410011358.s91DwOXJ033137@fire.js.berklix.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 06 Oct 2014 16:49:31 -0400 (EDT) Cc: Glen Barber , Ed Maste X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:49:35 -0000 On Wednesday, October 01, 2014 04:56:02 PM Mehmet Erol Sanliturk wrote: > On Wed, Oct 1, 2014 at 12:54 PM, Ed Maste wrote: > > On 1 October 2014 10:37, Glen Barber wrote: > > > On Wed, Oct 01, 2014 at 03:58:24PM +0200, Julian H. Stacey wrote: > > >> Maybe there was an explanation of -uefi- on a mail list. One can > > >> guess: for [some?] newer machines try uefi. But could we put a more > > >> exact purpose of uefi images in a README ? > > > > > > The UEFI images will be documented in the release announcement email, > > > because they are specific to the 10.1-RELEASE cycle. 11.0-RELEASE will > > > have the functionality in the default installation medium. > > > > To be clear, the existing, legacy-only images are built the same way > > as they always have been. The reason there are separate -uefi- images > > is to avoid accidental regression in legacy-only boot support. > > > > The 10.1 -uefi- images (as well as the 11.0 images) are actually > > dual-mode, and should boot in both UEFI and legacy configurations. > > I'm interested in receiving test reports of installations using the > > -uefi- images, in both UEFI and legacy boot configurations. > > > > (Technical detail: The image contains legacy MBR boot code, and is > > partitioned using the MBR scheme. One of the MBR partitions is an EFI > > system partition of type 0xEF. Legacy boot uses the MBR, while UEFI > > loads the first-stage loader /EFI/BOOT/BOOTX64.EFI. Both cases use > > the same root file system and boot the same kernel.) > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > I have installed both of the > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/FreeBSD-10.1-BETA > 2-amd64-dvd1.iso.xz > ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/FreeBSD-10.1-BET > A2-amd64-uefi-dvd1.iso.xz > > distributions into the same HDD in a non-UEFI mainboard ( Intel DG965WHM > ) . > > No one of them produced a bootable installation . > > Previously I have sent the message > > https://lists.freebsd.org/pipermail/freebsd-current/2014-August/051617.html > > about this issue . > > The problem is still persisting in Beta 2 . > > On the same computer , Fedora 21 Alpha is booting very well ( means there > is not any hardware problem ) . > > > I did not try 10.1 Beta 3 because there is no any mention of this problem > in the announcement message . > > > Thank you very much . I believe the issue here as I discussed with Marcel last year is that the x86 installer needs to tell gpart to set the active flag on the dummy MBR slice in the PMBR if GPT is being used without EFI (the installer knows if it is booted via EFI or not). In 9.2 and older, the flag was always set, but that violated the EFI spec and broke several systems, so in 9.3 and later, gpart was changed to not set the flag by default. However, we should still set it for non-EFI booting via GPT to cater to broken BIOSes (such as yours). -- John Baldwin