Notes on Inspiron 11 3147

  • Dell does not acknowledge it, but you can install an 8GB DDR3 SODIMM as long as it is low voltage (1.35V). I used “Crucial Ballistix Sport SODIMM 8GB Single DDR3 1600 MT/s (PC3-12800) CL9 @1.35V 204-Pin Memory” (BLS8G3N169ES4)
  • If the touch screen stops working, check the Device Manager to see if the USB 3 controller has become disabled. I do not know exactly why it would become disabled, but it did at one point for me. My guess is that if the controller detects a short it will disable itself, but I’m not sure.
  • If you reinstall Windows from scratch, the touchpad will not work correctly even if you reinstall the drivers from Dell. The speed will be wrong, and it will not disable itself when you fold the laptop to tablet mode. I found the solution online; to summarize:
    • Uninstall Dell Quickset, if installed.
    • Uninstall Dell Synaptics Touchpad driver, if installed.
    • Reboot.
    • Install the I2C Controller driver from the above link. As of 2014/12/26, Dell has added the I2C Controller driver as an official driver for the 3147, so you can download it directly from Dell.
    • Install Dell Synaptics Touchpad driver.
    • Reboot.
    • Install Dell Quickset.
    • Now you should have have access to touchpad settings from the notification tray, and it should disable itself properly in tablet mode.
  • Two-finger touchpad scrolling in Chrome will cause keyboard focus to be lost. There are solutions to be found on the internet for tweaking the Synaptics control panel to show a hidden option which fixes it. However because Dell customizes the Synaptics control panel, they do not work. By combining information from a few sources (notably from this superuser post) I was able to make it work.The key is to set this in the registry:
    [HKEY_CURRENT_USER\Software\Synaptics\SynTPEnh] “GlobalScrollingConfig”=dword:00000009

    Some other sources will say to set this in HKEY_LOCAL_MACHINE, but it seems (as one might deduce) that the setting in HKEY_CURRENT_USER takes precedence.

    I also found that this made the scrolling itself much more smooth (pixel-wise instead of line-wise perhaps) but I didn’t find anyone to corroborate this.

Supporting IE is still a thing.

An interesting tidbit I came across today.

Apparently Internet Explorer won’t make an XMLHttpRequest from a given security zone into a more secure zone. It makes perfect sense, but I spent a ton of time figuring out that it wasn’t a CORS issue. I even spent a bunch of time looking into P3P – blech. I didn’t even realize the sites were in different zones until I had a eureka moment.

An actual update

Hmm, I haven’t posted here in quite a while. Oh well.

I was working on a utility a couple days ago to help me verify the checksums of a large set of files to help prevent against bit rot. Basically, it is a beefed up version of md5sum which can operate on an entire directory tree and update the checksum database somewhat intelligently.

Perhaps someone will find it useful – I decided to post it on github.

Creating an alpha-blended cursor in Win32

MSDN has a fairly nice article about how to create an alpha-blended mouse cursor in Win32.

You can read the article at

The long and short of it is that you create a BITMAPV5HEADER structure to describe your bitmap, then you call CreateDIBSection to create a DIB to hold it, then copy your pixels in, and bam, it works.

Well, most of the time.

I’ve spent multiple hours today wrestling with this code which wasn’t working for me. I couldn’t get the alpha channel to work properly. At first I didn’t think the code worked at all, but with some input from others, I realized that the code did work exactly as it was listed, but that I had modified it a little.

Specifically, I was trying to alter the byte ordering. The BITMAPV5HEADER struct has 4 parameters, bV5RedMask, bV5GreenMask, bV5BlueMask, and bV5AlphaMask, which ostensibly allow you to configure which bits in the bitmap correspond to which colors.

The example, as given, was arranging the bits as AARRGGBB, which I believe would typically be called BGRA and I believe is typically the default on Windows due to its little-endian nature. However, the bitmap I wanted to use as a mouse cursor was arranged AABBGGRR (RGBA) as it had its origins in OpenGL land.

After wrestling with this for hours, I came to a conclusion. You just can’t use an RGBA bitmap to create an alpha-blended mouse cursor. I haven’t gone to the lengths of testing if you can create an RGBA HBITMAP at all (my guess: no), but it definitely does not work for mouse cursors. No way, no how, no amount of beating it with a stick. It won’t work.

I had to end up coercing the bitmap to BGRA (which isn’t hard, or all that expensive, but irritating), and now it works fine.

My guess is that there is some sort of optimization going on deep under the hood, but unless Microsoft wants to speak up about it, I doubt I’ll ever know. I just wanted to get this information out ‘on the webs’ because Google was sure failing me all day when trying to research the problem.

Converting an EC2 image to a VMWare virtual machine

I recently had occasion to convert an Amazon EC2 AMI image into a VMWare virtual machine, for local testing. Much of the process can be learned online, and I may go into details about it later, since the information is scattered, but there was one particular step that stumped me for quite some time, that I would like to document for the future.

