Installing Ubuntu on a Dell XPS 15 (9560)
Share: 

Installing Ubuntu on a Dell XPS 15 (9560)

24 February 2018

In this post I’ll details the steps I (eventually) worked out to install Ubuntu 18.04 on a late 2017 Dell XPS 15".

With thanks to https://github.com/rcasero/doc/wiki/Ubuntu-linux-on-Dell-XPS-15-(9560) and many other great Google hits. However, none of the instructions I found quite covered everything. This may well be because I tried a super pre-release version of Ubuntu, and by the time you read this is might all be fixed.

I assume you know how to install Ubuntu on a sunny day. This post will talk about building a pure Ubuntu system; I don’t preserve the factory Windows or its bootloader. (I intend to try to get clean Windows booting again from an external disk; watch this space).

Ubuntu version: 18.04. Yes, at time of writing (Jan 18) this is very per-release, and rcasero reports lots of problems being introduced at 17.10. However, I’m a developer and need cutting-edge package versions. This is band new hardware, support for which won’t necessarily get back-ported. I also hit a couple of kernel bugs, the best bet for which seemed to be to fail forwards.

So; to install:

  • Take a backup of the factory Windows. No, seriously. I’m not one for them normally, but so much can and did go wrong for me. You could be weeks with an expensive paperweight if you have to fix it the hard way. Not a good look if your company owns the machine. https://www.veeam.com/windows-endpoint-server-backup-free.html
  • Disable VT-X and VT-D in the UEFI. Otherwise you’ll get “rcu_sched detected expedited stalls on cpus/tasks”. Google reports this and fingers an X58-era firmware bug with IOMMU DMA remapping. This is a good 10 years newer than X58 but I guess it’s a different processor erratum in the same area, because this seemed to fix it.
  • Boot the installer with kernel cmdline option “nouveau.runpm=0”. Otherwise you’ll get almost total freezing, with the odd moment of CPU progress now and again. This one I can confirm by experiment. Apparently anything that wakes the nVidia chipset from sleep causes these freezes to start. That includes running lspci to find out what the laptop is made of, which is obviously the first thing you do after you’ve bought one. Also running Chrome, which uses gfx acceleration (WebGL?). Oh, and actually letting it sleep and wake.
  • dd /dev/zero over the first 512MB of the main /dev/nvme0n1 disk. Otherwise the installer will tell you “the machine’s firmware has started the installer in UEFI mode but it looks like there may be existing operating systems installed using BIOS compatibility mode. If you continue to install Debian in UEFI mode, it might be difficult to reboot the machine into any BIOS-mode operating system later”. The problem is that clicking either of the buttons on that dialog does nothing and that modal dialog stays firmly put. I couldn’t even kill the installer with signal 9; I assume something was stuck in disk sleep. My best solution was to wipe enough of the disk that Ubuntu didn’t detect the “legacy” Windows install. 512 bytes (MBR partition table and stage 1 bootblocks) didn’t do it. However, setting “count=1M” in anger did, even though there are partition table backups at the end of the disk. Meh. idk. Why the factory Windows was installed or miss-detected as BIOS-mode I don’t know either. A shadow protection MBR partition table maybe?
  • If you want a different filesystem, run the installer once with default disk settings, then go over it again. Otherwise you’ll get “Can’t install grub.” Totally opaque, with no meaningful error message. In my case I wanted btrfs for / so I chose manual disk partitioning. I dutifully made an EFI System Partition (512MB, usage “EFI”), and set the rest as btrfs root. Grub wouldn’t install. The only smoking gun I saw was that it’d formatted the ESP partition ext4; I swear it has be to vfat. Anyway, run once with default disk settings. This will wipe Windows (in addition to your dd attack above), make a vfat ESP, and successfully install grub. The system will boot but your filesystem will be a bit sub-par. Now run the installer again, chose manual partitioning, delete the rootfs and re-add as btrfs, but don’t touch the EPS. The installer seems to find the EFI boot machinery fine and update it (or maybe it doesn’t even — the path into / is the same I guess), but it doesn’t reformat it at least.

After installation:

  • Re-enable VT-X and VT-D. The installation medium doesn’t inject any microcode into the CPU, and CPU bugs were suspected for this one. The installed system does do this, out of the box, nothing to install. The Ubuntu 18.04 intel-microcode package even has microcode for this very new processor (family 06, model 9E, stepping 09). Yes, it’s true that the UEFI also contains a microcode blob which it loads at boot, and I updated my BIOS to the latest 1.5 version which was mere days old at time of writing, but that didn’t do it. For reference: Ubuntu was loading version 0x80.
  • Fix graphics driver Power Management issues. Essentially, the current nouveau driver is buggy with respect to the GTX1050 / GP107M in the laptop. This is a known issue. I guess your options are as follows. FWIW I chose 2, and while I don’t play games, I haven’t noticed any graphics performance problems on the desktop. Also the battery life is now awesome. Either way, confirm by running lspci and not getting a lockup.
    1. Wait it out, and don’t trigger an nVidia hardware wakeup in the mean-time
    2. Disable that chip completely in the UEFI (seemingly not possible) or kernel (prevent the driver from binding with modprobe.blacklist=nouveau in /etc/default/grub)
    3. Switch to the nvidia binary blob drivers (only supports Xinerama, no XRandR, so bad for external monitors and projectors. Also, yanno, Closed Source.)
    4. Make the nouveau.runpm=0 kernel cmdline permanent by adding it to /etc/default/grub

HTH,

matt