Prepare installation medium

Boot from USB medium

Press Template:Keypress to get into the boot menu. If the USB bootable device is not listed, enter the configuration menu and directly press Template:Keypress to save. Press Template:Keypress again on reboot: This time the USB bootable device should appear in the menu.

Select 'Boot Arch Linux (x86_64)" and press Template:Keypress. The installation system will be booted and you will end up with a terminal.

Partition the disk

As earlier mentioned this installation covers a setup with an encrypted hard drive and LUKS on top of it. Therefore we need at least three partitions:

Note: You can also keep the first two partitions in the default setup, especially if you want to dual boot windows. Those are UEFI boot partition and GPT partition.

We run gdisk /dev/sda to start the partition manager. By typing d we are capable of deleting all existing partitions and start with a fresh configuration.

Now use n to create new partitions:

UEFI boot partition:

ID: 1
Start (sector): <empty>
End (sector): +512M
Code: EF00

System boot partition

ID: 2
Start (sector): <empty>
End (sector): +200M
Code: <empty>

Encrypted system partition

ID: 3
Start (sector): <empty>
End (sector): <empty>
Code: <empty>

The <empty> command means that you leave the field in the prompt empty and just hit Template:Keypress directly. After creating those partitions enter p to print the partition table which should like the following:

Configure mkinitcpio.conf and create initial RAM disk

Configure rc.conf

Edit /etc/rc.conf and set:

USELVM="yes"

Configure bootloader

Load the required modules:

modprobe dm-mod
modprobe efivars

