Musings from

Sat, 26 Apr 2014

Moving a Sputnik 3 to Ubuntu 14.04 LTS

by on :

I just upgraded my Dell XPS 13 Developer Edition (AKASputnik 3”) to Ubuntu 14.04, the newest LTS release, in order to hopefully clear up some remaining glitches and source some newer software more easily. So far it seems to have been a mostly painless process, although there were a few hiccoughs getting encrypted disks working to my liking. This is how it went.

Preparing for installation

Because the Dell 12.04 image contains a number of third-party packages, I decided on a wipe-and-reinstall rather than an upgrade. My experience with various distributions has been that upgrading from a system with significant third-party package presence in the core system (such as drivers and X configuration, as was the case with the Dell image) is asking for trouble.

I have a large, encrypted offline backup disk, so I just booted to the install live image, mounted that disk, and dd'd the entire SSD to it. I then also took an image of only the encrypted /home partition, for convenience. This way I have my entire configuration and all auxiliary data, if I need it, but in the best case scenario I only have to copy over the home partition and be done with it.

With that out of the way, I just unmounted the backup disk, unplugged it, and then blew away the partition table. I'm not clear whether this is ideal from a TRIM point of view or not, but it was at least fast and easy.

Initial installation

Unlike the 12.04 installer, the Ubuntu 14.04 installer knows about whole-disk encryption. Unfortunately, the only way it seems to be able to do it (at least, assuming you want to use LVM) is to encrypt the entire disk other than /boot as a single LUKS partition, and then make that partition a LVM physical volume. This means that every partition on the system is encrypted under one key, and that it is impossible to create clear partitions. Well, that's no good. Therefore, I had to work around the installer again. This time, it was easier because the live image already knows about both LVM and encrypted volumes.

After determining that the default installer wouldn't do what I wanted it to do (boring details omitted), I tried a couple of workarounds before I landed on an actual solution. Unfortunately, I wasn't able to do a completely encrypted install — I wound up having to do a clear install and then encrypt it. This does require more twiddling with config files than I would prefer, but it worked.

First off, I wanted to use LVM but I didn't want to allocate the entire physical volume to a single logical volume. For some reason, this is all the installer appears to know how to do. To get around this, I booted to the live image and partitioned the disk myself. I created a 256 MB /boot partition, a 16 GB swap partition, and an LVM physical volume on a partition spanning the remainder of the disk. On the physical volume, I created a root partition volume of 30 GB and left the rest free. That done, I started the installer and installed the system to the pre-created partitions using manual partitioning.

Setting up encryption

After installing the system, I booted it once and immediately shut it down to get a plausible /etc/mtab in place and generally populate things that may populate on boot. I then rebooted to the live image.

Armed with a ready-to-go disk image, I created another LVM volume for the encrypted root (named root-crypt) and LUKS formatted it per my earlier article on Ubuntu encrypted disks. I then used cryptsetup to mount it, and repeated the process for a home volume named home-crypt. These two volumes are given mapper names of root and home, respectively, when opened. I then mounted these volumes and populated the root with the newly installed image and the home volume with my backup image. For the root volume, I mounted both the installed root and the newly formatted image in separate directories under /mnt and copied the data across with rsync -a. For the home volume I used dd to put the encrypted image back byte-for-byte. Having done this, I deleted the unencrypted volume and then mounted these filesystems, /boot, and various other necessary bits as follows:

mount /dev/mapper/root /mnt
mount /dev/mapper/home /mnt/home
mount /dev/sda1 /mnt/boot
for dir in /proc /sys /run /dev; do
    mount -o bind $dir /mnt/$dir

This gets enough stuff in place to chroot to the encrypted install with sudo -H chroot /mnt. Once you're in, there's a variety of patching up to do before the system is bootable.

First, for some reason Ubuntu doesn't install cryptsetup by default. Without it, an encrypted root isn't bootable. It took me a few minutes to figure that out, actually, because why wouldn't it be installed? It's installed on the live image! At any rate, apt-get install cryptsetup takes care of that.

