Ubuntu 13.10 for BeagleBone Black – Setting up zeroconf (Part II)

One thing which is very useful on embedded systems is to setup a zeroconf hostname so that you can access your BBB using SSH without actually knowing its IP address which may change from boot to boot. So how does this work?

  1. Install avahi-daemon on BBB:
    $ sudo apt-get install avahi-daemon

    After installing it, Ubuntu automatically starts it and enables it so that it gets launched on every boot.

  2. Change the hostname of BBB (default was arm for this Ubuntu image) to something meaningful like beaglebone by editing the file /etc/hostname. You can now reboot your BBB and it will be accessible on the network as beaglebone.local!
  3. Make sure you have nss-mdns installed on your host computer and mdns host lookup is enabled in /etc/nsswitch.conf. On Fedora, you have to install the package called nss-mdns from the repositories and change the hosts line in your /etc/nsswitch.conf file to look like below:
    hosts:      files myhostname mdns_minimal [NOTFOUND=return] dns

Now you should finally be able to ssh into your BBB with:

$ ssh ubuntu@beaglebone.local

Happy hacking!

Tired of attached modal dialogs in GNOME 3?

Modal dialogs are by default attached to their parent windows in GNOME 3. This is why you can’t change the position of a “Save as” dialog when you are in Firefox for example. If you want to disable this behaviour you can change it using gsettings:

$ gsettings set org.gnome.shell.overrides attach-modal-dialogs false

Multiple filesystem signatures on a partition

I have a separate partition for /root which is mounted through /etc/fstab. Last night I’ve done a huge update to my Fedora 18 laptop and today it got stuck in the mounting step.

Use rdbreak=pre-mount boot parameter

This is a nice kernel command line parameter which tells dracut to spawn a shell before mounting the filesystems. After dropping into the shell, I looked at blkid output:

# blkid
/dev/sda1: UUID="3E1691BA1691739D" TYPE="ntfs"
/dev/sda4: LABEL="LENOVO_PART" UUID="D4F69CB3F69C9778" TYPE="ntfs"
/dev/sda6: LABEL="f18" UUID="d73af424-0839-49d8-baff-fc3021f8160d" TYPE="ext4"

Oops, blkid doesn’t show /dev/sda2. Let’s force it to do low-level superblock probing which avoids blkid caches:

# blkid -p /dev/sda2
/dev/sda2: ambivalent result (probably more filesystems on
           the device, use wipefs(8) to see more details)

So, it seems that somehow the partition got multiple filesystem signatures instead of only ext4. Let’s look at it using wipefs:

# wipefs /dev/sda2
offset               type
----------------------------------------------------------------
0x4000040            btrfs   [filesystem]
                     UUID:  7630c42b-4275-45af-b7a0-24d05bfa4e5f
 
0x438                ext4   [filesystem]
                     LABEL: ssd75g
                     UUID:  d2675c32-931a-4e6d-8b73-5d9d488f2492

Well this is interesting. As far as I remember, I used btrfs before ext4 on this partition. So it is possible that after the latest updates, the fact that the partition got multiple signatures is not handled anymore by a layer. Let’s erase the signature for btrfs giving its offset:

# wipefs -o 0x4000040 /dev/sda2
/dev/sda2: 8 bytes were erased at offset 0x04000040 (btrfs): 5f 42 48 52 66 53 5f 4d

Now let’s look at what btrfs detects now:

# blkid
/dev/sda1: UUID="3E1691BA1691739D" TYPE="ntfs"
/dev/sda4: LABEL="LENOVO_PART" UUID="D4F69CB3F69C9778" TYPE="ntfs"
/dev/sda6: LABEL="f18" UUID="d73af424-0839-49d8-baff-fc3021f8160d" TYPE="ext4"
/dev/sda2: LABEL="ssd75g" UUID="d2675c32-931a-4e6d-8b73-5d9d488f2492" TYPE="ext4"

Woot, it came back 🙂