Wed Oct 10 02:02:02 CEST 2018

Success with UNIX V7/x86

After a longer hiatus on I continued with the v7x86 project. Prior status, a bit more in depth than the last time:

The INSTALL hints recommend to use some external method to prepare the (fdisk) partitioning of the target IDE disk but also point out the option to use the ptdisk tool coming with the installer. I chose that and ran into these problems:

  1. When ptdisking as described in the INSTALL notes, the rudimentory RAM filesystem lacks the file containing the actual MBR boot code. This went unnoticed by me (perhaps I did not pay enough attention?) before I continued with the (successful) installation of the entire unix/v7 system to its new partition. I ended up with an MBR describing the primary partition table entry for the v7x86 system but no boot code -- and hence with a non-booting system.

  2. I then found this problem mentioned in this ISSUE note and attempted an appropriate fix.

On my "Proxmox" virtualization linux system, I mounted the installation ISO, extracted the the prototypical MBR record, and dumped its boot code (the initial 446 bytes) to the (virtual) hard disk:

mount -o loop v7x86-0.8a.iso /mnt
tar xOf /mnt/v7x86-0.8a.tar  usr/boot/mbr > /tmp/mbr

dd bs=446 count=1 conv=notrunc \
    if=/tmp/mbr \

At this point, it was extremely helpful that I had chosen the dead-simple "raw" disk image format and not something complicated such as "cowq2".

However, the system still refused to boot.

Today, I took the standard NetBSD/i386 /usr/mdec/mbr boot code instead. Same method as above to dd the 446 bytes boot code. These successfully picked up the single, active partition, and I finally arrived at the UNIX V7 boot loader. \o/

At this point, I could continue with Robert Nordier's excellent introduction on how to boot unix/v7 and go from single to multi-user.

Great fun. I happen to like systemd but then again, I still love the simplicity of an /etc/rc (or perhaps even /etc/rc.local) you create from scratch and hence actually understand.

Posted by neitzel | Permanent link | File under: v7x86, done

Thu Jul 19 02:04:13 CEST 2018

eddie at eight

On Tuesday, the NetBSD source tree got tagged with netbsd-8-0-RELEASE. The announcement is not out yet, but that's no reason not to move from -RC2 to -RELEASE on eddie, the Asus EeePC 1000H dedicated to bleeding edge things. So the netbook was seriously burning CPU cycles in the last two days, and welcome, 8.0!

Small things learned:

  1. It's not necessary to the kernel modules explicitly, this is implied in the standard (userland) build. The installmodules=/ step is required, though.
  2. For the tweaked "EDDIE" kernel, I had stale dependency files lying around going back to 2015. It helps to occasionally rm compile/EDDIE -- a make clean or make cleandir won't do the job.

While eddie was busily chugging along on the systems sources, I used the time and updated the "beeper" blog notes from Sunday with further findings on the (now) 8.0 system.

Posted by neitzel | Permanent link | File under: done, marshlabs, bsd

Sun Jul 15 22:22:22 CEST 2018

beep beep m beep beep yeah

Starting with NetBSD-6.0, my ASUS EeePc 1000H netbooks lost their sysbeep(4) console beeps, i.e. those simple speaker beeps you should get when you request an echo ^G on the shell, mistreat vi(1), or shutdown the system and have options BEEP_ONHALT in your kernel.

During the recent pkgsrcCon, I learned that I am not the only one missing the bell. Here are my current findings on this matter.

This bell problem is pretty specific to this platform. The EeePc has a pair of pretty decent speakers hooked to its Intel AC97 audio system. There is no seperate, classic piezo speaker for the beeps.

Here, sysbeep autoconfigures as follows:

pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
sysbeep0 at pcppi1
spkr0 at pcppi1: PC Speaker

The spkr0 (speaker(4), /dev/speaker) allows for simple melodies. It stopped working likewise: echo 'ceg>c' > /dev/speaker will run for the appropriate time (3 seconds) but silently.

NetBSD-7 on an LX series IGEL-Terminal which has just a classic piezo speaker for the beeps and requires external speakers/headphones hooked to the audio0 at auvia0 at pci0 VIA Technologies VT8237 AC'97 Audio card. sysbeep is:

pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1

(And yes, midi0 works, too, in its own charming way. Too bad that spkr0 is not part of the GENERIC kernel...)

If I remember things correctly, NetBSD-5.x on the EeePc would do both "the bell" and the soundcard correctly (e.g., play MP3 files on the audio(4) device).

TDOD-1: I should try to find an 5.x Install CDROM and see how sysbeep used to autoconfigure there.