This will create an /etc/crypttab, but of course it doesn't know anything about the encrypted volumes that were just created. Therefore, it and /etc/fstab have to be patched up for the new configuration, and then /etc/mtab has to be brought into line so that update-initramfs will be able to do its job. For the first two files, they should look something like this (after prepping encrypted swap, per my previous article):

# fstab
/dev/mapper/root / ext4 errors=remount-ro,relatime 0 1
/dev/mapper/home /home ext4 relatime 0 2
/dev/mapper/cswap0 none swap sw 0 0

# crypttab
root /dev/vg0/root-crypt none luks,discard
home /dev/vg0/home-crypt none luks,discard
cswap0 /dev/sda2 none luks

The third, /etc/mtab, has to be fixed up to reflect the above mountings, which should be pretty straightforward. The old device names simply have to be replaced with the new mapper names.

With the filesystems configured, update-initramfs can be used to generate an initial RAM disk that has encrypted disk capabilities, and then update-grub can be used to fix up the root drive at bootup, as follows:

update-initramfs -k all -u

At this point, the system should boot, and ask for three passphrases on the way. Unlike 12.04, it even does it without undue graphical glitchery!

Fixing up features

This section will probably change as I locate more broken stuff, but so far it really has only required fixing hibernate and the touchpad (which is admittedly a biggie!).

First, the touchpad. For some reason, the i2c_hid module prevents multitouch from working on the touchpad, and generally causes it to be a little bit spastic. Fixing this is as simple as blacklisting the offending module. To do this, create a /etc/modprobe.d/blacklist-i2c_hid.conf file and place the single line blacklist i2c_hid in it. On the next reboot, it won't muck things up and synclient can be used to configure the touchpad the same as in 12.04.

The good news about hibernate is that it's a lot easier than it was in 12.04! All I had to do to get it working was edit /etc/initramfs-tools/conf.d/resume to point to the new encrypted swap device, rebuild the initial RAM disk again, and it seems to work fine. For some reason I have to decrypt both the root disk and the swap disk on resume (in 12.04 I only had to decrypt the swap disk), but that doesn't seem like a big deal.

Update 2014-04-26: The rsync-across method for achieving separately encrypted LVM volumes did have some collateral damage — rsync does not preserve capabilities. This first manifested itself as an inability for non-root users to ping, receiving the error message “ping: icmp open socket: Operation not permitted”. I fixed this by removing the ping package (which took with it ubuntu-minimal) and reinstalling it via ubuntu-minimal, which restored the cap_net_raw capability. There may be other, harder-to-fix permissions problems to deal with in the future. We shall see.


I'll admit that I basically didn't even look at the new default UI. I just installed my bevy of usual packages and logged right back into fvwm. I therefore can't say much about that.

However, I have been pleased with the Just Workingness of all the other stuff I've used so far, modulo the encrypted disk setup pain documented above. It also seemed less painful than 12.04 was, but that may just be because I've been through this rodeo recently. The fact that the wireless works on the live image and that it contains all of the packages I needed to hack up the setup out of the box make things seem easier, for sure. The (relative) simplicity of getting encrypted hibernate going was a big bonus, too. They're within epsilon of having it work configuration-free!

It's only been a few hours. There may be some time bombs in here I don't know about yet.

tags: luks, lvm, sputnik
path: /xps13 | permalink | Comments

Wed, 12 Feb 2014

A week of using the Dell XPS 13 Developer Edition (Sputnik 3)

by on :

I've been using the Dell XPS 13 Developer Edition (AKASputnik 3”) for about a week now, and it's time for a follow-up to my first impressions review. All in all, I think I hit on most of the critical points in that first review, but there are a few things worth clarifying or reiterating, and some new experiences to relate. That's what this post is.

Overall impressions

All in all, I'm still very pleased with this machine. I have a few gripes about the system software, some annoyances with the finish (more on that later), and a tiny bit of lingering sticker shock, but I am happy with its performance, portability, and apparent durability. I think it was a good selection for my needs, and I doubt I could have done substantially better.


