Gentoo Linux on DELL XPS 13 9350

As I found little help about this online I figured I’d write a summary piece about my recent experience in installing Gentoo Linux on a DELL XPS 13 9350.

EDIT: TL;DR if you need a working kernel config, you can also get my 4.12.5 kernel config here.

UEFI or MBR ?

This machine ships with a NVME SSD so don’t think twice : UEFI is the only sane way to go.

BIOS configuration

I advise to use the pre-installed Windows 10 to update the XPS to the latest BIOS (1.1.7 at the time of writing). Then you need to change some stuff to boot and get the NVME SSD disk discovered by the live CD.

  • Turn off Secure Boot
  • Set SATA Operation to AHCI (will break your Windows boot but who cares)

Live CD

Go for the latest SystemRescueCD (it’s Gentoo based, you won’t be lost) as it’s quite more up to date and supports booting on UEFI. Make it a Live USB for example using unetbootin and the ISO on a vfat formatted USB stick.

NVME SSD disk partitioning

We’ll be using GPT with UEFI. I found that using gdisk was the easiest. The disk itself is found on /dev/nvme0n1. Here it is the partition table I used :

  • 500Mo UEFI boot partition (type EF00)
  • 16Go Swap partition
  • 60Go Linux root partition
  • 400Go home partition

The corresponding gdisk commands :

# gdisk /dev/nvme0n1

Command: o ↵
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y ↵

Command: n ↵
Partition Number: 1 ↵
First sector: ↵
Last sector: +500M ↵
Hex Code: EF00 ↵

Command: n ↵
Partition Number: 2 ↵
First sector: ↵
Last sector: +16G ↵
Hex Code: 8200 ↵

Command: n ↵
Partition Number: 3 ↵
First sector: ↵
Last sector: +60G ↵
Hex Code: ↵

Command: n ↵
Partition Number: 4 ↵
First sector: ↵
Last sector: ↵ (for rest of disk)
Hex Code: ↵

Command: w ↵
Do you want to proceed? (Y/N): Y ↵

No WiFi on Live CD ? no panic

If your live CD is old (pre 4.4 kernel), the integrated broadcom 4350 wifi card won’t be available !

My trick was to use my Android phone connected to my local WiFi as a USB modem which was detected directly by the live CD.

  • get your Android phone connected on your local WiFi (unless you want to use your cellular data)
  • plug in your phone using USB to your XPS
  • on your phone, go to Settings / More / Tethering & portable hotspot
  • enable USB tethering

Running ip addr will show the network card enp0s20f0u2 (for me at least), then if no IP address is set on the card, just ask for one :

# dhcpcd enp0s20f0u2

Et voilà, you have now access to the internet.

Proceed with installation

The only thing to worry about is to format the UEFI boot partition as FAT32.

# mkfs.vfat -F 32 /dev/nvme0n1p1

Then follow the Gentoo handbook as usual for the next steps of the installation process until you arrive to the kernel and the bootloader / grub part.

From this moment I can already say that NO we won’t be using GRUB at all so don’t bother installing it. Why ? Because at the time of writing, the efi-64 support of GRUB was totally not working at all as it failed to discover the NVME SSD disk on boot.

Kernel sources and consideration

The trick here is that we’ll setup the boot ourselves directly from the BIOS later so we only need to build a standalone kernel (meaning able to boot without an initramfs).

EDIT: as of Jan. 10 2016, kernel 4.4 is available on portage so you don’t need the patching below any more !

Make sure you install and use at least a 4.3.x kernel (4.3.3 at the time of writing). Add sys-kernel/gentoo-sources to your /etc/portage/package.keywords file if needed. If you have a 4.4 kernel available, you can skip patching it below.

Patching 4.3.x kernels for Broadcom 4350 WiFi support

To get the broadcom 4350 WiFi card working on 4.3.x, we need to patch the kernel sources. This is very easy to do thanks to Gentoo’s user patches support. Do this before installing gentoo-sources (or reinstall it afterwards).

