The father by Florian Zeller. A punch in the face, it is rare to see a film that is so difficult to watch. But for a good reason, that it is superbly interpreted and admirably orchestrated.
FreeBSD on RaspberryPi
You may have heard that ARM64 is now a tier-1 platform on FreeBSD 13. This basically means that this platform is now fully supported by the various FreeBSD teams. Seeing ARM supported as a tier 1 is really cool, since we can now play around with those ARM boards (RaspberryPi, BeagleBone, …) that were so far reserved to a selected set of Linux distributions. Being able to use an entirely different OS is refreshing.
In the last few weeks, I’ve devoted some of the very little free time that I have to try just that. I’ve installed FreeBSD on some RPi3 boards in the hope of replacing whatever they were doing before on Raspbian. If you insist you can use the video, but it’s very slow and totally unusable as a Kodi media-center. The reason being (as far as I understand) that the VideoCore drivers are a pain in the ass to port even from RPi Linux flavor to another, let alone on FreeBSD. So I wouldn’t expect improvement on that front for some time.
However as a network appliance or audio-only media-center, it works nicely. It’s just a matter of downloading the appropriate SD card image for your specific board (here and there), dd
it to the SD card, boot with HDMI and USB keyboard, then configure your installation from there. Beware though, you should avoid editing the UFS partition of the image until it has been resized by growfs_enable=YES
. In my case that triggered some naughty kernel panics (which I had no time to investigate thoroughly, oops).
I’ve also tried some unsupported platform such as the NanoPi R2S with mitigated success. I managed to boot on the serial interface and install some packages. But USB devices are not (or not always) showing, the driver for the second Ethernet interface is missing, and random kernel panics do happen. So I gave up for now and tried an RPi3 board instead.
I also tried running it on a RaspberryPi 1 B+ v1.2. The reason I’m trying that is to replace my media-center setup, especially the audio part. The RPi1 should consume less power, is perfectly capable for the task at hand and I’ve got a lot of them lying around. Since the device will be always on, it should be a perfect replacement for the RPi3 I used so far. For this I had to use the RPi-B image. Contrary to the RPi3 which runs ARMv8 64-bit, RPi1 B+ is still an ARMv6 32-bit architecture and a tier-2 platform on FreeBSD.
One of the problem with the RaspberryPi is that there are a lot of different version nowadays and they all share similar names. For instance if you say RPi B+, is it RPi3 B+ from 2018, RPi1 B+ from 2014, a confusion with the RPi2 B v1.2 from 2016 or the RPi2 B? All these run on different SoC with different flavor of ARM from ARMv6 to ARMv8. You must pay attention to choose the correct image for your board. Use the Wikipedia’s RaspberryPi page to tell them apart, it’s very complete, especially the Specifications and Connectors sections.
ioctl mem-alloc FAILED
If while trying to play a video on the RaspberryPi, in particular with Kodi, the video doesn’t play and you get this error on the terminal:
[CGPUMEM]: ioctl mem-alloc FAILED [-1]
Then hopefully this post will help you.
You may have read elsewhere that you should increase your GPU memory in /boot/config.txt
, then add gpu_mem=256
.
But that’s not enough. You also need to increase the limit of the contiguous memory allocator. In /boot/cmdline.txt
add the option cma=256M
. Then reboot and you should be fine.
App. freezing in i3
If you encounter some applications freezing or taking a long time to start while using i3, I think in particular about Skype, Discord, CMST (Connman QT GUI), Hexchat, … then may be here is a solution for you. Those app do not appreciate when the desktop does not have any notification daemon running. So you might just install and start one when i3 starts.
So I’ve just installed lxqt-notificationd. Then you can start it from i3’s config file:
exec --no-startup-id lxqt-notificationd
Now all my applications work like a charm, and I’ve no reason whatsoever to temporarily switch to XFCE4.
Clear zpool property
If you want to clear a zfs property, you will often be told to use inherit to instead just inherit the value from the parent dataset. But what if you want to clear a zpool property instead? The answer is simple but you got to know it.
Here I put the ''
to emphasize the fact that it’s a pure empty space. that is, if you want to clear the property, there is nothing after ‘=’.
zpool set <property>='' <pool>
Replace USB boot key on FreeNAS
You don’t really install FreeNAS as you do with some other OS. Instead you have a device (often an USB key) that boots FreeNAS which itself manages your data storage. Indeed why wasting some precious SATA port for a boot device when all you need is a little USB key? Especially when thits boot device is less than 2GB in size.
The problem with USB keys is that they wear out over time. So it inevitably comes a time when it must be replaced. This is what happened to me a few days ago.
The freenas-boot pool switched to a DEGRADED state because checksum error happened too frequently. Fortunately a zpool scrub freenas-boot detected no error, and it seems that zfs was still able to correct those. So instead of reflashing a new USB key and restoring my config backup, I could from FreeNAS itself create a new bootable USB key and replace replace the faulty device in the freenas-boot pool.
Let’s login on FreeNAS and plug in your new USB key. We first find and verify what is the device name for the USB key, in my case it’s da2:
$ gpart part show da2 => 1 60088319 da2 MBR (29G) 1 31 - free - (16K) 32 60088288 1 fat32lba (29G)
You see that MBR table and a FAT32 partition, in my case it can only be the new USB key. We will replace that with GPT partitions. This will contain a boot partition (MBR boot or EFI boot), and a ZFS partition. As root:
# Clean that MBR and create GPT partition table gpart destroy -F da2 gpart create -s GPT da2 # If you use MBR boot gpart add -s 64K -t freebsd-boot da2 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da2 # If you use EFI boot gpart add -s 128M -t efi da2 gpart bootcode -p /boot/boot1.efifat -i 1 da2 # Create the ZFS partition gpart add -t freebsd-zfs da2
Now it’s time to replace the device:
$ zpool replace -f freenas-boot da1p2 da2p2 cannot replace da1p2 with da2p2: device is too small # OOPS! :(
If you got the message device is too small, that is because you’ve been trying to replace a device with another one that is smaller than the original (in term of ZFS partition size I suppose). ZFS requires that you replace a device with another with a size greater or equal to the old one. This can be a problem especially if you have a ZFS partition along with others in the partition table like here, or if the vendor announces a certain disk size but only within a certain approximation. You could result in a disk announced to be the exact same size ending up to be very slighty shorter than your original disk. And as a result you won’t be able to use it to replace any disk in your ZFS pool/vdev. That’s why some recommend to create ZFS filesystems several percents less than the available disk size.
But since we messed up, instead we will create a pool on the other USB key and use ZFS send/recv to migrate the files.
# Create the pool on the new USB key. # Note that we have to call it freenas-boot2 # because freenas-boot already exists. zpool create freenas-boot2 da2p2 # Create a recursive snapshot of the original pool # that we will use to restore the backup. zfs snapshot -r freenas-boot@restore # Send the snapshot from the old to the new USB key. zfs send -R freenas-boot@restore | zfs recv -F freenas-boot2
We also need to save the original setting for bootfs because FreeNAS has its own way of managing the boot pool. We will set this value later on the new pool.
$ zpool get bootfs NAME PROPERTY VALUE SOURCE freenas-boot bootfs freenas-boot/ROOT/11.3-U4.1 local
We still have to change that name from freenas-boot2 to freenas-boot. However we cannot do so on the running instance of FreeNAS because it already has a pool named freenas-boot. So, we will import it on another ZFS capable machine and fix its name.
(but if anyone knows how to do this live, I’m interested)
# On some other ZFS capable host (FreeBSD for instance ;) ) # import the pool and change its name back to freenas-boot. # The -f is required because it comes from another host. zpool import -f freenas-boot2 freenas-boot # Configure default boot filesystem. # Remember the value of bootfs we found before on the original pool. zpool set bootfs=freenas-boot/ROOT/11.3-U4.1 freenas-boot # Export the pool again. zpool export freenas-boot
Finally you can clear the old snapshot:
zfs destroy -R freebsd-boot@restore
Faster Intel graphics on FreeBSD
If you have a laptop with an Intel graphic card and architecture above Sandy Bridge (circa 2011), you can accelerate xorg significantly with this little hack. Create the file /usr/local/etc/X11/xorg.conf.d/intel.conf
:
Section "Device" Identifier "Intel Graphics" Driver "Intel" Option "AccelMethod" "sna" EndSection
See the manpage intel.4. It seems that the version of xf86-video-intel on FreeBSD falls back to the UXA acceleration method but forcing SNA provided good results on my ThinkPad X250.
Beid card reader on FreeBSD
So I’ve got to fill in my taxes, and to do this in Belgium, we need to use our ID card. Well we can use a phone app too, but to use this app we have to register… using our ID card… ¯\_(ツ)_/¯
Last time I tested, this didn’t work well on FreeBSD, but I didn’t look too much into it and perhaps things changed since then. Also, like always, I refuse to do this on another OS where I know it works, that would be far too easy!
So we should install the PC/SC-Lite architecture to be able to read the cards and the beid middleware so we can use the card. Fortunately, beid is in the ports so we can just install it:
pkg install beid
This will also install pcsc-lite. The package messages tell us that we must:
- Install drivers for the card reader
- Hack around devd to let the PC/SC Smart Card daemon recognize it
- Mount procfs
- Install the eID Belgium extension if you use Firefox (I’ll also explain how to install it in Chromium)
- Don’t trust your government
Let’s do just all of that!
Install drivers for the card reader
My card reader is a DunnoWhat-Random-USB-Card-Reader, perhaps devel/libccid should do? For some reason, this is not available in the packages but only via ports:
cd /usr/ports/devel/libccid make install clean
Does the card reader read cards?
Does it work tho? Let’s find out!
$ usbconfig ... ugen0.6: <SCM Microsystems Inc. SCR35xx v2.0 USB SC Reader> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ...
So our card reader is on the USB port ugen0.6. We run pcscd to see if it’s detected properly:
$ pcscd --info --color --foreground ... 00000155 [34366794240] ccid_usb.c:660:OpenUSBByName() Found Vendor/Product: 04E6/5410 (SCM Microsystems Inc. SCR 355) ...
Sweet, so it appears to be detected and working with CCID. However if I run eid-viewer, it doesn’t work. Looking at pcscd info, it looks like the power up of the card failed:
... 00000011 [34375102464] ifdhandler.c:1221:IFDHPowerICC() PowerUp failed ...
Searching a bit over the internet, I’ve found this bug report and it seems that we have to tweak the CCID driver a little.
Edit /usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist and search for <key>ifdDriverOptions</key>. By default it is set to 0x0000 which, if you read the description belows, means that it tries to power on the card at 5V, then 1.8V then 3V. But apparently this doesn’t work with my particular card reader. Instead I let the card reader decide, change the value to 0x0030:
<key>ifdDriverOptions</key> <string>0x0030</string>
Restart pcscd (pcscd --info --color --foreground
) and try the card again (eid-viewer
). In my case, I can see my card details, so I believe this means that the card reader is working well.
Hack around devd
First, let’s enable pcscd at boot in /etc/rc.conf with pcscd_enable="YES"
.
Now we need to configure devd as described by the pcsc-lite package message (pkg info -D pcsc-lite
). Add this to /etc/devd.conf:
attach 100 { device-name "ugen[0-9]+"; action "/usr/local/sbin/pcscd -H"; }; detach 100 { device-name "ugen[0-9]+"; action "/usr/local/sbin/pcscd -H"; };
The -H option is to re-read some configuration files in case of a non-USB reader. You can probably remove them.
Now let’s restart everything we need and check that it still works:
$ service devd restart $ service pcscd restart
Check that it works with the eid-viewer.
Mount procfs
It’s probable that you already have procfs mounted because it’s needed by a lot of other ports. But if you didn’t, just add this line to /etc/fstab
proc /proc procfs rw,late 0 0
and then just mount procfs
.
Install the eID Belgium extension (for Firefox)
If you use Firefox, you are looking for this extension. It should work after you have restarted Firefox.
Get it to work in Chromium
On Chromium there is no extension, instead we work directly with NSS. For beid, the process is straightforward since they provide a script to install the necessary module in NSS. Go in your home directory and start the command beid-update-nssdb. Then restart chromium completely and it should work.
Alternatively you can adapt this post which explains how to manually update nssdb on Ubuntu. You would have to adapt this to FreeBSD and also use this library /usr/local/lib/libbeidpkcs11.so.0 instead of libcac.
Don’t trust your government
You do this.
USB printer in FreeNAS jail
Running a printer in a FreeNAS jail may be interesting for home users, especially if you have one of those GDI printers that only provide a x86/amd64 driver for Linux/FreeBSD, and more especially if you happen to have a FreeNAS box in your living room with some free USB ports.
While exploring the subject, I’ve come across several solutions to use FreeNAS as a printer server. Some explain how you could install the printer inside (a very old version of) FreeNAS itself, which you should seriously not do. Not only all your changes would be overwritten by updates, but it offers limited flexibility and very little guarantee that anything will work or keep working in the future. Even if FreeNAS is FreeBSD at its core, it’s not supposed to be used as a full-fledged OS, if you want that, you should use a VM or a jail. Other solutions explain how to install the printer inside a jail but generally expose all the devices inside the jail just to access the printer. I’ve even heard of someone giving up half way to the solution presented here only to deploy a Windows VM in FreeNAS just to get the printer running.
Part 1: USB inside the jail
The main challenge will be to have the USB printer to appear inside the jail. That is for the device file to appear inside the jail /dev directory. By default, the content of this directory is pretty minimalist.
On FreeBSD (and FreeNAS), the creation of device files in /dev is handled by devfs. Each devfs mount has an associated ruleset number specifying how devices must be created on this mount-point.
FreeNAS uses iocage to manage its jails. You can get the ruleset associated to the jail devfs mount with the following command:
$ iocage get devfs_ruleset {myjail} 5
By default, this is ruleset number 5. You can list the rule in this ruleset with the command devfs rule -s 5 show
, see how it matches devices that you find under your jails.
We will create a custom ruleset for our jail that also include the USB device of the printer. The script will even detect the USB port automatically. But first let’s check if we see the printer and its name:
$ usbconfig ... ugen0.3: <Kyocera FS-1041> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) ...
We will create a new ruleset number 1000 that includes ruleset number 5 and unhides the necessary device for the jail. Also USB devices need to be owned by the group cups and permission 660. Normally, the cups port/package adds a file in /usr/local/etc/devd to change the group owner and permission when a new USB device is plugged in. However devd doesn’t work in jails, so we will also have to change these using devfs.
On a normal FreeBSD system, we could setup this ruleset in /etc/devfs.rules, however this file would be rewritten in FreeNAS on each reboot/update. Instead we create a script that will be started on each boot. We can also use this script to detect the USB port on which the printer is connected. In my case I store this script in my home directory on its own dataset (so it won’t be overwritten on reboot), but you can use any of your datasets. For this example the script will be in ~myuser/myjail-devfs-ruleset.sh.
Let’s edit that with nano:
#!/bin/sh # Custom ruleset for jails export PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin" RULESET=1000 CUPS_GID=193 PRINTER_NAME="Kyocera FS-1041" # Find the printer device. UGEN_DEV=$(usbconfig | grep "$PRINTER_NAME" | cut -d':' -f 1) USB_DEV=$(readlink /dev/$UGEN_DEV) if [ -z "$UGEN_DEV" -o -z "$USB_DEV" ] then echo "error: cannot find printer '$PRINTER_NAME'" echo "error: please check with usbconfig" exit 1 fi echo "Found $PRINTER_NAME on $UGEN_DEV" # Clean the ruleset devfs rule -s $RULESET delset # Include jails default ruleset and unhide USB device. devfs rule -s $RULESET add include 5 devfs rule -s $RULESET add path usb unhide devfs rule -s $RULESET add path $USB_DEV mode 660 group $CUPS_GID unhide devfs rule -s $RULESET add path $UGEN_DEV mode 660 group $CUPS_GID unhide devfs rule -s $RULESET add path usbctl mode 644 unhide
In this script you should edit PRINTER_NAME with the name of the printer found with usbconfig. You should also edit CUPS_GID with the gid of the cups group inside your jail (generally this is 193) and edit the RULESET number if needed.
Now adjust the permission and execute this script. We will also check that the rules are applied correctly:
$ chmod a+rx ~myuser/myjail-devfs-ruleset.sh $ sh ~myuser/myjail-devfs-ruleset.sh Found Kyocera FS-1041 on ugen0.3 $ devfs rule -s 1000 show 100 include 5 200 path usb unhide 300 path usb/0.3.0 unhide group 193 mode 660 400 path ugen0.3 unhide group 193 mode 660 500 path usbctl unhide mode 644
As you can see, the ruleset has been created correctly. We will now change the devfs ruleset used for the jail. In FreeNAS you can either do that in the GUI in Jails > myjail > EDIT > Jail Properties > devfs_ruleset or use the command line. Note that the jail has to be stopped before you can do the modifications. Let’s use the command line in our case:
$ iocage stop myjail * Stopping myjail + Executing prestop OK + Stopping services OK + Tearing down VNET OK + Removing devfs_ruleset: 5 OK + Removing jail process OK + Executing poststop OK $ iocage set devfs_ruleset=1000 myjail $ iocage start myjail * Starting myjail + Started OK + Using devfs_ruleset: 1000 + Configuring VNET OK + Using IP options: vnet + Starting services OK + Executing poststart OK
Login into your jail and check that /dev/ugen0.3 and /dev/usb/0.3.0 are accessible and owned by cups. Now we will make this configuration persistent across reboot. Iocage jails have a exec_prestart property executed before applying the devfs ruleset. However if iocage detects that the devfs ruleset does not exist, it will fall back to a default ruleset. In our case, this means that iocage will always revert to this instead of using our ruleset. Instead we could execute the script as an init task in FreeNAS GUI. However it seems that when a jail is onfigured with Auto-Start, it is started before the Pre-Init tasks. Therefore we configure devfs and then start the jail manually. Create another file (for example in ~myuser/start-jails.sh):
#!/bin/sh # Manually start jails. sh ~myuser/myjail-devfs-ruleset.sh /usr/local/bin/iocage start myjail
Go into Tasks > Init/Shutdown Scripts and ADD one with those info:
Type: Script Script: ~myuser/start-jails.sh When: Post Init Enabled: Yes Timeout: 10
Another problem is that iocage removes the configured devfs ruleset when the jail is stopped. So if you restart after that, the configured ruleset would not exist and iocage would switch to a default empty one that would expose all your devices in the jail. To fix that, we configure a property to also execute our script when the jail stops:
$ iocage set exec_poststop=$(ls ~myuser/myjail-devfs-ruleset.sh) myjail exec_poststop: /usr/bin/true -> ~myuser/myjail-devfs-ruleset.sh
Finally go into the FreeNAS GUI and disable Auto-Start (Jails > myjail > EDIT > Auto-start: off).
Note that none of these shenanigans would be necessary if iocage did not fall back on another ruleset if the one specifed in the devfs_ruleset property did not exist. But unfortunately, it doesn’t. If you have a nice idea on how we can get around this problem, please feel free to comment below!
You are done with this part. The jail is now ready with the USB device for the printer (and no more than that) accessible in its dev directory.
Part 2: Install the printer on CUPS
Since this is a post about running a printer in a jail, there must be a step where we install CUPS and the printer itself within the jail. For anyone that has already installed printers on *BSD or Linux, this should be pretty straightforward. I will not go into the details and assume that the printer is compatible with the default CUPS filters.
Let’s install cups. I do so via ports to remove some of the defaults options. Otherwise cups and cups-filters would depend on wayland avahi and a lot other stuff. If you are fine with that though, you can just pkg install cups cups-filters
. Via the ports, it’s a bit more involved:
$ cd /usr/ports/print/cups $ make install clean (remove AVAHI and DBUS) ... # Install some dependencies as packages # so you don't have to compile them from sources. # Some would say you should not do that. # But I don't. $ pkg install ghostscript9-agpl-base qpdf ... # Install cups-filters. $ cd /usr/ports/print/cups-filters $ make install clean (remove COLORD, AVAHI, LDAP) (select PSGHOSTSCRIPT as default PDF-to-PS renderer since POPPLER would depends on wayland too) # Lock the ports to avoid updates by pkg. pkg lock cups cups-filters
Add cupsd_enable="YES"
in /etc/rc.conf to start cups on boot. Start it with service cupsd start
. By default, cups is only accessible on https://localhost:631, we will use a ssh tunnel to access it and configure the printer:
ssh -NL 10631:localhost:631 {myjail-ip-or-hostname}
Use your web browser and go to https://localhost:10631 and you should see CUPS. If you don’t have a root password on your jail (and only use sudo), it might be a good idea to setup one with passwd, even if only temporary while you install the printer.
If you have a GDI printer that needs a special binary filter that only works on Linux, you should load the linux and linux64 modules in FreeNAS and install linux-c7 in the jail:
############################################### # Only if you need a Linux only binary filter # ############################################### # Add to ~myuser/myjail-devfs-ruleset.sh kldload linux kldload linux64 # In the jail: pkg install linux-c7
Go into Administration > Add Printer, it will ask for credentials, enter root and your root user password (don’t worry you only need to do this to install the printer). Hopefully you should see your printer in local printer.
Select it and continue. Configure name, description and location. Enable the Share checkbox, since you probably want to share this printer on your network. Continue, and select the appropriate printer model then Add printer. Set the default options.
You will be redirected to https://localhost:631 but this won’t work through the ssh tunnel (with local port 10631) so do not worry if the browser says that the site is not reachable. Just retype the URL and go to the printers https://localhost:10631/printers, select it, then Maintenance > Print Test Page.
If the CUPS Printer Test Page comes out of the printer at this point, congratulation! You’ve successfully configured a USB printer with CUPS inside a FreeNAS jail!
If on the contrary nothing comes out, remain calm, /var/log/cups/error_log might be of some use.
Part 3: Share CUPS with your network
We still have to make cups available on the network. To do so, edit /usr/local/etc/cups/cupsd.conf. You can find an example of this configuration in this CUPSD configuration example. In this example, we let everyone on the local network browse the CUPS server and create print-job. The job owner can cancel its own job and all other administrative tasks and printer manipulation are restricted to localhost. For those later operations, you should connect to cups using the ssh tunnel method presented above.
On each client (assuming that it has cups installed), you can configure /etc/cups/client.conf (Linux) or /usr/local/etc/cups/client.conf (FreeBSD) with the hostname of your jail:
ServerName {hostname-or-IP-of-CUPS-jail}
The printer should now be available. Check that lpstat works without error. If you have a problem, again have a look at /var/log/cups/error_log in the jail, it should give you a good start for debugging.
Part 4: Profitsssss
[1] Is it possible to access a USB printer from inside a jail?
[2] Enable sound inside jail
[3] Absolute FreeBSD, 3rd Edition: The Complete Guide to FreeBSD
[4] Exposing Device Files to FreeBSD Jails
[5] Ruleset exists but iocage does not find it #952
[6] USB (Z-Wave) device no longer shows up in iocage jail on FreeNAS 11.2
[7] USB device inside a linux jail (devfs)
UPDATE:
- It seems that with TrueNAS 12 the DevFS ruleset 5 does not exist anymore. As far as I remember these rules did hide everything then unhide the minimum necessary for a working jail. Now when creating the jail DevFS ruleset, you have to add the following rules:
hide
include 2
include 3
Kyocera FS-1040/FS-1041
Printers, who needs them anyway? You can probably just read from a PDF and as for those documents that must be printed on paper, we always have access to a printer somewhere, don’t we? Not so much anymore. So in all this lockdown situation maybe you thought about buying a budget laser printer. Maybe a Kyocera, because that’s the first LaserJet printer you owned, you remember that back in the days it was rock solid and worked flawlessly on Linux with CUPS. Surely now they should only be better, cheaper and more compatible. So you buy this new printer and find out that it’s not compatible with anything else than Windows. Congratulation, you’ve just been struck by the curse of the GDI printers. Those Windows-only printers are getting more and more common (they are cheaper to make) and it’s difficult to get them running as each model generally requires it’s own driver. So most of the time you depends on the goodwill of the manufacturer and when it does provide a driver for Linux, it’s more often than not in the form of a binary.
This has become a plague. When my parents bought a new printer several years ago, I remember asking the vendor multiple times if it was compatible with Linux and if this was a PCL-compatible printer. He assured me that, “yes, it is”, only to find out when I came home that “no, it isn’t”.
So hold on to your butts as I have a semi-great announcement to make with regards to printing with the low budget GDI printer Kyocera FS-1040/FS-1041. It just works! Not only on Linux, but also on FreeBSD. But that’s with a binary, and only on x86/amd64. That’s why it’s just semi-great news.
The great news is, it might be possible to run it with a reverse engineered CUPS filter. That means among other things that you could run this printer from an ARM platform such as a RPi. In the coming days, I plan to dedicate some of my spare time to try to get this open CUPS filter to run inside a jail on FreeNAS.
I’ll update this post as I progress and write further posts once it’s ready.
UPDATE
- USB printer in FreeNAS jail: It works but can still be improved. Especially the problem of applying devfs ruleset to iocage jails.
- Open KPSL filter: I got this version to work inside a FreeNAS jail. Had to hack the CMake rules a bit, but if you manage to compile it, you can replace the binary filter with it.
[1] GDI printers
[2] Reverse engineered Kyocera rastertokpsl filter for CUPS
[3] Access USB Serial Device In Jail