The experience of reinstalling Ubuntu 12.04, its supposedly supported operating system, woke me up to the fact that not all is entirely happy in Linux laptop support-land. I was unable to get a different distribution installed with some limited futzing (although I'm pretty confident it can be done, given some effort), and 12.04 is getting a little long in the tooth, so that's a little bit annoying.

Aside from that, I tried out both Unity and XFCE 4 before ultimately returning to my old standby, FVWM. Neither of the former two did anything for me, and both had fatal flaws with respect to window focus and placement. However, the combination of needing/wanting various “laptop-y” features and the desire to generally refresh my desktop integration experience has led me to spend a bit more time putting FVWM together with the desktop infrastructure that has sprung up since the last time I paid much attention. I'm still using FVWM and rxvt-unicode as my primary (non-Emacs) environment, but I've now hooked in NetworkManager, gnome-keyring, libnotify, and various other functionality to a greater or lesser degree. I'm using stalonetray for a notification area (I was previously using a program called wmsystray, and the original author expressed amazement at its continued existence some years ago), some sort of policy kit daemon for gnome-keyring support, and nm-applet to talk to NetworkManager.

Some people wouldn't call that “desktop integration,” but it's a step forward for me.

The sound situation is not ideal at all. ALSA card 0 is the HDMI output, which is inconvenient, and Pulse does some sort of weird thing where if I mute any of three separate channels on ALSA card 1 (the regular sound card), it mutes all three. Unfortunately, unmuting requires unmuting each one individually, and all three (master, speakers, and PCM) are required for sound output. I was able to work around that by using alsamixer -D pulse, which presents exactly one playback and one record channel, and mutes appropriately. Oh, and the reason I wound up using alsamixer at all? I couldn't find a system tray audio control that even had mute.

Suspend and hibernate work fine once the xfce4-power-manager applet is loaded, which is fine, because I'm using it for battery and charging status indication anyway. It doesn't notify me of impending suspend due to low battery, though, so that's taken me by surprise a couple of times. Its preferences suggest that it will, but I haven't seen it.

Other than sound quirks, and some agedness issues stemming from Ubuntu 12.04, I'm finding little to complain about in the software department. I mean, it's Linux.


We've been over the networking thing already, so I won't repeat it here, but it's a little annoying. Still, I expect it to get better as time goes on.

There are some more annoying driver (or perhaps more correctly, driver integration) issues. For example, the Fn keys on the keyboard. Some of them work perfectly (display brightness, for example), but some of them do nothing at all. None of the media keys (play, volume, etc.) generate a keysym that I can tell, and neither do they just Do their Thing. I assume they use some sort of new-fangled communication mechanism to talk to DE software (they work in Unity, for example), but I've been unable to figure out what it is. It's not X keysyms, it's not ACPI button presses, and it's not dbus. Suggestions are welcome on this front, because I'm not really sure where else to look. I'd really like for at least the mute and volume up/down buttons to work in FVWM.

The touchpad, while generally awesome, has its driver disappointments as well. For example, three- and four-finger gestures don't seem to generate any X11 events, although the touchpad seems to recognize them (because they don't generate motion or click events, either). For the most part it's fine, though, after getting cozy with synclient — I initialize it with synclient TapButton3=2 HorizTwoFingerScroll=1 VertEdgeScroll=0 on each login.

Other than those few things, Everything Just Works. No complaints about that!


It's awesome. That's really the bottom line. It's small, light, has an expansive screen in spite of it, and (relatively speaking) screams when it spins up those cores. The battery life is 6+ hours (sometimes as much as 7-8) under realistic (for me) loads. The qualifier there is that, while I'm a deep systems guy for a real-time Java vendor, and I do a lot of editing for development on my laptop, I actually do my compiling mostly on dedicated compilation machines. My typical CPU load is pretty low. That said, it will play streaming video or do Google hangouts for extended periods of time without complaint.

