NetBSD: pkgin stalls on update

I’ve got an old Raspberry Pi running NetBSD. When I run something like:

# pkgin update

It downloads a few per cent of the package list, then stalls then gives up. I don’t know why, but I found a way around it. When I switched from an HTTP to an FTP mirror, all was well.

The package list is in:

/usr/pkg/etc/pkgin/repositories.conf

So logged in as superuser and added an FTP repo to the top of the list and commented out any others.

For example,

ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/9.2/All

The $arch is replaced by whatever your machine needs — in this case:

ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/earmv6hf/9.2/All

It’s still not fast, I should say, but something about the FTP handshaking, or the way it keeps connections open, or something, seems to make it work better for me. Oh, and as a hint, if you want to explore an FTP site interactively, just install Lynx or Links, the text browsers — they have not disabled FTP like the modern browsers have. I guess they don’t suffer the tyranny of the majority…

Maybe it’s time to try NetBSD again on the Alpha.

 

Alpha? Bet!

Alpine email client on NetBSD

NetBSD on an RPi. Mail — Alpine is light and useful. First, installed it:

# pkg_add -v alpine

Then followed this post to try to set up the passwordy stuff, but the openssl command failed, because it found no /etc/openssl/openssl.cnf

I copied one from /etc/ssl/openssl.cnf on my Debian box.

Seemed to work.

Created ~/.pine-passfile with a single empty line in it.

Created my app password for Gmail.

Started Alpine on NetBSD

Followed my own instructions (here), but needed to use novalidate-cert as well.

Did not seem to be saving the password. So I tried this:

I had to create a ssl certificate and install the file in ~/.alpine-smime/private, ~/.alpine-smime/public and ~/.alpine-smime/ca. Only then will the imap password be saved

From: https://unix.stackexchange.com/questions/331927/alpine-refuses-to-save-imap-password

But actually, I had created .pine-passfile in the wrong place, so I am not sure these steps were vital.

But with .pine-passfile in the right place and the above steps done, it did work.

 

OK.

NetBSD on an old Raspberry Pi

I have always liked the idea of NetBSD — a cross-platform OS that offers a consistency of experience on widely disparate devices. I tried in on my AlphaServer 1200, when it was working (it needs a power supply) and in VirtualBox and whatever. Once the adjustment from the ease of installing something like Debian is allowed for, it’s all pretty good. But I never came across what I would call a compelling use case. If I want to use a machine on a desktop, and the hardware is up to it, Debian/Devuan is just so easy and complete. If I want to go retro, FreeDOS is more like it. Then, in a desk, I found a Raspberry Pi 1B from years ago. The relatively minimal install that BSD gives you — without a bunch of services running that you never asked for, for example — should suit. Plus, as the hardware gets old, NetBSD is the best chance for ongoing support. A little reading suggests that NetBSD earmv6hf is probably the way to go. BSD tends to be compact, and the thing has about 450 MB usable RAM. See here for better instructions than mine.

• Download: https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/evbarm-earmv6hf/binary/gzimg/rpi.img.gz
• gunzip it
• lsblk before and after inserting the SD card to make sure I get the device right:
  • $ lsblk > before
  • insert SD card
  • $ lsblk > after
  • $ diff before after
• OK, can now run dd command (from directory where the img file is):
• $ sudo dd if=rpi.img of=/dev/sdf bs=2M
• Mount card on the Linux box and there are all the files. Good!
• Put it in rpi, and turn it on. It boots twice (first time to resize the partition to fill the card).

That’s it, it now works. Rest is really standard NetBSD, but …

• Add root password
• Add user
• Add user to any sensible groups — wheel, dialout and so on. For example, as root:
  • # useradd -m -G users -g dialout username
• Enable binary installs by defining PKG_PATH in /etc/pkg_install.conf:
  • PKG_PATH=ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/earmv6hf/9.1/All/
• Then install some software; I began with
  • pkgin
  • sudo
  • bash
  • flwm
• Note that after installing pkgin, might need to update /usr/pkg/etc/pkgin/repositories.conf to use 9.1 and not 9
• Run chsh to choose bash as the shell of choice.

A few other things to make it more usable — enable more ttys:

