<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
To answer your questions Michael:<BR>
<BR>
"It" being UEFI Shell, lowering UEFI Shell in the boot priority of the BIOS. <BR>
<BR>
My assumption here is based on the context of this group and the original email. I see that context as being framed with installing a DIY OS (FOSS) on new hardware that is UEFI enabled with Windows 8. I currently work with EFI/UEFI enabled BIOS at the manufacturer level. The framework is there but via AMI BIOS can be depreciated out of the boot sequence so as to not be invoked in the current APTIO BIOS framework. I would assume the same thing would be true of new hardware implementations.<BR>
<BR>
Of course the BIOS manufacturer "may" render a system unable to boot another OS, live CD or the like if access to the boot sequence and/or boot devices is removed and hard-coded. I believe the UEFI code to be executed is stored on another partition on the HDD so if wiping a drive you'd be wiping that as well. Boy I'll bet such a system would love that!<BR>
<BR>
Again, my thinking is toward removal of Microsoft (not working around it as in a dual-boot scenario). I know that many people will want to dual-boot Linux but in the context of this group; I take it we're more adept to blowing MS out for *NIX. I for one am and only run Windows as bare-metal (for specialized applications and hardware that require it and is kept offline) or in VM's (and very little of that!) How Canonical chooses to co-habitat with Microsoft Windows 8 will be their deal...but as I see it the desktop is going the way of the dinosaur and mobile devices will be the winner. As to that arena there are two major players....iOS and Android; and of those last time I checked Linux was the winner on the global scale.<BR>
<BR>
Otherwise Newegg has lots of deals for those of us who roll their own (like me) and refuse to get locked-in by proprietary system builds that try to prevent installation of tandem OSes.<BR>
<BR>
Could this be a return to the 1990's and the days of IE4? BSOD to the neo-surf-nazi corporapists........ [had to get an Aaron reference in this somehow!]<BR>
<BR>
Back to work for me.....<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
On Fri, 2011-10-21 at 12:43 -0400, Michael H. Warfield wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Fri, 2011-10-21 at 12:18 -0400, Rich Faulkner wrote:
> I have yet to read about this so may be chiming in too early but...
> If the issue is UEFI related all you have to do is disable that in the
> BIOS or lower it in priority of the boot sequence so that it doesn't
> invoke.
I've been following the discussions in the forums and some of that has
centered around whether the vendors will be supply that functionality,
to disable or downgrade the secure boot, or not. Microsoft has publicly
stated that they (the vendors) are not required to and they (MS) are not
requiring them to. I'm not quite sure what you mean by lowering it in
priority? "It" being what? The secure boot?
> Flash a legacy BIOS (if available as well) but keep in mind
> that EFI/UEFI are standards that allow you to make your own pre-boot
> environment.
If by legacy BIOS you mean the old style BIOS, that may become more and
more difficult as newer hardware becomes available. Much of this will
require the extensibility framework of the UEFI. It gets even worse if
one of the OSs you want to use IS one that requires UEFI (Windows 8
going down the road of OS X?).
Looking at coreboot, FKA LinuxBIOS, may be beneficial but then there
will be the ability to flash a coreboot image into newer motherboards,
which tends to be problematical.
> Worth further reading online and originally developed by
> Intel as "The Framework" if memory serves....RinL
Yeah, UEFI is a framework that includes a Forth interpreter for plugin
extensions. Lots of good information on some of that up at the coreboot
site.
Regards,
Mike
> On Fri, 2011-10-21 at 09:34 -0400, Derek Atkins wrote:
>
> > Mike Harrison <<A HREF="mailto:cluon@geeklabs.com">cluon@geeklabs.com</A>> writes:
> >
> > > On Thu, 20 Oct 2011, Bob Toxen wrote:
> > >> <A HREF="http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement">http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement</A>
> > >
> > > Done.
> > >
> > > Remember the real vote is with your wallet. Support the hardware
> > > manufacturers that support your choice in OS. Which, while it goes
> > > without saying, they usually have little knowledge that you are using
> > > their hardware with Linux. As a group, we tend to just "make it work",
> > > It helps a lot to let the manufacturer and/or retailer know you
> > > bought it because it works with Linux.
> >
> > my understanding is that there would be a BIOS switch to turn this off.
> >
> > -derek
>
>
>
> _______________________________________________
> Ale mailing list
> <A HREF="mailto:Ale@ale.org">Ale@ale.org</A>
> <A HREF="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</A>
> See JOBS, ANNOUNCE and SCHOOLS lists at
> <A HREF="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</A>
_______________________________________________
Ale mailing list
<A HREF="mailto:Ale@ale.org">Ale@ale.org</A>
<A HREF="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</A>
See JOBS, ANNOUNCE and SCHOOLS lists at
<A HREF="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>