NetBSD-6.x would operate the audio(4) device if present in the kernel, but that would silence the sysbeep. Without audio, the sysbeep would be OK. A tough decision to make. IIRC, there was the choice to use either azalia(4) or hdaudio(4) as the underlying device driver for audio(4) on the EeePC, and both worked for audio but silenced the sysbeep.

TODO-2: I should hookup a 7-release USB drive to the netbook to see how things work (or fail to work) for that NetBSD version.

NetBSD-8.0 (just tagged) comes with a revised the sound architecture. In particular, it is now possible to configure the speaker(4) to the audio system. From the speaker(4) man page:

spkr0   at audio?

The corresponding cvs log entries:

revision 1.1145
date: 2016-12-13 21:42:18 +0100;  author: christos;  state: Exp;  lines: +4 -5;
wildcard speaker attachments, now that we can handle many of them.
revision 1.1144
date: 2016-12-11 00:03:24 +0100;  author: christos;  state: Exp;  lines: +2 -3;
remove VAUDIOSPEAKER for now, will be done differently.
revision 1.1143
date: 2016-12-09 03:24:17 +0100;  author: christos;  state: Exp;  lines: +2 -3;
revision 1.1142
date: 2016-12-08 12:31:10 +0100;  author: nat;  state: Exp;  lines: +6 -2;
Add a synthesized pc beeper and keyboard bell for platforms with an audio

The NetBSD-8.0 Release GENERIC kernel config provides just commented spkr lines:

#spkr*  at pcppi?               # PC speaker
#spkr*  at audio?               # PC speaker (synthesized)

Nevertheless, spkr0 autoconfigures to audio0 (and thence to hdafg0 to hdaudio0) and works just great in 8.0, out of the box. I can now hear the echo 'ceg>c' > /dev/speaker C major chord loud and clear.

However, the beeper is still explicitly to pcppi? configured, so we get

sysbeep0 at pcppi1 at acpi0 (SPKR, PNP0800): io 0x61

and that is still silent. Using boot -c into userconf and disabling the pcppi1 at acpi0 gave a sysbeep0 at pcppi0 at isa0 as intended but no bell, either.

The revision 1.1142 commit message suggests a possible audio? attachment, an attempt with an sysbeep0 at audio? proved otherwise, though.

Summary: as of now, no beeps.

Posted by neitzel | Permanent link | File under: done, bsd

Thu Jul 12 21:05:23 CEST 2018

aton(3) fun

Our dual-stacked hosts in the comapny inherit their IPv6-IIDs from their public IPv4 address. So, kenny = is given the IPv6 address 2a00:1030:0:42:: in mixed v6-dotted-quad notation. Yes, that's a possible way to spec an IPv6 address, both "in the shell" and, very convenient, in DNS zone files.

The notation will be turned into 128 bits and returned to you in canocial hex format, though:

$ host kenny has address has IPv6 address 2a00:1030:0:42::d90d:4263

Today I learned: yes, hex numbers are a possible way to spec an IPv4 address:

$ ping 0xd90d4263
PING 0xd90d4263 ( 56 data bytes
64 bytes from icmp_seq=0 ttl=61 time=1.982 ms
64 bytes from icmp_seq=1 ttl=61 time=1.129 ms

I was mildly surprised.

Not too much, though, because I was well aware of shortened "quads". Since a few weeks, Cloudflare operates as a public DNS server, and

$ ping 1.1
PING 1.1 ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=59 time=9.51 ms
64 bytes from icmp_seq=2 ttl=59 time=9.41 ms
64 bytes from icmp_seq=3 ttl=59 time=9.38 ms

is now perhaps the shortest way now to check for Intarweb connectivity.

Posted by neitzel | Permanent link | File under: learned

Wed Jul 11 01:08:07 CEST 2018 on 11.2

Upgrade from FreeBSD-11.1 to 11.2 (released two weeks ago) on, a lenovo X220 ThinkPad.

(Time needed to do the update: 1 hour with the fast Internet connection in the office and the SSD in the laptop. Beyond the commands

freebsd-update upgrade -r 11.2-RELEASE
freebsd-update install
shutdown -r now
freebsd-update install

no manual interaction (e.g., for merging /etc config files) was needed. Everything went smoothly.

Initial testing looks OK. Next week, I should do the same upgrade on my desktop system in the office.

Posted by neitzel | Permanent link | File under: done, marshlabs, bsd

Sun Jul 8 22:00:00 CEST 2018

pksrcCon 2018

Returned from two days pkgsrcCon at Berlin (cbase). Met a handful already known developers/maintainers and many new faces (mostly just known by nick or mail address, if at all).

This is a very relaxed and pleasant community. Though being an absolute pkgsrc newbie myself, I felt well at home.

I finished the Sunday with making my own pkgsrc download/install and building the figlet pkg. This all along the pksrc guide.

Joerg Sonnenberger was so kind and patiently answered all my questions regarding the pkgsrc releases, their numbering, and update policies.

Posted by neitzel | Permanent link | File under: friends, bsd

Sun Jul 1 18:00:00 CEST 2018

canossb 2018

Just returned from canossb ("a fork from canossa"), a long weekend with friendly nerds (most from the early Internet days in the sense of "we built this city"), way too much food, and too little sleep.

Thanks to snej, princess, and everyone else!

Posted by neitzel | Permanent link | File under: friends

Thu Jun 28 21:21:21 CEST 2018

No success yet with UNIX V7/x86

I spent another night with Robert Nordier's UNIX V7 port to the x86 architecture (

The first attempt had been a few months before on a real 32-bit netbook with a real spinning harddisk and a primary partition. The V7 system booted from the CDROM on a USB-attached drive just fine. But since the USB drive is not an ATAPI drive as assumed by the V7/x86, the installation process failed. (It would have been so nice to have the V7 right next to the Solaris10 on the same disk...)

This time I tried an installation in a proxmox VM, the ISO image being attached as a virtual IDE/ATAPI drive. (I had fired up ron running a proxmox installation just yesterday to check its version; I was pleasently surprised that I was at the same major release as a customer whom I need to support now.)

The V7/x86 installation ISO allows to escape into a shell in order to partition the target disk with a ptdisk utility. I then ran into the issue which I eventually found documented in

I was able to extract the missing /boot/mbr from the CDROM and run the ptdisk using it. This allowed the installation to run. However, the resulting MBR wouldn't boot the system from the (virtual) disk afterwards.

I guess it's a C/H/S geometry issue. I toyed around a bit before giving up. My next attempt would be to boot another OS on this VM to fdisk the disk, then try again with the V7/x86 install (as advised in the mentioned ISSUES page).


Lots of dd and od today... and also echo * because: the v7 ls is strictly -1.

Posted by neitzel | Permanent link | File under: v7x86, done

Wed Jun 27 17:33:25 CEST 2018

interface configs in systemd contexts

A small survey how different marshlabs hosts, all running systemd, get their network interface configured. As it turns out there is quite variety.


A ProxmoxVE 4.4 host, running Debian-8. The network configuration still resides in /etc/network/interfaces for use with ifup/ifdown and a sysV init script:

$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto vmbr0
iface vmbr0 inet static
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0

$ systemctl status network\*
* networking.service - LSB: Raise network interfaces.
   Loaded: loaded (/etc/init.d/networking)
  Drop-In: /run/systemd/generator/networking.service.d
   Active: active (exited) since Sat 2018-06-23 16:16:40 CEST; 4 days ago


A Raspian system, also Debian-8.0-based. Again, /etc/network/interfaces and networking.service auto-derived from the init.d script are used. This time, though, interfaces says:

iface eth0 inet manual

The configuration is completed by

$ systemctl status dhc\*
* dhcpcd.service - dhcpcd on all interfaces
   Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled)
   Active: active (running) since Sun 2018-04-29 13:17:06 CEST; 1 months 28 days ago
 Main PID: 424 (dhcpcd)
   CGroup: /system.slice/dhcpcd.service
       `-424 /sbin/dhcpcd -q -b


An LXC container within ron, running archlinux:

[root@foo neitzel]# systemctl status netwo\*
* - Network
   Loaded: loaded (/usr/lib/systemd/system/; static; vendor prese>
   Active: active since Wed 2018-06-27 16:16:28 CEST; 1h 11min ago
     Docs: man:systemd.special(7)

Jun 27 16:16:28 foo systemd[1]: Reached target Network.

[root@foo neitzel]# locate \*.network

[root@foo neitzel]# cat /etc/systemd/network/
Name = eth0

Description = Interface eth0 autoconfigured by PVE
Address = auto
DHCP = v4

[root@foo neitzel]# systemctl status dhc*
[root@foo neitzel]#

Summary: foo is the only system here using systemd-networkd.

Posted by neitzel | Permanent link | File under: learned, marshlabs

Tue Jun 26 16:56:10 CEST 2018

ubuntu interface configuration

Yesterday, I wondered why a ubuntu-16 system wouldn't lose its DHCP address after a change from dhcp to static in /etc/network/interfaces.

TIL: there was also /etc/network/interfaces.d/50-cloud-init.conf, still providing the old specs for both the loopback and ethernet interfaces. Fixed via rm.

I am getting too old for this crap. In particular, I was too old to notice the .d subdirectory. Let's blame the color-ls.

Posted by neitzel | Permanent link | File under: learned