
UEFI boot: how does that actually work, then? - justincormack
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
======
ackalker
From the article: "it’s a really good idea to go and read the UEFI
specification. You can do this. It’s very easy. You don’t have to pay anyone
any money. [...] You can find it [right here on the official UEFI site]. You
have to check a couple of boxes, but you are not signing your soul away to
Satan, or anything."

Before people click on that link and start thinking the author of the article
is a damn liar (the link takes one to a menacing "Access Denied" page which
prompts users to login or register (which in turn involves filling out a form
and possibly paying a large amount of money)), here is a link to free
downloads of the specification documents (as PDF files):

[http://www.uefi.org/specifications](http://www.uefi.org/specifications)

And by the way, no need to check any boxes at all, just click any of the links
and the download should start right away.

~~~
pgeorgi
But also read the blurb on the page: "By downloading any of the UEFI
Specifications, you acknowledge that no license, express or implied, is
granted to you to distribute, additionally reproduce, implement or otherwise
use for any purpose (other than to read only) the UEFI Specifications, and
that all rights, title and interest in and to the UEFI Specifications,
including all intellectual property rights of any type whatsoever, are owned
by the UEFI Forum, or subject to rights granted to the UEFI Forum."

So if I download these files, I acknowledge that I may not use the spec to do
anything useful with it. It might be better to derive UEFI knowledge from the
Tianocore sources, since those come with no strings attached.

------
bo1024
As as someone who just wants to install the OSes of their choice on their
machines, the main takeaway I got was

> _there used to be a thing called BIOS that was dead simple to deal with and
> did what you want. Now there is a replacement called UEFI that is insanely
> complicated to deal with and (at least in practice) makes it hard to do what
> you want._

Is that accurate?

~~~
josteink
Not really.

I'd amend your statement to be "There used to be a very limited thing called
BIOS, a collection of historical hacks, which only did one thing decently, but
not really well. To make matters worse, in all cases but this one, it
completely fell apart. There was no consistent tooling, and when it worked, it
was non-inspectable black magic even to the most sophisticated power-user. The
limitations of BIOS booting caused different OSes to constantly step on each
others feet."

UEFI is different, but actually has a _design_ , supports tooling, any OS can
work with it seamlessly without fear of collision, and as result it handles
all scenarios simple or complex equally well.

As a bonus it can also do a million things BIOS couldn't, like loading a
Linux-kernel directly, from acoss the network, without any intermedia-
bootloading proxy or iPXE shim.

Now you can actually put your bootloader setup in source-control. I'm not sure
_why_ you would do that, but please go ahead and try that with BIOS.

So yeah. UEFI really isn't that complex. It's just different. It just seems
more complex because now even regular guys like us can see all the moving
parts, where in the past only OS-designers could peek in.

~~~
epistasis
Really weird to see this downvoted. IMHO, UEFI is a godsend from the terrible
BIOS days. Things like ipmitool could sometimes be used to control the BIOS on
server hardware, but efibootmgr is much better, and available everywhere now.

~~~
bo1024
(Not a downvoter, but) I'm just saying that as a user who doesn't know what
things like ipmitool or efibootmgr are, all I know is that it was very easy to
install OSes as I wanted, dual-boot, etc with BIOS and whenever I hear about
UEFI it's scary/intimidating, for instance this article says:

> If you absolutely insist on having more than one OS per disk, understand
> everything written on this page, understand that you are making your life
> much more painful than it needs to be, lay in good stocks of painkillers and
> gin, and don’t go yelling at your OS vendor, whatever breaks.

I've dual-booted with multiple OSes per disk with BIOS several times and had
no problems at all. So I can't help but get a bad impression of UEFI.

~~~
josteink
> I've dual-booted with multiple OSes per disk with BIOS several times and had
> no problems at all. So I can't help but get a bad impression of UEFI.

I think this article was written back when you had to setup everything UEFI
manually, at least in the Linux-world. I don't think all parts still applies.

These days most of these things should be taken care of automatically for you,
by the OS vendor, just like they used to in the BIOS past.

Except now you wont have to mess around with installation-order, custom
bootloaders or weird grub-entries. It's all handled natively by UEFI.

------
pudquick
One piece that was not mentioned is the necessity of your UEFI / EFI
implementation including integrated chipset driver support for talking to
various devices (mass storage, USB, etc) at boot. Additionally how that can
interact with legacy Option ROMs.

It also didn't cover the replacement of the BIOS VGA baseline graphical
communication standard with GOP (Graphics Output Protocol) - meaning that your
graphics card itself specifically needs to be compatible with UEFI / EFI to
even boot.

I'm sad he took a negative stance to Apple in the article. Their
implementation (of EFI) is very interesting in the choices they made and it's
worth noting the differences (they do not, for instance, provide a graphical
configuration choice "boot menu" like most PCs - they only provide visual boot
media selection).

Another interesting thing Apple did was, prior to all Windows editions
natively booting to UEFI / EFI, they still wanted to provide dual boot support
for OS X and Windows on their Intel Macs. But this meant that while OS X was
EFI booting and required GPT drives - Windows was BIOS booting and required
MBR drives. As such, Apple used a hybrid GPT/MBR format where the partition
maps in both were in synchronization and GPT reserved the areas where MBR
information was stored on the drive.

~~~
cmurf
Apple makes some of the best and worse choices, often even simultaneously.

Good: No firmware setup UI. Leave the user out of it.

Good: Firmware built-in GUI boot manager that discovers _currently_ bootable
OS's dynamically. Plug in an external, an icon appears with an animated
reveal. Animation in the f'n firmware built-in boot manager.

Bad: That boot manager hard wires a label "Windows" for any legacy CSM-BIOS
installed OS, even if it isn't Windows.

Mixed: Apple's firmware is mainly based on Intel 1.10, with some extensions
such as UEFI GOP, and some Apple stuff. It's not a standard UEFI 2.x firmware
at all, and it's not documented at all. 3rd party bootloader programs have to
have physical access to Macs to poke them with a stick in order to figure out
how they work due to Apple's closed nature. So if you care about running open
source OS's on Apple hardware, this is probably more "bad" than "mixed".

Very bad: There's a long standing pernicious bug with Disk Utility, on Boot
Camp'd drives (OS X + Windows) which permits the user to resize the OS X
volume thereby creating a 5th partition: ESP, OS X, New Partition, Apple Boot,
Windows. And Apple's tools remove the hybrid MBR, replace it with a protective
MBR, and now Windows is unbootable. All without warning. This behavior
violates their own proscription against manipulating drives with hybrid MBRs.
Technote 2166: "If block 0 contains any other form of MBR, it should refuse to
manipulate the disk." Their message boards have hundreds of such complaints.
This isn't new, it's been a problem for years, it was bug reported years ago,
and Apple basically blamed it on Windows rather than their own tool which
actually causes the problem by wiping out the PMBR.
[https://developer.apple.com/library/mac/technotes/tn2166/_in...](https://developer.apple.com/library/mac/technotes/tn2166/_index.html#//apple_ref/doc/uid/DTS10003927-CH1-SUBSECTION11)

So I'm not a fan of their hybrid MBR hack, even though earlier on it was
probably unavoidable. Windows has supported UEFI booting since Vista, but
Apple's kinda dragged their feet on supporting UEFI Windows boot until very
recently, and I'm not even certain Boot Camp Assistant defaults to this
behavior yet.

~~~
pudquick
For Windows 8, yes, it defaults to UEFI now, thankfully.

~~~
cmurf
This support must require relatively recent hardware with newer firmware
because it's definitely not doing a UEFI install on a 2011 Macbook Pro.

------
jhallenworld
EFI Shell is the new (built-in) MS-DOS. I'm waiting for someone to make
doom.efi :-)

The the entire OS to BIOS API changed with UEFI. I've seen bugs where the BIOS
int 15 ax=E820 memory map does not match the EFI memory map passed to Linux.

All of this to support > 2TB drives.

~~~
wtallis
EFI isn't about 2+TB drives. That's just GPT, which could have been
implemented in a traditional BIOS. EFI was created because Intel needed
_something_ for the Itanium chips to run, and they didn't want to implement
OpenFirmware.

EFI came to the PC because Apple wasn't interested in starting a 16-bit 8086
programming division, and the rest of the industry followed suit because it
was easier than squeezing more things into the 16-bit BIOS. Now that we've got
both EFI and GPT widely available, we can have machines that can do things
like fetch and install their own firmware updates and we can have sane dual-
booting.

~~~
barrkel
However, in the meantime, we have to live with "complications" like a frequent
lack of support on Linux for decent console drivers in UEFI boots. For
example, technically the nVidia proprietary driver doesn't support framebuffer
console on UEFI boots, and if you don't get the parameters just right, you can
end up in the hilarious situation of typing your full disk encryption password
blind to a blank screen visibly indistinguishable from a crashed bootloader.

~~~
yuhong
I have been saying that BIOSes needs a proper support lifecycle and bug
reporting channel for both security and non-security bugs for a while now.

------
orbifold
I feel like Coreboot would be a much saner alternative to UEFI.

------
upofadown
From this I get that "BIOS compatibility mode" is a required specification.
Then I can ignore all the rest of the article.

I have recently been learning about OpenBSD. I really like how they have
handled all the weirdness associated with PC architecture
booting/partitioning. OpenBSD simply ignores it and does everything on top of
it. Once you have a partition marked as OpenBSD you are done the architecture
specific stuff. Then you go on to do things the OpenBSD way which is the same
over all architectures. So when Intel comes up with UUEFI (or whatever) you
can continue to ignore the whole mess.

~~~
pgeorgi
Compatibility Support Modules ("BIOS compatibility mode") aren't required. The
text states "many UEFI firmwares implement some kind of BIOS compatibility
mode, sometimes referred to as a CSM.".

"many" not "all", and the article sticks to that.

Since CSMs are incompatible with Secure Boot (since they can run whatever,
without extending the trust chain), I expect them to be on the way out. Same
as with the "Secure Boot optional" requirement on x86, by the way, since I
guess that the real reason Microsoft added that to their Windows Logo
requirements is that their large customers wanted to be sure that they can
image Windows 7 onto new machines for a while longer.

Once this kind of legacy is gone for good, Microsoft may tighten the screws
there. And since all big Linux vendors support Secure Boot now, that part of
the PC landscape won't make many noises either.

~~~
upofadown
Last I remember the Linux distros were just using a shim to get around the
secure boot stuff. In other words, something that just boots from the
partition that Linux just happens to be in with no verification of what that
is. If things are to be tightened then the keys for the shim would have to be
revoked. Then everyone is sad. Otherwise the OpenBSD approach still works as
normal with the shim.

~~~
geofft
That's not how the shim works.

The shim loader is an MIT-licensed piece of code that's signed by a Secure
Boot CA, typically MS for off-the-shelf x86 hardware. The shim has another
public key hard-coded into it, and verifies that the next bootloader (usually
GRUB 2) is signed with that key. It works around a couple of issues:

\- The turnaround time for getting something signed by MS is slow. Linux
distros want to be able to push out a new version of GRUB on their own. So by
having the CA sign a shim loader, new versions of the boot loader can be
signed with the distro's key alone, which they can automate as much as they
want.

\- There's some ambiguity over the GPLv3's TiVoization clause, so to avoid any
interpretation that MS would have to hand over its own private key, MS won't
sign any GPLv3 software directly (like GRUB). The distros think this is a non-
issue, and they're happy to sign their own GRUB binaries without imagining
they'd have to give up their private keys.

It doesn't change the security model of Secure Boot at all. You're still
verifying that someone whose key is in hardware has a trust path to your
bootloader. It's just that the trust path is one more step away.

If you want to include your distro's key in the UEFI variable that lists your
Secure Boot CA roots, you can do that, and skip the shim. (You probably can't
remove MS's key because UEFI drivers are signed with it, but that's a
different issue.)

Some distros (notably Ubuntu) have their _bootloader_ willing to boot unsigned
kernels, on the grounds that Secure Boot protects UEFI "boot services" (things
that run while UEFI still controls the machine, including access to certain
UEFI variables like Secure Boot config), but does not protect ring 0. Other
distros (Fedora, SuSE, etc.) think that that's nonsense, and Secure Boot
obviously protects ring 0. So their bootloader only boots signed kernels, and
those kernels, in turn, only load signed kernel modules.

MS has complained about Ubuntu's interpretation, but has so far not shown any
signs of forcing Ubuntu to change their practices. (I suspect with no real
information that MS is worried that, if they're holding the only CA for PC
hardware and they revoke the most popular Linux distro, they're going to be
reminded of what antitrust lawsuits feel like.) You can see MS's signing
policy here, including a link to the (non-MS) shim:

[http://blogs.msdn.com/b/windows_hardware_certification/archi...](http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-
uefi-ca-signing-policy-updates.aspx)

------
crdoconnor
>Most of the unhappiness about Secure Boot is not really about Secure Boot the
mechanism – whether the people expressing that unhappiness think it is or not
– but about specific implementations of Secure Boot in the real world.

Unfortunately, people in the real world use implementations of secure boot,
not its specification.

>If you want to get cheap volume licenses of Windows from Microsoft to pre-
install on your computers and have a nice “reassuring” ‘Microsoft Approved!’
sticker or whatever on the case, you have to comply with these requirements.
That’s all the force they have.

Post-US vs. Microsoft, MS does not want to be seen to be explicitly violating
anti-trust law, which is why in public and on the record, they will say and do
nothing wrong. This has actually done a lot of good, because it does shackle
their ability to engage in anti-competitive behavior.

It just doesn't shackle it completely, and it means that in order to do it
they have to be a bit more creative.

They still wield a large amount of power over the PC market, and manufacturers
know this. They still have several ways of opaquely favoring or disfavoring
some manufacturers over others. Manufacturers, on the whole, dont't mind being
opaquely favored and don't want to be opaquely disfavored and know that crying
foul about Microsoft abusing its market power in secret won't do them any
favors either.

It's a cut throat market and nobody is going to feel sorry for you as a
manufacturer if you died out because you didn't get an Microsoft promotional
tie in.

Thus sometimes, all it takes for anti-trust violations to continue and to go
unpunished is a nudge and a wink or an off the record conversation between MS
and manufacturers, and a decision made by either party that falls in a _gray
area_ of legal defensibility.

Here's where it gets evil, and here's the bit you are glossing over:

Secure boot PROVIDES that gray area while maintaining a veneer of
respectability.

>If you have an x86 system that claims to be Windows certified but does not
allow you to disable Secure Boot, it is in direct violation of the
certification requirements, and you should certainly complain very loudly to
someone. If a lot of these systems exist then we clearly have a problem and it
might be time for that giant lawsuit, but so far I’m not aware of this being
the case. All the x86-based, Windows-certified systems I’ve seen have had the
‘disable Secure Boot’ option in their firmwares.

Certainly you seem to be able to turn it off in most implementations I've
seen, but I haven't seen any that let me add trusted keys myself. Another gray
area methinks.

Nor is turning it off particularly easy. I know where it is and what it does,
but I know the history behind it.

MOST people draw a blank stare when they look at it and CERTAINLY don't get to
the menu and look at it and think "oh, for sure this is the thing that stops
me from installing linux".

Oh, and incidentally I've never eer seen a coherent error message caused by
secure boot's "protection". Not "you appear to be installing an untrusted OS".
Just blank screens and opaque error messages.

Let's say hypothetically that instead of being buried three menus deep, it was
a physical switch, with a clear explanation about what it actually does.

Let's say hypothetically that adding a key for secure boot were done using a
clean and simple UI that my mother could follow. Flip the switch, plug in a
USB key to boot from, menu asks if you want to trust this OS. You say yes and
flip the switch back on.

Let's say hypothetically that trying to install an "untrusted" OS gave you a
clear error message.

If these were the case (and these things certainly adhere to the spec), I
wouldn't have a problem with it either. Let's be realistic, though. It's not
that. It was not ever intended to be that. It was not supposed to be used to
secure your system, and while Microsoft did just enough to avoid a lawsuit
over it, their intentions are crystal clear.

Hardware manufacturers also know what's up, and won't be making it an easy to
use feature any time soon.

MS is playing the same game they did pre-DOJ, they're just trying to keep
plausible deniability at the same time as greasing all of the right palms. MS
pretends not to violate antitrust law. Microsoft contributes to all the right
election campaigns. DOJ pretends not to notice that Microsoft's secure boot
_initiative_ (if not the spec) is anti-competitive.

>As far as x86 devices go, though, right now, Microsoft’s certification
requirements actually explicitly protect your right to determine what can boot
on your system. This is good.

Microsoft is not explicitly breaking the law here. This is indeed good. Let's
award them a fucking medal. By the way, I didn't deal drugs today. This is
also good.

As for UEFI itself - it reminds me of XML - designed by committee, and yes,
strictly speaking it _does_ do the job, but it's ridiculously overcomplicated
and the market is littered with terrible implementations because of that
complexity. Worst of all it was never truly necessary because a simpler
specification (where's the UEFI equivalent of JSON?!) would have sufficed for
all use cases.

Another thing reminds me of XML too. There was a good market in being an
expert in XML for a while. It was almost a club, in fact. The arcaneness plus
the reliance the world had on it made for some excellent opportunities.
Opportunities that, say, JSON never provided.

There appears to be a good market to being the go to guy for UEFI too.

Just sayin'

~~~
mjg59
> Certainly you seem to be able to turn it off in most implementations I've
> seen, but I haven't seen any that let me add trusted keys myself. Another
> gray area methinks.

Which systems have you seen that have Secure Boot enabled by default and don't
provide any mechanism for key management? Many vendors won't provide a UI for
adding additional keys but _will_ let you remove all existing ones and then
enrol your choice - that's pretty much how the spec envisages this working.

> Let's say hypothetically that instead of being buried three menus deep, it
> was a physical switch, with a clear explanation about what it actually does.

And let's say that, hypothetically, hardware vendors refused to add a physical
switch that would cost a few cents extra per board and have an effect on their
bottom line. What then? And how do I prevent someone with brief physical
access from flicking that switch and replacing my bootloader?

> Let's say hypothetically that trying to install an "untrusted" OS gave you a
> clear error message.

Microsoft don't have enough leverage over the firmware vendors to be able to
mandate choice of language, so what you'd end up with is a variety of vendors
with their own idea of what a clear error message is.

> DOJ pretends not to notice that Microsoft's secure boot initiative (if not
> the spec) is anti-competitive.

The number of lawyers I've found who, after having had all aspects of this
explained to them, thought that Microsoft's behaviour here was anti-
competitive is zero. There was a much stronger argument before Microsoft
mandated that vendors provide a mechanism for performing key management and
agreed to sign third party bootloaders. Now? Not so much.

> There appears to be a good market to being the go to guy for UEFI too.

I'm doing pretty well out of it. But I did pretty well out of BIOS before
that, and if the market decides that Coreboot with a non-Tiano payload is the
way forward then I suspect I'll be fine there as well.

~~~
crdoconnor
>Which systems have you seen that have Secure Boot enabled by default and
don't provide any mechanism for key management?

All I've come across so far. Dells, Toshibas, a Lenovo, etc. I literally
haven't seen a UI for key management at all. Ever.

MAYBE that's because it's too well hidden or maybe those machines I've looked
at simply didn't have it.

>And let's say that, hypothetically, hardware vendors refused to add a
physical switch that would cost a few cents extra per board

I'd say that non-hypothetically speaking, they were trying to stay on
Microsoft's good side and coming up with a lame fucking excuse to do so.

That is, unless they came up with an equally good UI that didn't require a
button, which is possible.

Someone on this thread mentioned that chromebooks have a button. When pretty
much the lowest-cost point in the market can do it....

>Microsoft don't have enough leverage over the firmware vendors

Yes they do. If they have enough to mandate that it's written they have enough
to mandate that it's written coherently. They just have every incentive to
ensure that it isn't, and with a nod and a wink they can get their way.

>The number of lawyers I've found who, after having had all aspects of this
explained to them, thought that Microsoft's behaviour here was anti-
competitive is zero.

I wonder how many of those lawyers have ever tried to install linux with
secure boot turned on.

Maybe they all thought that if the spec was kosher that's all that matters.

>I'm doing pretty well out of it.

That certainly explains the apologetics.

~~~
mjg59
> MAYBE that's because it's too well hidden or maybe those machines I've
> looked at simply didn't have it.

Maybe you don't know what you're doing.

> I'd say that non-hypothetically speaking, they were trying to stay on
> Microsoft's good side and coming up with a lame fucking excuse to do so.

I'd say that you don't know what you're talking about.

> Someone on this thread mentioned that chromebooks have a button. When pretty
> much the lowest-cost point in the market can do it....

Except Google _are_ able to precisely define what a Chromebook looks like - if
you don't manufacture to Google's specifications, you don't get to ship
ChromeOS. Which, if Google were to dominate the market, would probably be the
point where you'd decry them as behaving in anticompetitive ways.

Microsoft have to perform an interesting balancing act. Vendors will adhere to
the Windows hardware certification requirements because it saves them money
per-unit. Microsoft can demand new firmware features because that's a one-off
cost per new platform. Hardware features cost per unit, and if they push that
too far it's cheaper for manufacturers to tell Microsoft to fuck off and
market their hardware without the Windows sticker. That's simply not an option
in the ChromeOS market. You can't compare them.

> Yes they do.

So cool you don't know what you're talking about.

> I wonder how many of those lawyers have ever tried to install linux with
> secure boot turned on.

Linux distributions having fucking dreadful installers really isn't what
determines whether something is an antitrust violation or not. Linux
distributions not being able to get their shit together sufficiently to get
things signed isn't either. Canonical, Red Hat and Suse (and a _whole_ _host_
of smaller distributions and specialised products) have managed to deal with
this.