This example is for gentoo-sources-4.3.3, adjust your version accordingly :

(chroot) # mkdir -p /etc/portage/patches/sys-kernel/gentoo-sources-4.3.3
(chroot) # cd /etc/portage/patches/sys-kernel/gentoo-sources-4.3.3
(chroot) # wget http://ultrabug.fr/gentoo/xps9350/0001-bcm4350.patch

When emerging the gentoo-sources package, you should see the patch being applied. Check that it worked by issuing :

(chroot) # grep BRCM_CC_4350 /usr/src/linux/drivers/net/wireless/brcm80211/brcmfmac/chip.c
case BRCM_CC_4350_CHIP_ID:

The resulting kernel module will be called brcmfmac, make sure to load it on boot by adding it in your /etc/conf.d/modules :

modules="brcmfmac"

EDIT: as of Jan. 7 2016, version 20151207 of linux-firmware ships with the needed files so you don’t need to download those any more !

Then we need to download the WiFi card’s firmware files which are not part of the linux-firmware package at the time of writing (20150012).

(chroot) # emerge '>=sys-kernel/linux-firmware-20151207'

# DO THIS ONLY IF YOU DONT HAVE >=sys-kernel/linux-firmware-20151207 available !
(chroot) # cd /lib/firmware/brcm/
(chroot) # wget http://ultrabug.fr/gentoo/xps9350/BCM-0a5c-6412.hcd
(chroot) # wget http://ultrabug.fr/gentoo/xps9350/brcmfmac4350-pcie.bin

Kernel config & build

I used genkernel to build my kernel. I’ve done a very few adjustments but these are the things to mind in this pre-built kernel :

  • support for NVME SSD added as builtin
  • it is builtin for ext4 only (other FS are not compiled in)
  • support for DM_CRYPT and LUKS ciphers for encrypted /home
  • the root partition is hardcoded in the kernel as /dev/nvme0n1p3 so if yours is different, you’ll need to change CONFIG_CMDLINE and compile it yourself
  • the CONFIG_CMDLINE above is needed because you can’t pass kernel parameters using UEFI so you have to hardcode them in the kernel itself
  • support for the intel graphic card DRM and framebuffer (there’s a kernel bug with skylake CPUs which will spam the logs but it still works good)

Get the kernel config and compile it :

EDIT: updated kernel config to 4.4.4 with SD Card support.

(chroot) # mkdir -p /etc/kernels
(chroot) # cd /etc/kernels
(chroot) # wget http://ultrabug.fr/gentoo/xps9350/kernel-config-x86_64-4.4.4-gentoo
(chroot) # genkernel kernel

The proposed kernel config here is for gentoo-sources-4.4.4 so make sure to rename the file for your current version.

EDIT: you can use and download a recent working kernel config at the beginning of the article.

This kernel is far from perfect but it works very good so far, sound, webcam and suspend work smoothly !

make.conf settings for intel graphics

I can recommend using the following on your /etc/portage/make.conf :

INPUT_DRIVERS="evdev synaptics"
VIDEO_CARDS="intel i965"

fstab for SSD

Don’t forget to make sure the noatime option is used on your fstab for / and /home !

/dev/nvme0n1p1    /boot    vfat    noauto,noatime    1 2
/dev/nvme0n1p2    none     swap    sw                0 0
/dev/nvme0n1p3    /        ext4    noatime   0 1
/dev/nvme0n1p4    /home    ext4    noatime   0 1

As pointed out by stefantalpalaru on comments, it is recommended to schedule a SSD TRIM on your crontab once in a while, see Gentoo Wiki on SSD for more details.

encrypted /home auto-mounted at login

I advise adding the cryptsetup to your USE variable in /etc/portage/make.conf and then updating your @world with a emerge -NDuq @world.

I assume you don’t have created your user yet so your unmounted /home is empty. Make sure that :

  • your /dev/nvme0n1p4 home partition is not mounted
  • you removed the corresponding /home line from your /etc/fstab (we’ll configure pam_mount to get it auto-mounted on login)

