Even the kernel that ran the installer crashes once it boots the image. Note, I'm using BlueSCSI v2 if that's relevant. Any suggestions?
(why did it take me this long to notice the typo in the title? grief)
[ Removed by Reddit on account of violating the content policy. ]
Clara and I found some Pentium III-era parts on the kerb earlier this month, and I’m finally getting around to cataloguing, cleaning, testing, and hopefully fixing what I can.
On the bench today is a Samsung 12x DVD-Master IDE drive, model SD-612
. The barcode sticker says it was manufactured in Korea back in March 2001, which makes it older than many of my readers. That’s terrifying, why did I have to say that.
As with much of my old hardware, I decided to use my 2000 Dell Dimension 4100 tower to test. This has become my favourite retro test bench on account of its side panel being the easiest to open! I connected the drive to the primary internal IDE interface, set the jumper to Cable Select, and tried.
First signs looked good. The BIOS reported the correct device:
SAMSUNG DVD-ROM SD-612F
Windows was also able to see the drive:
I pressed the eject button, and was happy to see the tray open and close without issue. If anything, it sounded way smoother than the scratchy modern 9.5mm BD burner in my FreeBSD Bhyve/jail tower. I loaded a disc, and heard some encouraging whirring sounds.
Unfortunately, Windows couldn’t mount any disc I tried. The first was a DVD-RW, so I tried a pre-recorded DVD, and a few CDs. No dice; it would spin momentarily, then give up.
Just in case it was Windows, I tried both my Red Hat 6 and NetBSD 8 x86 CDs, but neither booted. Alas, this looked like a hardware issue, unless classic Red Hat was in cahoots with an orange Daemon.
I’m not an electrical engineer, but given the drive was literally found half-buried in dirt during a thunderstorm, I figured it couldn’t hurt seeing if it was damaged inside (aren’t we all sometimes)?
Like all drives of this vintage, there’s a specific order for disassembly:
Turn the computer on and eject the tray. This lets you remove the bezel without trying to pry it open.
Close the drive, shut down the machine, and unplug.
Unscrew the bottom metal plate, exposing the drive’s PCB.
Gently push the plastic tabs for the front bezel inwards, letting you pop it out. Take your time here, these are easy to snap off if you’re not careful.
Lift the plastic drive mechanism and tray assembly out of the drive shell.
I was surprised how clean(ish) the inside of the drive was, save for some dust and slight corrosion at the front behind the drive bezel. It didn’t look like any major ingress of water or silt had happened, which was encouraging.
My first step with any malfunctioning magnetic drive is to clean the read/write head, so I figured I’d do the same thing here with its laser lens (pictured above). It looked fine peering under the spindle frame, but I dabbed it with a cotton swab sprayed with some IPA, and was shocked at the amount of fluff and gunk that came off! No wonder it couldn’t see any disc.
Besides this, everything looked in working order. I cleaned off and added a drop of new lithium grease to the moving metal parts, and used some compressed air to remove some of the dust.
I reassembled the drive, connected it to the Dell again, booted, and tried another disc. It… worked. First time!
There you go. If you have an old drive that turns on and ejects just fine, but can’t detect discs, give the laser lens a clean. I don’t think I’ve ever had to do that for an old optical drive before.
By Ruben Schade in Sydney, 2024-07-25.
Under https://cdn.netbsd.org/pub/NetBSD/images/10.0/ I see there are MD5 and SHA512 files along with the images, but neither is signed
Hi,
The reason I was tinkering with Caddy is because I came up with a project.
Replace a remote Linux by NetBSD (or any OS) on a remote server only by using the initial SSH access we have on the remote Linux server.
This is basically an in-place OS replacement.
After some research, I found a way to do that, and decided to write an article about it.
I thought it would made sense to host that article on a NetBSD server installed this way.
(My server might be one of the rare if not sole NetBSD server in the provider's data-center).
This is way I learned a lot about NetBSD system administration, for init scripts, npf firewall + blocklistd, user chroot service isolation the NetBSD way, Caddy setup to ease certificate management, and so on.
Here is my article.
https://cloudbsd.xyz/
I made the demo video in a local VM though.
I'm sharing because I think this might interest people here.
Hope you will like it,
Cheers,
As usual, partway through a couple weeks in Mallorca, we’re just getting the hang of it. After a few days of only the pool, it’s been pool mornings and beach afternoons. Every day, each kid gets more bold in both. I’ve managed to avoid getting sunburnt so far, though it’s getting harder to stay ahead of the situation. For mealtimes it’s kind of fun to be stuck in a tiny kitchen trying to cook my way out; bedtimes, down a sleepable room due to a broken air conditioner, were less so. My carcass got taken over by mosquitoes, who then rented most of it back to me. In a few days I might be ready to buy them out.
Usually here I’d consider taking a nap when the littles do. Definitely tired enough. But a little solo computer time feels more like what I’m needing: Refactoring some code, backing up some photos, updating pkgsrc stuff, writing posts on my website, that sort of thing.
For this summer vacation we’re hopping around more, which happens to simplify our transatlantic travel days. (Traditionally we’d have connecting flights before arriving anywhere.) One flight into Munich, where we stayed in the area for a few days visiting in-laws. From there a quick hop to Mallorca, the meat in our vacation sandwich. From here a quick-ish hop to Hannover for a week back in the little north-central German village where we lived out the first two years of COVID. Then we’ll drive to Frankfurt to see friends before our return flight to New York. Hopping around like this means we get to see more people and places, in exchange for which we get to find out what happens when kids try to sleep in a wider variety of environments and configurations. So far, sokay.
I wanted to clear all the newsletters items I’ve saved, so you are getting links until my inbox no longer paginates.
All that to say, I find that NetBSDs philosophy aligns with mine. The OS is small and cozy, and compared to many minimal Linux distributions, I found it faster to setup. Supported hardware is automatically picked up, for my Thinkpad T480s almost everything (except the trackpad issue I solved above) worked out of the box, and it comes with a minimal window manager and display manager to get you started. It is simple and minimal but with sane defaults. It is a hackable system that teaches you a ton. What more could you want?
↫ Marc Coquand
I spent quite some time using OpenBSD earlier this year, and I absolutely, positively loved it. I can’t quite put into words just how nice OpenBSD felt, how graspable the configuration files and commands were, how good and detailed the documentation, and how welcoming and warm the community was over on Mastodon, with even well-known OpenBSD developers taking time out of their day to help me out with dumb newbie questions.
The only reason I eventually went back to Fedora on my workstation was performance. OpenBSD as a desktop operating system has some performance issues, from a slow file system to user interface stutter to problematic Firefox performance, that really started to grind my gears while trying to get work done. Some of these issues stem from OpenBSD not being primarily focused on desktop use, and some of them simply stem from lack of manpower or popularity. Regardless, nobody in the OpenBSD community was at all surprised or offended by me going back to Fedora.
NetBSD seems to share a lot of the same qualities as OpenBSD, but, as the linked article notes, with a focus on different things. Like I said yesterday, I’m looking to building and testing a system entirely focused on tiled terminal emulators and TUI applications, and I’ve been pondering if OpenBSD or NetBSD would be a perfect starting point for that experiment.
Hello everyone,
I tried to create several virtual machines with qemu and NVMM this morning, and I encountered an unexpected situation: I was unable to create a "tap4".
I installed and configured everything as usual.
Brand new complete (with X11) install of NetBSD 10.0
1) Setup NVMM :
(become root)
su -
modload nvmm
echo nvmm >> /etc/modules.conf
chown myuser:wheel /dev/nvmm
2) Install qemu :
pkgin -y in qemu open-vm-tools OVMF
mkdir /var/run/vmblock-fuse ; vmware-vmblock-fuse /var/run/vmblock-fuse ; echo vmtools=YES >> /etc/rc.conf
(become myuser)
exit
vmware-user-suid-wrapper
3) Fix sound problem :
(become root again)
su -
sysctl -w hw.audio0.blk_ms=100
4) Create a NetBSD 10.0 VM (for example) :
mkdir /home/myuser/VM
qemu-img create -f qcow2 /home/myuser/VM/netbsd10.qcow2 12G
chown -R myuser:users /home/myuser/VM
echo "create" > /etc/ifconfig.tap3 && echo 'descr "NetBSD VM" up' >> /etc/ifconfig.tap3 && echo "! ifconfig bridge0 create" >> /etc/ifconfig.tap3 && echo '! ifconfig bridge0 descr "LAN VM bridge" up' >> /etc/ifconfig.tap3 && echo "! brconfig bridge0 add tap3 add wm0" >> /etc/ifconfig.tap3
chmod 660 /dev/tap3
reboot
5) Start the VM :
(become myuser)
qemu-system-x86_64 -accel nvmm -cpu qemu64 -smp cpus=1 -m 2G -display sdl,gl=on -usb -device usb-mouse,bus=usb-bus.0 -cdrom /home/myuser/ISO/boot.iso -drive file=/home/myuser/VM/netbsd10.qcow2,if=none,id=hd0 -device virtio-blk-pci,drive=hd0 -object rng-random,filename=/dev/urandom,id=viornd0 -device virtio-rng-pci,rng=viornd0 -audiodev oss,id=oss,out.dev=/dev/audio,in.dev=/dev/audio -device ac97,audiodev=oss -netdev tap,id=tap3,ifname=tap3,script=no -device virtio-net-pci,netdev=tap3 -bios /usr/pkg/share/ovmf/OVMFX64.fd -boot menu=on
Apart from a few usual issues with NVMM, it works quite well. VM access internet.. Well, everything is fine !
But this time, I decided to create a ... fourth VM!
And bam!!
no /dev/tap4... I tried manually (instead of creating an /etc/ifconfig.tap4), but no /dev/tap4 never appears...
What should I do ???
I see no limitations of tap interfaces number anywhere on the sysctl results.
I understood that it should now be necessary to integrate vether... but again, there is no documentation on how to do it with qemu, and no one seems to understand how to do, so I thought I would stick to tap for now.
Any idea ?
A big thank you in advance !
Hey everyone, I wrote a small essay/review of NetBSD that I thought the community might enjoy 🙂.
Hello
I have Raspberry Pi 1B running NetBSD 9.3 and I am struggiling with the upgrade to NetBSD 10, as the procedure is not clear to me. Sysupgrade does upgrade the system, however I have to upgrade the kernel manually and this is what is going wrong.
As I understood, I have to manually download https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/evbarm-earmv6hf/binary/kernel/netbsd-RPI.img.gz, extract it and copy it to /boot/kernel.img. As I understood, after that I can run sysupgrade to upgrade the system.
My problem is that after doing that, my Raspberry Pi 1B becomes unbootable. Am I doing the right steps or did I forgot something?
SilverStone announced the CS382 MicroATX case at the recent Computex in Taiwan, and it looks like an efficient box of wonders:
It has breathable panels, dust filters, a power supply shroud, mounting options for MicroATX and MiniITX boards, and a smaller footprint than my venerable homelab Antec 300. It can support a 240mm AIO, but it’s also efficiently laid out for a 168mm tower air cooler.
But the standout feature is its 8× tool-less drive sleds, which have mounting options for 3.5 and 2.5 SATA or SAS drives, and cooling mounted to the back of the cage. Most NAS cases top out at five drives, which is useless for using mirrored drives, and not really sufficient for ZFS RAID-Z2 or RAID6. Anyone using RAID5 today is getting the best bang for their buck, until it goes bang.
Other interesting features include a 5.25 drive bay (yay!), and even a separate 9.5mm optical drive slot! I could install my BD writer and a LTO drive, or use both for additional SSDs. The 5× PCI slots could accommodate beefy graphics cards, or plenty of expansion for a small bracket-mounted Raspberry Pi cluster, SAS controllers, and so on.
This wasn’t sponsored by SilverStone! I’m just glad people are still making hardware like this. Consumer-grade cases basically only target gamers now, who only want M.2 storage and maybe a 2.5 SSD. This would be a perfect homelab box for running FreeBSD with bhyve and OpenZFS, or NetBSD with nvmm, or a Penguin of some description.
Our Antec 300 homelab server is still rocking a Supermicro X11SAE-M MicroATX board with a Xeon E3-1240 v6. That… would fit in this. Uh oh.
By Ruben Schade in Sydney, 2024-07-16.
Based upon this Firefox Q2 issue, additional X utilities were affected, notably xpdf. I attempted a compile of pkgsrc, but firefox is too heavy for the laptop I have.
So, I would like to roll back to 2024Q1. Does anyone know which one of these options I should use ?
do a 'pkgin update' after reverting "/usr/pkg/etc/pkgin/repositories.conf" to use 2024Q1.
Perform these steps, as suggested here in this forum when someone broke their pkgsrc.
# rm -rf /var/db/pkg
# rm -rf /var/db/pkgin
# cp -R /usr/pkg/etc etcbackup
# rm -rf /usr/pkg
I do not mind reapplying pkgsrc, I have a script that will do that.
Thanks
Eager to see if I could use rclone-browser on NetBSD 10.0, I decided to see if it was still possible to compile it.
It is done.
From a complet NetBSD 10.0 install (with X11) :
pkgin install git cmake qt5-qtdeclarative rclone
cd /usr/pkg
git clone https://github.com/kapitainsky/RcloneBrowser.git
Open the file /usr/pkg/RcloneBrowser/src/main_window.cpp:
Replace the line:
QStringList lines = version.split("\n", QString::SkipEmptyParts);
With this:
QStringList lines = version.split("\n", Qt::SkipEmptyParts);
Also replace the line:
player->start(stream, QProcess::ReadOnly);
With this:
QStringList arguments;
arguments << stream;
player->start("playerExecutable", arguments, QProcess::ReadOnly);
You can make the 2 modifications above by directly executing the following commands:
sed -i 's/QString::SkipEmptyParts/Qt::SkipEmptyParts/' /usr/pkg/RcloneBrowser/src/main_window.cpp
sed -i 's/player->start(stream, QProcess::ReadOnly);/QStringList arguments;\n arguments << stream;\n player->start("playerExecutable", arguments, QProcess::ReadOnly);/' /usr/pkg/RcloneBrowser/src/main_window.cpp
Build :
cd /usr/pkg/RcloneBrowser
mkdir build && cd build
cmake .. -DCMAKE_PREFIX_PATH:PATH=/usr/pkg/qt5 -DCMAKE_INSTALL_RPATH=/usr/pkg/qt5/lib
make
make install
It would be nice to have a package
I installed NetBSD 10.0 in a VM and I want to install xfce4 as a graphical environment but I can't find any instructions. Can someone help me to install xfce4 in NetBSD 10.0 Thank you!!
I was not able to get this done early like the last few posts, but there’s still a good range here.
It’s no secret that I love FreeBSD and NetBSD, and use both wherever I can for work and fun. Their operation makes the most sense to me, they have the tooling I trust and prefer to use, I’m sympathetic to their permissive licensing, and I like being a part of their communities.
This has lead more than a few people email asking why I don’t like Linux, or going as far to claim I must hate it. The TL;DR is, I don’t! I literally run it every day, at work and at home.
(With thanks to sosuke for the amazing wallpaper. Pavolia Reine and Ceres Fauna are my favourite vtubers. Yes, I’m one of those people! Their original Pixiv account is gone alas).
I love Linux for a bunch of reasons.
On the server, it just runs (usually). I’d estimate half the customer VMs we run at work are Linux, but they’re responsible for less than 10% of our support tickets. When I am on pager duty for the evening and I get an alert from a Linux box, it’s almost always for something external affecting them. I wish I could say the same thing for Windows Server, which seems to spit the dummy at the slightest provocation.
Young people starting out in IT can get a Linux VPS or cloud server and learn to build amazing things. Every Linux server is another that would have previously been an expensive commercial system, or may not have even existed at all. This social good that comes from having access to this, alongside high-quality software a package manager command away cannot be understated; not to mention sticking it to convicted monopolists.
Moving to the desktop, modern Linux has made it feasible for me to not even need Windows for games, something I could have scarcely believed a decade ago. Red Hat Linux, Mandrake, and Cobind were my introduction to *nix before I even knew BSD was a thing, and I still run a lot of the software I got used to back then (even on the Mac).
This gets to the other fundamental reason I appreciate Linux. Just as Linux users and developers benefit from the tooling and code that comes from BSD, likewise we benefit from Linux existing. I run desktops and applications on my FreeBSD workstation that were mostly built for Linux. When something doesn’t have a native BSD build, it’s significantly easier to port or recompile a Linux application for BSD than, say, a Windows program (or even some old school UNIX). BSD users also tend to benefit from vendors realising they need to support Linux; it’s one step closer!
I don’t agree with some of the directions commercial vendors have forced the broader Linux ecosystem to take, though some Linux people don’t either!
Point is, even though I defer to BSD where possible, I’d still prefer to run Linux than almost anything else. I’m thankful it exists. 🐧
By Ruben Schade in Sydney, 2024-06-12.
NetBSD 10 was released recently, so a lot of people are experimenting with it and writing down their thoughts. I’ve got two of those for you today, to help you in case you, too, want to install NetBSD 10 and play around with, or just use, it.
First, what if you want to install NetBSD 10 on a UEFI system, but with full disk encryption in case your device gets stolen? It turns out there are countless guides for installing with full-disk encryption on MBR-based systems, but once you use UEFI – as you should be – things get a lot more complicated. The NetBSD installer is apparently rather basic, and a better solution is to drop to a shell and install NetBSD that way instead, and even then, full disk encryption with UEFI is actually not possible, as it seems the root file system – where the operating system itself resides – cannot be encrypted.
The restriction is in the root file-system. It needs to be in plain-text and in a regular partition. It seems to me that rootfs in CGD or LVM is not well supported.
↫ vsis.online
This seems like something the NetBSD team may need to take a look at, since full disk encryption should be an easy option to choose, even, or especially in 2024, on UEFI systems. Such encryption is easily achieved on Linux or Windows systems, and it seems odd to me that NetBSD is lagging behind a bit here. In the meantime, the linked guide will be a good jumping-off point for those of you interested in going a similar route.
The second article I want to highlight concerns NetBSD 10 on the Pinebook Pro, the inexpensive ARM laptop that normally ships with Linux. It turns out there’s a NetBSD 10 image for this device, so installation is quite a bit more straightforward than the more exotic setup I mentioned earlier. It seems most of the hardware works quite well out of the box, with the inly exception being the on-board Wi-Fi, which the author addressed with a USB W-Fi dongle.
Other than that, NetBSD is running well on the Pinebook Pro for the author, which is great to read since that makes this cheap device a great starting point for people interested in running NetBSD.
This isn’t so much a tutorial (because you should read the Handbook for such guidance instead) and more a case of oh, that’s neat.
I’ve mentioned you can create a FreeBSD jail using bsdinstall(8)
, which you might have used to install FreeBSD in the first place. This lets you choose multiple distribution sets, and enable/disable certain services.
For example, if your jails are in the same place as mine:
holo# zfs create srv/jail/pavoliareine
holo# bsdinstall jail /srv/jail/pavoliareine
If you only need base though, you can just extract a tarball instead you downloaded from a FreeBSD mirror:
holo# zfs create srv/jail/pavoliareine
holo# tar -xvf base.tgz -C /srv/jail/pavoliareine
Wait, that’s it? Yes!
Okay, you may still need to configure it, like setting up resolv.conf
and other files in /etc
if you intend it to be network-facing. But other configuration you would have set up in /etc/jail.conf
will be applied automatically.
When I talked about the practical differences between FreeBSD and Linux, this is one of the key ones that makes my life easier. I use a similar approach for chroot
environments on NetBSD too, which I use/abuse for similar deployments to jails; that probably warrants its own post.
By Ruben Schade in Sydney, 2024-06-10.
On my home network, some important jobs are performed by little ARM computers.
The house came with a decent sound system wired in. The receiver can take 1/8” stereo input — from AirPlay, with help from a decade-old Raspberry Pi 1 Model B Rev 2.
With a 4GB SD card, from macOS:
$ diskutil list # inspect output
$ SDCARD=disk6
$ diskutil unmountDisk ${SDCARD}
$ links https://raspi.debian.net/tested-images/
$ DISKIMAGE=20231109_raspi_1_bookworm.img.xz
$ fetch https://raspi.debian.net/tested/${DISKIMAGE}
$ xzcat ${DISKIMAGE} \
| sudo dd of=/dev/r${SDCARD} bs=64k oflag=sync status=progress
$ diskutil eject ${SDCARD}
Place the RPi somewhere convenient.
Connect SD card, keyboard, HDMI, Ethernet, and power.
Log in as root
, no password:
# apt update
# apt -y install etckeeper
# cd /etc
# git branch -M main
# apt -y install sudo
# visudo # for the sudo group, insert NOPASSWD: before the final ALL
# useradd -m -G sudo -s /bin/bash schmonz
# passwd schmonz
# exit
Log in as schmonz
:
$ sudo passwd root
$ sudo sh -c 'echo 127.0.1.1 schleierplay >> /etc/hosts'
$ sudo hostnamectl hostname schleierplay
$ sudo ln -sf /usr/share/zoneinfo/US/Eastern /etc/localtime
$ sudo etckeeper commit -m 'Set root password, hostname, and timezone.'
$ sudo apt -y install shairport-sync
$ sudo vi /etc/shairport-sync.conf
$ sudo etckeeper commit -m 'Set AirPlay name.'
$ sudo shutdown -h now
Place the RPi where it’ll live. Connect audio cable, Ethernet, and power.
$ ssh-copy-id schleierplay.local
Make sure receiver is set to AUX input. Use AirPlay.
As with any Debian:
$ ssh schleierplay.local -t 'sudo apt update && sudo apt -y upgrade && sudo apt -y autoremove'
To back up /etc
, git push
it someplace trustworthy and private.
I’d rather run NetBSD, but on 10.0 with shairport-sync
, I saw a lot of AirPlay Speaker Not Available: 'House' is being used by someone else
(even when it wasn’t).
My ancient USB-only HP LaserJet P1006 remains reliable for our basic needs and we’ve still got a pile of toner cartridges. A friend recently sent me a comparatively beefy Pine A64 board.
With a 4GB SD card, from macOS:
$ diskutil list # inspect output
$ SDCARD=disk6
$ diskutil unmountDisk ${SDCARD}
$ links https://www.armbian.com/pine64/
$ DISKIMAGE=Armbian_24.5.1_Pine64_bookworm_current_6.6.31_minimal.img.xz
$ fetch https://dl.armbian.com/pine64/archive/${DISKIMAGE}
$ xzcat ${DISKIMAGE} \
| sudo dd of=/dev/r${SDCARD} bs=64k oflag=sync status=progress
$ diskutil eject ${SDCARD}
Place the A64 somewhere convenient.
Connect SD card, keyboard, HDMI, Ethernet, and power.
Follow the prompts to set the root
password, create a user account, and select a locale.
Then continue:
# apt update
# apt -y install etckeeper
# cd /etc
# git branch -M main
# visudo # for the sudo group, insert NOPASSWD: before the final ALL
# exit
Log in as schmonz
:
$ sudo sh -c 'echo 127.0.1.1 schleierprint >> /etc/hosts'
$ sudo hostnamectl hostname schleierprint
$ sudo ln -sf /usr/share/zoneinfo/US/Eastern /etc/localtime
$ sudo etckeeper commit -m 'Set root password, hostname, and timezone.'
$ sudo apt -y install hplip avahi-daemon
$ sudo usermod -a -G lpadmin schmonz
$ sudo etckeeper commit -m 'Make myself a printer admin.'
$ sudo shutdown -h now
Place the A64 where it’ll live. Connect printer, Ethernet, and power.
$ ssh-copy-id schleierprint.local
$ ssh schleierprint.local
$ sudo hp-setup -i # follow prompts, mostly defaults; name the queue 'hpljp1006'
$ sudo etckeeper commit -m 'Add initial hplip config for P1006.'
$ sudo sed -i \
-e '/^\*ColorDevice: True$/s|True|False|' \
-e '/^\*OpenUI \*Duplex\/Double-Sided Printing: PickOne$/,/^\*CloseUI: \*Duplex$/s|^|*% |' \
-e '/^\*OpenUI \*ColorModel\/Output Mode: PickOne$/,/^\*CloseUI: \*ColorModel$/s|^|*% |' \
/etc/cups/ppd/hpljp1006.ppd
$ sudo etckeeper commit -m 'Correct advertised printer capabilities.'
$ sudo sed -i \
-e 's|^Info $|Info HP LaserJet P1006|' \
/etc/cups/printers.conf
$ sudo lpadmin -d hpljp1006
$ sudo etckeeper commit -m 'Name printer and set it as default.'
$ sudo cupsctl --remote-any
$ sudo etckeeper commit -m 'Let local network talk to CUPS.'
$ sudo sed -i \
-e '/^WebInterface /a PreserveJobFiles No' \
/etc/cups/cupsd.conf
$ sudo etckeeper commit -m 'Maybe avoid some disk writes.'
$ sudo systemctl restart cups
On macOS, do not override the generic driver with “HP LaserJet P1006”.
You won’t be able to print (with filter failed
in the server logs), except that every “Supply Levels” check —
including the ones that happen as part of every print job —
will produce a piece of paper containing the single line @PJL INFO SUPPLIES
.
As I understand it, some versions of CUPS have a server bug where it can’t discern whether incoming data has already been filtered for the target queue:
filters converted the data (via application/vnd.cups-raster
) to the printer’s native command set (whatever that might be)… but when the job got sent to the CUPS server it was tagged as application/vnd.cups-raster
rather than, say, application/octet-stream
.
While that discussion is over a decade old, its advice — leave the filtering to the server, and make sure clients don’t do any — has me printing from macOS, iOS, and Windows.
On macOS, add the printer. When it autoselects “Generic PostScript Printer”, leave it (details in sidebar). Print.
On iOS, print.
On Windows, add the printer. Print.
As with any Debian:
$ ssh schleierprint.local -t 'sudo apt update && sudo apt -y upgrade && sudo apt -y autoremove'
To back up /etc
, git push
it someplace trustworthy and private.
I’d rather run NetBSD, but neither 10.0 nor -current brought up HDMI.
I could try writing NetBSD to an SD card, mounting it from another NetBSD system, setting hostname
in rc.conf
, adding a non-root user, and then booting the A64 from it in order to do the rest over ssh
.
(Other systems that also didn’t bring up HDMI, wherefore I landed by trial and error on Armbian: FreeBSD 14, OpenBSD 7.5, Debian 12.)
Since one of my old Sonos speakers can’t be upgraded to AirPlay-compatible firmware, I’m not eager to upgrade the other. Instead, I’ve added AirConnect on the Pine A64 as an AirPlay relay.
Contents of /etc/systemd/system/airupnp.service
:
[Unit]
Description=AirUPnP bridge
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/home/schmonz/bin/airupnp-linux-aarch64-static -l 1000:2000 -N '%%s' -x /home/schmonz/etc/airupnp.xml -Z
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
Contents of /home/schmonz/etc/airupnp.xml
(to omit my UPnP router from the AirPlay list):
<?xml version="1.0"?>
<airupnp>
<device>
<udn>uuid:1e38fc78-51f5-5f5d-9268-50c6b1dc59f8</udn>
<name>Verizon FiOS-G1100 ManageableDevice+</name>
<mac>bb:bb:bb:bb:bb:bb</mac>
<enabled>0</enabled>
</device>
</airupnp>
I’d rather install AirConnect from a system-provided package, but there isn’t one for Debian. Maybe I can puzzle out the AirConnect build system and add it to pkgsrc.
Over on the GNU config-patches mailing list, Zack Weinberg is looking for help identifying a number of ancient operating systems and vendors.
These are probably all either vendor or OS names from the late 1980s or early 1990s. Can anyone help me fill out the following list of things that ought to appear in testsuite/config-sub.data, if I knew what to put in place of the question marks?
???-pc533 ???-pc533-???
↫ Zack Weinberg
???-sim ???-sim-???
???-ultra ???-ultra-???
???-unicom ???-unicom-???
???-acis ???-???-aos
???-triton ???-???-sysv3
???-oss ???-???-sysv3
???-storm-chaos ???-???-???
One of them has already been identified – “storm-chaos” turns out to have been added to binutils and/or maybe GCC in 2000, and after some digging around, John Marshall found what it’s referring to: chaos, a hobby operating system for x86 written in C. It has a long history, and after a period of inactivity came back in 2015 with a new website. Some new releases followed, with the last one being version 0.3.0 in 2019. It’s been silence since then.
The others are still up for grabs to be discovered. There is some talk that the pc533 one might be a misspelling of pc532, which would refer to the “NS32K-based PC532 board running NetBSD”. This is an incredibly obscure complete system built around the NS32532, of which only around 150 were built in the early ’90s. However, Weinberg is hesitant to accept this theory without more information, since there is already code to handle the pc532, and he wants to be sure before making any changes.
If there is one place on the internet outside of the GNU mailing lists that might be able to help Weinberg, it’s the OSNews audience. We have so many older people reading OSNews who have been working or otherwise active in this field for many decades, and I wouldn’t be surprised if these cryptic names make some bells ring for some of you. If one of you does e-mail a reply, be sure to mention this article – organic marketing to help keep us going!
IceWM, the venerable window manager we’ve all used at some point in our lives, has released a new version, 3.5.0. It’s a relatively minor release, so you’ve got things like a new install option which will install an extra theme, a fix for porting to NetBSD 10, translation updates, and more such small improvements. The AddressBar, a command line in the taskbar that can be summoned with ctrl+alt+space
, also got some love, with file argument completion and support for the cd
and pwd
commands.
You can compile IceWM yourself, of course, but it’ll most likely find its way into your distribution’s repository quickly enough.
Michał emailed earlier this year saying he’s been reading a lot about BSD lately, but wanted to know the practical differences between it and Linux.
The Internet is replete with SEO-optimised comparison sites that offer superficial summaries of LLM-generated data laundered from sites like Wikipedia, so I thought I’d address the comparison here with my own experiences running both in production.
All of these are completely factual, with absolutely no subjective invocations of personal experience, jokes, or silliness. Yes, of course. Much of this also applies to NetBSD.
FreeBSD is built, distributed, and updated as a cohesive system, rather than a collection of parts. You can feasibly install it by extracting a tarball onto a new partition. You can also build the kernel and entire userland with a few commands, and perform security audits with reproducible and verifiable builds. Ask Michael Dexter how far he got trying to do the latter on Ubuntu, for example.
FreeBSD is upgraded by rebuilding, or using the binary freebsd-update(8)
tool. Unlike Linux package managers, this doesn’t affect installed packages because…
FreeBSD’s ports system is installed and updated in a separate directory structure from the base system, meaning you can blow away installed ports without affecting the base if you mess something up. I find this so convenient, I run NetBSD’s cross-platform pkgsrc on some Linux servers I administer.
FreeBSD has more permissive licencing, which makes its operation more flexible. The GPL makes distributing OpenZFS difficult on Linux (unless you believe Canonical, oh “snap”?), but FreeBSD can work with the CDDL without issue.
Linux distros are broadly either long-term support (LTS) or rolling releases. Major FreeBSD versions are supported for five years, and are distributed under RELEASE, with STABLE and CURRENT branches for development. Their official names are always IN CAPITALS, for emphasis.
Linux has traditional package managers, Flatpaks, Snaps, AppImages, and so on. FreeBSD used to have a pkg_*
toolchain for binary packages, but pkg(8)
is probably closer to what you’re used to on Linux. Otherwise you can build from the ports tree.
Linux has better fanart than FreeBSD, though OpenBSD’s is even better. I’ll ask Clara if she’d be up for making some.
FreeBSD and Linux differ in how they’re better than Windows Server, but both are a tall glass of cool water (cool glass of tall water) by comparison. No really, I’d take bash(1)
and systemd
over PowerShell and Windows patches at 03:00 any day. Ask me how I know!
Linux has wider software support, owing to its larger install and developer base. FreeBSD has the Linuxulator, but I do keep Alpine Linux and Fedora rattling around at home for specific software. I think the trade-off is more than worth it for the system’s mature tooling, stability, and mascot.
FreeBSD can lag behind Linux in certain desktop drivers, and it has narrower hardware support (official Nvidia drivers always work well, but Wi-Fi and AMD Radeon drivers are spottier). FreeBSD operators tend to be more attractive, modest, intelligent selective with the hardware they use.
FreeBSD comes with a suite of tools that either differ from Linux, or don’t have direct equivalents, like DTrace, Jails, the bhyve hypervisor, and BSD Games. Others may be available, but they have better integrations on FreeBSD, such as Capsicum and ZFS.
This ZFS integration is worth its own point. There’s a misconception its only useful for storing data with integrity. It’s also used in tools like Poudrire to build new ports, as a base for new jails, to permit rolling back base updates, to send/recieve backups, and to tune specific datasets for specific workloads. It handles volume management, formatting, and other tasks. Linux’s closest equivalent is btrfs.
Linux is overseen by Tux, and FreeBSD has the BSD Daemon and Groff the BSD goat, whom I’ve had the pleasure of meeting a few times. He has an adorable hat.
Linux is shorter than FreeBSD and requires fewer invocations of the shift key, but looks less cool. This is likely why the FSF insists on calling the Linux kernel with other tooling GNU/Linux, in spite of popular usage to the contrary, and the fact it’s often not even true. I prefer to call my game desktop install KDE/ZFS/Proton/Linux.
FreeBSD is more “Unix-like” (especially Solaris of late), which may make migrations and experience from old UNIX systems easier. Linux is actively moving away from this, which you either see as “reinventing Unix, poorly”, or removing the shakles of compatibility for further growth.
Even Linux engineer I speak with admit FreeBSD isn’t as susceptible to chasing the shiny. Linux churns through frameworks, ABIs, and tooling like they’re going out of fashion (or when a commercial outfit baits-and-switches their community, as always happens). FreeBSD is more conservative with what it introduces, and supports them for longer. With its smaller developer base, it doesn’t have a choice.
There’s a wider debate about the influence large companies have on Linux, which is used to push changes that other distributions must integrate lest they lose broader Linux ecosystem compatibility. Then again, FreeBSD has large users like Netflix and Sony that I’m sure also wield influence.
I’ve pointed out the similarities between the systems to encourage Linux people to give FreeBSD a try, but I hope this explains more of the differences. I happen to think FreeBSD is better for most things, but as with any tool, you should evaluate it based on your use case and requirements. That won’t satiate those looking for a flamewar, but it’s fact.
The Handbook and FreeBSD Foundation have more resources, and Klara Systems have an excellent series of articles that go into more technical detail about differences and migration paths.
My attitude is that if you’re interested, give it a try! There’s a lot to like, and even if you come away from it thinking it’s not for you, the only thing you’ve lost are your Linux blinkers. You don’t need to justify or make excuses for curiosity.
By Ruben Schade in Sydney, 2024-05-26.
Windows Server 2025 comes equipped with dtrace as a native tool. DTrace is a command-line utility that enables users to monitor and troubleshoot their system’s performance in real-time. DTrace allows users to dynamically instrument both the kernel and user-space code without any need to modify the code itself. This versatile tool supports a range of data collection and analysis techniques, such as aggregations, histograms, and tracing of user-level events. To learn more, see DTrace for command line help and DTrace on Windows for additional capabilities.
↫ What’s new in Windows Server 2025
DTrace was originally developed by Sun as part of Solaris, but eventually made its way to other operating systems as Sun collapsed in on itself and Oracle gave it the final push. DTrace is available for the various surviving Solars-based operating systems, Linux, FreeBSD, NetBSD, macOS, and QNX, and Microsoft ported DTrace from FreeBSD to Windows back in 2018. With Windows Server 2025, DTrace will be shipped out of the box.
The NetBSD Project is pleased to announce NetBSD 8.3, the third and final release from the NetBSD 8 stable branch.
It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 8.2 in March 2020, as well as some enhancements backported from the development branch. It is fully compatible with NetBSD 8.0.
This also represents the end-of-life for the netbsd-8 release branch. No further security updates will happen. Users running 8.2 or an earlier release are strongly recommended to upgrade to a newer branch, preferably the recent NetBSD 10.0 release.
Pkgsrc has already desupported the netbsd-8 branch.
See the full release announcement (including download links).
My early imaginings of a collaborative Open Source successor to qmail, let me assure you, did not include going nearly four years between releases. Well, at least it hasn’t been more than four. notqmail 1.09 is here:
For decades, due to each administrator needing to patch in their particular missing bits of functionality, the qmail source code itself has effectively been a public API. Some future release of notqmail will include everything most everyone needs. On that day, we’ll freely make desirable code changes without worrying about breaking people’s patches. On that day, notqmail will have become a relatively normal software project operating under relatively normal constraints.
This is not that day. notqmail remains a uniquely challenging legacy-code rehabilitation project, and 1.09 is merely a solid, long-overdue release that includes the work of a couple dozen new contributors.
Since this release took too long, our next development cycle will be
In legacy code, every time we can turn a vicious cycle virtuous, it’s a big win. By making the code easier and safer to change, we’ll have more fun; by having more fun, we’ll make more progress; by making more progress, we’ll get more feedback; by getting more feedback, we’ll have more fun; and so on.
Have fun with notqmail 1.09! Let us know how the upgrade goes for you. (I’ll be updating the pkgsrc package soon.) And if getting involved is your kind of thing, please feel welcome to join us.
I am trying to use OpenVPN as a client under NetBSD using this command:
openvpn --client --config /etc/openvpn/config.ovpn
I am getting the following output and errors:
localhost# openvpn --client --config /etc/openvpn/openvpn.ovpn
2024-04-26 10:29:35 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2024-04-26 10:29:35 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2024-04-26 10:29:35 OpenVPN 2.6.10 x86_64--netbsd [SSL (OpenSSL)] [LZO] [LZ4] [MH/PKTINFO] [AEAD]
2024-04-26 10:29:35 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10
Enter Auth Username:********
Enter Auth Password:********
2024-04-26 10:32:48 TCP/UDP: Preserving recently used remote address: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 Socket Buffers: R=[32768->32768] S=[32768->32768]
2024-04-26 10:32:48 Attempting to establish TCP connection with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCP connection established with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCPv4_CLIENT link local: (not bound)
2024-04-26 10:32:48 TCPv4_CLIENT link remote: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2024-04-26 10:32:48 TLS: Initial packet from [AF_INET]**.191.33.**:1701, sid=0006909e 9b0d208f
2024-04-26 10:32:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2024-04-26 10:32:48 VERIFY OK: depth=1, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_CA, CN=UniFi_OpenVPN_CA
2024-04-26 10:32:48 VERIFY KU OK
2024-04-26 10:32:48 Validating certificate extended key usage
2024-04-26 10:32:48 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-04-26 10:32:48 VERIFY EKU OK
2024-04-26 10:32:48 VERIFY OK: depth=0, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_Server, CN=UniFi_OpenVPN_Server
2024-04-26 10:33:53 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2024-04-26 10:33:53 [UniFi_OpenVPN_Server] Peer Connection Initiated with [AF_INET]**.191.33.**:1701
2024-04-26 10:33:53 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-04-26 10:33:53 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-04-26 10:33:53 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.7.1,route 192.168.4.0 255.255.255.0,route 192.168.2.0 255.255.255.0,route 192.168.1.0 255.255.255.0,route 192.168.3.0 255.255.255.0,route-gateway 192.168.7.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.7.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2024-04-26 10:33:53 OPTIONS IMPORT: --ifconfig/up options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route-related options modified
2024-04-26 10:33:53 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-04-26 10:33:53 TUN/TAP device /dev/tun0 opened
2024-04-26 10:33:53 /sbin/ifconfig tun0 192.168.7.2 192.168.7.1 mtu 1500 netmask 255.255.255.0 up
2024-04-26 10:33:53 /sbin/route add -net 192.168.7.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.7.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net **.191.33.** 192.168.1.254 -netmask 255.255.255.255
route: writing to routing socket: File exists
add net **.191.33.**: gateway 192.168.1.254: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 0.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 0.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 128.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 128.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.4.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.4.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.2.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.2.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.1.0 192.168.7.1 -netmask 255.255.255.0
route: writing to routing socket: File exists
add net 192.168.1.0: gateway 192.168.7.1: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 192.168.3.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.3.0: gateway 192.168.7.1
2024-04-26 10:33:53 GID set to nogroup
2024-04-26 10:33:53 UID set to nobody
2024-04-26 10:33:53 Initialization Sequence Completed
2024-04-26 10:33:53 Data Channel: cipher 'AES-256-GCM', peer-id: 0, compression: 'lzo'
2024-04-26 10:33:53 Timers: ping 10, ping-restart 60
I have a working internet connection when running OpenVPN as a client, but I can't access any of the machines on the network **.191.33.**
, I know I should be able to SSH into 192.168.1.114, but I can't reach that machine through OpenVPN, there are firewall rules in the Ubuiquity box allowing traffic from 192.168.7.* to 192.168.1.* I know this is working, its testet from Mac and PC using the OpenVPN Client, I just can't get it to work on NetBSD
This is my routing table before running OpenVPN:
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 192.168.1.254 UGS - - - iwn0
127/8 127.0.0.1 UGRS - - 33624 lo0
127.0.0.1 lo0 UHl - - 33624 lo0
192.168.1/24 link#2 UC - - - iwn0
192.168.1.68 link#2 UHl - - - lo0
192.168.1.254 00:1e:80:a2:2e:ff UHL - - - iwn0
This is my routing table when running OpenVPN:
Internet:
Destination Gateway Flags Refs Use Mtu Interface
0/1 192.168.7.1 UGS - - - tun0
default 192.168.1.254 UGS - - - iwn0
**.191.33.**/32 192.168.1.254 UGS - - - iwn0
127/8 127.0.0.1 UGRS - - 33624 lo0
127.0.0.1 lo0 UHl - - 33624 lo0
128/1 192.168.7.1 UGS - - - tun0
192.168.1/24 link#2 UC - - - iwn0
192.168.1.68 link#2 UHl - - - lo0
192.168.2/24 192.168.7.1 UGS - - - tun0
192.168.3/24 192.168.7.1 UGS - - - tun0
192.168.4/24 192.168.7.1 UGS - - - tun0
192.168.7/24 192.168.7.1 UGS - - - tun0
192.168.7.1 192.168.7.2 UH - - - tun0
192.168.7.2 tun0 UHl - - - lo0
192.168.1.254 00:1e:80:a2:2e:ff UHL - - - iwn0
This is my routing table after stopping OpenVPN:
Internet:
Destination Gateway Flags Refs Use Mtu Interface
0/1 192.168.7.1 UGS - - - tun0
default 192.168.1.254 UGS - - - iwn0
**.191.33.**/32 192.168.1.254 UGS - - - iwn0
127/8 127.0.0.1 UGRS - - 33624 lo0
127.0.0.1 lo0 UHl - - 33624 lo0
128/1 192.168.7.1 UGS - - - tun0
192.168.1/24 link#2 UC - - - iwn0
192.168.1.68 link#2 UHl - - - lo0
192.168.2/24 192.168.7.1 UGS - - - tun0
192.168.3/24 192.168.7.1 UGS - - - tun0
192.168.4/24 192.168.7.1 UGS - - - tun0
192.168.7/24 192.168.7.1 UGS - - - tun0
192.168.7.2 tun0 UHl - - - lo0
192.168.1.254 00:1e:80:a2:2e:ff UHL - - - iwn0
This is my routing table when i have destroyed tun0:
ifconfig tun0 destroy
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 192.168.1.254 UGS - - - iwn0
**.191.33.**/32 192.168.1.254 UGS - - - iwn0
127/8 127.0.0.1 UGRS - - 33624 lo0
127.0.0.1 lo0 UHl - - 33624 lo0
192.168.1/24 link#2 UC - - - iwn0
192.168.1.68 link#2 UHl - - - lo0
192.168.1.254 00:1e:80:a2:2e:ff UHL - - - iwn0
The route to **.191.33.**
is still there when stopping OpenVPN and destroying the tunnel tun0, I don't know if this is expected behaviour.
Update I have checked several computers now, and none of them have the 192.168.1/24 route, its only on the PC running NetBSD, I have tried to delete it, with no success. I have also read a lot of man pages and various other documentation, but I have not come up with anything usefull yet.
OpenVPN Config
client
dev tun
proto tcp
remote **.191.33.** 1701
resolv-retry infinite
nobind
# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup
persist-key
persist-tun
auth-user-pass
remote-cert-tls server
cipher AES-256-CBC
comp-lzo
verb 3
auth SHA1
key-direction 1
reneg-sec 0
redirect-gateway def1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
Intent
I am trying to connect to a VPN at a remote location, from home. The remote network is protected by a firewall facing the internet, all computers on the network behind the router is accessible, the 192.168.7.* network is standard Ubuiquity and used for VPN clients, I have added a firewall rule to allow traffic from 192.168.7.* to the 192.168.1.* network, this works fine from all computers I have tried it with, Mac, PC, Windows, Linux, MacOS. etc. except a PC running NetBSD.
The network configuration on the PC running NetBSD was performed during installation, and I used the auto-configuration feature, so I have not specified any networks, routes or rules at all. I am able to access the internet when using OpenVPN client, I just cannot access any of the machines on the remote network. So I guess the part I am missing is the routing from 192.168.7.* to 192.168.1.* so I will be able to access computers attached to that network
A few years ago, I wrote a "state of things" blog post about Wayland on NetBSD. It's only natural that I should do one about X11, which is used by far more people to get a graphical environment on NetBSD.
There are a lot of differences from how NetBSD and the typical distributor ship X.Org. For one, we ship it as an optional monolithic package rather than separate individual packages. This means every driver is included on every system, rather than as an optional module. Sometimes, this means we need to fine-tune driver selection to ensure the correct drivers are loaded on the correct hardware, since multiple conflicting drivers can claim a video output. We also want sensible fallbacks, since if you're using a GPU from the future with an old OS version, you probably want X to seamlessly fall back to a regular framebuffer.
Secondly, the way our "xsrc" repository is set up, it's effectively functioning as a fork of X.Org that regularly pulls from upstream freedesktop.org (but does not push back). This allows X development to happen as part of NetBSD.
Thirdly, we use our own build system based purely on BSD makefiles, not X.Org's based on GNU autotools. This fits well with our build.sh cross-compilation system.
We have a number of drivers which have not made their way upstream. Perhaps the most ubiquitous of these is xf86-input-ws, a driver which came from OpenBSD, targets an API from NetBSD, and continues to be developed in both. This is a generic input driver that can support any pointing device that the kernel supports. Unlike xf86-input-mouse, it doesn't assume the device is a mouse, and can support advanced touchpad and touchscreen features. Other NetBSD exclusives include xf86-video-pnozz, xf86-video-mgx, and xf86-video-crime. While these all share the "xf86" name inherited from the historical XFree86 distribution, none of them are exclusively for x86.
There are a number of drivers that are accelerated when used in NetBSD, but the acceleration support is missing upstream. This is mostly due to the work of macallan@, who has diligently worked on drivers for accelerators found on SPARC and PowerPC hardware.
X.Org has historically supported two 2D acceleration modes, XAA and EXA. XAA seems complicated - according to the X.Org Foundation it supports accelerating "patterned fills and Bresenham lines" (eh?). XAA was removed from the X.Org server in 2012, and many old drivers were not updated to support the newer and simpler EXA model, except in NetBSD, over a time period of several years.
Did you know that Nvidia used to have an open source graphics driver? It supported 2D acceleration for a range of cards. In NetBSD, it's retained for platforms that included embedded Nvidia chips and aren't capable of (or predate, or don't want) the modern novueau driver. Six years ago, it was updated in NetBSD to support EXA acceleration.
There are a few ways our X integration could be improved. While lots of attention has been paid to the server, less has been paid to clients (programs). Did you know that X includes a text editor, and that text editor supports syntax highlighting and spell checking?
NetBSD includes its own command-line spell checker and associated dictionaries, spell(1), inherited from the BSD UNIX of yore. It's pretty basic, and only supports variations of English. To get spell checking to work in xedit, you need to install ispell (another command-line spell checker) from pkgsrc, install a dictionary, then set some Xresources (or create symlinks) to make sure xedit finds ispell. This could surely be streamlined by teaching xedit about spell.
We also ship every program that has been included with historical X.Org distributions. This includes well-known things like xterm, slightly less well-known things like xbiff(1), and obscurities like bitmap(1) (apparently a 1-bit-per-pixel alternative to MS Paint). A while ago, we removed some libraries which are no longer used by the modern X server, and maybe we should evaluate whether we need all of these programs too. xmh(1) is a frontend for a mail system that isn't included in base. Together, bitmap and xmh are around 300 kilobytes.
We include fonts, bitmaps and scalable, for a wide range of computing devices. In the latest versions of NetBSD, the font size will automatically scale with the screen size to support HiDPI displays as well as small mobile devices. However, we don't ship a scalable cursor theme at the moment. We're also missing high-resolution fonts for Japanese, a shame considering the popularity of NetBSD in Japan. Koruri looks interesting and is suitably small, maybe we should import it.
While we have many useful simple programs by default (a clock, a calculator, an editor, a window manager, a compositor, a terminal emulator...), we're notably missing a screen locking program for X in the default install, although we have lock(1) for the tty.
The big question - does all this have a future? The good news is that all new hardware has generic support in X. Someone writes either a modesetting kernel driver or a classical wsdisplay kernel driver and they will be automatically supported by the associated drivers in X. The bad news is that to have applications running we require access to a larger open source ecosystem, and that ecosystem has a lot of churn and is easily distracted by shiny new squirrels. The process of upstreaming stuff to X.Org is an ongoing process, but it's likely we'll run into things that will never be suitable for upstream.
Of course, on NetBSD, you also have the option of trying vanilla modular X.Org from pkgsrc, or using something else entirely.
The NetBSD Project is pleased to announce NetBSD 9.4, the fourth release from the NetBSD 9 stable branch.
It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.3 in August 2022, as well as some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0. Users running 9.3 or an earlier release are strongly recommended to upgrade.
The general NetBSD community is very excited about NetBSD 10.0, the latest NetBSD release, but if for some reason you can not (or do not want to) update to 10.0, it is strongly recommended to update to 9.4. This is especially true for users still using a NetBSD 8.x release as that old release branch will be desupported by the end of April 2024.
If you sorta squint and tilt your head, it’s a games theme this week.
Your unrelated music for the week: New Strategies for Modern Crime Vol 1. (via)
I am trying to write a driver for NetBSD that will reserve 10 pages of virtual memory, then provide the first 5 pages with physical addresses. At the end, I output the page number, its physical address, and flags such as Valid, User and Modified. However, it seems to me that the flags are not working correctly, since for all pages, all flags have the same value, which is 1 (true). Please help me figure out what I'm doing wrong.
#include <sys/cdefs.h>
#include <sys/module.h>
#include <sys/param.h>
#include <sys/sysctl.h>
#include <uvm/uvm.h>
MODULE(MODULE_CLASS_MISC, driver, NULL);
#define PAGESIZE 0x1000
extern paddr_t avail_end;
vaddr_t va;
struct pglist plist;
static int lab4_modcmd(modcmd_t cmd, void* arg) {
va = uvm_km_alloc(kernel_map, PAGESIZE*10, 0, UVM_KMF_VAONLY);
if (va == 0) {
return 0;
}
int error = uvm_pglistalloc(PAGESIZE*5, 0, avail_end, 0, 0, &plist, 5, 0);
if (!error) printf ("LAB4 loaded\n");
struct vm_page *page = TAILQ_FIRST(&plist);
for(int i = 0; page; i++) {
pd_entry_t *ppte;
ppte = L2_BASE+pl2_i(va+PAGESIZE*i);
paddr_t pa = VM_PAGE_TO_PHYS(page);
printf("Page - %d\n", i+1);
printf("Valid - %d\n", ((*ppte & PG_V) ? 1 : 0));
printf("Used - %d\n", ((*ppte & PG_U) ? 1 : 0));
printf("Modified - %d\n", ((*ppte & PG_M) ? 1 : 0));
printf("Physical address - 0x%lx\n", pa);
printf("\n");
page = TAILQ_NEXT(page, pageq.queue);
}
uvm_pglistfree(&plist);
uvm_km_free(kernel_map, va, PAGESIZE*10, UVM_KMF_VAONLY);
return 0;
}
I tried to look for other examples where these flags are used.
I have the following code that produces a window with a QTableView visible. I add a QTextEdit to the right but hide it. When I run the code it looks as though space has been reserved on the right for the TextEdit even though the TableView has a setSizePolicy of Expanding. What do I need to set so that the TableView initially takes up all the space in the window, then shrinks to accommodate the TextEdit and then expands fully when the TextEdit is hidden? Thank you in advance.
import sys
from PyQt5.QtWidgets import QApplication, QGridLayout, QMainWindow, QPushButton
from PyQt5.QtWidgets import QSizePolicy, QTableView, QTextEdit, QWidget
class MainWindow(QMainWindow):
# https://www.pythonguis.com/faq/file-image-browser-app-with-thumbnails/
def runBtn(self):
#https://www.youtube.com/watch?v=LCJEyuCZlAY
if self.hdn == True:
self.text.show()
self.hdn = False
else:
self.text.hide()
self.hdn=True
def __init__(self):
super().__init__()
widget = QWidget()
self.setCentralWidget(widget)
self.layout = QGridLayout(widget)
self.hdn = True
self.Btn = QPushButton('Hide/Show',self)
self.Btn.clicked.connect(self.runBtn)
self.layout.addWidget(self.Btn, 0, 0, 1, 1)
self.view = QTableView()
self.layout.addWidget(self.view, 1, 0, 48, 50)
self.view.setSizePolicy(QSizePolicy.Expanding, QSizePolicy.Expanding) # /73522221/
self.text = QTextEdit()
self.text.hide()
self.layout.addWidget(self.text, 1, 50, 48, 2)
app = QApplication(sys.argv)
window = MainWindow()
window.show()
app.exec_()
A few weeks ago, Apple released new versions of Xcode and Command Line Tools. Not thinking too hard about how my pkgsrc developer environment often gets broken by OS or tool updates, I updated promptly. For one thing, I’m kinda used to it. For another, it doesn’t usually break. For a third thing, managing dependencies — anything not my code that can break my code — means responsibility for dealing with the inevitable trouble, and therefore the sooner I find it the better. (More on my approach to life with dependencies.)
A vendor-provided toolchain is a significant dependency.
So I accepted the Command Line Tools update, and it commandeered my spare time for two weeks as I hurried carefully to repair
one of the world’s biggest continuous-integration cauldrons
on
one of its most popular platforms.
When I ran my usual pkg_rolling-replace -suv
to rebuild anything outdated, it did not go well at all.
This article uses “we” because the continued smooth operation of pkgsrc on macOS reflects the contributions of many developers on many occasions, including this one: I happened to be first on the scene, but several of us of were discussing the problems and potential workarounds and all of “my” commits were adjusted accordingly.
Did I mention that a few weeks ago we were aiming to stabilize for yesterday’s quarterly release? Suddenly, if we didn’t scramble to straighten things out for macOS users, we’d have to manage a complicated situation for a while. But if we created a mess on other platforms by moving rashly, that’d be even worse.
The usual feedback mechanism for proposed infrastructure changes is to compare full bulk builds before and after. There was no time for that.
Happily, the conclusion of the story is boring: as always, the pkgsrc 2024Q1 stable branch supports macOS and its developer tools, including the latest releases of each. (So does -current pkgsrc, of course, if that’s your thing.)
Curious what we had to do to keep it boring? Read on.
clang
defaultsUpstream Clang 16 and GCC 14 have promoted several warnings to errors by default, and Apple’s Clang 15 has followed suit. (Gentoo has very helpfully documented this for packagers.) These changes are intentional and well-intentioned, pushing maintainers to ship more reliable code. But pkgsrc’s job is to build nearly 30,000 codebases we don’t maintain. And stricter compiler defaults break a lot of builds.
As you might hope, we can make the breakage go away in one place.
In pkgsrc, packages declare which programming languages are required for their build. The compiler framework then selects package-and-platform-appropriate compilers, places them preferentially in the package’s build environment, and — crucially — intercepts compiler invocations and rewrites them for a variety of purposes.
When we look into pkgsrc’s clang
logic, we find prior art for this specific class of problem.
In September 2020, Xcode 12 (and its associated Command Line Tools) arrived even later in our quarterly schedule and promoted -Wimplicit-function-declaration
to an error.
The surgical fix: on macOS only, if invoking clang
reveals the new stricter default, we
pass -Wno-error=implicit-function-declaration
to demote the error back to a warning.
Apple Clang 15’s new strictures aren’t observable in the same way, so we adjust our workaround:
if clang
doesn’t complain when we try demoting the new errors back to warnings, we
pass those arguments too,
via the same compiler-framework mechanism.
m4
and yacc
This messy regression found only in the Command Line Tools 15.3.0.0.1.1708646388 update — not in the corresponding full Xcode 15.3 (build 15E204a) update — must have been unintended.
On macOS, some of the familiar Unix tools in /usr/bin
are in fact stubs.
When invoked, they either execute into the corresponding installed program (living somewhere under /Library/Developer
) or prompt the user to install the Command Line Tools.
This Command Line Tools update uninstalls m4
and yacc
from /Library/Developer
.
But since the OS-provided /usr/bin/m4
and /usr/bin/yacc
stubs still exist, running m4
or yacc
still does something:
it pops up a window prompting you to reinstall the CLT.
Unfortunately, as the latest available version doesn’t provide those tools, reinstalling is a waste of time.
As you might once again hope, we can hide the problem without personally visiting 29,000+ packages.
In pkgsrc, we also have a framework to control which non-compiler tools are invoked during builds. Packages declare which tools are required for their build. The tools framework then selects package-and-platform-appropriate incarnations of the declared tools and places them preferentially in the package’s build environment.
We just got handed a few new twists to handle in the framework, is all.
First, because this clever new CLT failure mode outfoxes our usual tool-detection mechanism, we special-case m4
and yacc
detection on macOS, performing an
existence check for the stubs’ targets.
Then the selection mechanism’s usual fallback logic can provide them some other way.
This prevents the primary source of needless CLT install popups.
For non-macOS platforms, no change.
Second, because some packages might not yet be declaring all their tool dependencies, we special-case m4
and yacc
handling on macOS:
when they’re not declared, we
place them in the build environment anyway,
as no-ops.
If the package build happens to invoke them, nothing happens.
This prevents the secondary source of needless CLT install popups, at the risk of breaking macOS builds for packages that are missing these tool declarations and have heretofore gotten lucky;
in such cases, the breakage will be obvious and the fix easy.
For non-macOS platforms, no change.
(At leisure, we might like to broaden this approach to help find and fix all undeclared tools on all platforms.)
Third, because the flex
tool expects to invoke a GNU-compatible m4
, we adjust the tools framework to
infer gm4
from a flex
declaration
so that the framework controls which m4
gets found.
This more correctly expresses our intent on all platforms, and in the macOS package build environment it restores /usr/bin/flex
to a working state.
xcrun
searchWe were already relying on xcrun
for a couple of things, so when our new tool-detection special cases were sometimes getting surprising results from it, that was concerning.
Turns out xcrun
no longer looks solely in Apple-controlled locations, but also consults the environment’s $PATH
.
By
invoking xcrun
with an empty PATH
and --no-cache
,
we obtain controlled, predictable tool detection.
Under the constraints, we changed as little as possible, as safely as possible, as similarly as possible to previous proven changes, avoiding novel constructs or any whiff of unforeseen consequences. We could not have done nearly as safe or thorough a job without good abstractions already in place. Total lines of pkgsrc infrastructure code changed: less than 100. Now that 2024Q1 is out, we have room to refactor.
These 15.3 updates also include a brand new linker. So far it hasn’t given us any trouble. If that changes, wanna guess whether we have one place to take care of it?
This is the ninth post in my toolchains adventures series. Please check the previous posts in the toolchains category for more context about this journey. There was no Q4 2023 report as there wasn't really anything worthwhile to write about.
I've been taking a break from Pkgsrc to only focus on OpenBSD at this point, for which I updated binutils to version 2.42 in the ports tree.
During this OpenBSD release cycle, the remaining parts required to get pinsyscalls(2) working have been committed, and I added support upstream for the PT_OPENBSD_SYSCALLS segment type to readelf in GNU Binutils, as well as in LLVM versions of objdump and readobj.
Lastly, I also wrote a blog post about Speedbuilding LLVM/Clang in 3 minutes on Power10.
As usual, I’ve also been busy reading different material, and adding new resources to toolchains.net.
binutils commits:
2024-02-12 | d86205c | Add support to readelf for the PT_OPENBSD_SYSCALLS segment type |
LLVM commits
2024-02-20 | a8d7511 | [llvm-readobj] Add support for the PT_OPENBSD_SYSCALLS segment type |
2024-02-20 | 1b89486 | [llvm-objdump] Add support for the PT_OPENBSD_SYSCALLS segment type |
2024-02-17 | 97eff26 | [Support/ELF] Add OpenBSD PT_OPENBSD_SYSCALLS constant |
2024-02-10 | d2e4a72 | [clang] Update Clang version from 18 to 19 in scan-build.1 |
The NetBSD project is pleased to announce the eighteenth major release of the NetBSD operating system
NetBSD 10.0!
See the release announcement for details.
The netbsd-10 release branch is more than a year old now, so it is high time the 10.0 release makes it to the front stage. This matches the long time it took for the development branch to get ready for branching, a lot of development went into this new release.
This also caused the release announcement to be one of the longest we ever did.
If you want to try NetBSD 10.0 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.
If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.
Recently, a backdoor was discovered in the xz compression library. xz/liblzma are included as a part of NetBSD and used by the project for distribution of new releases and packages.
The version of xz shipped in all stable (and unstable) versions of NetBSD predates any code changes by the author of the backdoor. NetBSD is therefore safe and unaffected by the recent discoveries. It is believed that the attack only targets Linux/glibc, but checking this allowed us to rule out any other attempts at compromising the library by the author.
The version of xz shipped in pkgsrc, however, is affected. Using xz from pkgsrc is a non-default setting on NetBSD, and requires explicit opt-in. Most users of NetBSD will not install xz from pkgsrc because the version from the base system is preferred. However, users of pkgsrc on other platforms will need to take precautions.
Regardless of NetBSD being affected or not, the discovery of the backdoor is a wake-up call and further discussion will be happening internally over how to proceed.
I'm debugging the NetBSD kernel with gdb
, but I would like to be able to display information about the memory region an address is in. I'm mainly interested in finding out the permissions of a page of memory, along with the size of the region it is enclosed in (if the latter part of that question makes sense).
Does the kernel have a concept of memory regions in kernel space? i.e. a contiguous block of pages (virtual addresses) reserved for a specific purpose (which is kept track of somewhere)? Or is it down to each specific module to keep track of which blocks of memory belong to a logical group?
Here's an example of what I'm looking for:
(gdb) addressinfo 0xffffffff80e1000
Start End Offset Perm Size
0xffffffff80e0000 0xffffffff80e2000 0x1000 r--p 0x2000
I don't mind adding a hook to the kernel for a GDB script to output this information, if this functionality does not exist. At the minimum it would be useful to add a hook for GDB scripts to view the page permissions.
Command line / history is I guess the mini-theme.