I was able to quite successfully unbundle the AMI, and ‘dd’ it into a partition inside a fresh VMWare VM. It could be mounted and played with, but would not boot, because it lacked a kernel. You see, Xen (which Amazon relies upon), unlike VMWare, does not emulate the full x86 boot process (at least in its standard configuration)- rather, the Xen host itself provides a paravirtualized kernel which is used to boot the Linux operating system stored within the image. Therefore, you will find most EC2 AMIs lack a kernel, since it is provided by the host (though they do contain a matching set of modules).

The solution to this seemed simple- mount the disk, chroot into it, then apt-get install a kernel package (the AMI was based on Ubuntu). However, apparently apt-get is.. a pretty elaborate system, and apparently relies on some things that would not normally be inside the chroot jail.

Specifically, it was trying very hard to work with pts’es, and complaining loudly (and subsequently segfaulting!) because /dev/pts was not valid within the jail. There are about a million pages on the internet that attempt to address this problem by doing something like:

mount -t devpts devpts /mnt/dev/pts

However, no amount of beating on this command with a stick would make it work for me. I tried also mounting /proc and /sys within the chroot, to no avail. I also tried to bring up udev within the jail, which appeared to work, except that it didn’t. It was really very unhappy with all of the techniques I was trying to get a valid /dev/pts tree (even though many of them appeared to work cosmetically).

Finally I stumbled across a working solution:

mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts

Aha! Instead of putzing around trying to get another copy of /dev/pts mounted, just use the bind option of mount to remount part of the filesystem in a second place. A clever hack, and it worked.

So, then I had a working copy of apt-get in the jail, and I could get on with fixing the other million things that go wrong when you convert an EC2 AMI to VMWare.

LVM and device mapper

So I ran into a small issue with LVM last night, and I thought I’d share my solution. I am by no means an expert on LVM, so whenever I encounter a problem, it is a learning experience.

Last night I moved around the drives connected to my file server, so that some of them were now connected to a different SCSI interface. Now, normally I filter the devices that LVM sees (through the filter directive in lvm.conf), so that there are no mishaps about which volumes LVM will let me touch. Because I have a lot of drives attached, and because Linux likes to rearrange the /dev/sdx names every other day, I use the nodes in /dev/disk/by-path to construct my filter.

Some of my drives are connected by USB, and some of them to SATA controllers. Previously, there was one USB and one SATA controller involved, so my filter directive looked like this:

filter= [
  "r/.*/" ]

However, I moved some of the drives connected to pci-0000:04:00.0 to a new controller that would live at pci-0000:05:00.0. Because of this change, I did not expect my LVM volumes to mount properly at boot- the filter should exclude those drives. I was surprised when I rebooted and my volumes mounted fine.

Now, this wasn’t actually a problem, since my volumes were mounting (which is the desired end goal), but I was concerned that my filter was not being respected. I ran through the various LVM ‘scan’ utilities (pvscan, vgscan, etc.) and they complained that they could not see all of the volumes, as I would have expected. So why were they still mounting?

As it turns out, it seems that the filter directive in lvm.conf only affects the lvm command-line utilities, but has no bearing on which LVM volumes the kernel device mapper actually sees. So, to restore my system to the state that I expected it to be in, I did the following:

  1. Unmount all of the LVM volumes.
  2. Issue `ls -l /dev/mapper`. Note that the unexpected logical volumes are still there.
  3. Issue `dmsetup remove_all`. This is the magic command that tells the device mapper to forget all device definitions that are no longer valid. In doing so, it appears that it requeries LVM, which at this point will read its configuration and take the filter into effect.
  4. Issue `ls -l /dev/mapper`. Note that the unexpected logical volumes have now been removed.

Now, I had the system in a consistent state, where there were no device mapper nodes referring to volumes that shouldn’t be visible. At this point, I of course wanted to get the system back into a state that was both consistent and working, so I did the following:

  1. Revise the filter definition in /etc/lvm/lvm.conf. My new filter definition looks like the following:
    filter= [
      "r/.*/" ]

    Essentially the same as before, but now with the disk controller at pc-0000:05:00.0 added.

  2. With the filter revised, how to recreate the device mapper nodes for the newly-valid volumes? Simple… Issue `vgchange -ay`. This tells LVM to make all volume groups (and their constituent logical volumes) active again. In doing so, the device definitions will be re-introduced to the device mapper, and the nodes will reappear in /dev/mapper.
  3. Issue `ls -l /dev/mapper`. Observe that the logical volumes have reappeared.
  4. Remount your volumes with `mount -a` or whatever is appropriate for your setup.

There you have it. I didn’t actually effect an obvious change by doing all of this- my volumes were mounted both before and after. However, I learned a bit about how the device mapper and LVM interact, and I learned about under what actual effect the filter directive in lvm.conf has. Now I feel more confident about using the LVM tools to do what I want.


Well, I guess this site is live, now.

I’ve created this to serve as more of a professional and technical blog. I’ll probably post the occasional review, code snippet, or piece of sysadmin wisdom here. Personal stuff goes.. elsewhere.

I wouldn’t expect this to be updated terribly often, but I’ve been posting tidbits elsewhere, and they always feel out of place. Hopefully this will serve as a better home for them.

As to the site design- sorry, I am not a graphic designer, and make no claims to being good at web design. So this is a pretty canned layout, and will probably stay that way. Oh well.