If I set the file system at FAT32, will install of Kubuntu be UEFI compatible?

[Shabakthanai]

**

gdisk can read MBR partition tables just fine. You can ignore the scary warning about "converting MBR to GPT" because the command format I gave you doesn't actually write anything to disk.

The reason I had you run both fdisk and gdisk is because fdisk can't read GPT partition tables. Because your fdisk output showed real partitions, running gdisk is superfluous. But because I didn't know ahead of time, I asked you to run both.

Let's say that you actually did have GPT disks. Remember that fdisk doesn't understand these. You would have seen something like this:

steve@t520:~$ [B]sudo fdisk -l /dev/sda[/B]

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sda: 256.1 GB, 256060514304 bytes
255 heads, 63 sectors/track, 31130 cylinders, total 500118192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1   500118191   250059095+  ee  GPT

fdisk throws up its hands and says, "I don't understand!" But it knows at least enough to tell us that the disk has a GPT partition table.

But in your case, since all of your disks are MBR, fdisk can display what we need to know.

Thanks Steve, I am going to relax a bit and wait to see if Kubuntu developers resolve the UEFI issues that seem to be hamstringing me. Best regards. Steven aka. Shabakthanai

[Qqmike]

Post #2 is excellent, Steve.

This:

A computer that comes from the manufacturer with Windows installed will typically already have:

• An EFI system partition formatted as FAT-32
• The small 100 MB (usually) unlabeled NTFS partition
• A manufacturer recovery partition at the very end of the drive's space
• The remainder of the space as one single NTFS partition, labeled C:

Take the case not of dual boot, but rather erasing Windows completely and installing Kubuntu. To do that, use, say, GParted to reformat the "one single NTFS partition, labeled C:" as, say ext4, then simply install Kubuntu to that ext4 partition, and install GRUB 2 to that drive (assuming you are using GRUB 2). Is that correct? I mean, there are no other hidden Window demons on that drive that should be a problem? Just leave everything else as is, including the 100 MB partition, or delete it, too? Of course, keep the ESP partition. Right? I assume ...please check me on this ... that when the Kubuntu installer installs GRUB 2, that GRUB 2 (or the installer, both being GPT-aware) will know to put GRUB 2 into the ESP, correct? And the UEFI then will take it from there automatically and make it all boot and run.

[Feathers McGraw]

If you want to erase windows completely, why wouldn't you just use ubiquity to remove windows? That way you just start fresh and the installer creates/formats the necessary partitions. I think the option is called something like "completely remove windows and install kubuntu", no need to even open the advanced options.

[Qqmike]

Yes, perhaps that's one way. But I do prefer selecting the "manual" option for setting up the partitions in the installer.

[Feathers McGraw]

Fair enough! Wouldn't that leave you with loads of junk partitions, though?

[Qqmike]

Actually, what I always do is to never trust the installer to do my partitioning! Call it chicken-stupidstition.
I first run the graphical GParted live CD, do all the partitioning, set all the tags etc., then install Kubuntu from its live CD. Fact is, with UEFI-GPT, I have no experience, am not even sure what the menus look like when they encounter their various types & tags. But that's precisely why I'm studying this stuff at the moment :-)

[Feathers McGraw]

Sure, I can see that it's a great way to learn stuff. I don't know if you've ever used a RasPi, but I learned some interesting things about MBR and GPT whilst tinkering.

I wanted to move the root filesystem to a USB drive instead of using an SD card, to speed things up (read speeds are better for USB than for SD cards). However, the RasPi bootloader doesn't understand UUID so I had to convert the USB drive's partition table to GPT and use GUID to tell the bootloader where the root filesystem was during the boot process.

http://www.samhobbs.co.uk/2013/10/sp...b-flash-drive/

Interesting where small problems like that lead you!

[Qqmike]

Somehow, this discussion raises another question for me. Suppose you install Kubuntu onto a GPT disk, and you want Kubuntu to boot by UEFI (and not by BIOS or CSM). If you boot the install disk (to install Kubuntu), you must boot the PC by UEFI; otherwise, after installing Kubuntu, it probably wouldn't boot by UEFI. Correct? (anyone...)

[Feathers McGraw]

Not quite sure what you mean, but the stuff I posted earlier was specific to the RasPi bootloader... I don't want to imply that it applies to Kubuntu too! The RasPi bootloader is pretty primitive compared to GRUB/rEFInd.

[Qqmike]

I think the answer to my question in Post #23, "Correct?" is Yes, that is correct.

