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
  • 7

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,924
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
  • 45,120
  • 7
  • 66
  • 108
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
  • 1
  • 6