Installing Debian GNU/Linux on a Lenovo Z380

Posted by Jedd on 2013-01-10

I recently acquired a Lenovo Z380 laptop. These devices have reasonable specs, though they do seem to change over time as Lenovo finds cheaper or more readily available components to throw into them.

This one ships with 1TB disk, 8GB memory, an i5 CPU, and nVidia graphics.

Specifically it's an Intel i5-3210 @ 2.5GHz, 798MHz DDR3-1596, CAS 11-11-11-28 dual channel memory, Seagate Momentus ST1000LM024 5k4 1TB SATA-II drive, with nVidia GeForce 610M.

hdparm reports ~ 105MB/s transfer speeds to the disk, but hdparm isn't hugely insightful

IntelliJ takes 15s to crank up on first boot in an otherwise empty KDE environment, but something under 5s the next time you launch it. There's clearly some significant penalty from a having a vanilla 5k4 drive, though 100MB/s is pretty respectable if that's sustained. (It probably isn't :)

 

Before we start

Let me be crystal clear about what you'll find here:

  • I'm not looking to dual-boot this sucker - it's going to be a Debian GNU/Linux machine
  • I'm not even looking to make a Lenovo / Windows rescue disc - I simply don't care
  • I also don't care about any alleged or real benefits of (U)EFI - disabling UEFI is the first step below
  • almost the entire drive will be dm-encrypted (only /boot remains au naturel) - you can ignore those bits below if you want

If this doesn't interest you .. then move along, citizen.

 

We start

Disabuse the machine of its deep Microcruft

In order to not continually boot into the dodgy pre-installed Windows 8 mess, you have to first boot into the BIOS. Make sure the machine is powered off (no gently throbbing light on the power button) and then hit the Novo button, that tiny recessed button just to the right of the power button. Follow the menu to the BIOS.

Once you're in the BIOS, apparently you need to set the administrator password to be able to disable Secure Boot. This is true, but disabling Secure Boot isn't sufficient – you also (or perhaps merely alternatively, but I wasn't sufficiently bored to go and undo that step before doing this next step) change Boot type to Legacy, rather than UEFI.

There's much talkings on the Internets about the technical, legal and other implications of this, but, well, heck, just do it. You'll be fine. Probably.

Installing Debian from CD

I used a Debian amd64 Testing netinst CD, dating from all the way back to 2012-11, as it's what I had handy.

During the first stage, it'll complain about possibly missing firmware, specifically the rt18105e-1, which you can retrieve from the archives (I grabbed mine from my local mirror). However, you don't seem to actually need it – the installer ignores it, and the free drivers seem to be enough to get the eth0 device cranked up. There may be performance / stability gains in upgrading this later. Note to self, and all that.

Go through the usual guff with host and network names, preferred mirror, and so on.

For partitioning, first erase the bewildering mess that comes from the factory:

Lenovo partition layout as shipped
Bewildering partition layout

My usual layout is to have three physical volumes:

  • 1GB - raw, ext4, configured for /boot
  • 50GB - 'for crypt', / (root file system)
  • remainder - 'for crypt' (for LVM).

Rationale: Logical volumes blow, and are not needed here. Naturally you must boot from somewhere, but /boot contains nothing sensitive. And I've had problems before where having / (root fs) on its own partition, even as a crypt-md, is much easier than when it's just an LV within a crypt-LVM – hence that's kept separate. The 950GB volume will be LVM'ed over the top of md-crypt, and inside it you can find living lots of heated arguments for various partitioning layouts for /var, /usr, /home, /pub and so on – knock yourself out. For my own part I tend to have home and pub LV's only, and that works well for me.

Within the Debian installer, configure the crypt partitions, and set sda2_crypt as / (root fs) and leave sda3_crypt unconfigured / unused for the time. It's easier to fiddle with this stuff once the box is up and running.

Also worth mentioning is that the absence of a swap partition is purposeful. It's an 8GB machine, so I'd be looking to have about 4GB of swap.

Three compelling reasons to use swap files rather than a swap partition – it's easier to adjust the size of your swap later, easier to encrypt than a swap partition, and swap files have comparable performance to partitions (particularly on a single spindle device).

Note that security of your swap is important – and if you really want a dedicated partition for swap rather than using this simpler method, then you need to read up on how to do this securely.

 

After setup, when things are ticking along

Set up swap files using dd to create them, making 4 x 1GB files (not for performance – purely for convenience when managing swap growth / reduction later).

As root:

for i in {1..4}; do dd if=/dev/zero of=/swapfile.${i} bs=1024 count=1048576; done
for i in {1..4}; do mkswap /swapfile.${i};  done
for i in {1..4}; do echo "/swapfile.${i} none swap swap 0 1" >> /etc/fstab   ;  done
swapon -a
free

I experimented briefly with the nVidia drivers, but the pain's just not worth it, and using the Nouveau drivers on Debian unstable branch is now pretty fine – very respectable performance, and no requirement for bimbling around with an xorg.conf.

 

Known problems

udevd stall, modprobe errors, intermittent seizes

During boot there's a problem occasionally exhibited with the kernel stalling on udev scanning for some tens of seconds, followed by lots of modprobe failures. This is an intermittent problem, and there's a few bug reports out there about this one, seemingly stemming from some DRM and/or TPM components that are sometimes found in laptops.

Two solutions are offered on the intergoogles. First, edit /etc/modprobe.d/modprobe.conf and add:

blacklist tpm_tis

Or add the following kernel parameter (via /etc/default/grub) 

# GRUB_CMDLINE_LINUX_DEFAULT="quiet "
GRUB_CMDLINE_LINUX_DEFAULT="quiet processor.nocst=1"

I tried both these, in order (some hours apart) and found that the latter solved the problem, whereas the former didn't seem to make any positive difference.

I've also noted some random total freezes of the machine (twice in the space of 6 hours, on neither occasion was the CPU really being pushed). It's early days, so not very compelling yet, but the processor.nocst=1 change seems to have prevented that happening too.

I ran a memtest86+ across the box for 8 hours, just to be sure it wasn't memory related (upper-memory problems tend to manifest infrequently).

Random freezes

These are well documented, especially on the Fedora and Ubuntu forums, with various Lenovo laptops, with some regular reference to Ivy Bridge architecture machines.

The symptoms are pretty profound – full system hangs, no sysreq access, let alone network visibility or text-consoles.

There are several approaches recommended on the intergoogle by the let's just fiddle with this and see if it works crowd:

  • Insist that Lenovo take the machine back for repair (typically a motherboard replacement)
  • Revert to i686, using PAE, to retain 8GB memory usage
  • Downgrading to the second most recent version of the BIOS
  • Fiddle with ACPI / APIC stuff (you know you're in unchartered territory when you get these blanket suggestions)
  • Add processor.nocst=1 to the kernel params
  • Add intremap=no_x2apic_optout to the kernel params
  • Upgrade to a kernel > 3.2

So far I've only tried the last three options, and am waiting to see how it plays out. I'm using 3.7-experimental from the branch of the same name ;)

Running with an external monitor (HDMI)

This works a treat .. but for the usual problems associated with any variation to your configuration. {sigh}

There's some great work being done on getting sane multi-monitor support in KDE and I expect that'll solve the problem Real Soon Now, but in the short term we're stuck with setting up xrandr (and variants, including KDE's plugin), which is still more than a bit painful to set up Just So.

No sound from speakers, but external audio (3.5mm) jack works fine

This is an especially weird problem that took me ages to even notice, as I almost exclusively use headphones in preference to laptop-speakers, for obvious reasons. However for things like Skype and G+ Hangouts, I can see the benefit of using built-in mic and speakers.

As at 2013-01-23 I've only just started exploring the problem. From what I can find it's not something other people have experienced, unfortunately. Having snotted the Windows partition it's not easy to check if the problem exists on another OS.

 

Unknown features (or my To Do list)

BIOS / Key-combo triggering of CPU dust-removal feature - need to confirm it does, under GNU/Linux. They reckon once a month. Flippin' heck. Cronable?

Easy swapping of screen outputs - there's some good work being done with KDE, but it's not yet in Debian unstable.

Easy flipping to wireless / wired networks - need to confirm wicd works as sanely here as elsewhere.