This is a modified post by nerasezi in the Ubuntu Forum
The main source for the UEFI was the Ubuntu UEFI guide
The following are the steps he did:
Use a live CD which matches the UEFI architecture. Mostly x86-64.
Boot up the live cd (xubuntu or lubuntu. Those are lightweight desktop but it should work with Ubuntu and kubuntu as well).
Be sure your live system is booting in UEFI mode. You may check it on the UEFI setup, probably under Boot option or similar. In my case it just put the "UEFI" prefix before the device name.
Once the live system is running set through the terminal a root password by typing
sudo passwd root
Then log out from the default live cd user and log in as root in gui mode.
Plug in the hard drive. I use a USB3 portable HDD but in most cases the hard drive is a SATA internal drive. Anyway, be sure you've BACKED UP ALL YOUR DATA, cause the process is going to wipe off everything on the drive.
Launch Gparted (a gui tool is much easier than the text one) and select the drive you're willing to install the system into. (Be sure to select the right one!)
Point to the top menu and select Device>Create Partition Table... A warning message pops out. Click on Advanced and select "gpt". Say OK
A new GPT disk layout had been created.
Now you need to create partitions on it. It's very important that you create as the first and primary partition, a FAT32 volume and you need to assign the label EFI to it. Once the partition is created, right click on it and select "manage flags". Check the "boot" flag and say OK.
Move on to the creation of the / partition (you may want to separate /home and /boot. Do it as you usually do. In my case I've just created the / partition), and a swap area. Always prefer primary partitions cause with GPT the 4 primary partition limitation has been removed.
Close Gparted.
Install the system into the hard drive "/" partition and remember to point here the bootloader (GRUB 1.99) to install to. If you've created a separete "/boot" partition, you have to choose that one for the bootloader installation.
Here comes the part from the UEFIBooting guide:
Building GRUB2 (U)EFI
Download the latest grub2 source code ZIP file. ftp://ftp.gnu.org/gnu/grub/
Building grub2 requires the following programs to be installed (build dependencies):
bison
autoconf
automake
flex
autogen
python (2.x series) (for autogen.sh if building from bzr repo)
texinfo
help2man
gettext (NLS support)
device-mapper
freetype2 (libs)
sudo apt-get install bison libopts25 libselinux1-dev autogen m4 autoconf help2man libopts25-dev flex libfont-freetype-perl automake autotools-dev freetype2-demos texinfo efibootmgr
efibootmgr was added to the software you need to install because you will need it later on.
For 64-bit (U)EFI:
export EFI_ARCH=x86_64
./configure --with-platform=efi --target=${EFI_ARCH} --program-prefix=""
make
In case you have a 32-bit architecture, check the online documentation at the link I have provided at the top.
Install GRUB2 in (U)EFI systems
Determine your EFI SYSTEM PARTITION. (it should be /dev/sda1 or /dev/sdb1 if is set on the 2nd hd)
Then mount the partition at /mnt/EFISYS (or at any mountpoint you wish). The following code assumes /dev/sda1 to be EFISYS partition.
sudo mkdir -p /mnt/EFISYS
sudo modprobe dm-mod
sudo mount -t vfat -o rw,users /dev/sda1 /mnt/EFISYS
sudo mkdir -p /mnt/EFISYS/efi/grub
Then, build an EFI application for GRUB and copy it and the other modules:
Enter the "grub2 compiled source/grub-core" directory - Default : /usr/lib/grub/{EFI_ARCH}
grub-mkimage -O ${EFI_ARCH}-efi -d . -o grub.efi -p "" part_gpt part_msdos ntfs ntfscomp hfsplus fat ext2 normal chain boot configfile linux multiboot
sudo cp grub.efi *.mod *.lst /mnt/EFISYS/efi/grub
Note : The -p "" option is important for creating a portable grub.efi app. Now create a grub.cfg in /mnt/EFISYS/efi/grub :
sudo touch /mnt/EFISYS/efi/grub/grub.cfg
Make the firmware launch GRUB2 (U)EFI as default
For non-Mac UEFI systems, efibootmgr is used to modify the UEFI Firmware Boot Manager. This requires the kernel to be booted in UEFI mode and that the kernel processor architecture should match the firmware architecture (and 'noefi' is NOT used) for 'efivars' kernel module to be loaded and efibootmgr to access the boot manager variables. Initially the user is required to manually launch "efi/grub/grub.efi" from the firmware console itself if grub2-efi was installed in BIOS mode. Then efibootmgr should be run to create the boot entry.
sudo modprobe efivars
Enter the "grub2 compiled source/grub-core" directory
grub-probe --target=device /boot/efi/efi/grub/grub.efi
Assuming the output the grub-probe to be /dev/sda1
sudo efibootmgr --create --gpt --disk /dev/sda --part 1 --write-signature --label "GRUB2" --loader "\\EFI\\grub\\grub.efi"
In the above command, /boot/efi/efi/grub/grub/efi can be split up as /boot/efi and /efi/grub/grub.efi, which translates to (/dev/sda) -> partition 1 -> \EFI\grub\grub.efi .
Open Synaptic and remove all grub packages and install just the grub-efi packages (amd64 for me) and all the necessary dependencies.
Once the installation is over, run sudo update-grub in the terminal. You should edit "grub.cfg" from /boot/grub and check that the disk UUID matches your disk and partitions, the voice "insmod part_" and "set root='(hd0," have "gpt" textline. If everything is ok, copy "grub.cfg" to the "efi/grub" on the EFI System Partition.
If something i mentioned before, doesn't match, just edit grub.cfg and manually change them values. Then copy the file to the "efi/grub" directory on the Efi System Partition (should still be mounted under /mnt).
Then when I rebooted the system, a new entry on the Boot tab under the UEFI setup has appeared, named GRUB2 and i set it as the default boot option.
This is visibly a known bug for Ubuntu 15+ when installing on Dell XPS 13 9343. A workaround has been documented on Launchpad. This answer is solely based on this ticket (which solved my problem).
Cause
The cause of the problem is the explained on this ticket:
The dev/sda1 is wiped removing the EFI boot partition
This is replaced but the dell bios expects to find /EFI/boot/bootx64.efi, but ubuntu only add EFI/ubutnu/*.efi entries, so consequently can not find the hard drive at all.
Workaround
The workaround is the following:
Create bootx64.efi
Boot with a live CD, open a terminal, and type the following commands:
sudo mount /dev/sda1 /tmp
cd /tmp/EFI
sudo mkdir boot
sudo touch boot/bootx64.efi
sudo reboot
Configure your boot
- Open the boot settings (when the DELL logo appears, press F2 until a yellow message appears in the upper right corner).
- Select Boot Sequence.
- Click Add Boot Option.
- In the new window, type the following:
- Boot Option Name: Ubuntu
- File Name: tap the three dots and select EFI/ubuntu/shimx64.efi
- Check the Ubuntu entry and uncheck UEFI: SAMSUNG SSD...
- Apply and Exit
Enjoy your working system!
Best Answer
You've installed Ubuntu in BIOS/CSM/legacy mode. I recommend you disable the Compatibility Support Module (CSM; aka "legacy boot support" or similar terms) in your firmware. Doing this will render some boot media unbootable. If you run into this problem, the solution is to fix the boot media. If you want to boot in EFI/UEFI mode, enabling the CSM is the worst thing you can do. For more on this subject, see my Web page about it.
Note that in EFI mode you do not boot from a "device"; you boot from a boot loader file, which is stored on the FAT EFI System Partition (ESP) and referenced in an NVRAM boot manager entry. There is one sort-of kind-of exception to this rule: EFI supports a "fallback" boot filename, which is
EFI/BOOT/bootx64.efi
for 64-bit (x86-64) systems. If no other boot entry is valid, or sometimes if there's an explicit entry for this loader, the system will boot it. This feature enables booting from OS installation media. It's also sometimes used to boot systems with badly broken EFIs that ignore or forget their NVRAM entries. This fallback entry may appear in the computer's built-in boot manager much like a traditional BIOS boot-from-device entry, but it's not quite the same thing.