[SteveRiley]

Post #2 is excellent, Steve.

Thank you.

Take the case not of dual boot, but rather erasing Windows completely and installing Kubuntu.

In this case, make your life easy: don't worry about preserving anything. Instead:

1. Boot the computer with a GParted Live or Partition Magic USB.
2. Delete the existing partition table.
3. Create a new partition table.
4. Create a 512 MB FAT-32 partition; this will become the EFI system partition.
5. Create however many EXT4 partitions you want.
6. Create a swap partition if you wish.
7. Save the partition table and exit the tool.

Now, reboot the computer with the Kubuntu and proceed with installation.

Actually, what I always do is to never trust the installer to do my partitioning! Call it chicken-stupidstition.

Your mistrust is placed well. Ubiquity is not good at this.

[SteveRiley]

Somehow, this discussion raises another question for me. Suppose you install Kubuntu onto a GPT disk, and you want Kubuntu to boot by UEFI (and not by BIOS or CSM). If you boot the install disk (to install Kubuntu), you must boot the PC by UEFI; otherwise, after installing Kubuntu, it probably wouldn't boot by UEFI. Correct? (anyone...)

Installing to GPT isn't enough -- you need to boot the installer in UEFI mode.

[Qqmike]

Thanks S-R. That is my cup of tea, for sure (erase completely).

But then, for people who might want to retain the OEM "recovery" partitions (that restore the HDD to factory status, like Lenovo's OneStep or ASUS' recovery), what then? You wish to get rid of Windows (at least for now) but (assume that) you do not wish to get rid of all those recovery partitions set by the OEM? So if you mess with the existing EFI System Partition, you are also messing with those recovery partition pointers (in the GPT) if you delete the GPT and rebuild it. You can delete the Windows C: partition, and its small 100 MB partition, but you would still have Windows loaders in the (old) ESP. (I recently saw a Lenovo G510s come with 6 partitions, including Windows and various recovery partitions, plus ESP.)

[SteveRiley]

Part of the challenge would be to correctly identify which are the recovery partitions. Once you've done that, you could save those and the EFI system partition while deleting the others; in this case, you won't be deleting the partition table of course. Once you've done that, then you can partition the newly freed up space however you'd like.

There is also the need to clean up the UEFI NVRAM variables accordingly, too. Most likely, you'd delete the variable that boots Windows and save the others.

[Qqmike]

About the recovery partitions ...

Examples of OEM partitioning:

Lenovo - G500s
diskmgmt.msc
Under Volume, there are 6 entries:
1000 MB Recovery Partition
260 MB EFI System Partition
1000 MB OEM Partition
892 GB Windows_8OS C: NTSF Primary Partition
25 GB Lenovo D: NTSF Primary Partition
11 GB Recovery Partition

Asus Q501LA-BSI5T19
diskmgmt.msc
Under Volume, there are 4 entries:
100 MB EFI System Partition
900 MB Recovery Partition
677 GB NTFS Windows
20 GB Recovery Partition

- - - - -

About the EFI System Partition (ESP):

I'm noticing an interesting thing about the 100 MB EFI System Partition, put there by Windows: it is only 100 MB. I'm not sure what it should be; but my sense is that if there are several bootloaders, maybe 200 MB would be better. But how would you safely expand it to 200 MB? taking a chance of disturbing the NTFS Windows partition.

Rod Smith says, http://www.rodsbooks.com/efi-bootloa...rinciples.html :

"Although the EFI specification is mute on the subject of the ESP's size, most OSes make it fairly small—Macs ship with 200MiB ESPs, and the Windows installer creates one of just 100MiB. Some users, however, have found that some EFIs have bugs that cause problems with FAT32 ESPs that are under 512MiB (537MB) in size. One very common problem is files that can't be read by the EFI. The Linux mkdosfs command defaults to using FAT16 for partitions of up to 520MiB (546MB). Therefore, adding a margin of safety to protect against MiB/MB confusion and rounding errors, I recommend creating an ESP that's at least 550MiB in size. If you must use a smaller ESP and if you encounter mysterious problems, try converting it to FAT16; most ESPs will work fine with this, and it may eliminate your problems. On the other hand, this may cause the Windows installer to fail should you need to install this OS ... The ESP holds EFI drivers, EFI applications, EFI scripts, and EFI boot loaders, among other things. This range of EFI data illustrates the fact that EFI is quite complex; it's similar in many ways to DOS in power."

---> Windows gets first shot at partitioning most HDDS! At 100 MB. WTH, huh?