I have a Dell XPS 15 9530 with Windows 8.1 pre-installed. SecureBoot is disabled.
I have shrunk the Windows OS partition, so I now have space to install Ubuntu as secondary OS with dual boot.
I downloaded ubuntu-gnome-14.04-desktop-amd64 and put it on a bootable USB stick using YUMI 2.0.0.3.
I was able to boot into Ubuntu from the USB stick, but only in "regular" legacy BIOS boot mode.
I am not able to boot into the USB stick using UEFI boot. I am not sure why: I am able to add some xxx.efi boot files that are located on the stick into the UEFI boot options, and I am able to boot those, but get stuck with a GRUB prompt. It does not boot all the way into Ubuntu.
After booting into Ubuntu USB, I started the Ubuntu installation, which completed successfully.
One thing I am not sure about is what to chose in the Ubuntu installer when it comes to partition layout and boot loader location.
I did use "Seomthing else" in the disk setup section. I picked sda7 (the partition I created for Ubunu) as moint point "/". I do NOT have separate "/boot" or other partitions, so everything is within sda7.
I am not sure what location to specify for the boot loader, though. sda? sda1? sda7? The UEFI ESP partition is in sda1.
Also, do I need to specify sda1 as mount point for /boot/efi in the partition setup screen? Or is that not necessary?
Subsequent boots only boot into Windows though, not into Ubuntu.
I then booted back into Ubuntu USB (using legacy boot mode again) and installed rEFInd manually using "install.sh".
It did confirm successful installation and placed itself into the UEFI EFI/Microsoft/Boot directory.
After adding a UEFI boot entry pointing to /EFI/Microsoft/BOOT/BOOTMGR.EFI I am now able to boot in the rEFInd start menu.
However, in there, I only have an option to boot Windows. There is no option for Ubuntu.
What exactly is the problem, and how do I fix it?
Is it the fact that I booted Ubuntu USB using legacy boot mode?
Is it because I used the wrong options in the Ubuntu installer as far as boot loader goes?
I have found different web pages that sounded like the key was booting the Ubuntu USB installer via UEFI boot rather than legacy BIOS boot mode, but I just can not get it to do that...
Thanks, MSA
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The last I checked, YUMI was a BIOS-only tool -- the disks it creates can boot in BIOS mode, but not in EFI mode. To do an EFI-mode install of Ubuntu, you must create an EFI-bootable installation disk. In my experience, the most reliable way to do this is to use dd in Linux (or similar tools in other OSes), as in sudo dd if=image.iso of=/dev/sdc to prepare the USB flash drive on /dev/sdc as the boot medium.
Since you didn't do that, you did a BIOS-mode install. Converting that to boot in EFI mode is possible, and if that's your intent, the question of where to install the BIOS-mode boot loader is irrelevant, so long as you don't put it somewhere that it will do damage, such as on an NTFS partition.
Chances are rEFInd isn't detecting Linux because you probably didn't install any EFI filesystem drivers. If you install the appropriate driver for whatever filesystem you used (probably ext4fs), you should see Linux options appear in rEFInd. Installing the driver is a matter of copying one file to the right directory. See the rEFInd documentation on drivers for details.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm creating a Fedora USB at the moment using the Fedora LiveUSB creator.
If that doesn't boot in UEFI mode, I will try using dd as you suggested.
I did try that for the rEFInd USB flash drive image, but wasn't able to boot that. The UEFI tool did not show the drive in the list. Booting via BIOS boot mode said that the drive wasn't bootable.
Any idea what might have gone wrong there? The dd command went through OK.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fedora install worked, that one was even able to install its own EFI boot loader/manager.
After getting rEFInd back, rEFInd picks up Fedora and windows - a whole bunch of Fedora, linux and fallback options actually. Not sure where those all came from, but that's OK for now.
So it might well have been YUMI that caused me my problems this whole time.
Will now try to go back to installing Ubuntu instead of Fedora with the Ubuntu-recommended Linux Live USB creator and see what that does...
Last edit: MSA 2014-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, now Ubuntu overwrote everything with its own EFI boot loader/manager and somehow kicked rEFInd out.
Is there a way to get rEFInd back, other than reinstalling it again?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can tell what the options are by examining the text that appears when you highlight an option. It normally reads something like "Boot path\to\foo from bar" for an EFI boot loader, where "bar" is a partition/filesystem name or description and "path\to\foo" is the filename.
Assuming Ubuntu didn't erase rEFInd (which it should not have), you should be able to use efibootmgr to restore rEFInd as the default boot manager. Type sudo efibootmgr in a Terminal to see the available boot programs, then use the -o option (as in efibootmgr -o 5,2,7) to set the order in which you want the firmware to use them. (In this example, it would use Boot0005 first, then it that failed use Boot0002, then Boot0007.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do see the text below the option, but as it only shows a description of the partition and not the partition name (e.g. sda1 or something like "disk X partition Y"), it is not obvious what they are exactly.
Trying them out, it seems like options such as "grubx64.efi" go to a subsequent boot menu, whereas the "boot\vmlinuz-...efi" style options go right into some kernel without another menu in between?
It sounds like what efibootmgr does can also be done in the Dell BIOS (add/delete boot options based on an efi file path, modify the order, and set the default).
I thought that Ubuntu hat actually overwritten the rEFInd files, but it looks like it just placed itself in front of rEFInd in the options (actually made itself default).
So apparently, the whole EFI mechanism works simply based on "regular" files in the EFI partition, which can be copied / archived to a ZIP file and also restored from there?
No "magic" with hidden stuff in some MBR or other weird sectors that you need special tools to get to?
I had made a tgz archive backup of all files in /boot/efi before installing rEFInd, and later deleted everything in /boot/efi just by using "rm -rRf *" and then restored the files from the tgz. Everything was as it used to be before I installed rEFInd. That seems quite nice.
Last edit: MSA 2014-05-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Correct; rEFInd can launch kernels without the help of GRUB.
Correct; the EFI uses ordinary files on the ESP without MBR-based boot code, although it relies on NVRAM-based variables to determine which file to boot. Be aware that these variables refer to partitions by the partition number and GUID, so if you were to repartition the disk, the NVRAM entries might fail to work and might need to be updated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I have a Dell XPS 15 9530 with Windows 8.1 pre-installed. SecureBoot is disabled.
I have shrunk the Windows OS partition, so I now have space to install Ubuntu as secondary OS with dual boot.
I downloaded ubuntu-gnome-14.04-desktop-amd64 and put it on a bootable USB stick using YUMI 2.0.0.3.
I was able to boot into Ubuntu from the USB stick, but only in "regular" legacy BIOS boot mode.
I am not able to boot into the USB stick using UEFI boot. I am not sure why: I am able to add some xxx.efi boot files that are located on the stick into the UEFI boot options, and I am able to boot those, but get stuck with a GRUB prompt. It does not boot all the way into Ubuntu.
After booting into Ubuntu USB, I started the Ubuntu installation, which completed successfully.
One thing I am not sure about is what to chose in the Ubuntu installer when it comes to partition layout and boot loader location.
I did use "Seomthing else" in the disk setup section. I picked sda7 (the partition I created for Ubunu) as moint point "/". I do NOT have separate "/boot" or other partitions, so everything is within sda7.
I am not sure what location to specify for the boot loader, though. sda? sda1? sda7? The UEFI ESP partition is in sda1.
Also, do I need to specify sda1 as mount point for /boot/efi in the partition setup screen? Or is that not necessary?
Subsequent boots only boot into Windows though, not into Ubuntu.
I then booted back into Ubuntu USB (using legacy boot mode again) and installed rEFInd manually using "install.sh".
It did confirm successful installation and placed itself into the UEFI EFI/Microsoft/Boot directory.
After adding a UEFI boot entry pointing to /EFI/Microsoft/BOOT/BOOTMGR.EFI I am now able to boot in the rEFInd start menu.
However, in there, I only have an option to boot Windows. There is no option for Ubuntu.
What exactly is the problem, and how do I fix it?
Is it the fact that I booted Ubuntu USB using legacy boot mode?
Is it because I used the wrong options in the Ubuntu installer as far as boot loader goes?
I have found different web pages that sounded like the key was booting the Ubuntu USB installer via UEFI boot rather than legacy BIOS boot mode, but I just can not get it to do that...
Thanks, MSA
The last I checked, YUMI was a BIOS-only tool -- the disks it creates can boot in BIOS mode, but not in EFI mode. To do an EFI-mode install of Ubuntu, you must create an EFI-bootable installation disk. In my experience, the most reliable way to do this is to use
dd
in Linux (or similar tools in other OSes), as insudo dd if=image.iso of=/dev/sdc
to prepare the USB flash drive on/dev/sdc
as the boot medium.Since you didn't do that, you did a BIOS-mode install. Converting that to boot in EFI mode is possible, and if that's your intent, the question of where to install the BIOS-mode boot loader is irrelevant, so long as you don't put it somewhere that it will do damage, such as on an NTFS partition.
Chances are rEFInd isn't detecting Linux because you probably didn't install any EFI filesystem drivers. If you install the appropriate driver for whatever filesystem you used (probably ext4fs), you should see Linux options appear in rEFInd. Installing the driver is a matter of copying one file to the right directory. See the rEFInd documentation on drivers for details.
I'm creating a Fedora USB at the moment using the Fedora LiveUSB creator.
If that doesn't boot in UEFI mode, I will try using dd as you suggested.
I did try that for the rEFInd USB flash drive image, but wasn't able to boot that. The UEFI tool did not show the drive in the list. Booting via BIOS boot mode said that the drive wasn't bootable.
Any idea what might have gone wrong there? The dd command went through OK.
Fedora install worked, that one was even able to install its own EFI boot loader/manager.
After getting rEFInd back, rEFInd picks up Fedora and windows - a whole bunch of Fedora, linux and fallback options actually. Not sure where those all came from, but that's OK for now.
So it might well have been YUMI that caused me my problems this whole time.
Will now try to go back to installing Ubuntu instead of Fedora with the Ubuntu-recommended Linux Live USB creator and see what that does...
Last edit: MSA 2014-05-20
OK, now Ubuntu overwrote everything with its own EFI boot loader/manager and somehow kicked rEFInd out.
Is there a way to get rEFInd back, other than reinstalling it again?
You can tell what the options are by examining the text that appears when you highlight an option. It normally reads something like "Boot path\to\foo from bar" for an EFI boot loader, where "bar" is a partition/filesystem name or description and "path\to\foo" is the filename.
Assuming Ubuntu didn't erase rEFInd (which it should not have), you should be able to use
efibootmgr
to restore rEFInd as the default boot manager. Typesudo efibootmgr
in a Terminal to see the available boot programs, then use the-o
option (as inefibootmgr -o 5,2,7
) to set the order in which you want the firmware to use them. (In this example, it would useBoot0005
first, then it that failed useBoot0002
, thenBoot0007
.)I do see the text below the option, but as it only shows a description of the partition and not the partition name (e.g. sda1 or something like "disk X partition Y"), it is not obvious what they are exactly.
Trying them out, it seems like options such as "grubx64.efi" go to a subsequent boot menu, whereas the "boot\vmlinuz-...efi" style options go right into some kernel without another menu in between?
It sounds like what efibootmgr does can also be done in the Dell BIOS (add/delete boot options based on an efi file path, modify the order, and set the default).
I thought that Ubuntu hat actually overwritten the rEFInd files, but it looks like it just placed itself in front of rEFInd in the options (actually made itself default).
So apparently, the whole EFI mechanism works simply based on "regular" files in the EFI partition, which can be copied / archived to a ZIP file and also restored from there?
No "magic" with hidden stuff in some MBR or other weird sectors that you need special tools to get to?
I had made a tgz archive backup of all files in /boot/efi before installing rEFInd, and later deleted everything in /boot/efi just by using "rm -rRf *" and then restored the files from the tgz. Everything was as it used to be before I installed rEFInd. That seems quite nice.
Last edit: MSA 2014-05-22
Correct; rEFInd can launch kernels without the help of GRUB.
Correct; the EFI uses ordinary files on the ESP without MBR-based boot code, although it relies on NVRAM-based variables to determine which file to boot. Be aware that these variables refer to partitions by the partition number and GUID, so if you were to repartition the disk, the NVRAM entries might fail to work and might need to be updated.