Dual Boot & UEFI -- another lost soul

[okie2003]

OK, thanks for all the advice. I did try to read over most of it. Some things are just learned by mistake. I found SteveRiley's comment "@okie2003: That warning you're seeing -- about the Reserved BIOS Boot Area -- appears because you're booting the installation media in BIOS compatibilty mode." made sense after I made the mistake. I did get Kubuntu installed (unfortunately in legacy mode, but the machine only sees Windows. It will still boot to Windows. But, how can I get the machine to see my USB or DVD installation media in UEFI made. I tried making a USB stick with Kubuntu's Startup Disk Creator, TuxBoot, and Unetbootin. I tried leaving off the installation of Grub in Startup Disk Creator. None work.

When I boot the machine and Press F12 (Dell's magic key) I get:
Boot Mode is set to: UEFI; Secure Boot: OFF
Legacy Boot:
Internal HDD
CD/DVD/CD-RW Drive
Onboard NIC
UEFI Boot:
Windows Boot Manager
Windows Boot Manager (no this is not a typo)
UEFI: SanDisk U3 Cruzer Micro 2.18
Other Options:
Bios SetUp
Device Configuration
Diagnostics
Change Boot Settings

The first time I did it, not fully understanding what I had read and being a creature of habit, I chose the USB option that appears under Legacy Boot when the machine is started with a USB drive inserted. Obviously wrong, but it appeared to work. My problem now is undoing that and creating an installation media that is recognized in the UEFI Boot section -- non of my various attempts have been and when I selected "UEFI: SanDisk U3 Cruzer Micro 2.18" hoping that was a USB drive option I got "invalid partition table".

[SteveRiley]

The only tool that I know of that reliably creates a bootable USB from an ISO image is good old dd.

1. Without the USB inserted, run the lsblk command. You should see a list of all drives and partitions. Here's mine:

steve@t520:~$ [B]lsblk[/B]
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238.5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
├─sda2   8:2    0   229G  0 part /home
└─sda3   8:3    0     9G  0 part [SWAP]
sdb      8:16   0 931.5G  0 disk 
└─sdb1   8:17   0 931.5G  0 part

2. Insert the USB drive.

3. Run the command again, and observe the new device name in the tree. Here's mine; the new device is /dev/sdc:

steve@t520:~$ [B]lsblk[/B]
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238.5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
├─sda2   8:2    0   229G  0 part /home
└─sda3   8:3    0     9G  0 part [SWAP]
sdb      8:16   0 931.5G  0 disk 
└─sdb1   8:17   0 931.5G  0 part
sdc      8:32   1   1.9G  0 disk 
└─sdc1   8:33   1   1.9G  0 part

4. Run the dd to transfer the ISO to the USB. This will completely overwrite everything on the drive. You will need to supply the full path and filename of the ISO to the if= parameter and the device name (not the partition name) of the USB drive to the of= parameter. Here's mine:

sudo dd if=/home/steve/ISOs/kubuntu-trusty-desktop-amd64.iso of=/dev/sdc

[SteveRiley]

Except, of course, the boot flag on the ESP, though the ESP can also be identified by type, I'm not sure how the UEFI system looks for the ESP.

From Rod Smith's page on EFI principles:

On a GPT disk, the ESP has a GUID value of C12A7328-F81F-11D2-BA4B-00A0C93EC93B, but most partitioning tools hide GUID values because they're awkward for humans to use. In GPT fdisk, ESPs are displayed as having a type code of EF00, and most libparted-based tools use a "boot flag" to identify the ESP. Note that in libparted tools, a GPT partition's "boot flag" is entirely different from a "boot flag" on an MBR disk. You should not set the "boot flag" on any OS partition under GPT, just on the ESP.

I'm pretty sure that on at least one occasion, I forgot to set the type code of the ESP to EF00, and the computer booted anyway. Sounds like something to test to confirm..

[Qqmike]

@SteveRiley, I have tested setting a boot flag in GParted Live on the ESP. It seems to work fine. In fact, it actually sets this flag: boot, esp. I've seen that GUID but not sure how to generate it afterwards to check it. (The ESP UUID is something else.)

@okie2003, I sure see lots of issues building live USBs around here. Do what SteverRiley says about dd (a favorite command at that). If I may ask, what's wrong with simply using a live DVD for the 64-bit Kubuntu installer? No DVD drive, perhaps? (Burning that DVD using k3b in Kubuntu.)

[SteveRiley]

@SteveRiley, I have tested setting a boot flag in GParted Live on the ESP. It seems to work fine. In fact, it actually sets this flag: boot, esp. I've seen that GUID but not sure how to generate it afterwards to check it. (The ESP UUID is something else.)

Your comment made me wonder if setting a the type code to EF00 would set the partition GUID (what you're calling the "ESP UUID" I suspect) to the proper value. Here's the experiment:

steve@t520:~$ [B]sudo gdisk /dev/sdc[/B]
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): [B]n[/B]    [i][COLOR="#B22222"]<--- create a new partition[/COLOR][/i]
Partition number (1-128, default 1): [b][Enter][/b]
First sector (34-3911646, default = 2048) or {+-}size{KMGTP}: [b][Enter][/b]
Last sector (2048-3911646, default = 3911646) or {+-}size{KMGTP}: [B]+100M[/B]    [i][COLOR="#B22222"]<--- 100 MB works for this test[/COLOR][/i]
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): [b][Enter][/b]    [i][COLOR="#B22222"]<--- don't set EFI System type just yet[/COLOR][/i]
Changed type of partition to 'Linux filesystem'