> That certainly explains the apologetics.

I've also done pretty well out of OpenStack, but I'd be the first to admit
that it's dreadful.

~~~
crdoconnor
>Maybe you don't know what you're doing.

I triple checked on two computers to be sure. Nada. Maybe go fuck yourself.

>I'd say that you don't know what you're talking about.

And I'd say you should stick to low level coding and not comment on the
economics of competition and the contents of the US vs. Microsoft dockets...
unless you are an antitrust lawyer, an economist AND a kernel hacker?

Thought not.

>Except Google are able to precisely define what a Chromebook looks like

So a single switch is monstrously expensive unless Google mandates it, in
which case it's not a problem.

>So cool you don't know what you're talking about.

Jesus Christ you are so fucking lame.

>Linux distributions having fucking dreadful installers really isn't what
determines whether something is an antitrust violation or not.

It's the FIRMWARE's job to tell you that it's "saving you from yourself", not
the installers.

>Linux distributions not being able to get their shit together sufficiently to
get things signed isn't either. Canonical, Red Hat and Suse (and a whole host
of smaller distributions and specialised products) have managed to deal with
this.

Funny. I tried installing (the latest release of) Ubuntu the other day and got
nothing but a cryptic error message because secure boot was turned off.

~~~
mjg59
> I triple checked on two computers to be sure. Nada. Maybe go fuck yourself.

