[MULTI BOOT] My Positive [Believe It Or Not] EFI/Dual-Boot Experience

[GKNByNW]

Since the prices on 4TB drives have started to come down ($125+shipping on Newegg as of this writing) I decided it was time to start looking into converting my system from MBR over to a UEFI/GPT-based setup. I've read through a LOT of information here on these forums, as well as other places and, being computer-savvy (I've been working with computers in one way or another for over 25 years), I decided to make a go of it so that I would know what I was doing when the time came to add a 4TB drive or two to my PC. I am no stranger to PCs or to installing operating systems, but UEFI was (and still is) something completely new to me. I had very few issues and none that I could not overcome, but since it seems like UEFI is still a major headache for many I thought I would share my experiences here. This is in NO way meant to be any definitive, final guide or tutorial, though I have done my best to be as detailed as possible in describing the steps I took. This is simply me documenting how I went about getting things done. Many of the things I talk about are plainly obvious facts to a lot of folks, but to me a lot of them are things I learned as I went along so I included them in the write-up. If someone else can learn a thing or two from what I did then that makes it all the better. And finally, I am NO expert on UEFI and I still have a LOT to learn but I am more than happy to answer any questions that I can.

First things first, here are the basics of the system I used during my experimenting:

Intel DP55KG Extreme Series motherboard
Intel i5-760 (first-generation) quad-core CPU @ 2.80GHz
12GB (3x4GB) DDR3
MSI GeForce 210 graphics card
ThinkPenguin TPE-N300PCIE4 Wi-Fi card
LG dual-layer "Super Multi Blue" BD burner
320GB Seagate platter drive
Win7 Ultimate SP1 - disc ISO obtained from Digital River (before M!cr0$oft stopped allowing them to host the Windows ISO files)
Kubuntu 14.04LTS 64-bit "standard" installation disc

I have not been able to find out which version of UEFI my mobo has, but a couple things are worth mentioning. First, nowhere in my BIOS can be found an option to enable/disable Secure Boot. I can only assume this is because, due to the age of my mobo, Secure Boot simply didn't exist or didn't exist in its current implementation when Intel was still manufacturing this board. The other thing worth mentioning is that I have not found an actual command line EFI Shell. During the install processes I ran into boot menu entries referencing EFI Shell (see below) but I've not found any way to access the EFI command line.

The drive used for this test was given a 1-pass erase with Active KillDisk to wipe out any info left from previous uses. Before beginning anything, all of my other internal and external HDDs were disconnected so as to avoid any complications or confusion. Once the blank drive was plugged in I was ready to go.

My first step was to set my BIOS to boot in UEFI mode. I believe I have read somewhere that SATA operation needs to be set to IDE/Legacy mode but I was able to have a working install with my controller left in AHCI mode. With AHCI mode set, however, the BIOS shows "No Boot Drive" on the boot order selection screen. Hitting [F10] during startup for the boot selection also shows no available boot devices. However, booting up with my Win7 disc in the drive showed the following entry in my [F10] Boot Option Menu:

[Internal EFI Shell--CDROM]

which I of course selected, and then the real work began.

A moment after pressing "any key to boot from CD or DVD" the language and locale selection screen popped up. I hit [Shift]+[F10] to open a command prompt, where I entered the following commands:

