3

After installing Ubuntu 16.04 on a Dell XPS 8920 (UEFI firmware, one 0.5TB SSD and one 2TB HDD) by erasing the disk and succesfull install, no bootable device is found.

Looking at gparted (which displays a Libparted warning that the block size is 2048 but Linux says it is 512 bytes), the partitions look the following:

  • Linux correctly installs in the SSD (/dev/nvme0n1p1 EFI partition, boot flag)

  • /dev/sda1 is somehow a Microsoft reserved partition, which not only should not be, as I erased Windows, but also might make some trouble if the systems looks to boot from here.

    Also looking through a lot of other similar blogs, I noticed I do not have access to a shimx64.efi boot file through the BIOS.

Does the computer try to boot from sda1 and failing because I install linux on the SSD and/or because there is still an unwanted Microsoft reserved partition on sda1? Does someone have any ideas?

UPDATE: After running boot-repair on the ubuntu live from the USB, I get the following summary: http://paste.ubuntu.com/25673811/

UPDATE 2 #SOLVED

The issue has been temporarily resolved: After installing ubuntu on the SSD, I installed it again, this time on the HDD. This installation showed successful but was NOT as there were no booting files in /sda1, only having installed the OS in /sda2. Not only that, but the previous install had not been removed and it was still complete on the SSD.

I moved the boot files from the SSD (all from /nvme0n1p1/EFI/ubuntu to /sda1/EFI/ubuntu, and placed the grubx64.efi into /sda1/EFI/Boot), and now Ubuntu boots correctly!

The findings so far: - The linux installation is faulty (did not properly erase disk, did not correctly install ubuntu on the HDD). - The BIOS has trouble reading/finding the boot files on the SSD. - The BIOS can read/find boot files on /sda1 , and boot linux on the SSD second partition.

I suspect that the BIOS can read the boot files on sda1, which are pointing to the OS installed in the SSD (as desired). This would mean that the OS installed in sda2 is useless. However when erasing the OS in sda2, nothing works again, indicating that this is somehow also necessary. I cannot explain this behaviour. Any ideas?

LHM
  • 65

3 Answers3

1

I had a similar issue with a Toshiba.
The EFI required a system reserve partition first on the disk, then the EFI partition second on the internal drive.

It also required that the default media path be used on the internal drive. Copy /efi/ubuntu/shimx64.efi to efi/boot/ and rename it bootx64.efi.
If you are not using secure boot, then efi/ubuntu/grubx64.efi can be copied and renamed.

ravery
  • 6,874
  • What are you calling the disk and what the internal drive? Where are you suggesting to do those operations, in the live ubuntu version in the USB drive? – LHM Oct 04 '17 at 14:25
  • I guess you are calling the HDD the disk, and internal drive would be the SSD. Are you suggesting to do those file operations in the USB stick? As in plugging it into another computer and rename those files? – LHM Oct 04 '17 at 14:43
  • the HDD and SSD are both drives("disks"), internal is one that is installed in the machine vs external which is plugged into a usb port.the changes have to be done to the boot drive in the computer, changing the usb stick will have no effect on the computer you are trying to boot. – ravery Oct 04 '17 at 14:47
  • So the address you mentioned "/efi/ubuntu/" is local in the computer and made after installation from the USB I presume. How can I access it? – LHM Oct 04 '17 at 14:52
  • it's in the EFI partition. boot a LiveCD to access. you will temporarily need to remove the ESP flag in order to mount the partition. – ravery Oct 04 '17 at 14:59
  • Ok, so to get this straight: In the USB try out version I can see all drives, though they are shown as block/character device drivers which I can't just access. I should mount /dev/nvme0n1p1 (SSD drive = EFI partition on gparted, label which should be temporary removed), and then I can access it, find the shimx64 or grubx64.efi and rename to bootx64.efi. – LHM Oct 04 '17 at 15:26
  • yes. make a copy to rename, then move to /efi/boot. you will need to make the folder. then re-enable the efi partition flag – ravery Oct 04 '17 at 15:31
  • There is already a bootx64.efi in efi/boot. I would be replacing it by the shimx64.efi (in case of secure boot), or would be replacing it with the bootx64.efi from /efi/ubuntu/ (in case of not using secure boot) – LHM Oct 04 '17 at 16:27
  • Wait, if we are being case sensitive, then I should make a new dir called efi/boot. The one already present is EFI/Boot. The new one would of course be empty. But why would this matter? – LHM Oct 04 '17 at 16:30
  • EFI/BOOT is the one you want, though I don't thin the EFI system is case sensitive. – ravery Oct 04 '17 at 18:17
  • Thank you very much for your recommendations and time! However this has not solved the booting problem. The system still cannot boot from the nvme0n1p1 partition (SSD). Thinking now on manually disconnecting the hard-drive so it only reads the SSD. – LHM Oct 05 '17 at 15:25