Command (? for help): [B]i[/B]    [i][COLOR="#B22222"]<--- show partition information[/COLOR][/i]
Using 1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)    [i][COLOR="#B22222"]<--- ah hah! looks like there are defined GUIDs for each type code[/COLOR][/i]
Partition unique GUID: 202C0B03-FE81-45A3-BA76-1FED2909A7BF
First sector: 2048 (at 1024.0 KiB)
Last sector: 206847 (at 101.0 MiB)
Partition size: 204800 sectors (100.0 MiB)
Attribute flags: 0000000000000000
Partition name: 'Linux filesystem'

Command (? for help): [B]t[/B]    [i][COLOR="#B22222"]<--- change the type[/COLOR][/i]
Using 1
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): [B]ef00[/B]    [i][COLOR="#B22222"]<--- the code for EFI system partition[/COLOR][/i]
Changed type of partition to 'EFI System'

Command (? for help): [B]i[/B]    [i][COLOR="#B22222"]<--- show info again[/COLOR][/i]
Using 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)    [i][COLOR="#B22222"]<--- and there we go, the correct GUID for EFI system[/COLOR][/i]
Partition unique GUID: 202C0B03-FE81-45A3-BA76-1FED2909A7BF
First sector: 2048 (at 1024.0 KiB)
Last sector: 206847 (at 101.0 MiB)
Partition size: 204800 sectors (100.0 MiB)
Attribute flags: 0000000000000000
Partition name: 'EFI System'

Command (? for help): [B]q[/B]

So we can conclude that:

• Memorizing GUIDs is unnecessary; tools will assign the appropriate GUID when you indictate the type code
• GPT partitions don't have "flags" like MBR partitions; some partitioning tools will reuse the "boot" flag as a way to indicate that a partition is an ESP

[Qqmike]

OK, interesting, helpful.

I was thinking about this (on my system /etc/fstab):

# /boot/efi was on /dev/sda1 during installation
UUID=74D7-02F2 /boot/efi vfat defaults 0 1