diskpart      - to open the Windows CLI-based partition utility
list disk     - to list the available disk(s) and what Disk # they are
select disk   - to select the appropriate disk (disk 0 in my case, but dependent on your specific setup
clean         - to wipe out any existing partitions even though the HDD had been Active KillDisk-ed and the MBR wiped with Super FDisk
convert gpt   - to convert the disk to a GUID Partition Table instead of MBR
list disk     - to verify that the disk now has the flag for GPT marked
exit          - to close DiskPart
exit          - to close the command prompt

At this point I could have continued on with the installation but, wanting to double-check everything, I rebooted and once again selected "[Internal EFI Shell--CDROM]" from the [F10] boot menu. Again I opened a command prompt and did a "list disk" in DiskPart to verify that the HDD was indeed now showing as a GPT disk after reboot. I exited DiskPart and the CLI and continued with the install, where I opted for a custom install.

The next screen was the disk selection/partitioning screen, which showed Disk 0 as empty and having no partitions. At the bottom of the window was a yellow warning triangle and "Windows cannot be installed to this disk. (Show details)". The details stated that "Windows cannot be installed to this disk. The computer's hardware may not support booting to this disk. Ensure that the disk controller is enabled in the computer's BIOS menu." This warning was due to my SATA operation being set to AHCI mode. In the previous trial runs that led up to this write-up, the warning message did not appear when I had my SATA set to IDE mode.

Clicking "Drive options (Advanced)" brings up the basic partition creation buttons. I cilcked "New" and opted for a 102400MB (100GB) partition - just an arbitrary number - clicked "Apply" and then "OK" in the standard notice about how Windows might create additional partitions. The end result was 3 partitions and the leftover unallocated space:

Name                       Total Size    Free Space              Type
Disk 0 Partition 1            100.0MB        95.0MB            System
Disk 0 Partition 2            128.0MB       128.0MB    MSR (Reserved)
Disk 0 Partition 3             99.8GB        99.8GB           Primary
Disk 0 Unallocated Space      198.1GB       198.1GB

I've read elsewhere on these forums recommendations that the EFI partition be 512MB but I decided to leave everything at the defaults since I'm only going to be installing one other OS (Kubuntu 14.04). Despite the continued warning that Windows cannot be installed, selecting Partition 3 and clicking the "Next" button began the install process. I'll not go into further details since everything after this point is subjective (user name, password, network, etc.) but the installation completed properly and without issue. I now had a PC that UEFI-booted into Win7.

Upon completion of the install, rebooting into the BIOS still showed "No Boot Drive" in the boot order tab. Of course that's because, now than an OS has been installed, the UEFI would be handling the boot order. With the Win7 install disc removed, the [F10] Boot Option Menu now showed two options:

Windows Boot Manager
[Internal EFI Shell--Hard Drive]

Choosing either one of these options loaded Windows. Although not necessary for my testing, I took the time to install my chipset, LAN, and graphics drivers, and to install all available Windows updates. Essentially, I had a complete Win7 installation that, with the exception of the few add-on programs I use, now mirrored my previous MBR installation. Win7 was good to go so it was time to move on to installing Kubuntu.

Since this is a Kubuntu forum I am going to assume that most of us here are familiar with installing Kubuntu. As such, I'll try to be a bit less in-depth than I was in explaining how I installed Win7.

Powering up with the "standard" (as opposed to Server, Alternate/OEM, etc.) Kubuntu 14.04 disc and bringing up the [F10] boot menu showed the following:

Windows Boot Manager
[Internal EFI Shell--Hard Drive]
[Internal EFI Shell--CDROM]

because the Kubuntu disc contains EFI boot code. One thing that immediately caught my attention was that, unlike loading the disc in legacy MBR mode, running it as EFI opened a GRUB menu:

Start Kubuntu
OEM install (for manufacturers)
Check disc for defects

After selecting "Start Kubuntu" and then "Install Kubuntu" from the Welcome screen, I logged into my Wi-Fi router and opted to install the third-party software as well as download updates during the install. The updates and third-party software are subjective, of course, but I do prefer to install them. For Installation Type I chose Manual because I certainly didn't want to wipe out the Win7 that I just got done installing. Using the free space at the end of /dev/sda I set up my / and swap partitions to my liking. I left the bootloader device at its default of /dev/sda and started the install. From here on out the entire process was exactly the same as it is on a BIOS/MBR system, and I followed it through to the final disc eject and reboot.

This time around my [F10] menu had "ubuntu" above the two previous entries. Selecting that brought up GRUB, which shows the standard options. Trying out the different entries in both GRUB and the EFI boot manager gave the expected results. I could find no discernable difference between loading the Windows Boot Manager from GRUB or from the [F10] menu.

As with Win7, I installed all available updates and a few basic extras that I include in my Kubuntu setups. A look at the list of installed packages did indeed show the EFI version of GRUB (grub-common, grub-efi-amd64, grub-efi-amd64-bin, and grub-efi-amd64-signed) and not the grub-pc package. On my other dual-boot PCs I use BURG, installed via Super Boot Manager, because I like the nice-looking, themeable boot menu. I was a little dismayed to discover that BURG is only available for MBR systems. In other articles here on Kubuntu Forums I have seen many mentions of rEFInd so I might give that a go just for the sake of learning something new. But for now I am content to leave well enough alone and end the day with the knowledge that, on my particular system anyway, I can easily set up a dual-boot EFI configuration for when the time comes to add storage larger than 2TB in size.


NOTES:
1. In the meanwhile since I wrote this all up, I did some further reading regarding the EFI shell. Unless I am mistaken, the EFI shell is something I have to install myself. While I know there are users out there who do, I can't see myself needing an EFI shell. As of this point I have still not installed one though I probably will at some point in the future just so I can learn how.

2. In my previous runs with the SATA controller set to IDE mode, the [F10] Boot Option Menu showed the "[Internal EFI Shell--CDROM]" as well as my optical drive and HDD. Selecting the EFI Shell option loaded the installer in EFI mode but simply choosing my Bluray drive ran the installer in "regular" mode and would not allow Windows to be installed as a UEFI operating system even though the UEFI Boot was enabled in the BIOS.

3. I've discovered through trial and error that with the BIOS showing "No Boot Drive", only discs with EFI boot code (i.e. the Win7 & Kubuntu install discs) will load. I had a minor issue with my HDD and had to temporarily switch SATA operation to IDE mode in order to load the CD with my testing software. I believe there is a way to use the EFI shell to add optical drives to the boot menu but, as stated in the main text and Note #1, I currently do not have an EFI shell available to me.

[Qqmike]

Nice write-up, good job. Thanks. I would call this an "expert" installation, as you've done it.

Just a few thoughts I had as I read through your excellent write-up.

First, nowhere in my BIOS can be found an option to enable/disable Secure Boot

I believe you. No motherboard manual (on line)? Call the maker? See Rod Smith? -->
http://www.rodsbooks.com/refind/secureboot.html

I have not found an actual command line EFI Shell ... I did some further reading regarding the EFI shell. Unless I am mistaken, the EFI shell is something I have to install myself. While I know there are users out there who do, I can't see myself needing an EFI shell.

You shouldn't need it. I have never used it and don't know how (except for one command (Shell> bcfg boot dump -v -b)). SteveRiley is a big fan of the EFI shell. It is mostly for expert use. Most of us will only use the efibootmgr command (see man efibootmgr).

DiskPart (command line) -- you can also use the graphical GParted Live CD/USB to create the GPT and make new partitions.

I've read elsewhere on these forums recommendations that the EFI partition be 512MB but I decided to leave everything at the defaults since I'm only going to be installing one other OS (Kubuntu 14.04).

Yes, 512 MB--mainly if you plan to store a bunch of kernel files in the ESP, and for possible future changes/use. For most people, 100 MB should be plenty for storing the usual bootloader files only.

One thing that immediately caught my attention was that, unlike loading the disc in legacy MBR mode, running it as EFI opened a GRUB menu: ...

Yes, exactly, can confirm that here.

Installing Kubuntu, Manual method,

I left the bootloader device at its default of /dev/sda and started the install.

Yes, and it won't matter anyway, no matter what you choose here: since it is a UEFI installation, the GRUB2-EFI files will go into the ESP that Windows already set up (partition 1).

Regarding your Note 2: Your observations are correct.

Note 3: I believe there is a way to use the EFI shell to add optical drives to the boot menu but, as stated in the main text and Note #1, I currently do not have an EFI shell available to me.

Rod Smith shows you how to use efibootmgr to add entries to your UEFI firmware (to register entries with the firmware--NVRAM variables); no need for the EFI shell.

rEFInd is neat, a life-saver sometimes when booting goes crazy. Easy, quick to install, my experience was
https://www.kubuntuforums.net/showth...l=1#post372221

It will work alongside GRUB and the Windows boot loaders, you can place it as #1 in BootOrder or not (see man efibootmgr with the -o option, examples at the end of that man page).

Finally, you might play with--maybe you have already done so--issuing the command
sudo efibootmgr
and
sudo efibootmgr -v
to see your NVRAM variables and boot order (BootOrder).


Again, nice job.

[Qqmike]

Btw, if you install rEFInd, you have an option on it (when you re-boot) to open an EFI shell. Or install the EFI shell yourself on your own system -- SteveRiley tells how somewhere on this kubuntuforum. But, as I said, you really don't need it unless you go into some fairly expert work. Most of us simply use (sudo) efibootmgr.

[GKNByNW]

Thanks for the kind reply and all the additional information, Qqmike. I had not heard of the efibootmgr command until now but I will definitely play around with it in the future. I have since reconnected my original drives and disable UEFI boot so that everything is back to the way it was before I did all this. In my case, that's the beauty of having extra hardware (HDD, extra PCs, etc.) laying around. It allows me to play around with things and learn what I can, then at the end of the day things can be put back the way they were literally in a matter of seconds.

I have a long way to go, and I'm fully aware that every system is different. So far I have not had any customers bring me UEFI systems to work on, but I know that day is coming soon. For me, the best thing I can do is read, read, read, experiment, and then read, read some more :P LOL I know I don't post much here on KF but I've spent plenty of time reading and there's still so much more I can glean from here as well as the rest of the web.

[Qqmike]

You probably already came across my two how-to's:

The Study Guide -- which has tons of references,
https://www.kubuntuforums.net/showth...l=1#post346604

UEFI for Kubuntu -- simplified, and dual-booting tips,
https://www.kubuntuforums.net/showth...l=1#post373198

And THE current expert on ALL of it--UEFI, GPT, rEFInd, gdisk--is Rod Smith (again, as you may know),
http://www.rodsbooks.com/
(Scroll down to "My Web Pages," and see all the (U)EFI pages he has listed (that he wrote).
Rod Smith also wrote rEFInd and the gdisk utility (which you should also get and learn about: gdisk is fdisk for GPT disks), and he has guides on gdisk on his web site(s).)

(run gdisk as sudo gdisk, btw.)

[GKNByNW]

Nice write-up, good job. Thanks. I would call this an "expert" installation, as you've done it.

Well, at the risk of tooting my own horn, I am far from a novice when it comes to PCs

No motherboard manual (on line)?

There's no mention in any of my documentation of Secure Boot and barely any mention of UEFI, either. Intel produced the DP55KG some time around 2009 and official support ended in 2012. I picked it up last year at a steal so I decided to build a system around it. UEFI was still relatively unheard of during that time period.

You shouldn't need it.

That's as I suspected, and is why I wasn't going to play around with it at this time.

DiskPart (command line) -- you can also use the graphical GParted Live CD/USB to create the GPT and make new partitions.

I do use GParted quite a bit but, for the sake of my experimenting, I wanted to see how the Windows installation handled creating the ESP & MSR partitions.

Rod Smith shows you how to use efibootmgr to add entries to your UEFI firmware (to register entries with the firmware--NVRAM variables); no need for the EFI shell.

Thanks for the tip. In reality, there's really no performance gains to be had from using AHCI over Legacy/IDE mode, so for ease of use in the future I will probably stick with IDE mode.

rEFInd is neat, a life-saver sometimes when booting goes crazy. Easy, quick to install, my experience was
https://www.kubuntuforums.net/showth...l=1#post372221

It will work alongside GRUB and the Windows boot loaders, you can place it as #1 in BootOrder or not (see man efibootmgr with the -o option, examples at the end of that man page).

Finally, you might play with--maybe you have already done so--issuing the command
sudo efibootmgr
and
sudo efibootmgr -v
to see your NVRAM variables and boot order (BootOrder).


Again, nice job.

Thanks again for the additional info. I will definitely be doing some more reading at the links you provided.

[Qqmike]

This is worth mentioning: you can put rEFInd on a live CD and play with it that way -- you can boot OSs (on your HDDs) using it on a CD; or have a look at the EFI shell (which I believe is on that CD); Rod Smith also tells how to put rEFInd on a USB flash drive. My experience w/CD was

rEFInd: Make a live CD to boot into your system

https://www.kubuntuforums.net/showth...l=1#post376838

[Qqmike]

Dual-booting, a summary of options (for UEFI),
https://www.kubuntuforums.net/showth...l=1#post376269

A new PC build with Kubuntu only (UEFI motherboard),
https://www.kubuntuforums.net/showth...l=1#post368216

[GKNByNW]

I went ahead and installed rEFInd on my test system and it was a piece of cake, no problem at all & works beautifully. rEFInd shows two Kubuntu entries, one for GRUB and one for the vmlinux image. I'm sure this is obvious to a more advanced *buntu user, but how do I remove GRUB2? I did a "sudo apt-get remove grub-common" followed by "sudo apt-get purge grub-common" but I still seem to have GRUB installed. Running "dpkg -l *grub*" outputs this:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
un  grub           <none>       <none>       (no description available)
un  grub-common    <none>       <none>       (no description available)
un  grub-coreboot  <none>       <none>       (no description available)
rc  grub-efi-amd64 2.02~beta2-9 amd64        GRand Unified Bootloader, version
un  grub-efi-amd64 <none>       <none>       (no description available)
un  grub-efi-ia32  <none>       <none>       (no description available)
un  grub-ieee1275  <none>       <none>       (no description available)
un  grub-legacy    <none>       <none>       (no description available)
un  grub-pc        <none>       <none>       (no description available)
un  grub-xen       <none>       <none>       (no description available)
un  grub2          <none>       <none>       (no description available)
un  grub2-common   <none>       <none>       (no description available)

and I while I DON'T have anything for GRUB in my /boot/efi/EFI/ I do still have the /boot/grub/ folder.

As long as rEFInd is working, I see no need to have two Linux bootmanagers cluttering things up. Perhaps a better question might be is there any way to install Kubuntu without installing GRUB at all? I thought perhaps the Alternate Install disc might have that option but I haven't checked to see.

[Qqmike]

Have a look at these:

https://www.kubuntuforums.net/showth...l=1#post309652

https://www.kubuntuforums.net/showth...l=1#post371932

http://askubuntu.com/questions/77920...b-and-plymouth

[oshunluvr]

Quote from Steve Riley on the subject

Once you get familiar with rEFInd, you can purge all the GRUB related packages, remove GRUB's subdirectory in the ESP, and delete its NVRAM variable.

[GKNByNW]

Quote from Steve Riley on the subject

Thanks for the replies. This is only a test system that I am playing around with, so anything I do here won't affect my day-to-day computing. It looks like rEFInd works well with the system at hand, so my idea was to remove GRUB2 completely, or - ideally - being able to install Kubuntu without install GRUB2 at all. To my line of thinking, not installing GRUB2 at all makes more sense than installing it only to turn around and uninstall it after the fact. Google-ing "remove GRUB2" (or variants thereof) and "install Kubuntu without installing GRUB" kept pointing me to articles on how to install or reinstall GRUB, but I did find one piece of information that I'm going to try. Short of downloading the Alternate Install disc, it looks like if I run the regular LiveCD and issue the following from a Terminal:

ubiquity --no-bootloader

then I can accomplish what I am asking. Of course I still need a way to boot my Kubuntu installation so that I can install rEFInd, but I'm going to try the rEFInd LiveCD and see how that works out for me.

[Qqmike]

ubiquity --no-bootloader

That's what I've heard, but have never tried it.

I'm going to try the rEFInd LiveCD and see how that works out for me.

The live rEFInd will get you booted into your Kubuntu -- it will do so by showing you the kernel to boot, the specific vmlinuz-etc. to boot. If in doubt, just keep guessing, booting, and re-booting until you pick the right choice from the rEFInd menu -- you can't damage anything.

[oshunluvr]

I have tried it and it does work. I'm still using GRUB at this point, so I don't know how the --no-bootloader option might effect EFI installation but I doubt you'll have any problem.

I did just order a new server so I'll be mucking about with EFI soon enough...

[Qqmike]

So you can purge GRUB2-EFI (see Muon Package Manager for the exact package name(s); even if you use sudo apt-get purge < ... >). That may leave the config file /boot/grub/grub.cfg, which you can delete. In particular, the stuff in /usr/lib/grub (i.e., the master GRUB files) should be purged by doing this. OK.

If you go GRUB-less without using rEFInd, then it's a bit more complicated, using this and the Kato link therein:

https://www.kubuntuforums.net/showth...l=1#post309652

If you go GRUB-less, and you use rEFInd, then it looks a lot simpler. I haven't thought through all the details--maybe I will experiment with this, time permitting--but it seems straightforward as rEFInd can always boot by the stub-loader way, and you can place rEFInd as #1 in BootOrder (using efibootmgr). As for details, what embellishments could one play with to make it more complicated or elaborate? I see no need to place the kernels or initrds in the /EFI/refind, for example. You can always play with the rEFInd config menu to rig up boot options having nice names. But, bottom-line, it looks like rEFInd could simply do its thing with the plain vmlinuz names (of course, the user must be able to identify the vmlinuz-XYZ and associate it with an OS). Also, making it easier, rEFInd will boot by default the last booted OS.