Tag Archive: configuration

Now, updating my desktop and laptop’s configuration to mount the Raspberry Pi. On my desktop this didn’t cause any problems, however on my laptop it caused the following proglem:

$ mount /mnt/rpisrv
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use ‘-o nolock’ to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified

The troubleshooting on the Arch Wiki says to change the NFS configuration not to need statd. But what about doing exactly what the message tells me to do?

root@hp # systemctl start rpc-statd.service

So, now it works, so enable it on boot:

root@hp # systemctl enable rpc-statd.service

So far my other machines, back to the Pi. CUPS, yes, let’s get that printer working. Apart from the problems with the actual printer, the drivers can cause problems as well. I have written about this before, reported a bug, it was once solved, but later was re-introduced I believe.

# pacman -S hplip cups

to install CUPS and the hplip driver (and its dependencies, which used to cause the mentioned problems before)

# systemctl start cups

is not enough, I cannot connect to the CUPS on my Raspberry. Looking the the config file, it appears to be configured to listen on localhost only, which is off course rather useless for a headless server. In /etc/cups/cupsd.conf, replacing Listen localhost:631 by Listen 631 should fix this problem, but it does not. Looking at the log files

E [17/Nov/2012:19:59:20 +0000] Unable to communicate with avahi-daemon: Daemon not running

it turns out there is a dependency on another daemon which should be started first. Now, the server is listening, but it gives me a 403.
I still need to set from which IP addresses the connections are allowed (in the same file as mentioned above). Adding Allow from 192.168.178.*
to all access levels will do. IPv6 configuration will be done later.

The Unable to get list of printer drivers: Success error appears again. meaning I cannot use the hplip driver due the foomatic problem.
Removing that shit again

# pacman -R foomatic-db foomatic-db-engine foomatic-filters hplip

and installing gutenprint instead

# pacman -S gutenprint

This is a problem which has been around for months if not longer. It had been fixed at some point I believe, but it re-appeared at some point.

Using the gutenprint drivers, I can add the printer, but there is still a problem. The printer doesn’t appear automatically in the list at the other computers. I can add the printer manually, and then it works, so I suppose this is a problem with avahi.

And it was indeed an avahi problem. But it was on the client side, where the

# systemctl start avahi-daemon
# systemctl enable avahi-daemon

The printer still doesn’t magically appear in the list, however, when I access cups, it will report the printer found, and can be added manually. But when I try to print to it, I get the error "Unable to locate printer "rpi-server.local". According to this page, it means incorrect hostname or ip address. Which can be correct, as .local isn’t valid in my configuration. My modem is a Fritz!Box, and appends local hostnames by fritz.box. I suppose this should to into the avahi config file. Changing that doesn’t help. Now the printer isn’t appearing anywhere. I suppose I should change this part in the avahi configuration on all machines. If that’s the case then it totally breaks the point of avahi, automatic configuration.

Anyhow, I have been trying various things, but it appears I cannot get auto, or semi-automatic configuration working. I assume this is related to the switch to systemd, as from memory, it used to work automatically, as soon as the “share this printer” checkbox was marked, the printer used to automatically appear on all computers in the network. Well… I can add it manually. I guess that’s what I will do for now…. but I am not pleased with the fact it ain’t working as it should.

Now, let’s get started with NFS, right? Well… first things first… this configuration is supposed to replace the BeagleBoard. As mentioned, I have occidentally overwritten its SD card. This also means I cannot access its current configuration.

I cannot login to the device anymore over ssh or serial connection due incorrect content of the root filesystem. However the NFS server is still serving perfectly fine. Since I cannot login, I cannot gracefully unmount the filesystems. The point is, I am listening to music. The music is on the USB hard disks connected to the BeagleBoard, which I will have to shut down in order to connect them to the Raspberry Pi to configure the mount points. If I could access the old configureation, I could just copy over the entries in /etc/fstab.

I will be using UUIDs to identify the partition to mount, as, when using USB, I cannot predict which device name it will have. I mean, if I disconnect, and reconnect the hard disks on a different USB port, I wish not to have to change the configuration. Therefore I will use UUIDs so no matter what device name it gets, it will work. So, let’s delay configuring the mount points to a later point. We will configure the mount points (same as currently on the BeagleBoard):

/mnt/1000 : 1000 GB USB HARD DISK, DATA
/mnt/1500 : 1500 GB USB HARD DISK, DATA

If I just create the directories, the rest of the procedure should work, and the actual hard disks can be added later. Let’s install the NFS software. Also… let’s install vim, the editor I am used to, as it isn’t installed by default in an ArchLinux installation (vi and nano are)

# pacman -S nfs-utils vim

For security reasons, we will set up an nfs root

# mkdir /srv/nfs4
# mkdir /srv/nfs4/1000
# mkdir /srv/nfs4/1500
# mkdir /srv/nfs4/andre

and add the following to /etc/fstab

/mnt/1000 /srv/nfs4/1000 none bind 0 0
/mnt/1500 /srv/nfs4/1500 none bind 0 0
/home/andre /srv/nfs4/andre none bind 0 0

and set up the exports in /etc/exports


To start the nfs server, just now

# systemctl start nfsd.service rpc-idmapd.service rpc-mountd.service rpcbind.service

Verifying the exports from my desktop machine:

$ showmount -e
Export list for

Since this looks fine, I can enable startup during boot using

# systemctl enable nfsd.service rpc-idmapd.service rpc-mountd.service rpcbind.service

This is the new way of configuring services at boot, as compared to the old /etc/rc.conf method.

So, I guess it’s about time to shut down the BeagleBoard and replace it by the Raspberry Pi. Even though there are some more services to be configured, such as my IPv6 tunnel, printer server, scanner server, and so on. As I am unable to gracefully shut the BeagleBoard down, and due its instability, I guess I’d better fsck all the external hard disks before putting them online in the new configuration.

One thing to verify before proceeding is to verify the Raspberry Pi boots up headless, and I’ve heard this might be an issue. However, the system comes up perfectly fine.

In order to listen some music while these operations are in progress, I will revert to vinyl. The real way to listen to music ;)
PS. I bought this record last wednesday. It’s awesome to see new music appear on vinyl only ;)

So, let’s continue configuring that Raspberry Pi, right? First, I would like to observe some weird behaviour. Please note I have attached a monitor, keyboard and screen to the Raspberry Pi, so I am not using a serial console, as I did when I configured my BeagleBoard.

The Raspberry Pi supports my monitors resolution 1280×1024, while the BeagleBoard does not (at a refresh rate high enough to be accepted by the monitor…. details) Another difference is that it works “out-of-the-box” on the Raspberry Pi. Just plug the monitor in and power it on. It will find out what resolution to use by itself, while the BeagleBoard required it as a kernel parameter.

The BeagleBoard is advertised as a developer board, while the Raspberry Pi aims at being a teaching tool. Another difference between those boards is that the BeagleBoard has a mounted RS-232 connector, while the Raspberry Pi only has the UART to pins on the expansion header, which is 3.3 Volt level. Therefore some level converters are required to be able to use this thing. I have ordererd this one on DX.com. The name says TTL, but in the specs it says “VCC: 3V / 5V”, therefore I think this one will do the trick. But I guess I will have to verify the voltage, as the Raspberry is *not* 5V tolerant.

DX.com, the chinese webshop, selling all kinds of stuff. I have ordered stuff there before. Free shipping, it may take a while to get it, but it’s for free. Not all my orders there have been without problems, but their customer services are good. If there are any problems, they offer replacement of refund. No difficult questions asked.

Anyways, why did I even start talking about the monitor being connected stuff, well, it’s because I am unable to log in (as root, I haven’t created users yet) on tty2, tty5 and tty6. But it works on tty1, tty3 and tty4. Looking at /var/log/auth.log

Nov 17 10:15:54 rpi-server login: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Nov 17 10:15:54 rpi-server systemd-logind[98]: New session c1 of user root.
Nov 17 10:15:54 rpi-server login: ROOT LOGIN ON tty1
Nov 17 10:16:04 rpi-server login: pam_securetty(login:auth): access denied: tty ‘tty2’ is not secure !
Nov 17 10:16:12 rpi-server login: FAILED LOGIN 1 FROM tty2 FOR root, Authentication failure

So, we see a successful login and an unsuccessful one. They’re similar for the other tty’s mentioned. Asking this question go Google gives me securetty. /etc/securetty is a text file which lists the tty’s where root is allowed to login. The content of this file agrees with the observed behaviour.

Still the question remains, why was it preconfigured with this content in the /etc/securetty file? One can assume it has been made for testing purposed, forgot about it, and ended in the image. Or is there a Raspberry Pi specific reason for doing this? Anyhow. I was planning to use this Raspberry Pi headless, so it doesn’t matter at this moment. However I am thinking about using a second Pi as desktop machine.

Well… the mystery has been solved. Let’s continue configuring this thing. Setting it up as NFS server… I am not sure if I have described this before when I’ve set this up on my BeagleBoard. However, due the conversion of ArchLinux to systemd, it would be outdated anyways.

Anyhow, since I’ve typed quite a lot already, the NFS configuration will go to yet another post. I have written two posts and the only thing I’ve done yet is booted it up, set root password and hostname.

PS: I’ve found an interesting link:Small Linux PCs overview

So… time to install ArchLinuxARM on my Raspberry Pi.

I will be using the ArchLinux image for the Pi released on 18 September 2012. I believe this is the first release using the new ARMv6 repo. This is an full image of a 2 GB SD card, so just a simple # dd bs=1M if=archlinux-hf-2012-09-18.img of=/dev/mmcblk0 will do the trick, given you enter this command as root, on the right machine, as stupid me entered this command on the BeagleBoard in stead of the laptop.

Since I am using a 16 GB SD Card, I will have to resize the partition to use the full card. However, I am planning to do this as final step, so I can create an 2 GB image of the configured system.

Given above steps went correctly, just insert the SD card into the Raspberry Pi and power it on. ArchLinux boots up. At this point, the /boot partition still contains the old-style bootloader. The new bootloader is however in the repository. As a first step I am planning to do an upgrade anyways. The default login is username/password root, which of course has to be changed. Anyhow… about upgrading the system, on ArchLinux:

# pacman -Syu

However, this gives an error less then 1024 bytes per second transferred the last 10 seconds. The default repository is set to a GeoIP/load balancer. It appears this sends me to the Chinese mirror. When pinging it I have a ping of ~450 ms. So, editing the /etc/pacman.d/mirrorlist. commenting the “load balancer” out, and removing the # from the Dutch mirror solves the problem, and the upgrades, including a new bootloader in the /boot partition, have been installed.

So… some basic tasks that need to be executed now, such as setting up root password, hostname etc. On ArchLinux, this used to go to /etc/rc.conf by setting HOSTNAME=, however, this method of setting up the hostname is deprecated. ArchLinux has switched to systemd recently. I have mentioned before, on my other machines, this switch required some changes. Merely the init= boot parameter, as there is some backwards compatibility with old configuration. However, it means I have to look at the new way of configuring stuff. (Yeah… I have been lazy for my old installations, not changing the configuration files to new style.) Please note that I can recommend setting the hostname first, before installing anything else, since some daemons may use it, and otherwise they’ll use the default.

# hostnamectl set-hostname rpi

However this gives an error: Failed to issue method call: org.freedesktop.PolicyKit1 was not provided my any .services files Apparently, for this to work, you need to install polkit and reboot first.