My older son just enrolled into my alma mater, Singapore Polytechnic, to do Electrical Engineering. It is really nice to see that he has an interest in that field and, yes, make me smile as well.
So, as part of the preparations for the new program, the school does need the use of software as part of the curriculum. Fortunately, to get a computer was not an issue per se, but what bothered me was that the school “is only familiar with windows” and so that applications needed are also meant to run on windows.
One issue led to another and eventually, we decided to get a new laptop for his work in school. Sadly, the computer comes only with windows 8.1 installed and nothing else. The machine has ample disk space (1TB) and the system was set up with two partitions – one for the windows stuff (about 250G) and the 2nd partition as the “D: drive”. Have not seen that in years.
I wanted to make the machine dual bootable and went about planning to repartition the 2nd partition into two and have about 350G allocated to running Fedora.
Then I hit an issue. The machine was installed with Windows using the UEFI. While the UEFI has some good traits, but unfortunately, it does throw off those who want to install it with another OS – ie to do dual-boot.
Fortunately, Fedora (and RHEL) can be installed into a UEFI enabled system. This was taken care of by work done by Matthew Garrett as part of the Fedora project. Matthew also received the FSF Award for the Advancement of Free Software earlier this year. It could be argued that perhaps UEFI is not something that should be supported, but then again, as long as systems continue to be shipped with it, the free software world has to find a way to continue to work.
The details around UEFI and Fedora (and RHEL) is all documented in Fedora Secure Boot pages.
Now on to describing how to install Fedora/RHEL into a UEFI-enabled system:
a) If you have not already done so, download the Fedora (and RHEL) ISOs from their respective pages. Fedora is available at https://fedoraproject.org/en/get-fedora and RHEL 7 Release Candidate is at ftp://ftp.redhat.com/pub/redhat/rhel/rc/7/.
b) With the ISOs downloaded, if you are running a Linux system, you can use the following command to create a bootable live USB drive with the ISO:
dd if=Fedora-Live-Desktop-x86_64-20-1.iso of=/dev/sdb
assuming that /dev/sdb is where the USB drive is plugged into. The most interesting thing about the ISOs from Fedora and RHEL is that they are already set up to boot into a UEFI enabled system, i.e., no need to disable in BIOS the secure boot mode.
c) Boot up the target computer via the USB drive.
d) In the case of my son’s laptop, I had to repartition the “D: drive” and so after boot up from the USB device, I did the following:
i) (in Fedora live session): download and install gparted (sudo yum install gparted) within the live boot session.
ii) start gparted and resize the “D: drive” partition. In my case, it was broken into 2 partitions with about 300G for the new “D: drive” and the rest for Fedora.
e) Once the repartitioning is done, go ahead and choose the “Install to drive” option and follow the screen prompts.
Once the installation is done, you can safely reboot the machine.
You will be presented with a boot menu to choose the OS to start.
QED.
Yes, I dislike the UEFI. I had hit that in my Samsung Series 9 laptop before. In deep was fortunate to have Fedora 20 installed in it wonderfully working :-).
UEFI is meant to keep the boot secure but the whole thing can be gotten around trivially by the determined person. When I buy a machine, I *own* it and so I should be free to do as I please with it. The way Microsoft did the UEFI stuff was to deny me my rights and that was not acceptable. Fortunately, we have smart enough ways to get around it and still play in the UEFI playground.
BTW, the laptop I had installed Fedora is a Dell Latitude E5440 with 8G (expandable to 16G) and a 1TB drive.
You seem to be using “UEFI boot” and “UEFI secure boot” as synonyms. They are not.
Thanks for pointing that out. Since I have not spent time on it, would you be able to explain what the differences are?
UEFI is an attempt to define a modern standard firmware platform. It existed before Secure Boot was invented. Think of it as BIOS 2.0. There are lots of good reasons to come up with a new firmware standard – in fact, come up with a formal firmware standard period, as BIOS was never officially codified anywhere – none of which have to do with boot chain integrity in particular.
Secure Boot is a mechanism for doing cryptographic signature-based verification of a boot chain. It’s a single effectively optional part of the UEFI specification, added in v2.2. It was put into the UEFI specification because, well, where else do you put a system for doing boot chain verification besides the firmware? But it’s just one little bit of UEFI, and very detachable from the rest of it: there are many UEFI implementations out there from before Secure Boot ever existed (I’m typing this on one), you could still write a firmware that implemented all of UEFI except Secure Boot and things would mostly work with it just fine, and the things about Secure Boot that people tend to find objectionable aren’t actually part of the SB specification itself at all (they’re more at the level of real-world pre-loaded implementations of SB). All the SB spec itself does is define a mechanism whereby the firmware can execute or not execute code based on whether it’s cryptographically signed with a trusted key (the actual keys to be trusted aren’t a part of the SB spec at all).
To blow my own trumpet a bit – you might want to link to https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ (a blog post of mine) and https://fedoraproject.org/wiki/Unified_Extensible_Firmware_Interface (a blog post I wrote) to provide a bit of a ‘user’s eye view’ of UEFI and Secure Boot. The latter is rather more up to date than the Fedora 18-era documentation you linked, that’s a bit behind the times.
Thanks, Adam for the post. Like I noted in an earlier reply, I’ve not been tracking this and left it till the time I had to deal with it. And, thanks also for the excellent work you’ve done (and continue to do) in this space.