I still think the touch screen is gimmicky. I've tried to use it a few times, but a laptop screen just isn't in a particularly good location for poking with a finger — particularly when it declares itself to be 96x96 DPI and everything is tiny. It also doesn't act like a touch display in a lot of ways. For example, touch and drag doesn't scroll, and neither does two finger touch and drag. I'm pretty sure the hardware is multitouch, but it doesn't seem to multitouch. Maybe something will come along to change my mind on this front, but as of now I don't get it.

The top surface (palm rests and bezel) and keyboard both show fingerprints like it's their job. I mean, it's actually kind of amazing they can print with such minimal contact. It makes the thing look a little bit grungy and well-used, even though it's almost brand new. My hands aren't normally greasy or sweaty, either.

The built-in camera is pretty underwhelming. Its contrast is distractingly high in almost all indoor lighting conditions, and it displays a fair amount of noise. It works, but it could certainly be better. On the other hand, I've heard no complaints about audio quality from the associated microphones, so that must be OK.


As they say on the 'bay, A++++++ would buy again; great transaction!. A little bit of software love from Dell (say, an update to 14.04 when it comes out in April, and completed multitouch for the touchpad) would improve the experience even more.

tags: sputnik
path: /xps13 | permalink | Comments

Sun, 02 Feb 2014

Setting the Sputnik 3 up with Encrypted /home

by on :

This is basically a guide for setting up a LUKS-encrypted home directory on LVM in Ubuntu 12.04, with the added wrinkle of working around the Dell installer setup bugs detailed in a previous post. Most of these instructions should work on other Ubuntu systems — you just probably don't have to do it this way, because you can set up LVM and LUKS at install time in the Ubuntu installer. Or so I suppose, I haven't actually done it.

This procedure makes a number of implicit assumptions. I'm going to make them more explicit here, so that you can decide if it's appropriate for your use:

  • My primary concern is protecting my data from loss/theft and prying eyes, not complete secrecy. In particular, this has implications on the configuration of LUKS and trim, and prepping the partition for storage. If you have greater privacy needs, there are other tutorials with information on how to mitigate some of the shortcomings here.
  • I am assuming that all important information that is privacy-sensitive is stored under /home. In particular, I am not (as yet) encrypting /tmp or any of the system directories. This assumption is true to a first approximation for the system on which I am installing it. Your needs may differ.
  • Hibernate is a desired feature for me. Since the keys for encrypted partitions are stored in memory, and thus flushed to disk at hibernation time, this necessitates encrypted swap. Encrypted swap is a good idea anyway, since some of my precious data might be in RAM, but failing to use encrypted swap with hibernate essentially provides a direct path to decrypting your entire disk.
  • I am willing to wipe the entire machine to set this up. I just got this laptop a couple of days ago, and I have good backups already. If your situation is different, you might want to take a more staged approach, resize partitions, etc. That task may be easier or harder, depending on your existing configuration and how you go about it.

Note: A mistake in the following, either in my instructions or in their execution, will almost certainly result in lost data. When followed correctly, these instructions will wipe your machine clean. Make sure you understand what you're getting into before beginning.

Repartitioning the disk and installing the system

I used the Dell recovery image, written to a USB flash drive, to repartition the disk. Hop through the prompts and tell it that you want to install only the Linux OS, that you want to do a fresh install, and that you want to set up the disks manually. I don't recall the exact prompt wordings, but if you're prepared to follow this guide you really shouldn't need them. If you get too confused at this point, abort — it doesn't get clearer from here on out.

Create three primary partitions. The first should be as large as you expect the system to be (I used 40 GB, which should provide about 20 GB of overhead). It's not going to be easy to expand this later, so be suitably generous. You can always store non-sensitive data there if you need to. The size of the second depends on the size of the third, which will be swap; it should be the remaining disk space minus about twice as much space as you have RAM. My XPS13 has 8 GB of RAM, so I used 16 GB of swap. Note that the recovery installer stupidly uses 1,000,000 byte megabytes, so you may want to do a little bit of math if you're compulsive like I am. Set this second partition to unused, we're going to format it later. The third partition is swap. Use the disk space you set aside in creating the previous partition, and mark it as swap. It won't be encrypted for now, but that's OK.

