Mint 16: IF you are having problems with x64 UEFI install

[gcvsa]

I've installed Mint 16 x64 on UEFI a few times now, both to an internal SSD and to a USB 3.0 stick. I have a brand-new system that consists of an Intel DH87RL motherboard. I am beginning to suspect that there are some bugs in the x64 installer that do not deal properly with UEFI machines. The installer reports that it finished, but upon reboot, the system fails to boot.

If you are having problems, go down this list and make sure you have everything.

1. You MUST have a GPT formatted disk.
2. You disk MUST have an EFI System Partition, and it MUST be formatted FAT32
3. The UUID of your EFI System Partition MUST be "70D6-1701" (I don't know why this is, can someone else explain it?). This seems to be a bug in the various Linux utilities that they will set the UUID of the EFI System Partition to SomethingElse, and I have yet to find a Linux utility that will allow me to change the UUID of a disk (again, help would be appreciated with this).
4. The /etc/fstab of your installed system MUST refer to your EFI System Partition with the UUID "70D6-1701", and mount it at /boot/efi

I have found that the easiest way to accomplish this is to format my disk under Mac OS X, since I happen to have a MacBook available. I have tried using Linux disk utilities to do this, but something always goes wrong. Apple has been using EFI sine the earliest Power Macintosh systems hit the market in the 90's, and obviously has used EFI since Day One of switching to Intel, so I figure Apple probably has a bit more expertise with EFI thatn everyone else.

After formatting my disk on the Mac, then running the live USB installer, selecting "Something Else", and specifying the EFI System Partition, my root partition (I don't do swap partitions), and telling it to put the bootloader on the EFI System Partition (which after much research seems to be the correct way to do it), I have found that the Mint Installer doesn't always copy the bootloader files to the EFI System Partition.

Fortunately, my DH87RL motherboard has a built-in UEFI shell, so I can drop to the shell and diagnose this problem. Int eh UEFI shell, you should see fs0: as your EFI System Partition. On this drive should be a folder called "EFI". In there, there should be a folder named "BOOT", and a folder called "ubuntu". I say, "should", because in the several times I have done this install, only ONE TIME has the Mint Installer actually copied these files to the correct location on the correct disk. (Yes, the new system also has an HDD with Windows 7 x64 on it. This machine is going to my mom and the niblings for Xmas.). If you have previously installed Windows x64 on this disk, you may also see "EFI\Microsoft".

In "EFI\ubuntu", there should be a bunch of files: "shimx64.efi", "bootx64.efi", "MokManager.efi", and "grub.cfg". The "grub.cfg" file MUST have the UUID of your root partition in it.

IF your installer didn't function correctly, you will find these files under "/boot/efi" on your newly installed root partition. You will need to copy them to the EFI System Partition. IF you installed from the Live USB, you should have a bootable system to do this.

Once you have all of this the way it's supposed to be, you *should* have a working system. Now you can boot it up, and fiddle with GRUB2 to get it to recognise your Windows installation, too.

[IF your motherboard's BIOS is wonky, like mine is with the Intel DH87RL v322, you may need to copy "bootx64.efi" to "fs0:\EFI\BOOT\BOOTX64.EFI". You're not *supposed* to have to do this according to the UEFI standard, but the DH87RL BIOS is buggy, and the only way it will recognise an HDD as bootable is if it sees that file. Also, on the DH87RL, you have to leave legacy boot enabled, or it doesn't work, and your PCIe video card will also not work, and you will tear you hair out for hours trying to figure out why...but that's another story.]

[srs5694]

3. The UUID of your EFI System Partition MUST be "70D6-1701" (I don't know why this is, can someone else explain it?). This seems to be a bug in the various Linux utilities that they will set the UUID of the EFI System Partition to SomethingElse

This is the first time I've heard of this bug. If you've identified it correctly, my guess is that it's a new bug in Mint 16, or conceivably in your firmware. Certainly Mint 15 did not suffer from this problem. Note that the bug is not that the value is being set incorrectly; it's that something in Mint is insisting on a certain arbitrary value. There's nothing in the EFI specification that says that the ESP must have a certain serial number.

Incidentally, FAT filesystems don't have true [url=http://en.wikipedia.org/wiki/Universally_unique_identifier]Universally Unique Identifiers (UUIDs).[/url] They've got 4-byte (32-bit) serial numbers (aka "volume IDs" or various other terms), but UUIDs are 16-byte (128-bit) numbers. The confusion arises because various Linux tools, such as the mount command and the /etc/fstab file, use "UUID" as an identifier for filesystem serial numbers, as in "mount UUID=db68b99f-7a2e-4b6b-ac70-e75d637ccd93 /mnt/something". This is accurate for all current Linux filesystems, which use UUIDs as serial numbers; but for FAT, NTFS, and perhaps some others, the same "UUID=" notation is used with non-UUID serial numbers. This distinction isn't critical for using the commands that use "UUID" notation, but it can be if you need to draw inferences or if you read something about UUIDs that is not true of a FAT serial number. Understanding this difference can also help with your next issue....

I have yet to find a Linux utility that will allow me to change the UUID of a disk (again, help would be appreciated with this).

I don't know of a Linux utility that will change the serial number of a FAT filesystem; however, the standard mkdosfs (aka mkfs.msdos, mkfs.fat, or mkfs.vfat) can create a new FAT filesystem with any serial number you like. Specifically, you'd use the "-i" option, as in:

Code: Select all

sudo mkdosfs -i AABBCCDD /dev/sdf1

This creates a new FAT filesystem on /dev/sdf1 with a hexadecimal serial number of AABB-CCDD. Note that this will wipe out any existing data on the partition. Note that the man page for mkdosfs doesn't refer to UUIDs; it describes "-i" as setting the "volume ID."

It is possible to change the UUID of an ext2/3/4 filesystem by using the tune2fs program and its "-U" option. This won't help you with your ESP issues, though.

[IF your motherboard's BIOS is wonky, like mine is with the Intel DH87RL v322, you may need to copy "bootx64.efi" to "fs0:\EFI\BOOT\BOOTX64.EFI". You're not *supposed* to have to do this according to the UEFI standard, but the DH87RL BIOS is buggy, and the only way it will recognise an HDD as bootable is if it sees that file. Also, on the DH87RL, you have to leave legacy boot enabled, or it doesn't work, and your PCIe video card will also not work, and you will tear you hair out for hours trying to figure out why...but that's another story.]

Generally speaking, if you've got a plug-in video card, you must either enable BIOS/CSM/legacy support in the firmware or the card must explicitly support EFI. The reason is that video cards have always had their own firmware, which works in conjunction with the motherboard's firmware. Thus, if the video card's firmware is BIOS-only, the motherboard's firmware must also support BIOS -- either because it is a traditional BIOS or because it's an EFI with BIOS/CSM/legacy support enabled. Using a BIOS-only video card in an EFI computer without that support is like trying to run an electric Tesla car on gasoline -- you could do it, but only with the help of a gas-powered generator (analogous to the EFI's CSM). I agree this can be a hair-pulling experience if you're not expecting it, but at least the reason is pretty straightforward.

[calgrainger90]

i made sure i had every thing listed down right and proper it installs until its time for grub2 and then you get an error about grub2 not being able to install under efi and without the bootloader the system is unbootable. the only solution was to install under legacy.