Date: Mon, 06 Oct 2014 16:34:49 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org, nathanw@freebsd.org Cc: Glen Barber <gjb@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: Media image names - Document & rationalise. Message-ID: <88376822.lFZdKxbhSR@ralph.baldwin.cx> In-Reply-To: <CAOgwaMuTPtKUk=2q=bcObr8So9DpGx%2Bo9y6DvCyPPP1y4ZKEXw@mail.gmail.com> References: <201410011358.s91DwOXJ033137@fire.js.berklix.net> <CAPyFy2DYkYwPD_6Hm6c1wyyDjVRmSAqVnGumXYfm_k6-Jo4MTA@mail.gmail.com> <CAOgwaMuTPtKUk=2q=bcObr8So9DpGx%2Bo9y6DvCyPPP1y4ZKEXw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, October 01, 2014 04:56:02 PM Mehmet Erol Sanliturk wrote: > On Wed, Oct 1, 2014 at 12:54 PM, Ed Maste <emaste@freebsd.org> wrote: > > On 1 October 2014 10:37, Glen Barber <gjb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?88376822.lFZdKxbhSR>