Now, running your gdisk commands on my system:

 mike@mike-desktop:~$ sudo gdisk /dev/sda
 [sudo] password for mike:  
 GPT fdisk (gdisk) version 0.8.8
 
  Partition table scan:
   MBR: protective
   BSD: not present
   APM: not present
   GPT: present
  
 Found valid GPT with protective MBR; using GPT.
  
 Command (? for help): i
 Partition number (1-4): 1
 [COLOR=#ff0000]Partition GUID code[/COLOR]: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
[COLOR=#ff0000] Partition unique GUID[/COLOR]: 0B3A3E36-B506-4F4A-9811-8549F1B5D884
 First sector: 2048 (at 1024.0 KiB)
 Last sector: 1026047 (at 501.0 MiB)
 Partition size: 1024000 sectors (500.0 MiB)
 Attribute flags: 0000000000000000
 Partition name: ''

So I see the differences (and the distinction in terminology):
UUID, Partition GUID code, and Partition unique GUID. Three different animals.
So what am I saying? I guess I expected the GUID code of the ESP to show up in my fstab, or somewhere easy to spot? I hadn't heard of partition GUID "code" before.

Of course, running
sudo gdisk -l /dev/sda
does yield what we hope/expect, but with no ESP partition GUID code:
1 2048 1026047 500.0 MiB EF00

[Qqmike]

Btw, okie2003, none of this affects you, except the dd Steve posted to get a Kubuntu USB installer.
AFTER you successfully install your Kubuntu 64-bit in UEFI mode, then you may wish to check things, running these commands (and others--see my 'New PC Build with Kubuntu only, messing with UEFI etc.' link above).

So, you have used GParted Live CD (or something like it) to set up your partitions for Kubuntu, in dual boot with Windows 7.
Now you are building a live Kubuntu USB installer to run.
Your ESP was put there already by Windows, so you can use that, no need to make another ESP partition, I assume (SteveRiley might comment on its small size ... I'm thinking it is adequate).

[SteveRiley]

So I see the differences (and the distinction in terminology):
UUID, Partition GUID code, and Partition unique GUID. Three different animals.
So what am I saying? I guess I expected the GUID code of the ESP to show up in my fstab, or somewhere easy to spot? I hadn't heard of partition GUID "code" before.

Yes, there are several instances of UUIDs here, as you've noticed.

The partition GUID code represents the type of the partition. After all, GPT = GUID partition table Wikipedia has a list of GUIDs and types.

The partition unique GUID is generated and assigned by the operating system each time you create a partition. It has no relationship to the partition GUID code. Only GPT disks have these; MBR disks do not. You can see all partition unique GUIDs this way:

ls -al /dev/disk/by-partuuid

The entry in fstab shows the filesystem unique GUID. This is generated and assigned by the operating system when you put a filesystem into a partition. It has no relationship to either the parition unique GUID or the partition GUID code. All filesystems have these, regardless of the disk type. You can see all filesystem unique GUIDs this way:

ls -al /dev/disk/by-uuid

[Qqmike]

Got it. Thanks.

[okie2003]

Qqmike & SteveRiley -- Thank you, thank you. you were so patient and helpful. When I started in Linux in 2004 I was using Mepis and the forum was helpful like you are. I have learned a lot. Some things are learned the hard way with help.

If I may ask, what's wrong with simply using a live DVD for the 64-bit Kubuntu installer? No DVD drive, perhaps? (Burning that DVD using k3b in Kubuntu.)

The truth is that again I was a creature of habit. That is the way I had done it the last few years. When I realized I had a problem I did try a DVD with a Boot-Repair ISO and it was not recognized either so I didn't try a Kubuntu DVD. When you suggested it that is what I did. It worked and I reinstalled Kubuntu using UEFI (now all those comments make sense). But if I need to install on a machine without a DVD drive I can also now do that.

Thanks again to both of you. I will try to continue to digest this thread and the others that were referenced.

[Qqmike]

It worked and I reinstalled Kubuntu using UEFI...

Do you happen to remember what that UEFI option looked like when you saw it and selected it in the PC's UEFI-BIOS setup? You may not recall it now. As I said in my "New PC..." write-up, mine looked like this:

UEFI (FAT) TSSTcorp CDDVDW SH-224DB (1028 MB) (= my Samsung DVD player).

Kind of strange huh? No mention of Kubuntu at all! Kubuntu on that DVD also showed up as something else, a second instance shown in my UEFI-BIOS setup menu, but no mention of UEFI, so that would have been the non-UEFI Kubuntu installation choice.

Congratulations on getting this. Looks like we both learned some new stuff here (for me, that GUID business cited at the end ...).

It really isn't so bad, is it? Even with Windows. From a certain point of view, this is easier and cleaner than the older BIOS methods in this sense: GPT means you get as many partitions as you wish (within reason, certainly up to 128 by default); one partition is special, the ESP, it holds the bootloaders for the PC--bootloader files for all OSs are dumped in there; no need to worry about Extended and Logical partitions--all partitions are the same (at the level of a Primary partition in the older jargon); and your PC's UEFI-BIOS access/setup shows you lots of information about what's bootable to choose from.

Glad you got it.

[okie2003]

Do you happen to remember what that UEFI option looked like when you saw it and selected it in the PC's UEFI-BIOS setup? You may not recall it now. As I said in my "New PC..." write-up, mine looked like this:

UEFI (FAT) TSSTcorp CDDVDW SH-224DB (1028 MB) (= my Samsung DVD player).

Kind of strange huh? No mention of Kubuntu at all! Kubuntu on that DVD also showed up as something else, a second instance shown in my UEFI-BIOS setup menu, but no mention of UEFI, so that would have been the non-UEFI Kubuntu installation choice.

Remember above my UEFI option before was:
UEFI Boot:
Windows Boot Manager
Windows Boot Manager (no this is not a typo)
UEFI: SanDisk U3 Cruzer Micro 2.18

I put the DVD back in and redid the process:
UEFI Boot:
ubuntu
Windows Boot Manager
Windows Boot Manager
UEFI: SanDisk U# Cruzer Micro 2.18
UEFI: HL-DT-ST DVD+/-RW GU90N

Based on what I thought I remembered you guys saying I chose the last entry and it worked. But yes, no indication it was a Kubuntu DVD. Just the hardware designation.

[SteveRiley]

Based on what I thought I remembered you guys saying I chose the last entry and it worked. But yes, no indication it was a Kubuntu DVD. Just the hardware designation.

The boot manager built into UEFI composes its list from two sources:

• NVRAM variables that point to boot loaders (interestingly, it is not required for the boot loaders to actually exist)
• Files named /EFI/boot/bootx64.efi in every discovered ESP

The last two items in your list are of the second type above.

[Qqmike]

Makes sense, all of it.

In Post #6, you said you had this partition:
100 MB Healthy, no type listed (EFI System Partition, came this way)
which we assume is your ESP partition.
At that time, you had a Windows bootloader in there. Now you also have a GRUB2 boot loader in the ESP to boot Kubuntu.

You can find out how much space is left in your ESP this way:
In Kubuntu, open Konsole (K > Application > System > Terminal/Konsole), and type
df -hT

I have just Kubuntu 14.04 on this PC, and mine says this about the ESP partition (sda1--500MiB):
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 vfat 500M 3.4M 496M 1% /boot/efi

Just 3.4 MiB used for the relevant GRUB2 files.
I'm thinking your Windows bootloader files could use 30 MB--guessing here.

[Qqmike]

Btw, if you feel this is Solved, you can mark it as SOLVED. On the first page where Post #1 is, over on the right, Thread Tools > Mark as solved. We can still continue to discuss things here. I'll bet others will be able to use this thread as many people--like you and I both--managed to avoid looking at this stuff for quite some time. I had a classical BIOS-GRUB2 system until I built this PC a couple months ago and then went straight UEFI (Asus motherboard).