Let the installer do its thing. When it gets all done and wants to restart, though, don't restart just yet. As I discuss in my previous post, the Dell installer is buggy and doesn't flag the boot partition as bootable. Therefore, just before the reboot, hit Ctrl-Alt-F1 and run sudo fdisk /dev/sda. If you partitioned the same as I described above, your boot partition is /dev/sda1, so hit a to toggle the bootable flag, and select 1 to select the first partition. If you partitioned differently, you know what you're doing, so do it here. Press w to write the partition table to disk (it may tell you it couldn't be loaded by the running kernel and will require a reboot, that's fine). Press Ctrl-Alt-F7 to go back to the installer, and hit Reboot.

Installing necessary packages and obtaining a setup environment

At this point, we're going to need some packages not present in the base install, for LUKS and LVM. We're also going to want a setup environment that doesn't use /home. We'll achieve both of these in one step. Don't log in to X11; instead, hit Ctrl-Alt-F1 to get to a virtual console and log in there. Then issue these commands:

    cd /
    exec sudo -H -s
    apt-get install cryptsetup lvm2

This will get you a root shell that isn't using any files under /home and provide the functionality necessary for the rest of the setup. use this terminal (and its root shell) for the remainder of this procedure.

Configuring encrypted swap

The next step is encrypted swap, because we need encrypted hibernate before we set up an encrypted /home. There are instructions for encrypted swap on the Ubuntu community wiki, although I don't quite like how they handle some things. For one, you don't need to enable ecryptfs and muck with the Ubuntu encryption solutions to get started, so don't do that — it just makes headaches. The cryptsetup package installed in the previous section provides everything necessary. The only major difference is that you'll have to create your own /etc/crypttab. You're going to be doing that for /home anyway, so not a big deal.

Note that you can follow these encrypted swap instructions to set up encrypted swap with hibernation without doing basically anything else in this document. Be forewarned that a misstep in the partition setup process will result in lost data, however.

Skip everything in those instructions up through How to Set up Hibernation, and do this instead:

  1. Run swapon -s and make note of the disk used by your swap device. If you partitioned as above, it will be /dev/sda3. The following will assume that device.

  2. Run:

    swapoff -a
    cryptsetup --verify-passphrase luksFormat --hash=sha256 \
        --cipher=aes-cbc-essiv:sha256 --key-size=256 /dev/sda3

    You may or may not want to tweak the cipher options; the recommendation above is what I used, but it does not represent any sort of guarantee on my part that it's suitable for your purposes. You'll be prompted for a passphrase to encrypt the swap partition; this is very important. This passphrase will be used to generate the key used to encrypt your swap partition, so make sure it is good and make sure you can remember it. I recommend using something much longer than your typical login password. If you forget this passphrase, you'll have to set up your swap partition again following these instructions; you also won't be able to resume from hibernation if you hibernate and then can't remember the password. You have been warned.

  3. Next, we need to mount that partition and set it up for swapping. Do that as follows:

    cryptsetup luksOpen /dev/sda3 cswap0
    mkswap -f /dev/mapper/cswap0

    It is important that you leave that partition mounted, and that we set it up for swapping during this session, so that the initramfs image created later knows what modules to include to mount it on boot. The name cswap0 is somewhat arbitrary, but it is important that it is consistent from here on out.

  4. The system then has to be told about the new swap partition, and its encryption configuration. To do that, you're going to edit /etc/crypttab and /etc/fstab as follows. First, open /etc/crypttab and insert the following line, which tells the system that there is an encrypted swap partition on /dev/sda3, that it uses LUKS for configuration, and that the user should be prompted for the passphrase:

    cswap0 /dev/sda3 none luks

    Next, remove or comment out the old swap configuration line in /etc/fstab and replace it with this:

    /dev/mapper/cswap0 none swap sw 0 0
  5. Run swapon -a and make sure your swap initializes correctly. If it doesn't figure out why not now, or you'll be sorry later.

