Linux 3.13+ on Zyxel NSA 310

I have already written an article about this Marwell Kirkwood device. This time, we are going to compile Linus tree kernel. Yes, almost everything have been already merged. Except LEDs.

It’s super easy now.

# make mrproper
# make kirkwood_defconfig

Creates clean and minimal setup for Kirwkood devices. I needed to make two changes - u-Boot on my device is old and does not support DTS enabled kernels, so I had to concatenate it. Also, for some reason the kernel was ignoring my command line, so I burnt it into the kernel image itself.

# grep CMDLINE .config
CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/sda3"

For your case, keep the console setting, but adjust our root to the proper device. If you know why the kernel was not picking up my command line (I was using 3.13 RC2), let me know under the article. If you need to change configuration and add more drivers, it’s the time now (e.g. USB WiFi sticks, printers etc.)

# make menuconfig

I usually write the configuration now and edit it via editor from now on which is faster. Let’s do the kernel now.

# make && make modules && make modules_install

The final step is very important - we need to make an uImage with concatenated device tree for our NSA 310.

# cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310.dtb \
    > /tmp/zImage-dtb-kirwood
# mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 \
    -n Linux-kikrwood-nsa310.dtb -d /tmp/zImage-dtb-kirwood \
    /boot/uImage-3.13.0-rc2

Boot the new kernel and note that everything works, except LEDs. Also the power button is working, which is great. I don’t need LEDs, actually I don’t like blinking LEDs at all so I am fine.

I have created an ultra simple script which controls the fan. There are other ways of doing that (e.g. via lm-sensors), but I prefer this lightweight solution (written in Go).

In my house, NSA 310 is great cheap 2 TB NAS, file server, print server, backup server and WiFi AP ($10 Tenda USB stick - was working out-of-box).

Drop me a line in the comments bellow!

How to reach your Fedora/RHEL behind NAT

I am using an excellent open-source tunneling solution called PageKite for about an year now. It’s a small utility written in Python with almost zero dependencies (okay there is one) and it enables you to reach various ports behind NAT. More on the PageKite.net which also provides subscription-based service for those who do not want to run their own man-in-the-middle server (which is needed for this to operate). By the way they datacenters are spread over whole world with excellent Europe coverage.

After decent testing time, I pushed PageKite into EPEL 5 and 6 (it is already included in Fedora repos). Installation and setup is ultra easy:

# yum -y install pagekite

In the PageKite.net service, create your account and create new “kite”. That is basically a subdomain which will be used for your machine. Now edit this file:

# vim /etc/pagekite.d/10_account.rc

Set your ‘kitename’ (which you created recently) and ‘kitesecret’ token and delete ‘abort_not_configured’ line. We want to enable SSH tunneling:

# mv /etc/pagekite.d/80_sshd.rc.sample /etc/pagekite.d/80_sshd.rc

If you want to tunnel HTTP, do this:

# mv /etc/pagekite.d/80_httpd.rc.sample /etc/pagekite.d/80_httpd.rc

You can tunnel any other protocol, read PageKite documentation for more. Start the thing:

# service pagekite start

Logs are here:

# tail /var/log/pagekite/pagekite.log -f

It’s the time to connect via your new tunnel. It is not that straightforward as you may expect, but you need to tune your ssh client configuration a bit:

# vim ~/.ssh/config
...
Host *.pagekite.me
    CheckHostIP no
    ProxyCommand /usr/bin/corkscrew %h 443 %h %p
...

I am using corkscrew tool which is a TCP tunneling solution via HTTP, which works great with PageKite. There are other options, but this one is the easiest and the most reliable. You will need to install the corkscrew tool (I am on Fedora):

# yum -y install corkscrew

Work done!

# ssh yourkite-yourname.pagekite.me

Nice, isn’t it? Now, if you find out how to tunnel mosh protocol, let me know bellow.

How to TRIM your encrypted SSD in Fedora 19

Few months ago I installed Fedora 19 on my new laptop with Samsung SSD and yesterday I found out TRIM is not enabled by default. I was installing using standard options with LVM/LUKS/ext4 partitions.

There were some problems in Fedora 18 with LUKS not propagating TRIM commands, but this was fixed in Fedora 19. On my system, TRIM commands propagate successfully. One just needs to make few changes in the configuration. First of all, we need to check if TRIM propagates for all partitions to the end device:

[lzap@lzapx ~]$ lsblk -D
NAME                                            DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                                                    0      512B       2G         1
├─sda1                                                 0      512B       2G         1
└─sda2                                                 0      512B       2G         1
  ├─fedora_lzapx-root                                  0      512B       2G         1
  ├─fedora_lzapx-swap                                  0      512B       2G         1
  └─fedora_lzapx-home                                  0      512B       2G         1
    └─luks-aaaaaaaa-6657-44f4-8297-bbbbbbbb1111        0      512B       2G         0

The last column shows if TRIM commands do propagate. We can see all is set, except the encrypted home (the last line). To get full TRIM support on LUKS-encrypted devices, we need to allow TRIM commands. Note that this can decrease encryption strengh. This is the Fedora 19 default crypttab file:

$ cat /etc/crypttab
luks-aaaaaaaa-6657-44f4-8297-bbbbbbbb1111 UUID=aaaaaaaa-6657-44f4-8297-a571e02e5492 none

I added allow-discards option there:

