Latest Entries »

Some more Pi

Filed Under: English by andre — 1 Comment
22 December 2012

My second Raspberry Pi still powered on and connected to my LAN. That’s how I left to stack last Thursday. So, I SSH’ed into my first Pi, and from there, being inside my lan, I SSH’ed to my second Pi. Let’s do something with it, shall we? As this is a fresh installation, we have some configuration to be done. Let’s start with installing yaourt. On ArchLinuxARM we don’t need to add a repository like we should on regular ArchLinux.

[root@alarmpi ~]# pacman -S yaourt

As this Pi is connected to a screen, let’s get some graphical enviorement

[root@alarmpi ~]# pacman -S xorg xorg-apps xfce4 xfce4-goodies gdm

Note gdm seems to have some weird dependencies such as pulseaudio and flac. I assume because it makes some sound during login. I’ve tried lightdm instead but it doesn’t work on my Raspberry Pi.
Also base-devel is not installed, so we cannot compile anything, and the locale needs to be fixed, as I described in the other Pi installation, which I should also continue to write about. I have an unfinished post on concept for like…. ages. And I have a lot more to do on that other Pi… Anyhow, that’s all what I did last thursday, at least, to the Pi, as I went to the pub that night. It was 20 December after all, so, as the world was supposed to end the day after, it was my last chance to have some beers with friends.

So, 20 December 2012, I was at a pub until late at night. The result was I overslept the next day and missed the end of the world. And since I missed it, and was apparently still alive, I decided to continue playing around with that second Pi.

Since all the graphical stuff takes a lot of space, we should resize the file system to occupy the whole SD card. How to resize it is described on the ArchLinuxARM forum. It just tells you what to enter, but let’s take a look at what we’re actually doing


[root@alarmpi andre]# fdisk /dev/mmcblk0
Welcome to fdisk (util-linux 2.22.1).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): d
Partition number (1-4): 2
Partition 2 is deleted

Command (m for help): n
Partition type:
p primary (1 primary, 0 extended, 3 free)
e extended
Select (default p): p
Partition number (1-4, default 2): 2
First sector (194560-31512575, default 194560):
Using default value 194560
Last sector, +sectors or +size{K,M,G} (194560-31512575, default 31512575):
Using default value 31512575
Partition 2 of type Linux and of size 15 GiB is set

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

We’re deleting the rootfs partition, and creating a new one. Since there is no space between the boot and the root partition in the first place, the new partition will start at the exact same position as the just deleted partition. This means, we’ve got a bigger partition, with a smaller filesystem in there.

We also observe the re-reading of the partition failed, since the partition is currently in use. Therefore we have to reboot in order for the new partition table to be known to the kernel. After reboot we can perform the resizing of the file system itself


[root@alarmpi andre]# resize2fs /dev/mmcblk0p2
resize2fs 1.42.6 (21-Sep-2012)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/mmcblk0p2 to 3914752 (4k) blocks.
The filesystem on /dev/mmcblk0p2 is now 3914752 blocks long.

Now, we’re occupyting the whole SD card. So… setting up graphical enviorement. We’ve got some more disk space now, let’s install a browser.

[root@alarmpi andre]# pacman -S midori firefox
error: target not found: firefox

Hmmm…. firefox not found… apparently not in the repository. (Neither is thunderbird) More stuff I have to compile myself, just like I had to compile qemu. Perhaps I should really look into how to set up my own repository. For now, let’s install some other browsers.

[root@alarmpi andre]# pacman -S links midori netsurf

Links for when I am using a console. Perhaps I should better install elinks. Midori is a webkit browser. Should be fine for normal surfing but has some rough edges. At least last time I used it on my x86_64 machine. Netsurf, it is the default browser on the RISCOS image for the Raspberry Pi. That’s when I first heard of it.

Another this that cannot be missed on a graphical installation is an IRC client. Recently I have migrated from Xchat to Hexchat, since the latest Xchat release is over two years old. As Hexchat is in AUR, we need to compile it ourselves. While installing, I ran into the following error.

==> ERROR: hexchat is not available for the 'armv6h' architecture.
Note that many packages may need a line added to their PKGBUILD
such as arch=('armv6h').
==> ERROR: Makepkg was unable to build hexchat.
==> Restart building hexchat ? [y/N]
==> --------------------------------
==>

It happens on some packages. Note that AUR is meant for ArchLinux, and that ArchLinuxARM is just using their AUR. They could have set arch=(‘any’) and it would have compiled anyways, but i686 and x86_64 are the official supported architectures, therefore putting those in the arch array makes perfect sense. Just edit the PKGBUILD and add ‘armv6h’ to the arch array, and it will work fine. They should have used any. The specefic i686 and x86_64 should only be used for binary packages (skype, dropbox, opera and other proprietary someware *shiver*) or software written in assembly (not aware of any)

Compiling takes long, especially on an ARM board. Therefore, during compiling I decided to install some more software. Qmmp is the music player I usually use on my Linux boxes. I used to use xmms in the past, but it being a gtk1 application, it’s considered a dinosaur. Some distros ditched it years ago, but Arch still has it in its repository.