1

Unfortunately, Boot Repair does a poor job of handling NVMe disks that show up as /dev/nvme* devices, as yours does. This means that your Boot Info Script output is missing several critical details. That said, what it does show looks like it should be booting, assuming reasonable contents on the NVMe disk. I do have some comments and suggestions, though:

  • Check your ESP -- Your EFI System Partition (ESP) appears to be on your NVMe disk, and as such, Boot Repair is providing very little information on it. (It appears to be /dev/nvme0n1p2, though.) Boot loaders reside on the ESP, so you may want to manually check it to see that it holds the files it should hold. In particular, it should hold a directory called EFI/ubuntu with files called shimx64.efi, grubx64.efi, and grub.cfg. (Note that the ESP uses FAT32, which is case-insensitive.) There may also be leftover Windows boot files in EFI/Microsoft and/or EFI/BOOT.
  • Repair or re-create the ESP's filesystem -- Windows 8 and later use features called Fast Startup and Hibernate, which leave filesystems in an inconsistent state when Windows "shuts down." These features can cause filesystem damage, which in some cases can cause an EFI to fail to read files from the ESP, even if other OSes can read those files. Sometimes running a filesystem check and repair on the ESP can fix those problems. You can do this from an Ubuntu emergency boot utility with dosfsck, as in sudo dosfsck -a /dev/nvme0n1p2. In extreme cases, backing up all the files from the ESP (with tar, zip, or cp), creating a fresh filesystem with mkdosfs, and then restoring the files may be required. If you go to this extreme, you'll need to edit /etc/fstab on your installation to get the ESP to mount again.
  • Complete wipe and re-install -- Since you've just installed Ubuntu, you might try re-installing it, but this time, do a better job of wiping the NVMe disk. (There are hints that the original ESP is present, based on the Boot Info output.) Using gdisk, sgdisk, parted, or GParted, you can delete all the partitions on /dev/nvme0n1, then either create new partitions with your partitioning tool or let the Ubuntu installer do so. This action will guarantee that the ESP is fresh, with no leftover Windows files or filesystem damage, and that there are no other strange partitions on the disk. (Sometimes OEMs put extra partitions on the disk and boot through one of them. Remnants of such a configuration could conceivably be causing problems for you.)
  • Try rEFInd -- You could try using my rEFInd boot manager to boot the disk. You can download the USB flash drive or CD-R image, prepare a boot medium, and boot with it. This should enable you to boot to Ubuntu. If this works, you could install the PPA or Debian package version to the hard disk. This might overcome some quirky problems; or even if installing to the hard disk doesn't help, you might be able to boot with a USB drive as a temporary basis while you investigate the problem more. OTOH, whatever is preventing GRUB from launching might also affect rEFInd, particularly once you install it to the hard disk.
  • Reset firmware settings to their defaults -- If you can find an option in your firmware setup utility to reset all its options to their defaults, you could try this; however, this will likely require re-creating the Ubuntu boot entry. Normally, Boot Repair could do this, but I'm not sure this will work with your NVMe disk. Thus, you'll need to do this manually or completely re-install Ubuntu, as noted earlier.
  • Upgrade your firmware -- Some EFIs are buggy and don't boot properly, except to Windows. A firmware update (probably called a "BIOS update" on the manufacturer's site) might help with such problems. Thus, it's worth checking for one. That said, Dells are usually better than average on this score, and manufacturers seldom release bug fixes for the types of bugs that might produce the symptoms you're reporting.
  • Use of NTFS -- Your /dev/sda is partitioned with a Microsoft Reserved partition and an NTFS partition. If you've completely removed Windows from the computer, you should not use NTFS on any internal disk. The reason is that there are no good Linux NTFS maintenance tools, so when (note: when, not if) the NTFS partition becomes damaged, you'll need to jump through extra hoops to repair it. If Windows had been installed to the NVMe disk, its removal would not affect your /dev/sda HDD, so this leftover of Windows is understandable -- but it's something you should correct. Note, however, that neither the Microsoft Reserved partition nor the NTFS partition is likely to be an issue in your current boot problem. I mention this because it's something you should correct once you get your system to boot; it's not something you should investigate or correct in an effort to repair the boot problem. OTOH, if your NTFS partition is on an external disk that you move between an Ubuntu and a Windows computer, use of NTFS is less of a problem, since you can repair it using the Windows computer.