Now that you've set up encrypted swap, follow the remainder of the instructions linked above to fix up the hibernation stuff. Skip generating the initial RAM disk, if you're going to go on to setting up an encrypted home partition, because you're just going to have to do it again later, anyway.

Configuring LVM and LUKS for encrypted /home

This part of the setup can likewise be followed without doing the reinstall or setting up encrypted swap, but as mentioned above it doesn't make a whole lot of sense to set up encrypted partitions and not encrypted swap if you plan to hibernate. If you don't plan to hibernate, you should be OK — but I make no guarantees.

Setting up an LVM disk, volume group, and logical volume is pretty straightforward and well-documented elsewhere, so I will include the commands here but not the rationale or detailed description. Red Hat offers a really fantastic LVM administration guide that should answer almost any questions that come up before the point that we start talking about encryption. So with that said, do this (again, this assumes the partitioning scheme set up earlier in this guide, adjust as necessary or lose data!):

pvcreate /dev/sda2
vgcreate vg0 /dev/sda2
lvcreate -Z n -L 100G -n home-crypt vg0

This should create a 100 GB logical volume called /dev/vg0/home-crypt. Feel free to adjust names and sizes as you wish, but names have to be consistent from here on out. Note that there are mechanisms for resizing LUKS volumes and filesystem sizes, so you can always fix things up later; I used 100 GB to leave room for additional volumes for virtual machines.

Setting up encryption for this volume is substantially similar to setting up encryption for the swap partition, but we don't have to jump through the hibernation hoops.

  1. Run:

    cryptsetup --verify-passphrase luksFormat --hash=sha256 \
        --cipher=aes-cbc-essiv:sha256 --key-size=256 /dev/vg0/home-crypt

    The same caveats regarding encryption setup for the encrypted swap partition apply here. Please review them if you are not fully aware of the consequences.

  2. Attach the encrypted volume and create the filesystem with:

    cryptsetup luksOpen /dev/vg0/home-crypt home
    mkfs.ext4 /dev/mapper/home

    You're going to want to leave this attached from here on out, too, so that update-initramfs can do its thing.

  3. Update /etc/crypttab and /etc/fstab as follows, correcting for any differences in naming you may have chosen:

    home /dev/vg0/home-crypt none luks,discard
    /dev/mapper/home /home ext4 relatime 0 1

    Note the discard option in the LUKS configuration above; this enables TRIM support and has security and privacy implications. In particular, it reveals which portions of the disk your filesystem is using. It may make certain forms of cryptanalysis easier, and will almost certainly leak information about how much data you are storing on the encrypted partition. I believe the tradeoffs are appropriate for my particular usage scenario, but you should understand the considerations before enabling it. Note that if you do not enable it, you may also need or want to take other steps not included in this document. There are various resources on the Internet discussing these tradeoffs, and I suggest you consult them if you have questions.

That completes setup for the partition that will hold your home directories. If you have data in /home already, you may want to mount /dev/mapper/home someplace and move it over now. You will almost certainly want to mount it and create a home directory for your user (remember to chown it appropriately!).

Creating an updated initial RAM disk and booting

