Identity

January 20th, 2015 -- Posted in Ableism, Frustration, Identity | No Comments »

One of the biggest struggles for me, when I got sick, was identity. I imagine it’s much the same for anyone dealing with chronic illness or disability. I can’t say that struggle is over, and the forces at play make it hard to strike a balance.

On one side, I want to be my own person, I am more than an illness and a bunch of can’ts. I have dreams, aspirations, fears, struggles and good moments just like anyone else. I want to be ordinary, just a regular person. I want to be seen for my personality, for who I am (whoever that is), and not to be defined by this illness.

But at the same time it does define me. It took over my life in a devastating and very visible way. It’s impossible to ignore. And I don’t want to. My illness is just as much a part of me as my tendency to over-think everything is, or my love for computers. There needs to be balance there.

It wouldn’t be an issue at all if I wasn’t being forced into all kinds of corners. Back when I began to play with the idea of viewing myself as having a disability (after more than a year of denial) I met a lot of resistance. I was told that I was ‘making’ myself disabled by even thinking about viewing myself in that light. Now I can understand that the people around me were having trouble accepting my situation as well, they had trouble uniting their view of disability with the person they knew. But it hasn’t stopped there. The people close to me all have gotten used to the idea, and can see past it. It’s meeting new people, or running into strangers, that poses a problem now.

Most people start out trying to fit me in their box and are not able to move past that. Either they label me as ‘the disabled girl’, start asking all kinds of intrusive questions about my health and abilities, take pity on me, and stop there. Those people usually vanish pretty fast, because once I lead the conversation away from my health, they either stop talking to me at all, or they switch over the the other extreme; I’m an inspiration for being able to sustain a regular conversation, for not being a crying, self-pitying wreck, for ‘overcoming’ disability. If they take that direction, I become standoffish towards them. And the result is the same. They disappear. The point is that they are stuck in their image of disability, and don’t even try to get to know me. They are only interested in those bits of me that will confirm their idea.

I used to make an effort, explain to them why I’m uncomfortable with their image of me, their attitude towards me, and hope they can move past it. But lately, I don’t even try any more. It’s no use. It always ends in uncomfortable silence, unanswered emails and vague excuses.

I wonder if it’s me. Am I being too confronting when I challenge these attitudes? I try my best not to be. I answer their inappropriate questions, and even make an effort not to call them out or accuse them directly, but try to show them another side of me hoping they get the message. All the while cringing inwardly. It’s not like I don’t get it. I wasn’t born into this, and once, I was that person. Not that I think I would ever have been so rude and inconsiderate as to have walked up to a stranger and asked them if they could go to the bathroom independently, but my first thought when I saw a wheelchair user was still “I wonder what’s wrong with them.” I wonder, if I had met my current self then, if I had been able to move past that.

Maybe it’s the other way around, and I’m not being upfront and direct enough, and I should not to rely on people’s ability to pick up on subtle clues to alter their deep-rooted misconceptions. But I feel like I have to walk on eggshells when dealing with them, if I come off too strong, they either jump to admiring me for being so inspiring (and eventually droop off because I refuse to play that part), or they are intimidated and droop off all the same.

Not that I want you to think I’m sad and lonely. My friends are loyal, and loving, and we’re all pretty close. I’m just fed up. I have been interviewing caregivers for over 6 months now, and I have not found a single one willing to work with me. I’m not exactly sure why, I think of myself as a pretty nice person, and it’s a good job I’m offering. I suspect it has a lot to do with my refusal to fit inside that box. Same story in the romance and friendship department, only less subtle.

I’ve had it. Very much so. Yes, I am opinionated. Yes, I’m stubborn, and intelligent, and caring, and a terrible geek. I’m also not here to inspire you, and my intimate personal life is not yours to pry in. Deal with it. Stop trying to box me in. Is it really so hard?

Hard anniversaries

December 22nd, 2014 -- Posted in Future, Reflections | No Comments »

Over the last year, my updates here have been predominantly tech-talk. That’s kind-of my way of sharing the good bits of life. I love solving problems, especially if they’re computer related. But there’s more to life than computers. So, here I am, sharing a bit of the non technical stuff.

January is almost upon us, and for me, that’s never an easy month. It’s the month I first started having trouble walking, it’s the month I became homeless, and it’s also my birthday, which, having been depressed for most of my life, wasn’t exactly a positive thing either. It also means I’ve been stuck in this bed for almost three years. Weird, to realize it has been that long. I can remember dragging my lasts steps out in the freezing cold at the bus stop all those years ago like it was yesterday. That must have been four or five years ago now.

But, this year is truly different. For one, I’m not depressed any more. Not to say I don’t despair on a regular basis, or get fed up with all the crap happening to me, but generally, I enjoy life. Short of a miraculous recovery and me jumping out of bed, charging head-first into the life I could have had, that’s the best thing that could have happened to me. Being able to do very little and not enjoy a single second is utterly hopeless, being able to do very little and have fun while doing it makes life worthwhile. Something very few people understand is that disability in itself is not something that makes life miserable. Sure, it sucks at times, but mostly because of the way society excludes people with disabilities. It’s always hard to have to adjust your expectancies, and adapt to a new way of living regardless of the circumstances, but that doesn’t say anything about the quality of life.

I can honestly say I enjoy living from this bed. Not something I would have expected when I stared this journey, that’s for sure. I was afraid my life would be empty and isolated. But nothing is less true. I have made great friends over the past few years, I see them daily.

In the beginning, I found it hard to always need assistance, and I felt that was a one-way thing. I felt like I used my friends and those around me and they got nothing in return. But now I find they depend as much on me as the other way around. Not being able to help them move turned out not matter at all. Not weird, if you think about it. Who rates their friends on their ability to help you move, after all. Come to think of it, who rates their friends in the first place?

I still struggle with the discrepancy between what I want and what I’m able to do. I don’t think that’ll change for the rest of my life, I’ve always wanted to do more than humanly possible even before I got sick. Finding a balance there may prove beyond me. But that won’t stop me from trying. The trick is to enjoy myself even when I feel crappy and I can’t do anything. Or maybe enjoy is the wrong choice of words here, I can’t imagine myself enjoying screaming in pain and frustration all night, no matter how much I try to. Maybe a better choice of words would be to aspire to be okay with it, as fighting makes everything a tenfold worse. Zennnnnn.

That’s another thing. Spirituality, religion. I’ve always been a spiritual person, but it hasn’t always been on the foreground. It could be a huge support when your life falls apart, but frankly I was too busy trying to keep the pieces together. Now that I have a bit more breathing room, I’ve been rediscovering those parts of myself. Not an easy feat from bed, when your religion calls for some strenuous physical activity, but I’m sure I’ll find a way there, given enough time.