Note: running `modprobe efivars' should display a few lines, confirming the success of the module addition. If such "efi variables" are not set up properly, errors will ensue and you won't be able to reboot on your partition correctly. One of the way to have such efi variables is to make a bootable UEFI device using UEFI#Create_UEFI_bootable_USB_from_ISO and to boot on it properly.

Note: Kernel parameter pcie_aspm=force status is unsure: Ubuntu wiki recommends it, but UX31E Arch wiki says it should not be used. There is no noticeable problem when it is added to the list, so it is probably safe.

Function keys

Note: A working keymap means that there is some output in xev when the key combination is pressed OR that the functionality is built in and "just works". It does not means that the keymap is linked to the functionality. For that it is often necessary to add a keyboard shortcut by the method of your choice or to use a desktop shell with built-in shortcut support for the keycode in question. For some of the keys the function operates on a BIOS level and no shortcut is needed.

This table shows the function keys, their intended function, what keycode (if any) X recognizes and whether the function key operates at the BIOS level or if it needs a shortcut.

Screen backlight fix

Warning: This is highly experimental. It works for the UX32VD with bios 2.06, no guarantee that it works for different configurations.

First off, this method requires that you know what you are doing (although there are good tutorials anyway), and needs a little bit patience. It also requires that you have the hexidecimal dump and undump package xxd available in the AUR: https://aur.archlinux.org/packages.php?ID=35311 .

#!/bin/bash
#
# Asus UX32VD acpi backlight fix
#
# Copyright(C) 2012 Eugen Dahm <eugen.dahm@gmail.com>.
#
# fix is based on a proposed bugfix posted on <[url]https://bugs.freedesktop.org/show_bug.cgi?id=45452[/url]>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#
# Asus UX32VD acpi backlight fix
# Disclaimer!!!! not recommended to use if laptop is not the Asus UX32VD\
# probably works with other models too, but the didl and cadl offset needs to be extracted
# from the dsdt
# Tested with bios 2.06
# IGDM_BASE has to be determined for each notebook
# IGDM is the operation region (\_SB_.PCI0.GFX0.IGDM) containing the CADL/DIDL fields
# \aslb is a named field containing the base-address of the IGDM region
# this address depends on the installed ram |-

load module acpi_call.ko.gz with insmod or copy to /lib/modules/.... and modprobe

echo '\aslb' > /proc/acpi/call

cat /proc/acpi/call

this is the IGDM base address - initialize the IGDM_BASE variable with this value in the script

Initialize your bios with this script on boot :

# echo "/usr/local/share/backlightfix" >> /etc/rc.local

Execute the script and hope the backlight buttons work afterwards. If they don't you probably have to disasselbe the dsdt for yourself, because you have to adjust the following 2 variables in the script:

DIDL_OFFSET=0x120
CADL_OFFSET=0x160

These are the offsets on the Asus UX32VD bios version 2.06. Try google to find a tutorial how to disassemble the dsdt.

Getting the DIDL and CADL offsets

Now comes the funny part:

open your disassembled dsdt. The should have the filename dsdt.dsl.

find the operationregion IGBM. It should have a Field statement below, and probably looks something like this:

This specifies some variables in this IGDM field (for me, they look similar to a c struct, except that you don't need to give the size of each element in a struct).
The numbers are the size for each element in bit.

You must add those field sizes until you reach the DIDL variable. With the UX32VD the DIDL offset is easy, because of this statement:

..
Offset (0x120),
DIDL, 32,

..
Don't know exactly why they use the Offset statement, since this is somewhat redundant. It tells you that the following element has the offset 0x120.

Since I thought it is obvious what this statement does, I didn't bother to look it up in the dsl language specification. I thought it tells the bios that the following
variable starts with an offset of 0x120 bytes relative to the previous element, but I was wrong. It basically tells you/bios that the following variable starts with an
offset of 0x120 relative to the beginning of the opregion (in this case its completely unnecessary).

Now the only thing left is the CADL offset. Add the numbers starting from DIDL until you reach CADL and add it to your previous offset. This should be the 2nd needed offset.

After updating both offset variables in the script and executing it again, the backlight should now work (no guarantee).

Solid State Drive

Touchpad

Tip: Multifinger taps: Two finger for middle click; three fingers for right click.

HDMI plugged at boot

There seems to be an issue whereby having an HDMI device plugged in at boot results in the screens being switched and also the laptop screen not coming on. To make this more bearable you can automate switching HDMI on with the following udev rule and script:

Other Devices and Drivers

mei

PCE device 8086:1e3a, the Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 and the associated device "/dev/mei" (10,59) relating to an Intel-specific hardware monitoring technology called "Advanced Management Technology". Intel has a downloadable configuration tool: AMT Tool. The tool requires libcrypto and libssl. It was coded to look for libcrypto.so.0.9.8 and libssl.so.0.9.8. This can be fixed with a symlink:

Some of the rest of the package requires compiling, but it fails for me.

rdrand

The i7 Core CPU has an on-chip random number generator, rdrand, code named "Bull Mountain". It appears that since 3.2, this is used as a source for /dev/urandom. It is also used as a randomness source by rng-tools version 4.

In contrast to other hardware random number generators, rdrand does not create a character device in /dev. However, rngd version 4 does appear to detect and use it.

Activating the watchdog under systemd is trivial, as systemd author Lennart Poettering explains in this blog post.

All you do is go into /etc/systemd/system.conf, uncomment the RuntimeWatchdogSec=0 line and change zero to how long the watchdog should go without receiving a ping before it reboots the system. I used 30s, which is the default setting for iTCO_wdt and seemed sane.

To fix the issue, blacklist the 'btusb' module on the next boot by running:

sudo echo "blacklist btusb" > /etc/modprobe.d/disable_btusb.conf

Then use rc.local to load it at the end of the boot process by running:

sudo echo "modprobe btusb" >> /etc/rc.local

This appears to avoid whatever race condition conflict that causes the kernel to panic on boot, but if you're still having the same issue, try removing 'modprobe btusb' from /etc/rc.local to avoid the module completely.

Legacy information

Here is legacy information from earlier fix that are no longer required.

function keys (other than screen backlight)

Note: Since Kernel 3.4.9-1 the instructions below concerning the kernel patch/dkms are no longer required.