• Edit /etc/ttys and turn on ttyE1 and ttyE2. E0 conflicts with constty (this really is E0 on this NetBSD image) and E4 is where X windows will show up.
• If you like, install a display manager:
  • # pkgin install xdm
• I modified /etc/X11/xdm/Xsession to make it start flwm, and modified /etc/X11/xdm/Xservers a little (used a few bits from here) just to allow reboot/shutdown buttons.
• And part of this meant messing with /etc/X11/xdm/Xsetup_0 as per the link (here).

With X running, it is pretty responsive, actually, though I would not want to run LibreOffice(!)

Ampersand nbsp ;

AlphaServer 1200 — Gentoo, OpenBSD or NetBSD? Or quite old Debian?

There’s a question about what to run on it. OpenVMS on one HD makes sense, just to see what it’s like. Other OSs that are still available include NetBSD, OpenBSD, Gentoo — that’s about it. There’s a Debian community supported option out there http://backup.parisc-linux.org/, which is a mighty effort but which is likely to require some hacking to work. A small group of enthusiasts just can’t be expected to test stuff on all different types of hardware.

Here I sum up my experiences so far, given I am in mid-process.

Debian: Official Debian support for Alpha ended with Debian 5.0.10, the last update to Lenny, in about 2012. That makes it vulnerable to security exploits, though one suspects that anything that depends on a hardware exploit is pretty unlikely — how many nasties are out there targeting Linux on Alpha? If security by obscurity is ever going to work, this is it! On the other hand, once the system is installed there’s no update cycle to worry about, and the software ecosystem is pretty big (no Open/LibreOffice, but that’s about it). I’ve got a whole post on putting Debian 5 on the thing. Short answer: (almost) works right out of the box.

OpenBSD: Installs effortlessly, but lacks an X server, though does have some X tools. I guess that means you could use X on the machine if you had a second machine acting as the server, or maybe try to use the NetBSD ports/pkgsrc route. OpenBSD looks like a good option for a server or if the text terminal is your thing.