If none of the above suggestions help, you might want to do some further background reading, since then you're deep into EFI weirdness territory:

Rod Smith
  • 44,284
  • 7
  • 63
  • 105
  • Thank you Rod for you long answer. This helped me a lot to understand the backgrounds of what is happening. The final solution came though from changing the placements of the boot files and the OS (see update2). – LHM Oct 07 '17 at 23:54
  • @rodsmith -- grub.config is now on the linux partition not the efi partition – ravery Oct 08 '17 at 14:43
  • @ravery, Ubuntu ships with both signed and unsigned versions of GRUB. The unsigned version has always put its grub.cfg file in /boot/grub, which is on the / or /boot partition, depending on how the system is partitioned. The signed GRUB, though, needs to have a grub.cfg file on the ESP. This grub.cfg file points to the grub.cfg in /boot/grub. Even systems with Secure Boot disabled are usually installed with the signed GRUB, so there will usually be a grub.cfg on the ESP. It's possible to remove the signed GRUB, but AFAIK this requires special configuration. – Rod Smith Oct 08 '17 at 17:41
  • @RodSmith -- grub used to put it's config and modules in the EFI directory (trusty) it is only recent updates (xenial) that moved it to /boot/grub – ravery Oct 08 '17 at 18:25
  • @ravery, you're wrong. I've got both Ubuntu 14.04 and 17.04 VMs running right now. Both versions have grub.cfg in both locations, with the one on the ESP being a bare-bones version that points to the one in /boot/grub, just as I specified. Note, however, that this is how Ubuntu does it. GRUB is quite flexible, and can be configured in other ways by other distributions or if you do it yourself. – Rod Smith Oct 09 '17 at 19:19
0

"sda1" will be your USB device. Since linux isn't booting, are you booting off of the USB?

I suspect the problem is your bootloader isn't configured correctly, or it cannot access the SDD. Remove the USB and reboot. Enter the bootloader options menu by repeatedly pressing the F12 key (I'm not sure when is the "right time" to press it) while booting up. You should get to a bootloader menu. From there, you should be able to choose your boot device.

This link might help. You already have SDD access, so much of this won't apply, but make sure AHCI is selected for your SATA operation.

Gaylord
  • 66
  • The USB shows as /dev/sdc. AHCI is selected too (but I did this just by changing it on the BIOS. Other solutions propose a three step change using the windows cmd terminal, but since I do not have windows installed anymore, this is not possible).

    After pressing F12 I can select the SSD under "Legacy options" and ubuntu under "UEFI" options. Both lead to a booting failure

     – LHM Oct 04 '17 at 14:17