AFAIK, the LUKS password you’ll set on the first slot when issuing luksFormat below should be the same as your user’s password !

(chroot) # cryptsetup luksFormat -s 512 /dev/nvme0n1p4
(chroot) # cryptsetup luksOpen /dev/nvme0n1p4 crypt_home
(chroot) # mkfs.ext4 /dev/mapper/crypt_home
(chroot) # mount /dev/mapper/crypt_home /home
(chroot) # useradd -m -G wheel,audio,video,plugdev,portage,users USERNAME
(chroot) # passwd USERNAME
(chroot) # umount /home
(chroot) # cryptsetup luksClose crypt_home

We’ll use sys-auth/pam_mount to manage the mounting of our /home partition when a user logs in successfully, so make sure you emerge pam_mount first, then configure the following files :

  • /etc/security/pam_mount.conf.xml (only line added is the volume one)
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<!--
	See pam_mount.conf(5) for a description.
-->

<pam_mount>

		<!-- debug should come before everything else,
		since this file is still processed in a single pass
		from top-to-bottom -->

<debug enable="0" />

		<!-- Volume definitions -->

<volume user="USERNAME" fstype="auto" path="/dev/nvme0n1p4" mountpoint="/home" options="fsck,noatime" />

		<!-- pam_mount parameters: General tunables -->

<!--
<luserconf name=".pam_mount.conf.xml" />
-->

<!-- Note that commenting out mntoptions will give you the defaults.
     You will need to explicitly initialize it with the empty string
     to reset the defaults to nothing. -->
<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" />
<!--
<mntoptions deny="suid,dev" />
<mntoptions allow="*" />
<mntoptions deny="*" />
-->
<mntoptions require="nosuid,nodev" />

<!-- requires ofl from hxtools to be present -->
<logout wait="0" hup="no" term="no" kill="no" />


		<!-- pam_mount parameters: Volume-related -->

<mkmountpoint enable="1" remove="true" />


</pam_mount>
  • /etc/pam.d/system-auth (only lines added are the ones with pam_mount.so)
auth		required	pam_env.so 
auth		required	pam_unix.so try_first_pass likeauth nullok 
auth		optional	pam_mount.so
auth		optional	pam_permit.so

account		required	pam_unix.so 
account		optional	pam_permit.so

password	optional	pam_mount.so
password	required	pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 
password	required	pam_unix.so try_first_pass use_authtok nullok sha512 shadow 
password	optional	pam_permit.so

session		optional	pam_mount.so
session		required	pam_limits.so 
session		required	pam_env.so 
session		required	pam_unix.so 
session		optional	pam_permit.so

That’s it, easy heh ?! When you login as your user, pam_mount will decrypt your home partition using your user’s password and mount it on /home !

UEFI booting your Gentoo Linux

The best (and weird ?) way I found for booting the installed Gentoo Linux and its kernel is to configure the UEFI boot directly from the XPS BIOS.

The idea is that the BIOS can read the files from the EFI boot partition since it is formatted as FAT32. All we have to do is create a new boot option from the BIOS and configure it to use the kernel file stored in the EFI boot partition.

  • reboot your machine
  • get on the BIOS (hit F2)
  • get on the General / Boot Sequence menu
  • click Add
  • set a name (like Gentoo 4.3.3) and find + select the kernel file (use the integrated file finder)

IMG_20160102_113759

  • remove all unwanted boot options

IMG_20160102_113619

  • save it and reboot

Your Gentoo kernel and OpenRC will be booting now !

Suggestions, corrections, enhancements ?

As I said, I wrote all this quickly to spare some time to whoever it could help. I’m sure there are a lot of improvements to be done still so I’ll surely update this article later on.