But doing this on a Raspberry Pi Model B Revision 1, with only 256 MB of shared RAM, well…. it ran out of RAM, and both terminals were closed. (My XFCE was running already) I need to connect a USB Hard Disk with a swap file and home partition. Compiling stuff on a SD card, it’s not a wise thing to do. Too many writes and a limited number of write cycles. I would like to use the SD for a little longer.

I know it’s not wise, but I’ve tried another attempt building hexchat, this time, not doing other things with the Pi during the build.

==> Tidying install...
-> Purging unwanted files...
-> Compressing man and info pages...
-> Stripping unneeded symbols from binaries and libraries...
-> Removing libtool files...
==> Creating package...
-> Generating .PKGINFO file...
-> Adding install file...
-> Compressing package...
bsdtar: Failed to set default locale
xz: (stdin): Cannot allocate memory
bsdtar: usr/share/locale/lv/: Write error
==> ERROR: Failed to create package file.
==> ERROR: Makepkg was unable to build hexchat.
==> Restart building hexchat ? [y/N]
==> --------------------------------
==>

So, it actually finished, but ran out of memory during the package creation. We really need that hard disk… But…. what hard disk to use? I have three external hard disks connected to my server Pi, but they’re in use. I have one more external HD. I wasn’t sure what was on it, but… there is stuff on it, and it’s full. A 500 GB Hard Disk… Backing the data up to my desktop… well… all it’s hard disks are smaller. One hard disk, containing a Windows 8 Developer Preview and an OpenIndiana installation, but mostly unpartitioned space. OpenIndiana isn’t really usefull on that machine, and I haven’t booted it since… long ago. And well… Windows… I don’t think I need to explain. So… that hard disk had been extracted from my desktop (blaatkonijn) and connected using a USB-IDE adaptor.

I’ve recently ordered an USB->IDE/SATA at dx.com. It looks exactly like my USB->IDE except for the SATA connector at the top. My USB->IDE power supply came with a switch in the cable, which the USB->IDE/SATA one lacked. More overly it came with a type B power plug.

 

Even though it comes with a type B power plug, mostly used in the United Stated (120 VAC) and Japan (100VAC), the power adaptor says 100-240 VAC, so just connecting a different cable should do the trick. Still I was a little suspicious, as when inserting the power cable, it made this clack noise as if its initial current was rather high. Therefore I have verified the output voltages with a multimeter before connecting any hard disks to it. This is something I’ve done a few weeks ago.

Anyhow, I’ve decided to use that power adaptor, as I don’t need the switch, and I started to parition it. GParted refused to start, due incorrect locale. The locate problem, for now, I just did a export LC_ALL="C", but this was another problem that needed to be fixed. Well… GParted working on C locale. How big should I make the swap partition? I’ve made it 8 GB. It’s insane, but better too much then too little, and the rest of the disk as home partition.

As I am configuring my fstab anyways, let’s take care of my network mounts as well.

[root@alarmpi andre]# pacman -S nfs-utils

This results in the following entries added to my fstab


UUID=5d44c79b-7fc0-4711-a9f5-73dcaea98275 swap swap defaults 0 0
UUID=839de469-ef9d-48a7-aedd-d2a6b05f1a5f /home ext4 defaults 0 2

rpi-server:/srv/nfs4/1000 /mnt/1000 nfs defaults 0 0
rpi-server:/srv/nfs4/1500 /mnt/1500 nfs defaults 0 0

At first I put nfs4, but it didn’t work yet, so I am using nfs3 instead. Looking at my other machines, they’re also using nfs3, so that’s consitent with the rest of my installation. I should look at how to migrate to nfs4, but nfs3 is good enough for now.

Why did I mention that power adaptor? Well… it went poof and blew my fuse after operating for a while. At least, I blaim that thing for my blews fuse, as it was rather hot and smelled burnt, and I had a feeling about it since I got it. Hooray, I had a little mini tiny apocalypse, a blown fuse.

Connecting my other power supply, the one with the switch, which came with this USB->IDE adaptor, everything works fine. This power supply remains at a normal temperature, and has been running for quite a while without problems. However, now I don’t have any power supply for the other USB->IDE/SATA adaptor.

As this post is getting lengthy, this is where I stop. More will follow in a next post, as there are some more things I’ve encountered. I mean, a lot has happened while waiting for the world to end. Also, a package with a 5¼” floppy drive I’d bought on ebay arrived

Tags: ,
Comment

CubieBoard, and a little Pi

Filed Under: English by andre — 2 Comments
16 December 2012

Last friday, my CubieBoard arrived. I only had time today to play around with it. First of all, it turned out to be a 512 MB version. I was under the impression the CubieBoards from the Indiegogo campaign were the 1 GB version.

Anyhow, let’s get started. Since it is an Allwinner A10 based device, it *should* work as follows:
Prepare the SD card as for a Mele A100 and replace the script.bin file with the adequate version.
The script.bin file is a compiled fex file, using the fex2bin tool. It should be somewhere in that git repository as well, but there is an AUR package so just install sunxi-tools-git and there we go.

The package included an USB to 3.3 Volt serial cable. How to connect it however? A little looking around finds me the answer.

DSC_0002

Connected to the serial console… nothing!!! Nothing at all.

Now…. I have been stupid. I had another USB-to-Serial adaptor inserted to my compyter, connected to an (unpowered) BeagleBoard. No wonder I saw nothing
on the serial connection!

So… connected to the correct serial port, I see an u-boot prompt, the usual countdown till boot. And booting the kernel. However…. the kernel isn’t very happy about the board…

The ArchLinux kernel is OOPSing… also, it detects 512 MB of RAM. This was supposed to be the 1 GB version of the CubieBoard, wasn’t it?
I have installed the script.bin for the 1 GB version. Perhaps that’s why it is having trouble? Replacing the script.bin file didn’t solve the issue.

I’ve downloaded a cubieboard specific boorloader/kernel from linux-sinxi which boots the board correctly. So, the board boots… however, using a kernel out of repository. I’m not that happy about having files in my filesystem pacman isn’t aware of.
Another issue with using this kernel is there are no kernel headers, so compiling kernel modules will be a problem as well.

So far so good, I’ve got a login prompt at the serial console. The system boots. Connecting the HDMI output to my DVI-D monitor doesn’t give me an output however. I will probably have to configure it somewhere. In the meantime, let’s look at some other stuff.

I’ve bought an HDMI -> VGA adaptor. Since my (second) Raspberry Pi is known to be working with my display, on it’s DVI-D input, I’ve decided to hook it up over VGA with the adaptor. This second Pi is not configured yet, just having (almost) unused image on it.

On boot, the monitor reports Out Of Range. This probably means the EDID information from the screen isn’t correctly passed through the HDMI interface, causing the Pi to select an unsupported resolution/refresh rate.

Of course it is possible to force a specific resolution in the config tile in the boot partition, but I consider this an ugly practice. So, software controlled resolution changing it is. It was a little work to figure this out, as it requires two separate tools to perform this action.

First there is fbset, a tool to configure the framebuffer. (Install package fbset)

Just setting

fbset -xres 1280 -yres 1024

doesn’t work. Therefore I have connected the monitor over DVI-D input again, and tried changing the resolution on a working screen. Even through the tool reports a different resolution, the content of the screen tells otherwise.

A little searching on the internet points me to a tool called tvservice. I have no idea to which package it belongs, it appears to be located in /opt/vc/bin. This directory is not in the path. It’s linked against libraries in /opt/vc/lib, which is also not in the library path. So, to tell ld to also look for libs there. (Note: temporary solution, also LD_LIBRARY_PATH was empty, otherwise I would have been replacing it with the command below)

export LD_LIBRARY_PATH=/opt/vc/lib

To list supported display modes

[root@alarmpi bin]# ./tvservice -m DMT
Group DMT has 8 modes:
mode 4: 640×480 @ 60Hz, progressive
mode 6: 640×480 @ 75Hz, progressive
mode 9: 800×600 @ 60Hz, progressive
mode 11: 800×600 @ 75Hz, progressive
mode 16: 1024×768 @ 60Hz, progressive
mode 18: 1024×768 @ 75Hz, progressive
mode 35: 1280×1024 @ 60Hz, progressive
mode 36: 1280×1024 @ 75Hz, progressive

To change resolution:

[root@alarmpi bin]# ./tvservice -e=”DMT 35″

This, indeed, does chnage the output resolution/refresh rate, however, it just outputs a blank screen. In order for it to work, afther changing the resolution with tvservice, the fbset command is required. Then it appears to work.

In the meantime, I have been thinking about other caused for this behaviour. I have heard about issues with similar adaptors in combination with the BeagleBoard. As the device is powered from the HDMI interface, it draws current from it. The current requirements were too high for the BeagleBoard, requiring a polyfuse to be replaced by a bigger one on the Beagle.

So, in order to test the device, I’ve hooked it up to the HDMI output of my laptop. The laptop (HP EliteBook 8530w) does not see the monitor connected. Not at all. At the moment when I unplugged the device, something funny happened.

Anyhow, seeing the results on the changing resolution on the Pi made me decide to give it another try. Surprisingly, this time it just worked out-of-the-box. I didn’t have to change any settings, the correct resolution was used right away.

I suspect the case was causing trouble again. There is this plastic case around my Pi, and the hole is just big enough for the metal part of the HDMI connector to pass through, however, the part where you hold the plug is against the cover, therefore, not allowing the plug go in as far as it normally would. This can cause some bad connection. Perhaps that’s what went wrong the first time. My usual HDMI->DVI-D cable has also bad contact issues, but it causes no signal.

This no-signal situation is what caused me to look into the online changing the output settings of the screen in the first place, as I don’t feel like rebooting until the damn plug makes contact.

However, I still have not verified the passing through of the EDID code. It could be that this tvservice is playing with me, and storing the resolution in the config file in the boot partition. It would not be neat if it did that, and I could just verify if the config file is untouched. Let’s assume for now, it just passed through the EDID as it should have.

Anyhow…. that was my Pi for today. I will have to look at the CubieBoard again, see how to make it generate some output on that screen. At least it boots, so it’s probably just a matter of configuration. And that’s going to be a little harder on the CubieBoard. The community is a lot smaller then the Raspberry Pi community, and AllWinner isn’t giving away much documentation about its SoC.

If it’s about documentation, a TI SoC is to be recommended I believe. I haven’t been reading much documentation myself, but that’s what I’ve been hearing. I still have that BeagleBoard C3 lying around. It’s that damn USB problem that’s keeping me from using it…. I should have returned it right away… I should… but back in the days I assumed it was a software issue and waited for a new kernel.

Well… the BeagleBoard, BeagleBoard-xM and BeagleBone are a little more expensive then Raspberry Pi and CubieBoard. I guess they’re also targeted at a different audience. Let’s just say, I’ve ordered a Raspberry Pi in the UK, I’ve ordered a CubieBoard in China, and a BeagleBoard in the USA. For the BeagleBoard I had to send a verification about the intended use to the American customs. Seriously!

P.S. Another funny observation: When unplugging the CubieBoard from its power source while connected to the supplied USB to serial cable, the power led remains lit (dimmed, but still emitting light)

Tags: , , , , ,
Comment

Just some thoughts

Filed Under: English by andre — 2 Comments
10 December 2012

So, before I was interrupted by that server hickup, I was about to write about dot-matrix LCD-displays. I have recently ordered a 128×64 LCD display at dx.com. This is more-or-less a cat-in-the-bag, as there is no datasheet provided, and there is no clear brand/type of the display. However, a possible datasheet might be this. This datasheet mentions a serial mode, but shown no clue how the controlling in serial mode is supposed to happen. The customer reviews are even more confusing as one user mentions it supports I²C and another user mentions SPI.

In the past, I have had some experience with a KS0107-based display. However, I have no guarantee which controller this display uses. However, it is likely to be a ST7920-based display. At least, if I have to believe a thread on how to get the display working in combination with an arduino. I am not familiar with the arduino platform, but the thread gives a few useful hints. The ST7920 datasheet tells about a parallel and a serial mode. The serial mode looks like a synchronous serial connection. I should provide a clock signal and data. Apart from some synchronisation bits, the serial data seems equal to the data which should be provided at the parallel interface. There is also a pin for selecting between serial and parallel mode.

The Arduino related discussions appear to be using the SPI to interface with this display in serial mode. I am not familiar with the SPI protocol, but from what I have read from it, it’s send-a-byte, receive-a-byte, but according to what I’ve read controlling this display in serial mode is just sending data. The use of SPI for this seems like a hack to me, however, if it works on an hardware SPI bus, it’s less CPU intensive then just bitbanging the protocol over GPIO.

As mentioned, I have been using a KS0107-based display before. I have been using this in parallel mode. Therefore, parallel mode would be my preferred mode for using this display as well. It’s simpler and faster, but it requires more GPIO pins, but I believe I am a little short of GPIO pins, and that’s what makes the serial mode preferable. Since my hardware also has an SPI bus, interfacing it over the SPI bus sounds like an option. Looking at the datasheet, the display also supports a 4 bit operation mode. So this is another alternative to interface such a display.

However, I still have not received my display yet, so it’s just some reading ahead what I’ve done. But the plan is to interface such a display with my Raspberry Pi. I might also order a 4×4 keypad to be used in combination with that display. Looking at the picture it has 8 pins.

Tags: , , ,
Comment

Server hickup

Filed Under: English by andre — 2 Comments
10 December 2012

I was about to write some thoughts down about a dot-matrix LCD display…. when my server failed to respond. It did reply to a PING, so the network connectivity was OK. When I was able to log in again a few minutes later, I noticed an insane load.
load average: 47.38, 80.48, 55.56
80?!?!?!?!?! what the fuck is my server doing!?!?!?! What has caused this behaviour? Is it a Denial-of-Service attack? If so, who has interest in bringing my server down?

Anyways, apart from the insane load, and the temporary being unavailable of the server, the real problem is this condition causes the server to run out of memory eventually, causing the kernel to start killing tasks, and when it does so, clamd is most likely the victim. When clamd is down, the mail server will refuse to handle any more mails. The default behaviour in case of out-of-memory is to kill the task using most memory. Clamav is a memory-hungry daemon. Why does it use that much memory? Anyhow, I am wondering if there is a way to exclude a specific process from the list of potential-to-be-killed tasks?

I believe the high load is caused due nearly running out-of-memory, causing heavy swap usage. Anyhow, everytime this event appears, it is caused by apache. So, that raises the question if there is a way to prevent apache (and anything that runs under it, such as php) from using too much memory?

Last this problem occurred, there were 128 instances of apache in memory. I guess, I should reduce this to a way lower value. I have been having problems like this before, and as solution I have started using mpm prefork. Its configuration allows me to set the maximum number of instances, and I have reduced this to a lower value. I hope this prevents this problem from appearing in the future.

So, in the end, it appears to be a simple misconfiguration. No attack whatsoever.

Tags: , , , , ,
Comment

ArchLinuxARM on the Raspberry Pi (part 6)

Filed Under: English by andre — Leave a comment
21 November 2012

There are no compilers installed on the system yet, so let’s do something about it, right? I mean, what is a Linux machine without compilers?

[andre@rpi-server ~]$ yaourt -S base-devel

I once wrote about dropbox, and tried to get it working on my BeagleBoard. Now, dropbox is proprietary software. I hate proprietary software you know. Actually, why would I trust some binary blob running on my system. It might be doing god knows what. Not showing your source? What are you trying to hide? Anyhow, the problem is the fact dropbox is only available as binaries, compiled for either x86 or x86_64, and we are on a armv6h system. So, we got to emulate x86 (or x86_64). For this purpose I suggest qemu, which is able to run linux elf binaries compiled for other systems, provided the required libraries are available.

My last attempt on my BeagleBoard wasn’t really successful, but that might be due the fact I didn’t have a full base system for the emulated architecture. With the new ArchLinux installation method, basically creating a base system using the pacstrap program, I should be able to setup a working system.

Now, the next problem is, qemu is not in the ArchLinuxARM repository

[andre@rpi-server ~]$ yaourt -Ss qemu
extra/vde2 2.3.2-2
Virtual Distributed Ethernet for emulators like qemu
community/libvirt 1.0.0-3
API for controlling virtualization engines
(openvz,kvm,qemu,virtualbox,xen,etc)
The URL http://aur.archlinux.org/rpc.php?type=search&arg=qemu returned error : 301

Looking at the last line, it appears the request to search the AUR is failing. However, 301 is not an http error code, but a redirect. The aur repository should be accessed through https and not http. We can fix this by setting AURURL="https://aur.archlinux.org" in /etc/yaourtrc

[andre@rpi-server ~]$ yaourt -Ss qemu
extra/vde2 2.3.2-2
Virtual Distributed Ethernet for emulators like qemu
community/libvirt 1.0.0-3
API for controlling virtualization engines
(openvz,kvm,qemu,virtualbox,xen,etc)
aur/aqemu 0.8.2-2 (0)
QEMU GUI written in Qt4
…

Now, we got results from AUR as well… but still no qemu. Last time I just grabbed the source from the qemu site and compiled that, but this time, I am going to build a package and install it through pacman.

Well, if there is no binary package, perhaps we can go through ABS (Arch Build System) and build the package ourself. So let’s look up how it works, shall we?

[andre@rpi-server ~]$ man yaourt
man: can’t set the locale; make sure $LC_* and $LANG are correct

Hmmm? what’s that? can’t set the locale?

[andre@rpi-server ~]$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE=”en_US.UTF-8″
LC_NUMERIC=”en_US.UTF-8″
LC_TIME=”en_US.UTF-8″
LC_COLLATE=C
LC_MONETARY=”en_US.UTF-8″
LC_MESSAGES=”en_US.UTF-8″
LC_PAPER=”en_US.UTF-8″
LC_NAME=”en_US.UTF-8″
LC_ADDRESS=”en_US.UTF-8″
LC_TELEPHONE=”en_US.UTF-8″
LC_MEASUREMENT=”en_US.UTF-8″
LC_IDENTIFICATION=”en_US.UTF-8″
LC_ALL=

No such file or directory? We’re missing something here! It seems, in the rootfs image for Raspberry Pi, the locate isn’t set up
correctly. In /etc/locate.conf the language was set to LANG=en_US.UTF-8, however, it was never generated, since /etc/locale.gen isn’t configured, all
possible langauges were still commened out. Removing the comments for en_US.UTF-8 UTF-8 and nl_NL.UTF-8 UTF-8 and running locale-gen

[root@rpi-server andre]# locale-gen
Generating locales…
en_US.UTF-8… done
nl_NL.UTF-8… done
Generation complete.

Problem solved! Right, were where we, yes, compiling from ABS. Seems adding a

[andre@rpi-server ~]$ yaourt -Sb qemu

Gives me a not found too, so using ABS directly isn’t going to work either. So, what we’re going to do is get the PKGBUILD from the regular ArchLinux repository and build that.

[andre@rpi-server ~]$ wget http://mirrors3.kernel.org/archlinux/sources/packages/qemu-1.2.0-1.src.tar.gz

[andre@rpi-server ~]$ tar -xvf ./qemu-1.2.0-1.src.tar.gz

Edit the BUILDPKG file and add armv6h to the arch= array, (alternatively call makepkg with the -A option to ignore the architecture) and start buildpkg

[andre@rpi-server qemu]$ makepkg
==> Making package: qemu 1.2.0-1 (Tue Nov 20 21:01:34 GMT 2012)
==> Checking runtime dependencies…
==> Missing Dependencies:
-> sdl
-> alsa-lib
-> nss
-> bluez
-> vde2
-> libpulse
-> seabios
-> libcap-ng
==> Checking buildtime dependencies…
==> Missing Dependencies:
-> texi2html
==> ERROR: Could not resolve all dependencies.

Okay, missing some dependencies. If we were running through yaourt, it would install the missing dependencies for me. But let’s just install what it tells me to install.

[andre@rpi-server qemu]$ yaourt -S texi2html sdl alsa-lib nss bluez vde2 libpulse seabios libcap-ng

error: target not found: seabios

We discover seabios is not in the ArchLinuxARM repository either. However this is a noarch package, so we can just take it from the regular ArchLinux repository.

[andre@rpi-server qemu]$ yaourt -U http://mirrors3.kernel.org/archlinux/extra/os/x86_64/seabios-1.7.0-1-any.pkg.tar.xz

Now, we’re ready to build. Since this may take a while… let’s run it in a screen. Since this was a new installation, screen was not yet installed

[andre@rpi-server qemu]$ yaourt -S screen

and here we go!

[andre@rpi-server qemu]$ makepkg
==> Making package: qemu 1.2.0-1 (Tue Nov 20 21:35:20 GMT 2012)
==> Checking runtime dependencies…
==> Checking buildtime dependencies…
==> Retrieving Sources…
-> Found qemu-1.2.0.tar.bz2
-> Found 65-kvm.rules
==> Validating source files with md5sums…
qemu-1.2.0.tar.bz2 … Passed
65-kvm.rules … Passed
==> Extracting Sources…
-> Extracting qemu-1.2.0.tar.bz2 with bsdtar
==> Removing existing pkg/ directory…
==> Starting build()…

Since this is going to take for a while, just detach the screen, and tomorrow we’ll see if it worked

Something I might want to look into is cross-compiling, and not just compiling, but also to build the package. makepkg doesn’t appear to have an option for target architecture. Well, only in it’s configuration file, but as it doesn’t appear to have support for cross compiling by itself, I doubt if it will work if I just change the main config file.

I have been searching the ArchLinux wiki for cross compiling packages, without any luck yet. Perhaps I will find something on the ArchLinuxARM wiki, but not today. PS. I might consider setting up a repo for hosting qemu packages, but I need to collect more info what’s involved in doing so.

Tags: , , ,
Comment

Gutenprint, hplip, foomatic

Filed Under: English by andre — Leave a comment
19 November 2012

I mentioned using the gutenprint driver for my HP Deskjet 895Cxi printer. This driver is causing issues, I’ve been experiencing for quite a while. The first page it prints is often corrupted, and looks like this

The tail of /var/log/cups/error_log looks like

W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/KONICA_MINOLTA/KOC451JX.ppd.gz!
W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/Epson/eplp850c.ppd.gz!
W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/Epson/eplp950c.ppd.gz!
W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/Epson/eplp980c.ppd.gz!
W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/Epson/eplp920c.ppd.gz!
W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/Epson/eplp9100.ppd.gz!
W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/Epson/eplp960s.ppd.gz!
W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/Epson/eplp830c.ppd.gz!
W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/Epson/eplp880c.ppd.gz!
W [19/Nov/2012:15:48:24 +0100] [CGI] Missing NickName and ModelName in /usr/share/cups/model/foomatic-db-ppds/Brother/BR5070DN_GPL.ppd.gz!
E [19/Nov/2012:15:48:25 +0100] [cups-driverd] Bad driver information file “/usr/share/cups/model/foomatic-db-ppds/Kyocera/ReadMe.htm”!
E [19/Nov/2012:15:48:26 +0100] [cups-driverd] Bad driver information file “/usr/share/cups/drv/cupsfilters.drv”!
~

As these files do not involve the printer I am interested in, I can remove these files, and I am able to use the hpijs or hpcups driver, which don’t have the issue I am experiencing with the gutenprint driver.

Please note: This is happening on the cups on my desktop computer, as it locally renders and sends the rendered data to the cups server running on the Raspberry Pi. However, it should apply to any CUPS installation.

Tags: , , , ,
Comment

ArchLinux using systemd: X on tty1, but what if X fails?

Filed Under: English by andre — Leave a comment
18 November 2012

After migrating my ArchLinux from sysvinit to systemd, I’ve noticed my X screen to be at tty1 in stead of the usual tty7. At that point, I didn’t realise the consequences of this, until this morning. Yesterday I’ve run updates in my system, and this morning, the GUI wouldn’t come up. It turned out to be an Xorg problem. However, in the old situation, I would simply see a login prompt on tty1. But since tty1 would now turn into the X screen, all there is to see are some messages that appeared during boot, and then nothing, the system appears to hang, until I switch to another tty, where I see my usual login prompt.

The problem, the nvidia driver updated to nvidia 310.19-2. In the log messages appears

[ 10.500692] nvidia: module license ‘NVIDIA’ taints kernel.
[ 10.500701] Disabling lock debugging due to kernel taint
[ 10.536285] NVRM: The NVIDIA GeForce 6200 GPU installed in this system is
NVRM: supported through the NVIDIA 304.xx Legacy drivers. Please
NVRM: visit http://www.nvidia.com/object/unix.html for more
NVRM: information. The 310.19 NVIDIA driver will ignore
NVRM: this GPU. Continuing probe…
[ 10.536462] NVRM: No NVIDIA graphics adapter found!

Therefore I am not so pleased with this Xorg on tty1 thing. I believe that in the old sysvinit situation I would even get a message about there being an X problem, but now, the system appears to hang.

Also… how to fix the problem? I could install nvidia-304xx, but why am I using the tainted nvidia driver anyways in stead of the open source nouveau? I believe this had something to do with the nivdia control panel, as back when I installed the machine, I wasn’t familiar with the xrandr tool to configure my TV-out correctly.

Removing the old driver doesn’t work due dependencies:

[root@blaatkonijn andre]# pacman -R nvidia nvidia-utils
checking dependencies…
error: failed to prepare transaction (could not satisfy dependencies)
:: freeglut: requires libgl
:: glu: requires libgl
:: gnome-session: requires libgl
:: lib32-libgl: requires libgl
:: libva: requires libgl
:: mesa: requires libgl
:: mplayer: requires libgl
:: qemu: requires libgl
:: qt: requires libgl
:: webkitgtk2: requires libgl
:: webkitgtk3: requires libgl
:: wxgtk: requires libgl
:: xorg-xdriinfo: requires libgl

Another approach, to tell pacman to install the nouveau driver won’t work either. Pacman detects a conflict, two packages providing the libgl, which caused the problem mentioned above.

[root@blaatkonijn andre]# pacman -S nouveau-dri xf86-video-nouveau
resolving dependencies…
looking for inter-conflicts…
:: libgl and nvidia-utils are in conflict. Remove nvidia-utils? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: nvidia: requires nvidia-utils=310.19

So, the correct way to switch from nvidia to nouveau is to remove nvidia, but leave nvidia-utils, and then install the nouveau driver.

[root@blaatkonijn andre]# pacman -R nvidia
checking dependencies…

Targets (1): nvidia-310.19-2

Total Removed Size: 3,88 MiB

Do you want to remove these packages? [Y/n]
(1/1) removing nvidia [######################] 100%
[root@blaatkonijn andre]# pacman -S nouveau-dri xf86-video-nouveau
resolving dependencies…
looking for inter-conflicts…
:: libgl and nvidia-utils are in conflict. Remove nvidia-utils? [y/N] y

Targets (4): libgl-9.0.1-1 nvidia-utils-310.19-1 [removal]
nouveau-dri-9.0.1-1 xf86-video-nouveau-1.0.4-1

Total Download Size: 13,05 MiB
Total Installed Size: 49,96 MiB
Net Upgrade Size: -18,14 MiB

Proceed with installation? [Y/n] y
:: Retrieving packages from extra…
libgl-9.0.1-1-x86_64 4,8 MiB 423K/s 00:12 [######################] 100%
nouveau-dri-9.0.1-1… 8,1 MiB 423K/s 00:20 [######################] 100%
xf86-video-nouveau-… 69,8 KiB 426K/s 00:00 [######################] 100%
(3/3) checking package integrity [######################] 100%
(3/3) loading package files [######################] 100%
(3/3) checking for file conflicts [######################] 100%
(4/4) checking available disk space [######################] 100%
(1/1) removing nvidia-utils [######################] 100%
(1/3) installing libgl [######################] 100%
(2/3) installing nouveau-dri [######################] 100%
(3/3) installing xf86-video-nouveau [######################] 100%
==> make sure you use KernelModeSetting (KMS)
==> see http://wiki.archlinux.org/index.php/Nouveau#KMS for more

I think it feels kinda weird for the nvidia package to depend on nvidia-utils in stead of the other way around.

But… X still doesn’t start. This is because the nvidia driver was still listed in /etc/X11/xorg.conf. Removing the file, leaving X in auto configuration mode, solves the problem. However, it takes quite a while to lead, while there are no messages to my console during that time. I suppose this is some kind of configuration issue. Shutdown also appears to hang, but it could also be I just have to waaaaaait a little longer.

Just after getting my desktop running again for a few days, it seems it’s causing me troubles again. But I guess I’ll have to look at them another time. I’ve got to spend some time on my study, I’ve got a few papers to read.

edit: Even though the login screen comes up, after entering password, it doesn’t start my desktop environment. This seems to be related to an issue with dbus. Starting my X session manually using xinit works fine. Buuuut… I am procrastinating again, I should be reading papers.

Tags: , , , , ,
Comment

ArchLinuxARM on the Raspberry Pi (part 5)

Filed Under: English by andre — Leave a comment
17 November 2012

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.

Tags: , , , ,
Comment

In de keuken

Filed Under: Nederlands by andre — Leave a comment
17 November 2012

Tussen alle technische blaat en computerlatijn door vraagt mijn maag mijn aandacht, en dan met name het feit dat er weinig in zit. Als ik dan naar de klok kijk is het inderdaad etenstijd, dus… ik ga maar eens de keuken in. Wat zullen we vandaag eens eten?

Qua groenten, gister een courgette en twee pastinaken gekocht. Maar ik had van vorige week nog een bakje champignons, dus die moeten op voordat ze bederven. Dus, wat gaan we hiermee maken. Vandaag eens aan het improviseren geslagen. Heel bakje champignons in schijfjes, heel de courgette in stukjes, en dat gebakken. In porties, het past niet allemaal tegelijk in de pan. Pas als alles gebakken is de boel bij elkaar gooien. Een uitje kan hier ook nog wel bij. (maar daar ga je wel van janken) Een blokje roomkaas erbij en laten smelten, en dan nog een blikje tomatenpuree erdoorheen roeren, op smaak brengen met Italiaanse kruiden.

Bovenstaand recept geserveerd met tagliatelle en notengehakt

Tags: , , ,
Comment

ArchLinuxARM on the Raspberry Pi (part 4)

Filed Under: English by andre — Leave a comment
17 November 2012

So, now I have ran fsck -f on all usb hard disks, just to be sure the file systems are not corrupted. I am aware there is probably some corrupt data on those disks, due the unstable USB bus on the BeagleBoard.

Well… plug everything in and boot up the system. The Raspberry Pi has two USB ports. I am currently using only one of them. I have connected a 4 port powered USB hub, to which I have connected the three hard disks, and another, bus powered, 4 port hub. To this hub I have connected my printer (HP Deskjet 895Cxi). This printer used to cause the BeagleBoard to crash all the time. It’s from the early USB-era, and therefore it might be not fully USB-complaint. However, I hope it won’t cause any problems on the Raspberry Pi. (I will have to repair my HP Deskjet 3320, but that’s another topic)

So… we got to configure the mount points. As I said, this will be done using their UUIDs. To see them, use the command blkid

# blkid
/dev/mmcblk0: PTTYPE=”dos”
/dev/mmcblk0p1: SEC_TYPE=”msdos” UUID=”A697-C157″ TYPE=”vfat”
/dev/mmcblk0p2: UUID=”f9e11351-e87a-4df2-a9be-27f03d215329″ TYPE=”ext4″
/dev/sda1: LABEL=”Extern1000″ UUID=”74afebc6-5b3f-4306-82dc-b164f4185aa3″ TYPE=”ext4″
/dev/sdb1: UUID=”577e2053-b83e-45d3-bad6-355475d07c36″ TYPE=”ext4″
/dev/sdb2: UUID=”effa82e7-ccc6-4d27-98d1-1aa255a702f3″ TYPE=”swap”
/dev/sdc1: LABEL=”Extern1500″ UUID=”30a34cab-aaf9-4c75-b63b-4e196cf8ef66″ TYPE=”ext4″

This translates to the following lines in /etc/fstab

UUID=74afebc6-5b3f-4306-82dc-b164f4185aa3 /mnt/1000 ext4 defaults 0 2
UUID=30a34cab-aaf9-4c75-b63b-4e196cf8ef66 /mnt/1500 ext4 defaults 0 2
UUID=577e2053-b83e-45d3-bad6-355475d07c36 /home ext4 defaults 0 2
UUID=effa82e7-ccc6-4d27-98d1-1aa255a702f3 swap swap defaults 0 0

However, looking at the already present lines, I am not sure if I am completely happy with them.

devpts /dev/pts devpts defaults 0 0
shm /dev/shm tmpfs nodev,nosuid 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 0

Seeing the root file system is not present, and the boot file system has last parameter 0, meaning, the content of the SD card will never be checked for errors. I don’t know if this is the desired behaviour. So, I will change it to:

UUID=f9e11351-e87a-4df2-a9be-27f03d215329 / ext4 defaults 0 1
/dev/mmcblk0p1 /boot vfat defaults 0 1

and reboot… after a while, the system comes up, looking at the output of the mount command, everything seems to be mounted as it should. However… looking at

/dev/root on / type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)

I wonder weather it is fsck’ed during boot…

Sooo, let’s see what still has to be done: make user accounts, install cups, perhaps sane, perhaps an http and sql server (as they ran on the BeagleBoard as well), transmission-deamon, and more.

Originally I intended to also run an IRC server on my BeagleBoard, but due instabilities I have stopped doing so. If this board is stable, I guess I will try again. Another project I started, which I now may continue a lot easier due the changed in ArchLinux is getting Dropbox to run. Now, it’s quite easy to generate a base system using pacstrap. As I believed not having a complete base system was the reason my previous attempt on the BeagleBoard failed.

However, I am forgetting one of the tasks the Raspberry Pi should take care about, my IPv6 tunnel. Since back when I configured my BeagleBoard, systemd has been introduced, but it appears the wiki hasn’t been updates, and still tells me to make the script and put it in the /etc/rc.conf file.

Tags: , , , , ,
Comment