The final critical step is creating an updated initial RAM disk that contains the modules and crypto configuration to boot your machine with the encrypted swap and filesystems in place. At this point you should double check your /etc/crypttab, /etc/fstab, and hibernation configurations, and make sure the swap partition and encrypted home partition are mapped (they don't necessarily have to be mounted). When you are sure that everything is in place, run this command:

update-initramfs -u -k all

It should complete without errors. When it does, your system is set up, and you can reboot. I recommend doing so now. Upon bootup, you will be prompted for the passphrase first for your swap partition, and then for your encrypted /home partition. The first prompt is pretty and nice and everything works normally. For the second prompt, for some reason there will be some on-screen glitches (at least, there are on my machine), but everything works normally anyway. Note that you will be prompted three times for each passphrase if you make a mistake on entry, and after the third time bootup will continue without the partition in question. Not having /home in particular is not going to lead to a nice day, so type carefully and remember those passphrases!

tags: hibernate, luks, lvm, recovery, sputnik, swap
path: /xps13 | permalink | Comments

Installing linux on an XPS13 isn't as easy as running it!

by on :

There are likely to be a lot of these XPS13 posts, so I've created a category for them. This is the first post in that category.

Wherein a reinstall is harder than it should be

So I decided to wipe and reinstall my XPS13 for a variety of reasons, most of which boil down to encrypted /home. I found that that process was somewhat more difficult than it could otherwise have been, mostly because a) the Sputnik 3 install image does not have networking support, b) the recovery process doesn't partition correctly, and c) nothing else has networking support, either.

The setup

Let's start with networking support. Apparently, the wifi adapter in the Sputnik 3 is about five and a half minutes old. You have to have a very new kernel, and very new firmware, to get it to work. I have read variously that Linux 3.10 and 3.12 are the requisite kernel versions, and several different comments on firmware blobs. I don't know for sure, I haven't gotten that far. The bottom line is that neither Debian 7 (wheezy) nor Debian testing (jessie) netinst images would work, even with extra non-free firmware packages. That's not entirely unsurprising, but what is surprising is that Dell's own recovery image doesn't appear to have the appropriate driver and/or firmware. This means that you can't install software to the recovery image system.

... Which is unfortunate for me, because the whole point of this exercise was to set up the drive using LVM and LUKS encrypted partitions. Ubuntu 12.04 supports both of these things just fine, just not on the Dell recovery image. Ugh.

Reinstall #1

I decided to do things the “hard” way, leave everything but /home unencrypted, and just set up the encrypted /home partition once the recovery image had done its thing. For this to work, I deleted the partitions I didn't want, created a / partition, a large unused space for LVM, and a swap partition, then installed. The recovery image appeared to be happy, and did its thing for a while. So far so good. Except ...

When the laptop rebooted, it said Operation system not found. Yeah, “Operation system“. The Chinese-to-English translator was sleeping on the job that day, apparently. I had left a small FAT partition on the drive that appeared at a glance to be for UEFI, so I thought maybe it required some updates to get things working. I was a bit confused, though, as the system was configured for legacy boot and I wasn't sure why it would want that partition, anyway. So, figuring I could just do a complete restore (restoring the UEFI and recovery partitions, as well as the Linux install) if things went too wrong, I took the nuclear option.

Reinstall #2, and resolution

I rebooted to the recovery image, wiped the UEFI partition as well, and reinstalled with only the Linux install and empty partition. Same as before, everything appeared to go fine, then reboot, and whoops, no dice.

So I said to myself, “surely it's not as simple as they installed grub to the OS partition and didn't mark it bootable!,” and I rebooted to that !*$@& recovery image AGAIN. I fired up fdisk, marked /dev/sda1 bootable, wrote, and rebooted — without even looking at their GUI. Presto, the annoying setup video played and I was off to the races.


I'm done jacking with this thing for tonight. We'll see how the rest of the saga goes tomorrow (and maybe I'll write it up). This situation doesn't really significantly damage my opinion of the hardware, as it's obviously still great, but it does give me some pause regarding Dell's commitment to the product. Ubuntu 12.04 is pretty old, there doesn't appear to be a way to install anything newer (at least, without doing some installer futzing) at the moment, and even the Dell installer doesn't really seem to be brought up to speed for the new hardware. It's almost like they shipped with the Sputnik 2 installer and some extra install-time packages.

The charitable part of me hopes that this is because this product is only a month old, and they're already prepping 14.04 for April. Any word on that, Dell?

tags: bugs, recovery, sputnik
path: /xps13 | permalink | Comments

[ | | ]