NetBSD: Installs just as easily. X is there, just haven’t quite got it to work. Since OpenBSD can be made to play with NetBSDs source packages, it may be possible to get X onto OpenBSD in a roundabout way.  Tried to compile X and to install ‘modular X’ (https://wiki.netbsd.org/pkgsrc/how_to_install_modular_xorg/) but compile of the server failed with various problems with the C code which I am not in a position to wrestle with (‘cos I don’t know enough C and I do not intend to spend my time learning it). Looks like the code just does not dovetail with the Alpha. I’ve not given up yet. NetBSD without X seems to work fine, I should add, and X is not everything.

Gentoo: Life is too short for this! Actually, I intend to have a crack. Already tried once and failed but I think that was me not Gentoo — made some mistakes with the (long and arduous) install process and ended up with a broken system. Need to try again.

Debian unofficial: The 9.0 install media would not boot on my machine. The 8.0 booted and installed but X does not work out of the box and ‘$ Xorg -configure’ throws a seg fault. Lots of ‘unaligned traps’ suggests that a lot of the code base has not been customised for one of the unfortunate quirks of the Alpha architecture. Tried importing the xorg.conf from Deb 5 but it did not like that.  May need to recompile X.  Experimenting with apt-src, but looks like this is not going to work without a lot of hands-on.

I have 3 SCSI HD I can use. Debian 5 is working well. I’d like to have a BSD for interest. So Gentoo or Debian unofficial? I’m inclined towards having another crack at Gentoo. Especially now that I have increased my internet download limit.

 

Compile it.

 

md5 and sha512 checksums

This is really simple but what the hell, blog needs posts.

What are checksums? Basically, an algorithm creates some kind of code (string of characters) based on the bits and bytes in a file, and ideally the checksum is different if even a tiny change is made to the file.

So, for example, a website that hosts files might provide the file — say an iso disk image — plus a checksum (a string of characters). We download the file, which might be GB of data, then run the checksum program locally and if it matches the checksum the website posted, we know we downloaded the file successfully. It also has security aspects — if someone messes with the file but does not change the expected checksum, there will be a mismatch. Of course, if they compromise the file and then hack the website and change the posted checksum, all bets are off.

But how about a concrete example?

Let’s say I go to http://ftp.netbsd.org/pub/NetBSD/install-images/7.1.2/ and download an install disk for the AlphaServer that I bought off ebay for 99¢ (well, I paid $1).

So I download NetBSD-7.1.2-alpha.iso.

In the same directory on the server there are two files — MD5 and SHA512. I can look at those and I see:

MD5 (NetBSD-7.1.2-acorn26.iso) = 502dca7c8628b7583500ccf2436e6eba
MD5 (NetBSD-7.1.2-acorn32.iso) = cd03d084925ee592d85603dd2334b390
MD5 (NetBSD-7.1.2-alpha.iso) = 090c25b2fcb7e770a6ae5b615a96963c
MD5 (NetBSD-7.1.2-amd64-install.img.gz) = cbd76159c1ed5eb32a19a3b19eae8cfd
MD5 (NetBSD-7.1.2-amd64.iso) = 2765516ec1b2ed56923c623e890388f0
MD5 (NetBSD-7.1.2-amiga.iso) = 35a345c82c9b399d1fc4ee6553849de8
MD5 (NetBSD-7.1.2-arc.iso) = cf2abd42a8e1244430dd0536c686d0b9
MD5 (NetBSD-7.1.2-atari.iso) = 2010fe541156c9650d2a2566e0ceb7a0

(the file goes down a long way — NetBSD runs on almost anything).

And

SHA512 (NetBSD-7.1.2-acorn26.iso) = 533ae5b61f7e9a870dacdb3a4e57df8cc768f93d5cdda7407dcecbe42dbb9856421bbb73eacbad66d08e61498385b5b3571fa3d66c66afb8eef07a27600d603d
SHA512 (NetBSD-7.1.2-acorn32.iso) = 0367108ec724ca47609fa324c9d1012e43c8249978afd057d9410e5724307309e3e8899167f6b1f58816c232a7ee7dc64aa93acaf7940b7384ae177bedf0af1a
SHA512 (NetBSD-7.1.2-alpha.iso) = dce2431b41f656bd07baffb8b97a270e32261600231f631761ccbeeefb8c8fd437ff02ed5ed2253699f14aebc45bc79d7633c2bb8874b8d24596cd43b7b537fc
SHA512 (NetBSD-7.1.2-amd64-install.img.gz) = 3e625cd6335c9bba631e5aee7c40a4606b915b3d73aeeaba1b693c4d9a7ad627d1a3ac08b23144fa5f1e2b84c9fc4cd8faef2d4a681a79862f3b8c29c103b85c
SHA512 (NetBSD-7.1.2-amd64.iso) = aaccacbfa3ee5a497170025aed9426de1ef91f8f7ebdaf862bd178c4922a5db1b82171832c916acd7a4e2038dd9ec39ef1061c41d98c5b5af56e3165cc945539

where we can see that the SHA512 sums are longer and generally considered ‘better’.

So I’ve got the file on my Linux box. I just do the sums:

$ md5sum NetBSD-7.1.2-alpha.iso 
090c25b2fcb7e770a6ae5b615a96963c  NetBSD-7.1.2-alpha.iso

$ sha512sum NetBSD-7.1.2-alpha.iso
dce2431b41f656bd07baffb8b97a270e32261600231f631761ccbeeefb8c8fd437ff02ed5ed2253699f14aebc45bc79d7633c2bb8874b8d24596cd43b7b537fc  NetBSD-7.1.2-alpha.iso

And I can eyeball these and compare and see that all looks fine.

There’s another thing to do.

I can create little files with the same format as the output from the checksum programs, but using the values from the server’s files. Say I make md5.txt and it has a single line in it that looks like this:

090c25b2fcb7e770a6ae5b615a96963c NetBSD-7.1.2-alpha.iso

I can then do this:

$ md5sum -c md5.txt
NetBSD-7.1.2-alpha.iso: OK

and the checksum program will compare the strings for me. SHA does the same.

In my case, I am trying to get an OS to work on a badly mistreated DEC AlphaServer 1200, largely for the hell of it. The CD drives are old and may not be reliable, so it is really valuable to be able to eliminate one source of failure from the checks I have to do.

 

Time wasters.