$ cat /etc/crypttab
luks-aaaaaaaa-6657-44f4-8297-bbbbbbbb1111 UUID=aaaaaaaa-6657-44f4-8297-a571e02e5492 none allow-discards

After reboot, LUKS can be checked (for discards flag) with:

[lzap@lzapx ~]$ sudo cryptsetup status luks-aaaaaaaa-6657-44f4-8297-bbbbbbbb1111
/dev/mapper/luks-aaaaaaaa-6657-44f4-8297-bbbbbbbb1111 is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/mapper/fedora_lzapx-home
  offset:  4096 sectors
  size:    370683904 sectors
  mode:    read/write
  flags:   discards

Now, to enable TRIM and take advantage of it, there are two options:

Optional LVM configuration

If you modify your LVM logical volumes often (e.g. shrinking, deleting), you want to set issue_discards to 1 in /etc/lvm/lvm.conf. Then you need to do the next optional step described bellow.

Optional init RAM disk regeneration

If you have root partition encrypted by LUKS (not my case) or if you have your root partition on LVM and you want LVM trimming when shrinking or deleting (see above optional step), initial RAM disk needs to be regenerated using the following command:

dracut -f

You will need to reboot to make this change effective of course.

TRIM when deleting files

It is possible to configure ext4 to send TRIM commands while deleting data. You can do this by adding discard option to partitions in /etc/fstab. Note that this slows down deleting a bit. It depends on the SSD drive, but this can slow down quite significantly on some drives.

Do not put discard option to swap devices as this is not required (and perhaps it will not work either). Swap is SSD friendly by default and propagates TRIM command.

TRIM from cron

This is the preferred option because it can be scheduled daily, weekly or during night if you do not turn off your laptop/server:

cat /etc/cron.weekly/01-fstrim
#!/bin/sh
fstrim /
fstrim /home

chmod +x /etc/cron.weekly/01-fstrim

Try to run the script now, it should not print any error message. If you changed LUKS configuration, you might need restart before doing that. If you delete lots of files often, consider scheduling trimming every day or even every hour. The more you trim, the faster the process should be.

That’s all folks. I would like to thank Lukáš Czerner, Kamil Páral and Chris Smart for helping me with this.

How to backup/migrate entire partitions easily

I needed something to migrate my NAS drive to a bigger one and I have stumbled upon fsarchiver - awesome tool which is in Fedora and super easy to use.

I connected my drive with existing data to my USB cradle and installed this masterpiece:

sudo yum -y install fsarchiver

I saved partition(s) into one archive (fsa extension) with ultra-fast lzo compression (-z 1):

sudo fsarchiver savefs -z 1 migration.fsa /dev/sdc1 /dev/sdc2

I swapped the drive for a brand new one and after creation of exactly the same partition layout (not using LVM in this case) I migrated the data back:

sudo fsarchiver restfs migration.fsa id=0,dest=/dev/sdc1 id=1,dest=/dev/sdc2

There are other options (e.g. parallel compression, splitting into smaller archives or excluding files), all is documented in the man page. Ideal tool for fast migrations and for full off-line backups.

Installing Win XP/7/8 in RHEL6 KVM

I was trying to install Windows XP system on a RHEL6 operating system using libvirt and I was surprised how smooth this was. Basically, it is very easy to do via virt-manager, but I had special requirements:

• standard RHEL6 server only (not RHEV)
• libvirt via virt-install
• remote installation via Spice

So the first step is to enable optional and supplementary channels for RHEL6:

subscription-manager repos --enable rhel-6-server-optional-rpms
subscription-manager repos --enable rhel-6-server-supplementary-rpms

Now, install virtualization packages. Easiest method is:

yum groupinstall "Virtualization" "Virtualization Client" "Virtualization Platform" "Virtualization Tools"

In the next step, we will install VirtIO official Red Hat (signed) drivers which will work seamlessly with Windows 7/8 installers:

yum install virtio-win

To create a VM, issue this command. Note the second --disk option which contains drivers. Also note this command configures Spice at standard port (5900) and libvirt will listen on all interfaces. Password is set.

virt-install \
    -n xp \
    -r 2800 \
    --arch i686 \
    --cdrom path_to.iso \
    --os-type windows \
    --os-variant winxp \
    --disk pool=default,size=5,bus=virtio,format=qcow2 \
    --disk path=/usr/share/virtio-win/virtio-win_x86.vfd,device=floppy \
    --graphics spice,listen=0.0.0.0,password=test123 \
    --noautoconsole

The command above creates 32bit system, if you change --arch option to 64 bits, also change path to virtio-win_amd64.vfd instead of the x86 one.

Now it is the time to connect to the hypervisor:

remote-viewer spice://my-server:5900

This should work with Windows XP/7/8 and maybe others (Server and stuff). But if you are using Windows XP, you must be quick to press F6 to “Install other drivers”, then press “S” and select WinXP 32bit driver (or 64bit if you changed the architecture and VFD file).

You can mount the Red Hat official driver ISO and install Guest Agent and few more drivers:

virsh domblklist xp
virsh attach-disk xp "/usr/share/virtio-win/virtio-win.iso" hdc --type cdrom --mode readonly

BUT I recommend to head over to http://www.spice-space.org/download.html and download spice-guest-tools-XXXX.exe installer which is much easier to use. I tried this with Windows XP, not sure if it does support Windows 7/8 (it looks like it should).

That’s it.