Other things haven’t changed though (to my regret). I’m still deteriorating. I keep expecting to hit rock bottom, but I keep on descending. I hope the coming year will bring some improvement there, but I find it hard to really believe that. The past few years have left me with a more than healthy dose of pessimism. We’ll see, in any case.

Slackware, luks, root encryption and remote booting through ssh

December 7th, 2014 -- Posted in Tech | No Comments »

It’s quite a mouth full, and while writing, I find myself amused about what crazy project I pulled off this time.

I got myself into quite a bit of trouble with failing hard disks (of course always one too many for the raid array to recover from), and a complete lack of backups. I know, I know, shame on me. So I decided to better myself. A NAS unit is a bit above my budget, and besides, I have pretty high standards. I’d rather whip something up myself that meets my needs completely. So I decided to repurpose an old pc I got as a gift a while back.

The problem I ran into was as follows: This is going to be a headless machine, hooked up in the meter closet (or whatever it’s called in English). I want to encrypt the root filesystem, it’s not much use encrypting anything if your backup leaks data. But… ans here comes the trouble: I’m bedridden. I can’t get up and go to the machine to provide it with a password in the event it needs rebooting. One option is to use a key to decrypt, and put it on a usb stick. But it’s not much use if the usb stick is always in the pc.

So I started looking into providing a password through ssh, during boot. There are several tutorials and scripts available, but only for ubuntu/debian style initrd. Slackware has it’s own particular initrd system, and I couldn’t find anyone who had documented doing this before. Seeing as I got it to work, I though it’d share it here.

Disclaimer

This is not for the faint-hearted! It will involve getting to know the boot process, debugging it, editing scripts, working with the kernel and a lot of tinkering.

Aside from that, I wrote this guide from memory, after 3 days of debugging and mucking about and finally getting everything in working order. I did not do a spell check, so don’t copy commands blindly. I might have missed a few steps, my memory isn’t great. Feel free to contact me if you’re having trouble, you can leave a comment, but you have a better chance of getting an answer if you email me at info_AT_nihlaeth_DOT_nl

Root encryption in Slackware 14.1

This needs a bit of explanation, as the documentation provided with slackware 14.1 won’t get you a working system. The error in README_CRYPT is that you’re told you can name your crypt devices anything. This is false. If you use an initrd, you have to name your cryptdevice the standard: luks[device] – so, for example: lukssda3, which would be the third partition on /dev/sda.

Another error is in the instructions for lilo.conf. If you use the huge kernel, you need the “root=” line, but this will conflict with options set in initrd. So make sure /boot/vmlinuz points to the generic kernel, and not the huge kernel. Or even better, just point it directly to the correct kernel and prevent confusion. And don’t forget to comment out the root line in /etc/lilo.conf.

I advise you to use the script in /usr/share/mkinitrd/mkinitrd_command_generator.sh to create your initrd. I just echo it to /etc/mkinitrd.conf because we’ll be running it A LOT (and editing a bit).

With the above in mind, complete the installation and make sure you can boot the normal way. If not, get back in with the installation cd.

The process of getting back in goes as follows:
decrypt your root filesystem:

cryptsetup luksOpen /dev/[device#partition] luks[device#partition]

Now mount it:

mount /dev/mapper/luks[device#partition] /mnt

If you have incorrectly shut down the machine before, the filesystem might need checking before you mount:

fsck.[fstype] /dev/mapper/luks[device#partition]

If you have more than one encrypted partitions, go ahead and decrypt and mount them. Don’t forget to mount your boot partition (vital!):

mount /dev/[device#partition] /mnt/boot

Now you need to provide the dev, proc and sys filesystems:

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

Now you’re ready to get back in and fix whatever went wrong:

chroot /mnt

Now you can make the necessary changes, run mkinitrd and lilo again, and rinse and repeat until it works.

By the way, if you get a screen saying “L99 99 99 99 99…(etc)”, you might try telling lilo to overwrite the MBR:

lilo -M /dev/[device] mbr

Booting with an initrd

First of all, I’ll explain some of what I learned about the boot process with an initrd. I might be wrong about some of it, all I know I got from the initrd scripts because there isn’t much to be found about the workings of initrd.

First, your bios loads. This will look for either a boot flag, on some partition, or a bootloader (for example in the master boot record). In our case, this will be lilo. Grub is also an option, but that’s beyond the scope of this tutorial.

Secondly, lilo loads the kernel. We told it where to find that in /etc/lilo.conf, but as our devices are not decrypted yet, it doesn’t know about that. That’s why you have to run lilo every time you change something (even if all you changed was a single line in the initrd init script). When you run lilo, it writes the exact disk locations for the initrd and kernel so they can be loaded with minimal knowledge of the filesystem.

After the kernel is loaded, lilo extracts the initrd image, mounts it as read only temporary root and starts the init script inside.

The init script then starts loading the kernel modules needed to use raid, cryptsetup, lvm, and pretty much anything else you tell it to, so they are available without the root filesystem being mounted.

After that, it starts udev, and checks what needs to be done (for example, starting raid arrays, activating lvm groups, decrypting drives). When all the needed filesystems are available, it mounts them, and passes the torch to the normal booting process.

What we want to do here, is tell init to load the necessary kernel modules to start the network, and have udev make the network interfaces available. When that’s done, we’ll actually start it, and start a minimal ssh daemon (dropbear in our case).

After that’s loaded, we’re going to halt the boot process. If we didn’t do that, your timing in logging in would have to be very good, and even then you wouldn’t have any time to type the passphrase. We want to still be able to boot with a connected keyboard, so we have to be able to continue via that way, and also of course, to be able to continue via ssh.

The solution for this is simple. We start a script that waits for an input of ‘ok’. If you’re done decrypting via ssh, you can kill the script, and init will continue like normal. At the terminal, you can type ok, and boot the regular way.

It’s actually a bit dirty, because what you do with an ssh login during boot, is decrypt the needed harddisks and then have init continue like nothing happened. Which means, init will try to decrypt a couple of already decrypted devices. It won’t do any damage, and it’ll work, but it does not deserve a beauty award.

Remote boot via ssh

First of all, we need to correct the command that generates initrd. Initrd first checks if /boot/initrd-tree exists, and if it has the -c option. If it doesn’t exist, or you used -c, it will write a new source tree to /boot/initrd. So the first thing we’ll do after the source tree is present, is remove the -c option from /etc/mkinitrd.conf (if you don’t have that, start reading at the top). If you screwed up and want to start over, just remove /boot/initrd-tree and run /etc/mkinitrd.conf again, it will provide you with a fresh tree. And because it’s easy to overwrite the tree by accident, I advise you to back up the customized tree.

From that tree, the initrd image will be made, so we’ll be doing all adaptions in /boot/initrd-tree.

The second step is to ensure that the right device is indicated. -C should point to the physical device. This should be ONE device, unless you use raid, and you need multiple devices to make up the root filesystem. Any other devices you want to decrypt through ssh, you should hardcode into the init script.

The mkinitrd command generator script automatically includes the needed modules to use a usb keyboard, now all we need to add is the correct module for your network card. In my case, this was e1000e. To find out which driver your network card uses:

dmesg | grep "eth"

Or, if you use a different interface name, grep for that of course. That will tell you which kernel module is used by your network card. Include this in the modules list. My mkinitrd command looks like this:


#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:


#added e1000e module to be able to start the network during boot
mkinitrd -k 3.10.17 -f jfs -r /dev/mapper/lukssda3 -m usbhid:hid_generic:uhci-hcd:jfs:e1000e -C /dev/sda3 -u -o /boot/initrd.gz -L

The -L option is also vital, it adds /sbin/dmsetup. It wasn’t automatically added in my case, and I didn’t think I’d need it as I don’t use LVM. But I needed it, I suspect you will too. If your boot process dies with the message it can’t find /sbin/dmsetup after asking you for a password, chances are you need the -L option with mkinitrd.

Anyway. That’s mkinitrd. Before we dive into the init script, we’ll need to add some files to the initrd tree. First of all, don’t be fooled into adding/replacing libraries in the tree. It will most likely result in kernel panics if you do. Other distros need this, initrd in slackware doesn’t. Aside from a boot script, initrd in slackware also provides a rescue console, so most essentials are already there.

All we need to add is the dropbear binary, and some config files in the /boot/initrd-tree/etc directory.

You can compile dropbear with this slackbuild(link). After compilation, I would advise against installing it, as it conflicts with the openssh package. Just dump the package inside an empty directory and untar it to get to the binaries we need.

First of all, create the usr/bin dir inside the initrd tree:

mkdir /boot/initrd-tree/usr/bin

Now, copy dropbearmulti and make a symlink to it that can start the server:

cp /[pkgdir]/usr/bin/dropbearmulti /boot/initrd-tree/usr/bin/.
ln -s dropbearmulti /boot/initrd-tree/usr/bin/dropbear

Now we need to arrange the configuration for dropbear. It doesn’t need much, the defaults will be fine in most cases, but it does need a set of host keys. For this, we need to create a symlink to dropbearmulti capable of creating keys:

ln -s dropbearmulti /[pkgdir]/usr/bin/dropbearkey
mkdir /boot/initrd-tree/etc/dropbear
/[pkgdir]/usr/bin/dropbearkey -t dss -f /boot/initrd-tree/etc/dropbear/dropbear_dss_host_key
/[pkgdir]/usr/bin/dropbearkey -t rsa -t /boot/initrd-tree/etc/dropbear/dropbear_rsa_host_key

Now we’re making a banner file. It’s just some text that will be displayed when you ssh in during boot. I recommend explaining to yourself what to do from there, because you probably won’t remember when you have to reboot this headless backup server six months from now:

vim /boot/initrd-tree/etc/dropbear/banner

My banner file says something along the lines of just run “unlock”, and that if I need to do anything other than provide passwords, not to run unlock, as it will advance the boot process.

That’s all the configuration dropbear needs. Now you need to edit the /boot/initrd-tree/etc/passwd file, as the root user has a default shell of bash, which is not installed in the initrd. After changing it, it should look like this:

root:x:0:0::/root:/bin/sh

It’s best to delete the rest, you won’t be needing other users anyway.

One file that’s not included by default is the shadow file. If you’re going to use a password to log in, you’ll need it. It’s a bit of a security risk, as you’ll be putting it on an unencrypted filesystem, but it’s one I can live with personally. You can also use public/private key authentication, and it shouldn’t be hard to set up. I just didn’t bother to do it.

cp /etc/shadow /boot/initrd-tree/etc/.

It’s best to delete all lines that are not root here as well.

In order for udev to correctly setup the network interface(s), it needs an udev rules file. The default one is fine:

cp /etc/udev/rules.d/70-persistent-net.rules /boot/initrd-tree/etc/udev/rules.d/.

Now we’ll need a lock and unlock script.

vim /boot/initrd-tree/bin/unlock

This is my unlock script, obviously you should adjust the devices and crypt device names accordingly. No mounting is needed, init takes care of that. I do recommend you put the kill lock and exit on the same line, my session wouldn’t terminate otherwise.

#!/bin/sh
PATH="/sbin:/bin:/usr/sbin:/usr/bin"
# unlock needed devices
cryptsetup luksOpen /dev/sda3 lukssda3
cryptsetup luksOpen /dev/sdb1 lukssdb1

echo "#############################"
echo "###        TNXBYE         ###"
echo "#############################"

# terminate locking script
killall bootlock; exit 0

I named my lock script bootlock for no good reason. If you decide to call it something else, don’t forget to adjust the ‘killall’ command above.

vim /boot/initrd-tree/bin/bootlock

My bootlock script (this shouldn’t need any adjustments):

#!/bin/sh

#lock the booting process to allow a network user to login first

echo "###########################################"
echo "###        Wait for user input          ###"
echo "###########################################"
echo "Type ok and press enter to continue booting:"
INPUT='wait'
while [ $INPUT != 'ok' ] ; do 
  read INPUT
done

Now we make them both executable:

chmod +x /boot/initrd-tree/bin/bootlock
chmod +x /boot/initrd-tree/bin/unlock

That’s all the files and configuration that’s needed. All that’s left now is the init script. I’ll paste mine here. Don’t copy this without editing, there are several spots where you need to customize. Besides, it’s way more fun if you understand what it all does. I’ll put my adaptions in red, so it will be easier to adapt future versions of the init script.


#!/bin/ash
#
# /init:  init script to load kernel modules from an initramfs
#         This requires that your kernel supports initramfs!!!
#
# Copyright 2004  Slackware Linux, Inc., Concord, CA, USA
# Copyright 2007, 2008, 2009, 2010, 2012  Patrick J. Volkerding, Sebeka, MN, USA
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
#  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
#  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
#  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
#  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
#  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
#  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
#  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
#  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
#  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
##################################################################################
# With a generic kernel, you need to load the modules needed to mount the
# root partition.  This might mean a SCSI, RAID, or other drive controller
# module, as well as the module to support the root filesystem.  Once the
# root partition is mounted all the other modules will be available so you
# don't need to load them here.
#
# Config files used by this script:
#
# /rootdev        Contains the name of the root device, such as: /dev/hda1 
#
# /rootfs         Contains the root filesystem type, such as: xfs
#
# /initrd-name    Contains the name of the initrd file.
#
# /resumedev      Contains the name of the device to resume from hibernation.
#
# /luksdev        Contains colon separated list of luks encrypted devices to
#                 be unlocked.
#
# /lukskey        Contains the path to a LUKS key-file for automatic unlock
#                 Format: LABEL=:/path/to/file
#                         UUID=:/path/to/file
#
# /wait-for-root  Contains a number - the init script will wait this amount
#                 of seconds before creating device nodes.
#
# /keymap         Contains the name for a custom keyboard map 
#
# Optional:
#
# /load_kernel_modules
#                 A script that uses modprobe to load the desired modules.
#
#                 There's an example in here.  To actually use it, you'll
#                 need to make it executable:  
#
#                     chmod 755 load_kernel_modules
##################################################################################
# Changelog
# 10-Dec-2012 
#  * Added support for the official Kernel parameters to select root filesystem
#    type ('rootfstype') and pause before attempting to mount the root filesystem
#    ('rootdelay').  The original parameters may continue to be used.
##################################################################################

INITRD=$(cat /initrd-name)
ROOTDEV=$(cat /rootdev)
ROOTFS=$(cat /rootfs)
LUKSDEV=$(cat /luksdev)
LUKSKEY=$(cat /lukskey)
RESUMEDEV=$(cat /resumedev)
WAIT=$(cat /wait-for-root)
KEYMAP=$(cat /keymap)
INIT=/sbin/init

PATH="/sbin:/bin:/usr/sbin:/usr/bin"

# Mount /proc and /sys:
mount -n proc /proc -t proc
mount -n sysfs /sys -t sysfs
mount -n tmpfs /run -t tmpfs -o mode=0755

if grep devtmpfs /proc/filesystems 1>/dev/null 2>/dev/null ; then
  DEVTMPFS=1
  mount -n devtmpfs /dev -t devtmpfs
fi	

# Parse command line
for ARG in $(cat /proc/cmdline); do
  case $ARG in
    0|1|2|3|4|5|6|S|s|single)
      RUNLEVEL=$ARG
    ;;
    init=*)
      INIT=$(echo $ARG | cut -f2 -d=)
    ;;
    luksdev=/dev/*)
      LUKSDEV=$(echo $ARG | cut -f2 -d=)
    ;;
    lukskey=*)
      LUKSKEY=$(echo $ARG | cut -f2- -d=)
    ;;
    rescue)
      RESCUE=1
    ;;
    resume=*)
      RESUMEDEV=$(echo $ARG | cut -f2 -d=)
    ;;
    root=/dev/*)
      ROOTDEV=$(echo $ARG | cut -f2 -d=)
    ;;
    root=LABEL=*)
      ROOTDEV=$(echo $ARG | cut -f2- -d=)
    ;;
    root=UUID=*)
      ROOTDEV=$(echo $ARG | cut -f2- -d=)
    ;;
    rootfs=*|rootfstype=*)
      ROOTFS=$(echo $ARG | cut -f2 -d=)
    ;;
    waitforroot=*|rootdelay=*)
      WAIT=$(echo $ARG | cut -f2 -d=)
    ;;
  esac
done

# If udevd is available, use it to generate block devices
# else use mdev to read sysfs and generate the needed devices 
if [ -x /sbin/udevd -a -x /sbin/udevadm ]; then
  /sbin/udevd --daemon --resolve-names=never
  /sbin/udevadm trigger --subsystem-match=block --action=add
  /sbin/udevadm settle --timeout=10
  # initialize network interfaces for ssh boot
  /sbin/udevadm trigger --action='add' --subsystem-match='net'
  /sbin/udevadm settle --timeout=10
else
  [ "$DEVTMPFS" != "1" ] && mdev -s
fi

# Load kernel modules (ideally this was already done by udev):
if [ ! -d /lib/modules/$(uname -r) ]; then
  echo "No kernel modules found for Linux $(uname -r)."
elif [ -x ./load_kernel_modules ]; then # use load_kernel_modules script:
  echo "${INITRD}:  Loading kernel modules from initrd image:"
  . ./load_kernel_modules
else # load modules (if any) in order:
  if ls /lib/modules/$(uname -r)/*.*o 1> /dev/null 2> /dev/null ; then
    echo "${INITRD}:  Loading kernel modules from initrd image:"
    for module in /lib/modules/$(uname -r)/*.*o ; do
      /sbin/modprobe $module
    done
    unset module
  fi
fi

# Sometimes the devices need extra time to be available.
# A root filesystem on USB is a good example of that.
sleep $WAIT

# Load a custom keyboard mapping:
if [ -n "$KEYMAP" ]; then
  echo "${INITRD}:  Loading '$KEYMAP' keyboard mapping:"
  tar xzOf /etc/keymaps.tar.gz ${KEYMAP}.bmap | loadkmap
fi

if [ "$RESCUE" = "" ]; then 
  # Initialize RAID:
  if [ -x /sbin/mdadm ]; then
    # If /etc/mdadm.conf is present, udev should DTRT on its own;
    # If not, we'll make one and go from there:
    if [ ! -r /etc/mdadm.conf ]; then
      /sbin/mdadm -E -s >/etc/mdadm.conf
      /sbin/mdadm -S -s
      /sbin/mdadm -A -s
      # This seems to make the kernel see partitions more reliably:
      fdisk -l /dev/md* 1> /dev/null 2> /dev/null
    fi
  fi

  # Unlock any encrypted partitions necessary to access the
  # root filesystem, such as encrypted LVM Physical volumes, disk
  # partitions or mdadm arrays.
  # Unavailable devices such as LVM Logical Volumes will need to be
  # deferred until they become available after the vgscan.

  if [ -x /sbin/cryptsetup ]; then
    
    # I assume this functionality will only be needed if one uses encryption
    # if you need it for something else, put the code below outside this if.

    # See if network card gets loaded properly.
    # Uncomment this section if you're having trouble.
    # The sleeps are there so you have the time to examine
    # the command output, as nothing is logged at this point
    # and there's no scrolling.
    #echo "###########################################"
    #echo "###         Debug network               ###"
    #echo "###########################################"
    #sleep 5
    #echo "-------- ls /dev/net"
    #ls /dev/net
    #sleep 5
    #echo "-------- cat /proc/net/dev"
    #cat /dev/net/dev
    #sleep 5
    #echo "-------- ifconfig -a"
    #ifconfig -a
    #sleep 5

    # init network
    # Obviously, you should put in the correct interfaces
    # here, and edit the ip addresses. It's easiest to 
    # use a different ip address than the pc usually
    # has, because the host keys are different and ssh
    # will die over that, unless you explicitly tell it
    # not to EVERY SINGLE TIME. This way, ssh will not
    # see this as the same host and there's no problem.
    # Right now, it's configured for a static ip. Dhcp 
    # is within the possibilities, I just don't use it.
    # It will most likely be difficult though, as it's
    # not automatically included in the initrd. Do
    # yourself a favor and just configure it statically.
    # ;)
    echo "###########################################"
    echo "###      Initializing network           ###"
    echo "###########################################"
    echo "-------- Bringing up lo on 127.0.0.1"
    ifconfig lo 127.0.0.1
    echo "-------- Bringing up eth0 on 192.168.1.34"
    ifconfig eth0 up 192.168.1.34
    echo "-------- Adding 192.168.1.1 as default gw"
    route add -net 127.0.0.0 netmask 255.0.0.0 lo
    route add default gw 192.168.1.1

    # Test if internet connection is ok
    # Uncomment this if the network isn't coming up.
    # Be sure the ip is actually reachable, and don't
    # use a domain name, as there's no nameserver
    # capability at this point.
    #echo "###########################################"
    #echo "###       Test network                  ###"
    #echo "###########################################"
    #sleep 5
    #ping 192.168.1.1 -c 5
    #sleep 5

    # start ssh
    # This kinda speaks for itself. You could set a few
    # options for dropbear if you wanted (-s to disable
    # password login for example).
    echo "###########################################"
    echo "###    Starting ssh daemon              ###"
    echo "###########################################"
    echo "-------- Starting daemon on port 22"
    dropbear -b /etc/dropbear/banner

    # lock system until user provides input, or this script is killed (via ssh)
    bootlock

    # We don't need ssh anymore - kill off dropbear
    echo "###############################################"
    echo "###            Shut down network            ###"
    echo "###############################################"
    killall dropbear

    # Now shut down the network so it doesn't interfere with the normal booting process
    # I'm not sure this is needed, but I've read reports of network issues because the
    # regular boot process couldn't overwrite the initial configuration. Seemed the safe
    # thing to do. Also, I don't like the idea of leaving the network open unprotected
    # (no firewall) any longer than I have to. 
    ifconfig eth0 down
    ifconfig lo down
    

    # Determine if we have to use a LUKS keyfile:
    if [ ! -z "$LUKSKEY" ]; then
      mkdir  /mountkey
      KEYPART=$(echo $LUKSKEY |cut -f1 -d:)
      LUKSPATH="/mountkey$(echo $LUKSKEY |cut -f2 -d:)"
      # Catch possible mount failure:
      if blkid -t TYPE=vfat $KEYPART 1>/dev/null 2>&1 ; then
        MOUNTOPTS="-t vfat -o shortname=mixed"
      else
        MOUNTOPTS="-t auto"
      fi
      mount $MOUNTOPTS $(findfs $KEYPART) /mountkey 2>/dev/null
      # Check if we can actually use this file:
      if [ ! -f $LUKSPATH ]; then
        LUKSKEY=""
      else
        echo ">>> Using LUKS key file: '$LUKSKEY'"
        LUKSKEY="-d $LUKSPATH"
      fi
    fi

    LUKSLIST_DEFERRED=""
    LUKSLIST=$(echo $LUKSDEV | tr -s ':' ' ')
    for LUKSDEV in $LUKSLIST ; do
      if /sbin/cryptsetup isLuks ${LUKSDEV} 1>/dev/null 2>/dev/null ; then
        if echo $ROOTDEV | grep -q "LABEL=" || echo $ROOTDEV | grep -q "UUID=" ; then
          CRYPTDEV="luks$(basename $LUKSDEV)"
        elif [ "x$ROOTDEV" = "x$(basename $ROOTDEV)" ]; then
          CRYPTDEV="$ROOTDEV"
        else
          CRYPTDEV="luks$(basename $LUKSDEV)"
        fi
        echo "Unlocking LUKS encrypted device '${LUKSDEV}' as luks mapped device '$CRYPTDEV':"
        /sbin/cryptsetup ${LUKSKEY} luksOpen ${LUKSDEV} ${CRYPTDEV} /dev/tty0 2>&1
        if [ "$ROOTDEV" = "$LUKSDEV" -o "$ROOTDEV" = "$CRYPTDEV" ] ; then
          ROOTDEV="/dev/mapper/$CRYPTDEV"
        fi
      else
        LUKSLIST_DEFERRED="${LUKSLIST_DEFERRED} ${LUKSDEV}"
      fi
    done
  fi

  # Initialize LVM:
  if [ -x /sbin/vgchange ]; then
    mkdir -p /var/lock/lvm	# this avoids useless warnings
    /sbin/vgchange -ay --ignorelockingfailure 2>/dev/null
    /sbin/udevadm settle --timeout=10
  fi
  
  # Unlock any LUKS encrypted devices that were deferred above but have now
  # become available due to the vgscan (i.e. filesystems on LVM Logical Volumes)

  if [ -x /sbin/cryptsetup -a -n "${LUKSLIST_DEFERRED}" ]; then
    for LUKSDEV in ${LUKSLIST_DEFERRED} ; do
      if /sbin/cryptsetup isLuks ${LUKSDEV} 1>/dev/null 2>/dev/null ; then
        if echo $ROOTDEV | grep -q "LABEL=" || echo $ROOTDEV | grep -q "UUID=" ; then
          CRYPTDEV="luks$(basename $LUKSDEV)"
        elif [ "x$ROOTDEV" = "x$(basename $ROOTDEV)" ]; then
          CRYPTDEV="$ROOTDEV"
        else
          CRYPTDEV="luks$(basename $LUKSDEV)"
        fi
        echo "Unlocking LUKS encrypted device '${LUKSDEV}' as luks mapped device '$CRYPTDEV':"
        /sbin/cryptsetup ${LUKSKEY} luksOpen ${LUKSDEV} ${CRYPTDEV} /dev/tty0 2>&1
        if [ "$ROOTDEV" = "$LUKSDEV" -o "$ROOTDEV" = "$CRYPTDEV" ] ; then
          ROOTDEV="/dev/mapper/$CRYPTDEV"
        fi
      else
        echo "LUKS device '${LUKSDEV}' unavailable for unlocking!"
      fi
    done
    /sbin/udevadm settle --timeout=10
  fi

  # Scan for btrfs multi-device filesystems:
  if [ -x /sbin/btrfs ]; then
    /sbin/btrfs device scan
  fi
  
  # Find root device if a label or UUID was given:
  if echo $ROOTDEV | grep -q "LABEL=" || 
     echo $ROOTDEV | grep -q "UUID=" ; then
    ROOTDEV=$(findfs $ROOTDEV)
  fi

  # Clean up after LUKS unlock using a keyfile:
  if grep -q mountkey /proc/mounts 2>/dev/null ; then
    umount -l /mountkey
    rmdir /mountkey 2>/dev/null
  fi
  
  # Resume state from swap
  if [ "$RESUMEDEV" != "" ]; then
    if ls -l $RESUMEDEV | grep -q "^l" ; then
      #RESUMEDEV=$(ls -l $RESUMEDEV | awk '{ print $NF }')
      RESUMEDEV=$(readlink -f $RESUMEDEV)
    fi
    echo "Trying to resume from $RESUMEDEV"
    RESMAJMIN=$(ls -l $RESUMEDEV | tr , : | awk '{ print $5$6 }')
    echo $RESMAJMIN > /sys/power/resume
  fi

  # Switch to real root partition:
  /sbin/udevadm settle --timeout=10
  echo 0x0100 > /proc/sys/kernel/real-root-dev
  mount -o ro -t $ROOTFS $ROOTDEV /mnt
  
  if [ ! -r /mnt/sbin/init ]; then
    echo "ERROR:  No /sbin/init found on rootdev (or not mounted).  Trouble ahead."
    echo "        You can try to fix it. Type 'exit' when things are done." 
    echo
    /bin/sh
  fi
else
  echo
  echo "RESCUE mode"
  echo
  echo "        You can try to fix or rescue your system now. If you want"
  echo "        to boot into your fixed system, mount your root filesystem"
  echo "        read-only under /mnt:"
  echo
  echo "            # mount -o ro -t filesystem root_device /mnt"
  echo
  echo "        Type 'exit' when things are done."
  echo
  /bin/sh
fi

# Need to make sure OPTIONS+="db_persist" exists for all dm devices
# That should be handled in /sbin/mkinitrd now
/sbin/udevadm info --cleanup-db
/sbin/udevadm control --exit

unset ERR
mount -o move /proc /mnt/proc
mount -o move /sys /mnt/sys
mount -o move /run /mnt/run

[ "$DEVTMPFS" = "1" ] && mount -o move /dev /mnt/dev
echo "${INITRD}:  exiting"
exec switch_root /mnt $INIT $RUNLEVEL


Well, that was all. Don’t forget to run /etc/mkinitrd.conf and then lilo after every alteration. I hope this guide saves you a few days of constant rebooting 😉 But most of all I hope you’ll have fun rooting around in the boot process, how cool is this?

Awareness

October 28th, 2014 -- Posted in Ableism, Activism, Diagnosis, Frustration, Medical | No Comments »

When I first learned about Ehlers Danlos Syndrome, I reacted with disbelief. How could I possibly have this incredibly rare condition? I did not have the weird scars and easy bruising that were mentioned. I could not suffer from EDS, no way.

I know better now, but the ignorance surrounding EDS both in the medical community and outside it, and the general lack of good information and proper research continues to baffle me.

If you’ve been reading this blog you already know how ignorant some doctors can be. I’ve rarely met a doctor who knows what EDS entails, aside from ‘hypermobility complaints’, let alone they’d be able to recognize and diagnose the condition. Even worse, many deny the possibility of dislocations sustained without the presence of considerable force, saying hypermobility can’t cause pain, and there’s nothing wrong, medically speaking.

It isn’t to be expected that doctors would be knowledgeable about every rare disease. They can’t even be knowledgeable about all the common diseases. Even specialists have specializations. But from what I can see, and more and more people are sharing this opinion with me, EDS isn’t nearly as rare as one might think, and it’s long over due for some research.

The tagline has been that EDS occurs about 1-2 times per 10.000 people. This has been adjusted to 1 in 3.000, though I’ve never seen a decent study to confirm this. However, EDS is extremely poorly recognized, and many go undiagnosed for years. Even more severe cases often go unrecognized and get diagnosed with fibromyalgia, chronic regional pain syndrome, chronic fatigue syndrome or some sort of psychosomatic disorder.

I’ve recently come across claims that EDS occurs in about 1 in 100 people, and that 1 in 3.000 are severe cases of EDS. Again no research to back this up, but from my own experience, those numbers can’t be far off target. It’s to be expected that I would know a lot of people with EDS from patient organizations, or in my own family, but that doesn’t explain how I keep running in to people who fit the criteria of EDS outside of those groups. They are usually undiagnosed and unaware of EDS and have lived for years with unexplained and misunderstood pain and other symptoms. Even after finding out, they often choose not to pursue a diagnosis, as they are not keen to repeat their misadventures in the medical system, with such bleak treatment options.

EDS as I understand it today is a multisystemic condition. Aside from joint instability, (sub)luxations, tendons that tear easily and heal poorly and in some types fragile skin and blood vessels, there is often digestive tract involvement. This can range from mild obstipation to severe gastroparesis. Bladder problems are also very common. Chronic bladder infections, urine retention and incontinence are common complaints. Organs in the pelvic region often prolaps. This goes for the uterus and bladder but also the rectum. Heart palpitations are also common and usually harmless, though sometimes indicative of a malfunctioning valve. But this still isn’t all. There’s fatigue, memory problems, impairment in coordination, a higher chance of depression and anxiety disorders (maybe that’s just the stigma of living with a misunderstood or unexplained condition) and even delayed development in kids. Often there are muscular symptoms as well, and a slightly anomalous muscle structure. A little less common is autonomic nervous system involvement, but still common enough to raise questions. Also gluten intolerance or allergy seem to be more common among EDS patients. I could go on for a while, but there’s no point really because even for the most prominent complaints there is little to no research available about frequency of occurance, origin of the complaints or effectiveness of treatment.

Take the joint instability for example, and accompanying (sub)luxations and pain. This is the most debilitating feature of EDS, but we have no idea why one person with EDS makes progress with physical therapy, and why another person with EDS only deteriorates. There are probably multiple factors in play, like the available living adaptions, braces and other joint-stabilizing measures, and the amount of rest a person allows one self. But I have long suspected that there are wrong and right ways to train a person with EDS. The question is what is wrong and right here. This is not something I can find out on my own. Maybe it’s really true that there are people with EDS who simply don’t respond to exercise. But we can only find out with some proper research. And with proper I mean a study with more than 20 test subjects per training method, over the course of multiple years, preferably with a rehab team, to facilitate as much stability as possible during training.

Another important thing to realize with this kind of research is that EDS is not a single well-defined condition. It’s a collection of similar connective tissue disorders. Especially the hypermobility type. At this time we can not differentiate between these conditions and we have to treat them the same, even though they aren’t. What works for one condition might not work for the other.

That warrants some research on it’s own, the different flavors of EDS. Over the years I’ve read about and developed several theories as to the different causes of EDS. I know little about genetic loci, so I can’t do any educated guesses there. If it was that easy, the genes would have been found long ago. But other than that I’ve stumbled upon some interesting ideas.

The first one is hormonal. It is well known that about 95% of known EDS cases are women, even though genetically speaking, there should be just as much men suffering from EDS as there are women. The common explanation is simply ‘hormones’, though this has to my knowledge never been confirmed. There are however numerous studies on the effect of estrogen and progesterone on connective tissue. There is no consensus, but the notion that estrogen strengthens connective tissue and progesterone weakens it seems to coincide with what women with EDS experience. There is a noticeable worsening of instability and subluxations from a few days before our periods to a few days after. Pregnancy is also a time that is strongly linked with deterioration. Male hormones (testosterone) are known to increase muscle mass, which in turn helps prevent (sub)luxations. This does not suggest a cause, but it does a treatment option.

Another interesting hormone is relaxin. Research focusing on female athletes concluded that women with a higher relaxin concentration in their blood were generally more hypermobile and more susceptible to injury. Question here is if there might be a group of people with an EDS diagnosis who simply have an unusually high relaxin concentration. These people would not have easy bruising, or skin tearing, but they would have stretchy skin and reduced scarring.

A few years back there was a woman with EDS on the internet, who had gone from being bedridden for over 10 years, to being able to walk for 5 miles. Needless to say she got a lot of attention both positive and negative. In the end it got too much for her, and she removed all the information she posted. A shame really, because she and her doctor had developed a very interesting theory. This doctor had discovered that several of his patients with EDS, but also patients with Marfan syndrome had a shortage of certain amino-acids. Oral supplementation did not help, so he started injecting his patients with the amino-acids that they lacked. It didn’t have such a dramatic effect on all of his patients, but most experienced improvement. It would suggest that there is a group of EDS and Marfan patients where the defect is primarily metabolic, and the following shortage of essential amino-acids would result in weak connective tissue. I hope that these two are raising money for research behind the scenes, I do not have the data to back this theory up. It has the potential to improve a lot of lives.

The last theory is that there might be mitochondrial involvement in another group of people with EDS. Mitochondria can be seen as the energy plants of the cell. If there’s something wrong with them, all kinds of problems can arise. There is an overlap in possible symptoms, though I know way too little about this to be able to judge this theory on it’s likelihood.

About all of the available treatment and symptom management is based on personal experience of the people in question, and have zero backing in medical research. Don’t get me wrong, I am very grateful to the many doctors, physical therapists and occupational therapists out there who have taken it upon themselves to try and help people with this debilitating condition. Without them, we would be lost. But I don’t think it’s too much to ask that we combine that wealth of experience into a treatment protocol. I’d like to see basic quality of care for people with connective tissue disorders, and handholds for the people treating them. I’d like to see clarity about what Ehlers Danlos Syndrome is, and what we can do to improve quality of life.

How is it that everyone knows what ALS is, even though it occurs 2 in 100.000 people, and EDS, with an extremely conservative estimate of 1 in 10.000 is unknown even by most doctors. In medical school, prospective doctors are told EDS is an extremely rare condition and they are unlikely to ever encounter it. Other than that, it has something to do with hypermobility. That’s it. With the likelihood of sick people visiting doctors, I’d say a doctor is very likely to come across EDS in their practice. If my estimates are anywhere near accurate, they are likely to come across several new EDS patients every year. Definitely something worth learning about. Even for specializations that generally don’t have anything to do with EDS. Like other people, people with EDS get sick like everyone else. They get cancer, they get strokes, they get diabetes, just like everyone else. The problem is that EDS complicates the treatment of all those illnesses, so it is vital that doctors know this condition. At the least there should be treatment protocols to fall back on for those that don’t.

I’d also like to see an effort to educate people with hypermobility about joint care. Even if one does not have Ehlers Danlos Syndrome, overextension of joints significantly increases susceptibility to injury, and degenerative joint disease. I think we could prevent a lot by teaching kids about how far their joints are supposed to go in Physical Education class. After all, 10% of people is hypermobile. Among kids, it’s even 40%.

To this day, I still get surprised learning I’m not supposed to be able to move a certain way. Because we have a habit of moving in very weird and unexpected ways, people don’t even notice. It turned out a friend of mine had a habit of bending from her lower back, instead of her hips. She could make a 90 degree bend with the bottom few vertebrae, and sat on the back of her pelvis instead of her bottom. No one ever noticed, but once we noticed it we couldn’t figure out how no one had before. When your joints can bend that way, and you can’t feel where the limit is, you develop very strange habits. Unfortunately those habits are harmful. And as there is no cure, just management, prevention is our best shot.

Finding tagless files with tmsu

August 13th, 2014 -- Posted in Tech | 2 Comments »

I have a vast ebook collection, and as ebook titles are not as descriptive as one would like when searching for books on a certain topic, I decided I needed a way to organize my books. I went with tmsu, a command line utility that keeps an sqlite database of files and associated tags. It does not require anything special, and because of the option to mount a virtual, tag-organized filesystem, it’s useable with any software you like.

So I went on and tagged a big part of my collection. In theory, when I add to my collection, I should tag those files right away. In practice, that does not happen. So I found myself looking for a way to list all untagged files in a directory.

tmsu added the –untagged handle for the ‘tmsu files’ command, to be used together with –path. Unfortunately, that does not work at this time though. It requires the –all argument, but that does not include the untagged files. So I started playing around with xargs. The problem here was that many of the file names include spaces, underscores, and other stuff that really does not belong in a file name. After a lot of trial and error, I came to this solution:

find . -maxdepth 1 -print0 | xargs -0 -eof tmsu tags | grep “: $”

Of course, if you want to list files in a subdirectory too, you should change the -maxdepth argument. I added an alias for this, as I’m not going to remember it. I hope this saves you a long search.

ImportError: cannot import name QVariant

July 21st, 2014 -- Posted in Tech | No Comments »

I was installing a self-compiled instance of calibre (all-in one ebook solution) on one of my virtual machine when I ran into a particularly unhelpful python error: “ImportError: cannot import name QVariant”.

First of all, a little bit about my situation. I do my compiling on a separate development vm, which has a lot of packages installed. I run slackware 14.0 (custom install) – strictly 64 bit. I used a slackbuild to compile, so all dependencies were listed and I had compiled & installed them previously. This usually means that all dependency errors can be resolved with packages present in a slackpkg mirror.

Logically, the first place to look with a python error is python. So I fired it up and ran the offending command, hoping it would provide me with some more useful error message:

from PyQt4.Qt import QVariant

The original command was a bit longer, but this was the part the error was about. But no luck here, the error message was exactly the same. I tried “import PyQt4.Qt” after that, but no error there.

Seeing as I did not get any errors during compilation, I tried firing up calibre at my dev vm. No errors. So I decided to run the offending command in python there too (in verbose mode) and compare the results to the non-working machine.

No clear problem spotted, but I noticed that all files mentioned were in the same directory (/usr/lib64/python2.7/site-packages/PyQt4). Both machines had the exact same stock PyQt4 version, but who knows what went wrong during the installation, so i decided to take a look there.

There was nothing missing, or different, but I noticed this file: pyqtconfig.py

I thought, what the heck. Let’s run it. And yes, there was the actual error: ImportError: No module named sipconfig. A quick slackpkg search pointed me towards the sip package, and after that was installed, I ran the pyqtconfig.py file, and calibre started without problems!

Now you ask, why didn’t I say so right away? Well, because learning to solve errors by yourself is hard. It took me a long time, and I hope that by reading about my methods, you’ll get better at it too. Good luck!

Declaring an array of objects in arduino cpp

May 10th, 2014 -- Posted in Tech | 3 Comments »

I have been working on an adaptive input device for keys4all, and in that process, I’ve ran into some interesting aspects of arduino cpp. I say arduino cpp instead of cpp, as arduino’s version of cpp is quite different from ‘regular’ cpp. I’d go as far as to say it’s not cpp at all.

Some of the differences are that you can’t define types in the same file as where you use them (don’t ask me why, it has something to do with prototypes apparently). Also, using preprocessor macros has influence on all the libraries you use. So watch out for naming conflicts. But those weren’t the most surprising, or frustrating.

For my keyboard, I have been using the Bounce library to debounce keys. It’s main class, Bounce, is initialized with a pin number and a delay in microseconds.

Because my keyboards might use different amounts of keys, and looping over an array is easier than referencing every key individually, I decided to store my Bounce objects in an array inside my ‘keyboard’ struct. Here is where it gets hairy.

Doing this the regular way (“Bounce keys[NumKeys];”) gives a lot of compile errors. First, it complains that keyboard::keyboard() has been implicitly deleted because of malformation. But more interestingly, the bounce library complains that it has been initialized without parameters. Apparently declaring an array of objects implicitly initializes those objects.

Let me repeat this. Declaring an array, implicitly initializes it in arduino cpp. Are you baffled yet? I am. Of course, you aren’t allowed to initialize anything inside a struct declaration, and the Bounce class expects two parameters, so the errors aren’t unexpected.

I can’t understand why this design choice has been made, or why it is not documented. It took me a hours of debugging before I figured this one out.

How to get around this? Use pointers (“Bounce * keys[NumKeys];”). Arduino cpp will now behave as expected and won’t try to initialize empty Bounce objects. Hope that helps.

gdk-pixbuf-csource: could not recognize image file format for stock_attach.png

December 16th, 2013 -- Posted in Tech | 3 Comments »

When compiling libgnomeui, I ran into a particularly persistant error. Namely “Could not recognize image file format for ./stock_attach.png”

With my system being a very slimmed down slackware 14.0, first thing I checked was the presence of libpng, which was neatly installed. With a little help from google I discovered that this error usually meant an empty /etc/gtk-2.0/gdk-pixbuf.loaders file.

It was not empty in my case, but to be sure I generated a new one with gdk-pixbuf-query-loaders (don’t forget to add -64 if you’re on a strictly 64 bit system). Needless to say it did not make a difference.

After a bit of digging I discovered the ‘gdk-pixbuf-csource’ command to be the culprit. I had it execute on different file formats, jpg, gif, all things clearly present in the gdk-pixbuf.loaders file. Same error over and over again.

Looking at the gdk-pixbuf.loaders file I noticed the recognition pattern was formatted like a mime type. Now it started dawning on me. I did not have any libraries present which handled mime data.

And yes, after installing gmime and shared-mime-info, gdk-pixbuf-csource correctly identified image file types and libgnomeui compiled without further errors.

The only way you’d run into this problem is if you were stupid enough to prune even the most basic packages from your slackware install, but if you do, I hope this helped.

Accessing a time machine / os x / hfs+ volume in linux

August 12th, 2013 -- Posted in Tech | 3 Comments »

In moving my data from my dying os x 10.6.8 (snow leoppard) macbook pro to my 100% linux workstation I ran into a few problems. My laptop is extremely unstable so I initially did not think transferring the data over the network would be a bad idea. Why would I anyway, I had time machine backup volumes with all the data I needed on them.

But in trying to access those from my workstation I ran into a few problems. The filesystem os x uses by default, hfs+ (journaled) is only partly supported by linux. With hfs-utils installed I was able to mount the volume, though read only. Not a problem, I thought, as I only need to copy the data over, not alter it. Boy was I wrong. I was logged in as root and I changed working directories to my home directory in the most recent backup. When I started to copy things over, I got a “permission denied” denied error. Wait, I was root right? No mistake there. No matter what I tried, I could not get access to the files inside my home directory.

After some googling I tried mounting with some masks:

mount -t hfsplus -o umask=0,uid=0,gid=0 /dev/sdb2 /mnt

But it appears those masks are only applied when an ‘unknown’ id is listed at the permissions, and it didn’t work very well because I still had a lot of unknown and undefined id’s in the permissions.

So I tried to create a user with the right uid and gid. No success. By the way, there was a different gid on every file in my home directory even though in os x it was all “nihlaeth:staff”.

I decided I needed the disk writeable to try some chowning. Back in os x I tried chowning recursively. “permission dienied”, even with sudo / root. Then I tried disabling journaling so I would be able to write to it in linux. This should be possible by using disk utility, selecting the volume and then alt-clicking “File” -> disable journaling. Needless to say, os x refused.

At this point I started transferring data from my account to another disk the regular way. But there was one other thing I could try: disk permissions in finder. Go to finder, right click the volume and pick “Get info”. At the bottom yon see some permission settings, and a little lock under it. Unlock, click the cogwheel and click “apply permissions recursively”. Roughly 5 hours later “Locum” was done doing that but the files were still unaccessible.

Other files on the disk outside of the time machine folders were accessible however. I have no idea what kind of funky shit time machine pulls on these files, but I’m not amused. Backups have to be accessible to be of any kind of use. What if your ‘awesome’ os x machine fails and all you have to access your very important and needed files is linux or windows? Well, then you’re screwed. If you have the choice, I advice you to use rsync instead of time machine.

P.S. If you want to be able to write to a non-journaling hfs+ volume, you have to set ‘force rw’ under -o. Writing to a journaled hfs+ filesystem is not possible with linux at this time.

Errno.h: no such file or directory

August 8th, 2013 -- Posted in Tech | No Comments »

I’m trying to get my samsung ML 1670 printer working on a cups server running on slackware 14. The pdd files provided by samsung simply don’t work and unfortunately slackware does not provide an alternative. As a last resort I decided to try and compile splix, which claims to support my printer. There’s a slackbuild available.

I’m not making it easy on myself as usual, my slackware is very minimal. I use my own tailored tagfiles. As a result it’s always tricky to find all the missing packages at compile time. At one point I ran into the daunting errno.h: no such file or directory error. I could tell right away this was not a matter of running “slackpkg install errno”, it sounded way too essential for that.

I was right. All I could find on this particular error was that I needed to install both the kernel source and headers. Needless to say, a kernel update and a lot of reboots later, it still didn’t work. But running “slackpkg file-search errno.h” revealed some interesting information:

[ installed ] – kernel-headers-3.2.45-x86-3

[ installed ] – kernel-source-3.2.45-noarch-3

[uninstalled] – dev86-0.16.17-x86_64-2

[ uninstalled ] – glibc-2.15-x86_64-7

[uninstalled] – libnl3-3.2.11-x86_64-1

[uninstalled] – tetex-3.0-x86_64-8

Installing glibc did the trick. Hope that saves you a long search.

Also, what was I thinking, not installing glibc…