For the Thinkpad I have here:

1) Enter firmware 2) Go to security 3) Select "Reset to Setup Mode" 4) Enrol
keys using UEFI SetVariable() interface

What models are you talking about? Shipping with no mechanism to do this is in
violation of the Windows hardware certification requirements, and vendors
falsely claiming compliance are both falsely advertising and breaching their
contracts with Microsoft, so it's a pretty big deal for them to do so.

> And I'd say you should stick to low level coding and not comment on the
> economics of competition and the contents of the US vs. Microsoft dockets...
> unless you are an antitrust lawyer, an economist AND a kernel hacker?

You _are_ an antitrust lawyer and an economist?

> So a single switch is monstrously expensive unless Google mandates it, in
> which case it's not a problem.

In the Windows world, if Microsoft's demands become too extreme you can ignore
Microsoft, undercut your competitors and ship Windows anyway. In the ChromeOS
world, you can't.

> Funny. I tried installing (the latest release of) Ubuntu the other day and
> got nothing but a cryptic error message because secure boot was turned off.

If Secure Boot is turned off then your inability to boot Ubuntu has nothing to
do with Secure Boot.

------
pgeorgi
Interesting overview. I just dislike how it sets the tone with the 'everything
on the internet is crap except for what my Red Hat buddies and I say' intro
which is then followed up with several minor inaccuracies in the text.

~~~
crdoconnor
>I just dislike how it sets the tone with the 'everything on the internet is
crap except for what my Red Hat buddies and I say'

The UEFI world seems to be very clubby. I suspect its arcaneness and the
lucrative nature of working in it contributes to this.

I've seen this patronizing straw man "you don't know the spec like I do" from
a few other UEFI blog posts, too.

------
rbanffy
After fighting an eMMC-based "Windows Chromebook" for the last couple weeks, I
think I can answer how its specific implementation of UEFI works with one
word: "poorly".

~~~
arthurfm
What were you trying to do with it?

~~~
rbanffy
I was trying to install Ubuntu so that it boots off the eMMC. No luck there,
but Fedora can boot from a tiny USB stick that barely protrudes from the
chassis.

