Feed on
Posts
Comments

Proxmox PXE install error – ‘stream did not contain valid UTF-8’

Sep 8th, 2026 by

TL;DR – Uninitialized/non-UTF-8 data in motherboard DMI fields causes the Proxmox bare metal installer to stop when fetching answers.toml over the network. I don’t have a good fix, I need to open a bug report.

I finally got around to trying an unattended PXE installation of Proxmox onto an Intel NUC and immediately hit a bug that halted the install. Apparently when configured to fetch the customizations answers file over HTTP it does some DMI introspection of the system to send along in the HTTP POST request for the answer.toml file (which is kinda neat). My NUC was causing the installer to error with:

root@proxmox:/# cat /tmp/fetch_answer.log
INFO: Fetching answer file in mode Http:
INFO: Gathering system information.
INFO: Fetching answer file via HTTP failed: Error: 'stream did not contain valid UTF-8' on /sys/devices/virtual/dmi/id/board_asset_tag'
ERROR: Aborting: Could not find any answer file!

Nothing showed up on the build HTTP server yet because it aborted before even attempting anything.

The key here was path in the error message, which told me it was trying to look up the system’s asset tag in DMI fields. When I looked at what’s in that file, it was garbage:

DMI Type 2 board asset tag data

and because of that it was failing to be decoded as UTF-8, and causing the installer to bail.

TIL the DMI information is available from the kernel /sys/ filesystem without dmidecode installed.

Root cause

The installer is kicked off by a call to unconfigured.sh. This runs /usr/bin/proxmox-fetch-answer, which is what actually tries to fetch the answers file built in to the ISO image, HTTP, or a partition, and redirects the output to a file in /run/. This is then fed to the actual installer at the next step.

After digging through the pve-installer code, the problem lies in https://github.com/proxmox/pve-installer/blob/master/proxmox-installer-common/src/dmi.rs. The bare metal installer plugin proxmox-fetch-answer/fetch_plugins/http.rb calls out to sysinfo::get (proxmox-auto-installer/src/sysinfo.rs), to proxmox_installer_common::dmi::get()?, then let content = match fs::read_to_string(&path) tries to coerce each of those results into string. However if the data from DMI is not UTF-8, it returns an error, when it should probably skip over it. Apparently it’s a coincidence this module is named “sysinfo” and is not related to the Rust sysinfo crate, which initially confused me.

There’s no way to skip over or avoid this error with a flag or option.

Other Intel NUCs I have have similar randomness in their DMI asset tags, so it would likely fail on them too.

$ cat /sys/devices/virtual/dmi/id/board_asset_tag | xxd
00000000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000010: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000020: ff0a                                     ..

$ cat /sys/devices/virtual/dmi/id/board_asset_tag | xxd
00000000: c01c 5b87 0a                             ..[..

$ cat /sys/devices/virtual/dmi/id/board_asset_tag | xxd
00000000: 0a                                       .

$ cat /sys/devices/virtual/dmi/id/board_asset_tag | xxd
00000000: 0a

Workarounds?

Booting with modprobe.blacklist=dmi_sysfs to completely skip exposing DMI data in the sysfs didn’t work, as it was already compiled into the kernel and not as a module. This may or may not be a good idea to skip anyways as DMI data would be handy identifying the system, else you’re just left with the ethernet MAC address to identify the target system.

Fetching a host-specific answers file baked into the initrd/ISO file doesn’t help me, as I want to fetch from the build server to customize the data being sent back, and I sure don’t want to be in the business of per-host images. However this does indeed skip the DMI lookup.

Fetching the answers URL through a DHCP option doesn’t matter, because it’s still going to take the URL provided and perform the exact same DMI and HTTP request.

I looked into trying to patch the initrd, but it’s not simple. It has BusyBox and a wget alias, so in theory you could wget the answer file directly and drop it off on the system somewhere. The problem is there’s not a good place to bolt this onto unconfigured.sh, you’d either need to overlay/bind mount a new patched copy of unconfigured.sh or a wrapper pretending to be /usr/bin/proxmox-auto-installer. It’s certainly doable but now you’re carrying around a bunch of one-offs you need to script for the inevitable next version.

The other option is to fix the data in the DMI fields. I got lucky and found a copy of the Intel Integrator Toolkit v6.1.10 on Internet Archive that works on these NUCs. Unfortunately this only modifies DMI type 3 fields (“chassis”) and does not change the DMI type 2 fields (“base board”) that we need:

# dmidecode -t 2
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: Intel corporation
	Product Name: NUC6i3SYB
	Version: H81132-503
	Serial Number: GESY61500EPR
	Asset Tag: .=\.                 <<<<<<<< !@#!@$!#!!
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Default string
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Here’s where I turned my attention to EFI NVRAM variables. There’s a variable that contains all of the DMI type 2 data, the Intel board model, serial number, and our weird asset tag:

root@prox01:~# efivar -l | grep -i dmi
70e56c5e-280c-44b0-a497-09681abc375e-DmiData

I turned Claude loose on that variable to make sense of it. It tried several different ways to try to write to it but in the end finally gave up and decided the system firmware itself must be preventing any writes to it. No luck there.

In the meantime I got this system installed by hand but now I got nerd sniped I’m invested enough in this problem I need to open a bug report with Proxmox.

Hand wavy installer overview

As a bonus, here’s my overview of how the whole unattended PXE install process works. Compared to how CentOS kickstart and Ubuntu autoinstall works, it’s kind of janky. After going through the process I kind of get why it is the way it is, it’s just work. The big part is you have to piece together a custom initrd by gluing some files together, then serve that to your target system. There’s just not a “net-installer” image you download.

First, you need to take a Proxmox VE .ISO file, mount it locally, then copy the linux26 kernel and initrd.img files out of the image onto your build tftp/http server. Then you have to run proxmox-auto-install-assistant (which is only packaged for Debian/Ubuntu, I used a container on CentOS) which writes all of four lines to one copy of an answer.toml file you’ll bundle into the installer:

mode = "http"
partition_label = "proxmox-ais"

[http]
url = "http://build.wann.net/ks/proxmox/answer.toml"

it also spits out a prepared.iso file. This is almost exactly the same .ISO you downloaded originally but not quite. You take the prepared.iso file, turn it into a gzip’d cpio file, then straight up append this to the original initrd.img you extracted from the ISO image (i.e. cat boot/initrd.img proxmox-iso.cpio.gz >> initrd.img) whew. You now wind up with a 1.7 GB initrd.img file that’s pretty much self contained. There’s ample warning you’ll want to serve this over HTTP and not over TFTP.

Now, when the target system PXE boots, downloads the linux26 and the initrd which contains the ISO image. Instead of fetching packages from a repo server, the ISO image is mounted at /proxmox.iso. Here’s where the installer goes to fetch the real answers.toml file from your build server over the network with HTTP. How you serve that file is up to you, a static file, or some sort of dynamic script pretending to be that URI. The answers file is fed to the actual installer program and off it goes.

I need to come up with a post-script to tweak my installs. The big one is that it comes out of the box with IPv6 disabled, boooo.

Intel Integrator Toolkit

The ITK isn’t completely useless. In the process of trying it it out on the NUC I was able to modify the Type 3 Chassis data and here set the asset id to TUX-1234:

Using the ITK to change the Type 3 chassis asset tag

The toolkit is just a EFI PE binary that you run from the UEFI shell from the motherboard. You can either extract and copy ITK6.efi to your system’s EFI system partition (e.g. /boot/efi/EFI) like I did, reboot, and go into the UEFI shell to run it, or burn it onto a USB thumb drive and boot off of it to run it. Either way it’s going to involve rebooting. Copying it to the ESP was easiest for me, I didn’t have to go fetch a USB drive. I don’t think there’s a Linux or Windows userspace version of this tool so I don’t know how you’d do this at any sort of scale.

Tags:

Posted in troubleshooting, Uncategorized | No Comments »

DOSBox-X, PatchWC! v3.00 and BTInitIsam error followup

Jul 30th, 2026 by

PatchWC! v3 running in DOSBox-x

After boiling the ocean with Claude paired up with DOSBox-X I finally have a followup to the “10310 BTInitIsam” error I wrote about in https://binaryfury.wann.net/2026/01/patching-wildcat-bbs-for-y2k-in-2026/. This was about the PatchWC program that applies Y2K patches to the Wildcat! BBS v4 software not being able to run in DOSBox-X. This may be helpful for other DOSBox-X users in similar other situations.

The TL;DR fixes:

DOSBox-X:

Since DOSBox-X doesn’t have true SHARE.EXE, this tricks the program into enabling the file locking it needs. Add to your DOSBox-X preference file (this is not exposed on the config dialog):

[dos]
drive z is remote = true

Plain MS-DOS or Windows 95 exited from the GUI:

Run SHARE.EXE or even MSCDEX.EXE first

 

Here’s the long detailed explanation I’ve come to understand from obsessing over why PatchWC! doesn’t work on DOSBox-X and works on other combinations of DOS. Not knowing all this really bugged me when I was trying to find another MS-DOS system to run the patch program on. It would work on one system and then a year later I’d need to run it again to find it would error out on me on another system. I knew other people in the BBS community were hitting the exact same problem and I wasn’t finding satisfactory answers.

The PatchWC! v3 tool is linked against the TurboPower B-Tree Filer library (written in Pascal). I’m assuming the program has its own internal B-Tree database for managing patch sets even though it just has a single one today. Other possible uses for this library is that C:\WILDCAT could be a mapped/mounted Novell NetWare share and this lets the patch program safely handle locking while it does its work. Another plausible reason, and I don’t think that’s the case here, is to safely work with Wildcat!’s message/user databases directly (keep reading for an example of this). But I digress.

When the program starts and B-Tree code is called it tries to find out what kind of record-locking mechanisms it has available and if it is running in an environment where it needs to use locks. One is a direct NetWare-aware check, INT 21h AX=E300h, if function 11h is implemented. Two others are Microsoft-compatible checks, INT 21h AX=5C00h which could be backed by SHARE.EXE or a real live network redirector (LockCallDefined), or “is any drive remote” by using INT 21h AX=4409h IOCTL checks (ADriveIsRemote).

If all of these checks fail, then IsamInitNet returns false and then the BTInitIsam function fails and returns the error 10310.

When PATCHWC.EXE is run in DOSBox-X, the built-in SHARE.EXE support doesn’t implement record locking so the first check fails. Then the IOCTL check happens for all 26 DOS drive letters A: through Z:, and they all fail because they’re not considered “remote”. The Novell check fails, both Microsoft checks fail, thus it can’t figure out what locking to use and the 10310 error in DOSBox-X.

Why it doesn’t just proceed in a “single user” mode I don’t know.

Claude figured out and identified the INT 21h accesses using the DOSBox-X debugger and wrote a short PROBE.COM program to reproduce the behavior and point out which checks failed or worked. I tried it on my various test configurations and here’s the results. I didn’t boot FreeDOS this time around, but I assume the results are similar. I don’t know what it does under OS/2.

Interestingly, while MSCDEX has nothing to do with the network, it has a side effect that CD drives register to DOS as “remote” so that satisfies the “network” checking here. This was a Claude suggestion to see what it did.

Config                     AH=5Ch lock probe           Drive-remote?         PatchWC result
==========================================================================================
DOSBox-X,                  AX=0x01 Invalid Function    no                    Fails (10310 error)
  Z: remote auto/false
DOSBox-X,                  AX=0x01 Invalid Function    yes                   Success!
  Z: remote true
Win95 GUI loaded           AX-0x21 Lock Violation      n/a                   Success!
                           (legit return)
Win95 GUI exited to DOS    AX=0x01 Invalid Function    no remote drive       Fails (10310 error)
Win95 command-line only    AX=0x01 Invalid Function    no remote drive       Fails (10310 error)
DOS 6.22                   AX=0X01 Invalid Function    no remote drive       Fails (10310 error)
DOS 6.22 with MSCDEX,      AX=0x01 Invalid Function    yes, CD registers     Success!
 no SHARE.EXE                                          as remote drive
DOS 6.22 with MSCDEX,      AX=0x21 Lock Violation      n/a                   Success!
 and SHARE.EXE             (legit return)

Enabling something that looks like a record locking function or makes the system look like it has remote drives is enough to satisfy the program’s internal locking checks and proceed.

So if you’re one of the dozens of us working with Wildcat! BBS in one of these configurations, that’s what you’ll need to look out for. Ensure you’re running real SHARE, try running MSCDEX, change the dosbox config. Heck, fire up the NetWare client. This probably applies to a variety of other Pascal programs back in the day that might have also used this library too.

POSTMSTR.EXE 10310 errors

PostMaster 10310 error in DOSBox-x

Which segues into seeing the same sort of 10310 error in another BBS program last night with DOSBox-X that’s also fixed with “drive z is remote = true“. This one was kind of an accidental edge case I stumbled upon and was surprised to see it turn up in a totally different program.

I have been using an unregistered copy of Joe Leomine’s PostMaster program now for a couple of years to automatically send test messages on the BBS to ensure my UUCP mail and usenet system is working correctly. It works by directly accessing the Wildcat! message database to insert messages. My main mild annoyance is that it sends registration nag emails every day. I’ve set up a wcPRO filter to automatically delete them, but I’ve been after a way to avoid that with a fake registration code.

While poking at it with Claude to find a way to spoof registration codes (I don’t think the dude is around anymore to register a 30 year old program) I learned a couple of things. First, it modifies its own .EXE to keep count of how many times you’ve run it, to appropriately shame you for using it 27,436 times. Second, is that it can do its own networking checking similar to what PatchWC did. I’m assuming it’s doing very similar things because of its database access, which would need good, safe file locking to not corrupt things.

It turns out when running in DOSBox-X, with Wildcat!’s MAKEWILD “Network type” is set to “DOS Share“, and the PostMaster program is run it exits with “ERROR! Initializing Network: : 10310“. I hadn’t noticed this on the real BBS before and I think every other time I’ve messed with PostMaster in DOSBox-X it was apparently with “Network type” set to “None“. When set to “None” the program works just fine in DOSBox-X.

Running strings on the POSTMSTR.EXE binary I don’t see any of the same B-Tree code as PatchWC or really any telltale signs of what it database code it’s using, so I’m not sure if it’s using the same library or not, but it’s curious it had a very similar 10310 error in this situation.

However if I re-enable drive z is remote = true and restart dosbox, PostMaster works just fine even if “Network type” is still set to “DOS Share“. Neat.

I don’t know if every multi-user-possible DOS program follows this same heuristic of checking for SHARE and remote drives, but curious that it worked in both these cases.

Now I can finally rest and stop thinking about these programs in the back of my mind!

Claude Code with DOSBox-X

It’s fascinating seeing Claude Code interact with DOS / DOSBox-X. I’ve found a couple of ways to bolt them together, one was over a serial cable, another was hacking an MCP onto DOSBox-X to give it a toe hold. The first time I tried working on the DOS programs in this post this Claude Code would spawn DOSBox-X with the debugger, then take screenshots of my screen to see what the debugger and the VGA output of the DOS session looked like. It was very slow and clunky but it just figured it out. The second time it figured out it could run DOSBox-X in headless mode. I don’t know what it was doing behind the scenes but it was launching and iterating over DOS programs much quicker.

I was very amused while working with PostMaster it eventually gave up trying to prompt me through the debugger to find the registration algorithm and was just “do you want me to patch the binary so it works instead”?

Posted in bbs, retro, vintage | No Comments »

Modem teardown additions

Jul 18th, 2026 by

New additions to the dial-up modem teardowns gallery. As usual yes I know a flickr album isn’t the best way to organize these, at least they’re alphabetical by name. Even with Claude I still haven’t got around to making something better. No, you can’t steal my photos and create your own modem website.

US Robotics Courier 2400

US Robotics Courier 2400

7/22/2026: a last minute addition! I got this because it had the manuals, will be scanning it soon they are now up on Internet Archive. This has a copper-colored faceplate, very snazzy.

8/10/2026: TIL there’s a Courier 2400e variant that supports Class 5 MNP (MNP5). This looks like it came out in 1986-1988, it’s FCC ID CJE794CORUIER24E, FCC REG# CJE794-11323-DM-E. The AT commands on the bottom show &Kn “n=0 Data compression disabled” so it sounds like it supports MNP5 compression too, which explains how it gets “up to 4800 bps speeds”. I don’t have one, maybe someday.

Wang 9648/24e

Wang 9648/24e modem

Apparently manufactured by Nuvo, it is a pretty basic 9600 bps fax / 2400 bps data modem from 1992. It uses a Rockwell RCC224ATF data pump, not many frills, not even error correction. I wrote about this modem the other day.

US Robotics Courier HST Dual Standard with V.32 bis and ASL “widebody”

I believe this may be the last “widebody” USR Courier released before switching to the narrower chassis we’re familiar with today. The modem I have is experiencing electrical problems that I haven’t figured out how to fix. So I can’t confirm if this is does HST at 14,400 bps or 16,800 bps (I’m assuming the latter), and I don’t have action photos of it yet. FCC ID CJE-0129, FCC Reg # CJE794-72748-MD-E, part number 1.014.327. It takes a
18 VAC power transformer with a male DIN-5 connector and the modem has a female DIN-5 socket.

This one was pretty popular back in the day, BBSs and online service would advertise separate phone numbers “USR HST Dual Standard” meaning they could handle callers with V.32 bis standard (14,400 bps) modems or other USR Courier HST modems to get a speed boost at 16,800 bps.

My modem had several capacitors that leaked on the board and had started corroding traces. I replaced them but the unit still flickers on/off rapidly when I turn it on.

 

Capacitor leakage

Trace and solder mask damage from corrosion due to capacitor leaks

US Robotics Courier HST Dual Standard power on clicks

US Robotics Courier HST Dual Standard power on clicks video

US Robotics Courier I-modem – internal

The collection isn’t strictly limited to external modems, this is an internal version of the modem that’s a combo ISDN TA and V.Everything that can do both digital and analog calls. Mainly so I can remember what jumper settings are there, COM 1-4 and IRQ 2/3/5/7 (why you no IRQ 10!). I have submitted these for the I-modem entry over on The Retro Web. The teardown gallery does include the external I-modem as well along with detailed power supply information.

US Robotics Courier 14400 HST power supply

After figuring out the pinout and making my own power supply, I finally got my hands on an original (maybe? there’s no USR branding) power adapter for the Courier 14400 HST that wasn’t an insane amount of money. This is a triple voltage output, +5 V, +12 V, -12 V DC, Female DIN-5 connector on the transformer end and male DIN-5 socket on the modem. It was made by Multi Products Int’l part number WA512750/27 with no US Robotics model.

I was missing the COM pin on the adapter I made last year. It’s an absolute unit, nearly 4.5″ long and 2.25″ tall.

Tags:

Posted in retro, vintage | No Comments »

Mediawiki editing quick reference

Jul 8th, 2026 by

Mediawiki editing quick formatting reference

I have been forever annoyed in Mediawiki for having to look up the subtle differences in formatting markup, especially after writing Markdown for a while. That “Editing help” at the bottom of a Mediawiki edit page takes you to a whole editor help page and buried in the middle is “Help:Formatting” that I really want. Between either getting the formatting wrong the first time, going back to edit it, or digging for the formatting guide takes me out of the writing flow.

But today I found out you can edit the “MediaWiki:Edittools” page, which lets you add your own stuff below the editor. Fire that up, add in your own quick reference like https://gist.github.com/bwann/b9981500d21965275dd9cad6637bc50c and you’re in business!

 

Posted in Uncategorized | No Comments »

Netbox, NAPALM, SSH keys

Jul 1st, 2026 by 

PLUGINS_CONFIG = {
    'netbox_napalm_plugin': {
        'NAPALM_USERNAME': 'napalm',
        'NAPALM_PASSWORD': 'secretsquirrels',
        'NAPALM_ARGS': {
            'optional_args': {
                # This is used globally for all napalm connections
                'key_file': '/home/netbox/.ssh/id_ed25519-napalm',
                'use_keys': True,
                'allow_agent': False,
            },
        },
    },
}

I finally got around to playing with NAPALM integration in Netbox more. I’ve been bothered by the fact that it’s assumed you’ll configure a napalm username and plaintext password in netbox/configuration.py and then go configure that same username and password on all of your devices. Passwords suck, especially hardcoded passwords, what about if you use SSH keys for user logins on your devices?

Per-platform/driver SSH key config

I accidentally found the answer to this and it’s passing extra arguments to NAPALM drivers via the Netbox config to specify using a key_file (some drivers may want key_filename?) containing a private SSH key. You can do this globally in PLUGINS_CONFIG in configuration.py, or you can add it on a per-platform config basis:

Just make sure the SSH key file is owned and readable by the user that runs Netbox, e.g. netbox. Else you get weird “TCP connection problems” on the web UI and it tries to SSH to the device and nothing is logged. I don’t know how well this is known to other Netbox users, it wasn’t immediately obvious to me but I’m surfacing it here so hopefully others can find it.

Ubiquiti EdgeSwitch driver

I have several EdgeSwitches and their CLI is different enough that none of the existing NAPALM drivers will work for it. So I had claude write me one: https://github.com/bwann/napalm-edgeswitch. It’s been tested against my switches and seems to work fine. Annoyingly despite what I just wrote above about SSH keys, EdgeSwitches only support password authentication so I still have to carry username "napalm" password hashhashhash in my configs.

Ubiquiti EdgeRouter driver fix

I have forked an existing napalm-edgeos repo to fix fetching configuration, something about a get_config() not implemented. I need to test it and review it before I send a PR to the other dude, but my work-in-progress version is at: https://github.com/bwann/napalm-edgeos

Posted in Uncategorized | No Comments »

Wang 9648/24e modem

Jun 30th, 2026 by

Wang 9648/24e fax modem

At last I finally got my hands on another modem I had as a teenager, a Wang 9648/24e. It’s an external 9600/4800 bps fax and V.22bis 2400 bps data modem. I’m not exactly sure why I bought this back then, because I already had a internal 2400 bps modem I got with a free Prodigy starter kit. I guess I just wanted the status LEDs to look cool or wanted faxing. It came out around 1992, and I purchased mine at Wal-mart for who knows how much money. After I started collecting 1990s modem I had to find another one to relive for the collection.

And boy does it disappoint! Apparently it’s so basic it doesn’t even do any kind of hardware MNP/V.42/V.42bis/LAPM error correction or data compression, I guess I completely forgot. It’s based on a bog standard Rockwell RC224ATF like virtually every other cheap modem out there, like the Viva 9600/2400 faxmodem which looks very similar. A datasheet I found for a different RC224ATLV variant leads me to believe it might support error correction in software via the Rockwell Protocol Interface (RPI) driver, but after trying it in Qmodem 4.6 Test Drive with RPI support turned on it didn’t seem to connect any differently. ATI3 only reports AFES-C2501-H0, there’s no -RPI- listed so maybe it doesn’t support it.

A side note, it’s interesting that Qmodem 4.6 Test Drive (compiled 1994) has Rockwell RPI support in it but Qmodem 5.0 (compiled 1992) doesn’t, and why was the test-drive newer?

RC224ATLV Rockwell Protocol Interface support

 

Modem board with Rockwell RC224ATF

The FCC ID JDJ-96424EFX leads back to a Nuvo Corporation, and the back of the PCB does say “NUVO 01-0063-52” so it’s not even a Wang design. This one didn’t come with a power adapter, looking at the board I didn’t see a bridge rectifier circuit so I assumed it was DC powered. It fired right up when I used a 9 VDC power adapter.

I don’t remember if the lack of error correction was a deal breaker as much as it was just being a sloooow 2400 bps. It’s probably no wonder why I justified saving up to buy a Zoom VFX 14.4k modem after it. The itch has been scratched and I feel shallow and empty again. The original one I had was relegated to doing credit card processing for the ISP as it was reliable and didn’t need anything faster than 1200 bps, so this one will likely be demoted to a box or a shelf somewhere.

Along the way I found this page talking about a Nuvo modem with RC224ATF and interestingly explains why the modem can do 9600 for fax and only 2400 for data (half-duplex and crosstalk).

Tags:

Posted in Uncategorized | 1 Comment »

Archiving a SunOS 4.x floppy disk written with tar

Jun 10th, 2026 by


I was trying to archive some old Livingston Portmaster software for SunOS from a 3.5″ floppy disk and suddenly realized I wasn’t sure how this was going to work with Greaseweazle, given it wasn’t a IBM formatted floppy, or really formatted at all. It was a tar archive written directly to the floppy disk by SunOS. Greaseweazle generally likes to be told something about the tracks/sectors/format of a disk when creating anything other than .SCP images. In the old days this might be extracted with something like tar xvf /dev/rfd0 using the raw floppy device name.

It turned out to be rather simple, I used this process:

  • Create a raw flux SCP image with Greaseweazle: ~/bin/gw read --raw PortMaster-2.3-SunOS-tar.scp --drive=A
  • Use HxCFloppyEmulator to take a look at the tracks it read
  • Export a .IMG raw disk image
  • On my Linux machine use losetup to mount the .IMG file
  • Use regular old tar against the /dev/loop0 device to extract files

I was able to pull off all the files from this 34 year old floppy disk using my Linux workstation! This is posted up on the Internet Archive here. I need to fire up an old instance of SunOS 4.x to use it, but I suspect it’s all intact.

Mounting disk image

[bwann@raptor tmp]$ sudo losetup -f -P PortMaster-2_3-SunOS-tar_scp.img
Success. Logging you in...
[bwann@raptor tmp]$ losetup -l
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                                 DIO LOG-SEC
/dev/loop0         0      0         0  0 /var/tmp/PortMaster-2_3-SunOS-tar_scp.img   0     512

Viewing contents

[bwann@raptor tmp]$ sudo tar tvf /dev/loop0
Success. Logging you in...
-rw-r--r-- 0/1               0 1991-08-30 15:52 ./Zcheck
-rwxr-xr-x 0/1            2082 1992-09-22 12:47 ./pmconsole
-rwxr-xr-x 0/1            1222 1992-09-22 12:45 ./pmdial
-rwxr-xr-x 0/1            1563 1992-09-22 12:45 ./pminstall
-rwxr-xr-x 0/1            1231 1992-09-22 12:45 ./pmreset
-rwxr-xr-x 0/1            1231 1992-09-22 12:44 ./pmcommand
-rwxr-xr-x 0/1             904 1992-09-22 13:03 ./lstty
drwxr-sr-x 0/1               0 1992-08-24 19:52 ./pm_data/

Extract to a local directory

[bwann@raptor tmp]$ mkdir portmaster-sunos
[bwann@raptor tmp]$ sudo tar xvf /dev/loop0 -C ./portmaster-sunos

[bwann@raptor tmp]$ ls -l portmaster-sunos/
total 24
-rwxr-xr-x 1 root bin  904 Sep 22  1992 lstty
-rwxr-xr-x 1 root bin 1231 Sep 22  1992 pmcommand
-rwxr-xr-x 1 root bin 2082 Sep 22  1992 pmconsole
drwxr-sr-x 1 root bin    0 Aug 24  1992 pm_data
-rwxr-xr-x 1 root bin 1222 Sep 22  1992 pmdial
-rwxr-xr-x 1 root bin 1563 Sep 22  1992 pminstall
-rwxr-xr-x 1 root bin 1231 Sep 22  1992 pmreset
drwxr-sr-x 1 root bin   38 Aug 24  1992 snmp
drwxr-sr-x 1 root bin  264 Sep 23  1992 sun3_4.0
drwxr-sr-x 1 root bin  240 Aug 24  1992 sun3_4.1
drwxr-sr-x 1 root bin  264 Sep 10  1992 sun4_4.0
drwxr-sr-x 1 root bin  264 Sep 23  1992 sun4_4.1
-rw-r--r-- 1 root bin    0 Aug 30  1991 Zcheck
[bwann@raptor tmp]$

Making an on-disk tarball

This one amused me the most, it’s simply: dd if=/dev/loop0 of=portmaster.tar

Posted in vintage | No Comments »

O’Reilly UUCP books

Jun 8th, 2026 by

UUCP book versions

I’ve written about UUCP a few times and may have mentioned UUCP books but I don’t think I’ve actually explained the differences in what’s out there from O’Reilly and Associates. Dated technology calls for dated books! Most of the “modern” UUCP how-to guides found online are short, expect to be using UUCP over TCP/SSH, and just don’t give a lot of background on the hows and whys some things were set up the way they were. For instance, why add users to uucppublic? why prefix some usernames with a U like Utuxedocat? what’s the advantage and downside to uucico as a login shell? Of particular note is walking through the security implications. UUCP was used during a time when we were lucky to have working systems to begin with and there was an element of trust amongst users. It’s far from a secure file transfer mechanism, but the books help secure it the best it can be. These ORA books are straightforward and live up to their reputation for walking you through things. These not only cover UUCP but also go into detail on things like how to set up mgetty, serial ports, and modems.

There’s a few different titles from ORA on the topic with some important differences to be aware of if you’re looking for reference for a particular vintage of software. I wanted an edition that covered Taylor UUCP that comes with Linux, so I wanted one of the later editions. I learned many sellers use the wrong title, wrong cover photo, wrong edition information when they list these books for sale as they have similar titles and use bears on the cover, so I’ve included the ISBN information to help tell them apart. Fortunately these are all up on Internet Archive so you can borrow them online, but some people like me still like dead tree editions.

Managing uucp and Usenet

The original book “Managing uucp and Usenet” by Tim O’Reilly and Grace Todino was first printed in 1986 and covered both UUCP and Usenet. It had at least 10 editions spanning 1986-1992. There was even an earlier “nutshell handbook” version, which is available on the Internet Archive. The ISBN for my copy is 0-937175-93-5.

Managing UUCP and Usenet, Tenth edition, 1992

This covered HoneyDanBer UUCP (a/k/a BNU), Version 2 UUCP, Telebit modems, and Netnews. The ninth edition from 1990 is available on Internet Archive as well as the tenth edition from 1992.

Using UUCP and Usenet

Grace Todino and Dale Dougherty, first published in 1986. I don’t have this book, I didn’t even know it existed until I was writing this post. The back cover claims it’s the companion to Managing uucp and Usenet, directed at end-users performing day-today tasks instead of system administrators actually setting up UUCP, and predecessor to the dedicated Using & Managing uucp. The 1991 version is up on Internet Archive.

Using & Managing uucp

Using & Managing uucp, Second Edition,1996

Ed Ravin, Tim O’Reilly, Dale Dougherty, Grace Todino. ISBN 1-56592-153-4. This book notes it is based on the previous two books I just mentioned above. This one focuses solely on UUCP, all of the Usenet/netnews content has been removed.  For me this is my favorite reference as it covers Taylor UUCP, which is the implementation still included in some modern Linux distributions like CentOS and Ubuntu. The second edition is up on the Internet Archive too.

UUCP versions covered in Managing UUCP

Managing Usenet

Henry Spencer and David Lawrence. ISBN 1-56592-198-4. Because the Usenet/netnews content was removed from the UUCP books, a new title was released just for Usenet. I’ve included it here because inevitably when you think UUCP you start thinking Usenet thoughts. It doesn’t appear to have direct heritage from the previous UUCP books as it has different authors. Published in 1998 it’s a bit later but it covers C News and INN, the latter of which is still bundled with Linux today.

Tags:

Posted in vintage | No Comments »

Hello from CentOS 10 Stream

Jun 8th, 2026 by

I finally got around to upgrading my VPS hosting my public website over to CentOS 10 Stream, CentOS 7 was starting to get long in the tooth. At some point Linode apparently bumped up the storage included in my plan from 50 GB to 80 GB without me knowing it, so it’s nice to start over and get an extra 30 GB that I really needed.

Posted in Uncategorized | 3 Comments »

Syncing time on vintage Novell Netware servers?

May 14th, 2026 by

I was flipping through my new “The Complete Guide to NetWare 4.1” and noticed it mentioned syncing time on NetWare servers to external sources. This got me to wondering what server administrators might have used in the 1990s for setting time on their NetWare 3.x/4.x servers. Today we use NTP over the Internet, or GPS receivers, or from the cellular network to synchronize time. NetWare 4.x has a TCP/IP stack and could technically use the Internet to get to NTP servers, I have a feeling a lot of organizations weren’t yet on the Internet and still had a need for setting reliable time.

Off the top of my head I thought possible solutions available then could be dialing up the NIST time service (ACTS) with a modem or some sort of WWV radio receiver hooked up to a RS-232 serial port on your NetWare server, and some sort of Netware Loadable Module (NLM) to interface with it. GPS receivers were probably starting to be available by then and probably very expensive. Whatever the reference, you’d probably still need something that used a RS-232 port to interface with the server. I don’t recall seeing too many ads for clock sources in magazines back then but surely there was something. I guess if anything there was dialing your local bank’s time and temperature phone number and setting it manually that way.

I eventually found this article on the old Novell support website, “Time in the NetWare Environment“. Down at the bottom is a list of hardware and software that could maintain time on NetWare servers and I went searching to see if I could find any of them. I’m really interested in the ones that could dial up with a modem because I have a modem and the NIST time service is still functioning today.

Time Master TM.NLM/TS.NLM

A NLM that appears to synchronize time just between NetWare servers and DOS clients. I found it on a shareware CD (World of Communication) on Internet Archive, but it doesn’t seem to support external reference sources.

CTS-10 card and Odetics RTCTOOLS.NLM

This one was interesting, I didn’t even know there was a hardware ISA card that was a WWV clock receiver. It was made by Coordinated Time Link Company in Santa Clara, CA. There was an NLM that would speak to this CTS-10 card and set the server time. Major Jackyl on vogons.org has the only photographs I’ve seen of the card from 2024. Then there was somebody on the time-nuts mailing list in 2011 asking about the card. They claim they’ve used the card for a long time but the software doesn’t support anything beyond the year 2010. Of course the reply disregards the card software questions and “what, why use that, why don’t you just use NTP and GPS?”

C-Note Software – Cadence

A NLM that used a dial-up modem to synchronize to NIST. I was able to find the old Polygon website on Internet Archive but the software looks like it was on a FTP server that wasn’t archived and requires a license key. Filenames were CADV252.EXE, CTS_V310F.EXE (NT and NetWare?), Polygon seems to have lasted until 2012 but still used FTP links.

Legal File Software – WANTimes

Another modem dialer NLM. CompuServe forums are long dead and I haven’t found any archives that carry the NOVUSER forum nor found that WANTIM.ZIP file in any software stashes.

Then there were two other NLMs to set clocks from UK and German national clocks.

So I haven’t turned up any of the original NLM modem software, which is a bummer. The AppNote provided a short BASIC example for dialing up to NIST but it’s far from a finished program, and I think you’d have to stop NetWare and run it from DOS to set the computer’s RTC. NIST also provided some ACTS modem dialer software too (still works!), but these would’ve required bringing down NetWare and running from DOS as well.

For now what I’m doing on my NetWare 4.1 server is calling out to a packet driver and mTCP during AUTOEXEC.BAT, running the SNTP client, then going on to load the NetWare server. It’d be a lot neater to have a NLM that could dial periodically.

Posted in vintage | No Comments »

Older Posts »