27 thoughts on “Gentoo Linux on DELL XPS 13 9350

    1. ultrabug Post author

      Not that I know of. But tbh, I did not test booting on an initramfs instead of a kernel from the UEFI boot, I will try on later and report back if it works.

      Reply
      1. Brad Laue

        I’m booting my XPS 15 9550 using crypt root and an initramfs – I’m using systemd with the gnuefi USE flag set so its integrated bootloader is enabled.

        From there I:
        1) bootctl install –path/boot /dev/nvme0n1p1
        2) set a /boot/loader/entries/gentoo.conf up with the kernel, initrd and options lines
        3) Select bootx64.efi in the firmware’s built-in file browser in my Gentoo entry

        Works nicely.

        Reply
  1. Mike Lothian

    I’ve got a very similar setup on my Alienware 15

    Linux on the 1TB M.2 SSD, 50MB vfat /boot, 50GB / and the rest /home – both ext4. I tried using f2fs but I gave up after it took ages and a lot of cpu whilst copying the files from my old system.

    Reply
  2. Anton

    while it’s true that you dont need a bootmanager, my personal choice is still use it. I feel it’s tricky to mess around with BIOS everytime you upgrade kernel or want to load a different version. Grub2 is just too big for that so check out sys-boot/efibootmgr instead.

    Reply
    1. ultrabug Post author

      I surely agree with you Anton. The thing is, like I said, that the GRUB2 and efibootmgr methods didn’t work for me on this machine so I ended up managing the boot from the BIOS !

      Reply
      1. Igor Krivenko

        Thanks for the useful guide!

        I think you might want to give another try to efibootmgr, when kernel 4.5 is out. After some experimentation with efibootmgr I came to a conclusion that it is *almost* usable with my XPS 13 9350. The only missing part is a wrong (made of zeros) EUI-64 identifier of the NVMe device in the EFI boot variable it creates.

        efibootmgr tries to read that identifier from /sys, but it is not yet available with kernel 4.4 . As far as I understand, kernel 4.5 will include this patch

        https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2b9b6e86bca7209de02754fc84acf7ab3e78734e

        which fixes the issue.

        Reply
        1. ultrabug Post author

          Thanks a lot for the heads up and explanation Igor, I certainly will try that out then 🙂 cheers

          Reply
          1. ahxxm

            I got grub-9999-r1 working locally on my XPS 15 9550, with kernel config (NVM Experss) enabled and UUID=xxx-xxx-xxx in fstab. The BIOS keeps telling me it can’t find filesystem..

          2. ultrabug Post author

            BIOS or GRUB ? In this article, I do NOT use GRUB and therefore you need to have a FAT32 boot partition so that your BIOS can read it !

  3. Clem

    Hi there !
    I got one of these XPS last November and back then I followed mostly the same steps (including using my Android phone as an access point), based on advice from Arch users. Except I run systemd and I used the experimental kernel branch since I didn’t want to bother with the patch and all.

    The only glitch I had left was that video playback was terrible, slow and sluggish. I first blamed Firefox, but it turned out the problem remained outside the browser. Well your blog is post is actually the first one I see that specifies the use of i965 with mesa rather than i915. Sources haven’t been really specific about this. Using i965 fixed it, so thanks for the hint.

    Just a detail too : I wouldn’t use Windows to update the BIOS. It’s easy enough to do without. In my country, it would also mean you could not get the cost of the licence refunded, as not using it is a prerequisite. And on such an expensive laptop, it does count 🙂

    Reply
    1. ultrabug Post author

      Glad it helped mate. Sure you’re right about that Windows part, it’s just the lazy way when refund is not an option so thanks for pointing this out.

      Reply
  4. nv86

    I read you added your UEFI entry in your BIOS, I did the same on my Lenovo ThinkPad W530, and am planning on doing the same on a Dell machine here soon. But don’t you need to add any kernel parameters like root=/dev/… or initrd=/… because mine wouldn’t boot without parameters. Or did you specify those parameters statically in the kernel?

    Reply
    1. ultrabug Post author

      Hello, yes and I specified it on the article : the root partition is hardcoded in the kernel as /dev/nvme0n1p3 so if yours is different, you’ll need to change CONFIG_CMDLINE and compile it yourself. CONFIG_CMDLINE is what you’re looking for.

      Reply
  5. Lujeni

    i finally got my desire setup with the same laptop ( MBR + grub2 + luks on the root partition) ! However, the grub is a little bit slow to propose the menu.

    bios:
    – SATA operation to AHCI
    – Boot sequence to Legacy

    fstab:
    /dev/nvme0n1p1 /boot ext4 noauto,noatime 1 2
    /dev/mapper/root / ext4 noatime 0 1
    /dev/nvme0n1p2 none swap sw 0 0

    luks:
    $ cryptsetup luksFormat /dev/nvme0n1p3 # format the partition
    $ cryptsetup luksOpen /dev/nvme0n1p3 root # mount the luks partition

    $ USE=”crypt cryptsetup” emerge cryptsetup genkernel # genkernel need this setting
    $ genkernel –luks –menuconfig all # how to generate the initramfs with luks and co

    # ensure this setting are enabled (luks support) in the Kernel
    Device Drivers
    Multi-device support (RAID and LVM)
    [*] Multiple devices driver support (RAID and LVM)
    Device mapper support
    Crypt target support
    Cryptographic API
    SHA256 digest algorithm
    AES cipher algorithms

    grub:
    – version: sys-boot/grub-2.02_beta2
    – /etc/default/grub
    GRUB_CRYPTODISK_ENABLE=
    GRUB_CMDLINE_LINUX=”crypt_root=/dev/nvme0n1p3 real_root=/dev/mapper/root root rootfstype=ext4″

    $ grub2-install –modules=”linux search_fs_uuid luks part_msdos” –recheck /dev/nvme0n1
    $ grub2-mkconfig -o /boot/grub/grub.cfg

    Reply
    1. rm-ass

      thanks that’s help a lot !
      In GRUB_CMDLINE_LINUX’s line i guess you mean real_root instead off real_rool

      Reply
      1. ultrabug Post author

        I guess he did yes, so I corrected the typo on his comment. Thanks !

        Reply
  6. Ross Youngblood

    Thanks for this, it is one of the FEW living examples of /dev/nvme* disk mounting out in the wild.
    For an ancient Sunos/Solaris kernel wrangler, this was VERY useful to getting me started with Gentoo.
    I was able to get my ASROCK PRO4 H170 motherboard to boot Gentoo off my intel .m2 128GB SSD.

    Direct EFI booting.
    Required EFI stub support, builtin kernel command line and override boot loader arguments.
    I used
    /sbin/blkid to get the PARTUUID of the /root partition (strangely the UUID didn’t work, must use PARTUUID).
    Then set the builtin kernel command string to:
    root=PARTUUID=4ddd…(PARTUUID of partition containing root /dev/nvme0n1p3 in my case)

    I was unable to get /dev/nvme0n1p3 to work. EFI boot loader would run my kernel but it would panic.

    There is a good Gentoo forum on this
    https://forums.gentoo.org/viewtopic-p-7965444.html#7965444

    Thanks for this blog entry and associated support, it was the first credible breadcrumb on my week long journey to get Gentoo booting on my .m2 disk.

    Reply
    1. ultrabug Post author

      Thanks for your insight and sharing this Ross. I’m glad it was helpful to you 🙂

      Reply
  7. Pingback: Gentoo on the DELL XPS 13 9350 | 0ddn1x: tricks with *nix

  8. Leo

    Hey,

    I don’t expect an answer because it’s an old article but does this guide also apply to the XPS 13 9360? Sadly I don’t know the differences between the two devices.

    Thanks and hoping for an answer.

    Reply
    1. ultrabug Post author

      Hello Leo, I’m afraid that I’ve not tested this with the 9360 XPS 13 version yet.

      But if you have a NVME based one, I guess most of this article should apply. You’ll most probably have to double check your kernel modules for newer hardware such as the wifi card / webcam / sound card / SD reader / touchscreen but the core should be good I guess.

      If you happen to test, I’ll be happy to hear about the results! Thanks.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *