Posted on

Fun with Telescopes

Recently I purchased a small telescope to look at solar spots. When choosing a mount, I checked whether it can be controlled with OSS.

In this context INDI is mentioned everywhere and my desired mount was supported. indi and kstars are already part of Debian, so “apt install”, selecting my mount, …. oh, wait, the menu shows it, but I can not select it.

Ok, that was the time when I learned about the difference of indi and indi-3rdparty. The indi package just contains a few drivers and others are available from a different repository. This split has been done either due to different release cycles of the driver, a different OSS license of it, or just due to binary blobs without source being part of some drivers.

Fine, there are already packages of the 3rdparty-repository available from an Ubuntu PPA, so it should be no problem to add them do Debian as well.

Some manufacturers freely distribute at least the specification of their API so that others are able to write the corresponding software. Some manufacturers even write their own driver. Examples are:

  • Skywatcher (mounts who can be controlled by the Skywatcher Protocol)
  • Shelyak to control some spectrographs
  • Radio Astronomy Supplies’ SpectraCyber hydrogen line spectrometer
  • Vixen, for controlling Vixen Starbook and Vixen Starbook Ten
  • Starlight Express, SX CCDs, SX wheel and SX Active Optics

A minor part actually does not have binary blobs but distributes the sources of their software. Unfortunately they have licenses that are not compatible with DFSG and those packages still need to go to non-free. Examples are:

  • Finger Lakes Instrumentation (FLI), L.L.C.
  • Lunatico Astronomia
  • Astrojolo
  • Astromechanics

But there also seem to exist lots of manufacturers of astronomically accessories, especially cameras, that just distribute some binary blobs to talk to their hardware. This is sad, but at the moment it is just the way it is and such package need to go to non-free.

Luckily their blobs are accompanied with corresponding licenses. At least those manufacturers understand how software licenses work and packaging their SDK is just straight forward. Examples are:

  • SBIG Astronomical Instruments
  • Moravian Instruments Inc.
  • Player One Astronomy

However, when looking at the license information of some Ubuntu packages, several of them were distributed under a CC license. This is not a common license for software, so I wanted to get a confirmation whether these information are correct.

Unfortunately most of such manufacturers don’t want to disclose their licenses. For whatever reason they distribute their tarballs without any hint and emails to their support channels are just ignored. Examples of such bad behaviour are:

  • Altaircam
  • QSI (was bought by Atik)
  • Atik
  • Touptek
  • QHY

However the best answer comes from the Levenhuk support. My question about the license of their SDK was answered by:

I am afraid we cannot disclose any further information except the software file that is available on our website.

So strictly speaking nobody is allowed to use their software. I wonder whether such competence also becomes visible in their products. I will never really know as there are more than enough OSS friendly manufacturers available.

Anyway, most of the indi-3rdparty drivers are now available and I got lots of suggestions about hardware I need to buy in the future :-).

Posted on

Fun with APC USV

About two years ago I bought two APC Back-UPS BX. Everything worked fine and they helped to survive one or two power cuts. Occasionally on one of them I got a message about a power outage whereas the other remained silent. Yet everything worked fine and I didn’t pay attention. After a while these messages did not appear again.

Some days ago I wanted to look at the battery state and was quite surprised to only get an error message about a lost connection to the USV. The USV was not available on the USB bus and disconnecting/connecting the USV or rebooting the attached computer did not help. I had to switch off the USV, really pull the plug and wait sometime. Afterwards everything worked fine again. Of course the other one had the same problem :-(.

And the moral of this story: Missing messages might have a reason and if something can fail, write a test and let nagios (or icinga or check_mk or whatever) tell you that there is something wrong.

Posted on

Fun with broken harddisks

Today I needed to replace a faulty harddisk, which had a GPT, in a software RAID1. A GPT is a Guid Partition Table and is normally needed for partitions > 2TB. But wait, my external harddisk has 4TB and it uses an MBR (Master Boot Record)!?

In an MBR the partition size is stored in four bytes, which could have 0xFFFFFFFF as a maximum value. This would be 4294967295 in decimal. But the partition size is not given in bytes but in sectors. On Linux systems the sector size of an attached harddisk can be found in /sys/block/sd[X]/queue/hw_sector_size.

root@server:~ # cat /sys/block/sdd/queue/hw_sector_size
512

This is the normal sector size of a harddisk, so 4294967295 sectors of 512 bytes result in 2TB.

Luckily some external harddisks have a sector size of 4096 bytes.

root@server:~ # cat /sys/block/sda/queue/hw_sector_size
4096

This results in a partition size of 16TB.

Anyway, my disk had a GPT and after installing the new harddisk, it had to get a copy of the GPT of the first one. This can be done with sgdisk, that is part of package gdisk on Debian systems. So after doing apt-get install gdisk one can:

sgdisk --replicate=/dev/sdb /dev/sda

In this case /dev/sda is the source disk and /dev/sdb is the new one.

You can see the GPT with:

sgdisk -p /dev/sda
sgdisk -p /dev/sdb

Due to the cloning, both disks have the same GUID and to avoid hassle, the new one needs a new GUID. This is done with:

sgdisk -G /dev/sdb

The structure of the software raid can be seen in /proc/mdstat. In my case I have three md devices: md0, md1 and md2
On my system md0 currently has only one active member /dev/sda2. So /dev/sdb2 has to be added:

mdadm /dev/md0 --manage --add /dev/sdb2

As this is just a small partition, it took only a few seconds and syslog showed:

[ 5881.551829] md: bind
[ 5881.581014] RAID1 conf printout:
[ 5881.581020] --- wd:1 rd:2
[ 5881.581026] disk 0, wo:0, o:1, dev:sda2
[ 5881.581030] disk 1, wo:1, o:1, dev:sdb2
[ 5881.581174] md: recovery of RAID array md0
[ 5881.581180] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[ 5881.581186] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
[ 5881.581195] md: using 128k window, over a total of 499988k.
[ 5889.511049] md: md0: recovery done.
[ 5889.614014] RAID1 conf printout:
[ 5889.614020] --- wd:2 rd:2
[ 5889.614026] disk 0, wo:0, o:1, dev:sda2
[ 5889.614031] disk 1, wo:0, o:1, dev:sdb2

The same needs to be done for the other partitions:
mdadm /dev/md1 --manage --add /dev/sdb3
mdadm /dev/md2 --manage --add /dev/sdb4

They are way bigger and recovery of the RAID lasts a bit longer. But finally everything is done and nagios switches back from red to green. Mission accomplished!

Posted on

First steps with arm64

As it was Christmas time recently, I wanted to allow oneself something special. So I ordered a Macchiatobin from SolidRun. Unfortunately they don’t exaggerate with their delivery times and I had to wait about two months for my device. I couldn’t celebrate Christmas time with it, but fortunately New Year.

Anyway, first I tried to use the included U-Boot to start the Debian installer on an USB stick. Oh boy, that was a bad idea and in retrospect just a waste of time. But there is debian-arm@l.d.o and Steve McIntyre was so kind to help me out of my vale of tears.

First I put the EDK2 flash image from Leif on an SD card, set the jumper on the board to boot from it (for the SD card boot, the right most jumper has to be set!) and off we go. Afterwards I put the debian-testing-arm64-netinst.iso on an USB stick and tried to start this. Unfortunately I was hit by #887110 and had to use a mini installer from here. Installation went smooth and as a last step I had to start the rescue mode and install grub to the removable media path. It is an extra point in the installer, so no need to enter cryptic commands :-).

Voila, rebooted and my Macchiatobin is up and running.

Posted on

Wireless Shower Speaker

This is the time of the year, where more or less useful items change their owner. Though I don’t think that my singing in the shower sounds that terrible, I got a Wireless Shower Speaker. The model is SP0052W from LogiLink.

As I had some time between meals I read the user manual. It consists of one page with instructions in four languages. Half of the space is occupied by safety instructions. So I got my magnifying glass and read them carefully. Please note, it is for a Wireless Shower Speaker! Most of the instructions are about what I should not do with the device, among others:

  • Dont’t expose the device to water, moisture or high humidity.
  • Avoid direct contact with water.

I don’t know anybody from LogiLink but those guys must be real tough. At least the people from their product management are far from being wimps. But can they really enjoy their own devices under cold showers? Or maybe they already invented sonic showers for home use!?

Posted on

APU and Debian

I just got an APU1D4 made by PC Engines. I bought it from a German retailer called VARIA System GmbH. They are also located in Chemnitz, so at least I could support the local economy. I purchased a bundle consisting of mainboard, case, power supply and 16GB SSD. The board has 4GB RAM and three network adapters and shall replace my old PC that I use as router to the internet.

As there is no VGA/HDMI output, the first hurdle was organizing a null-modem cable. Of course I could have prepared the SSD on another PC, but I wanted to try PXE. After finding the cable on the ground of a box, deeply buried under other boxes, I could start.

The DHCP server got an entry

host apu1d4 {
  hardware ethernet 00:0d:b9:42:a0:e8;
  fixed-address apu1d4;
  option broadcast-address 10.42.255.255;
  option routers 10.42.10.1;
  next-server 10.42.10.1;
  filename "pxelinux.0";
}

and the TFTP server got a file …/tftp/pxelinux.cfg/01-00-0d-b9-42-a0-e8

default install
label install
        menu label ^Install
        menu default
        kernel debian-installer/amd64/linux
        append initrd=debian-installer/amd64/initrd.gz --- vga=off console=ttyS0,115200n8

The files debian-installer/amd64/linux and debian-installer/amd64/initrd.gz are the normal debian installer files obtained from the official Debian servers.

That’s it, the installer starts, spits its output over the serial line and I can install the system. Great! Thanks DebianInstaller team. Why couldn’t everything be always so easy?

Posted on

USB 3.0 hub and Gigabit LAN adapter

Recently I bought an USB 3.0 Hub with three USB 3.0 ports and one Gigabit LAN port. It is manufactured by Delock and I purchased it from Reichelt (Delock 62440).

Under Wheezy the USB part is recognized without problems but the kernel (3.2.0-4) does not have a driver for the ethernet part.
The USB Id is idVendor=0b95 and idProduct=1790, the manufacturer is ASIX Elec. Corp. and the product is: AX88179. So Google led me to a product page at Asix, where I could download the driver for kernel 2.6.x and 3.x.

mkdir -p /usr/local/src/asix/ax88179
cd /usr/local/src/asix/ax88179
wget www.asix.com.tw/FrootAttach/driver/AX88179_178A_LINUX_DRIVER_v1.13.0_SOURCE.tar.bz2
tar -jxf AX88179_178A_LINUX_DRIVER_v1.13.0_SOURCE.tar.bz2
cd AX88179_178A_LINUX_DRIVER_v1.13.0_SOURCE
apt-get install module-assistant
module-assistant prepare
make
make install
modprobe ax88179_178a.ko

After editing /etc/network/interfaces and doing an ifup eth1, voila, I have a new network link. I hope the hardware is as good as the installation has been easy.