If you are reading this because you, like me were lost and frustrated… I feel your pain. But let me try and help!

A few weeks ago I added a POE HAT to a Raspberry Pi 3B+ and installed FreeBSD to so I could build a remote access server. I also bough another Raspberry Pi 3B+ to replace by OrangePi Zero + USB uBlox 5 NTP server.

Unlike Raspbian it is surprisingly hard to stop FreeBSD’s kernel from grabbing uart0 for it’s console. Lets start with why you are probably here… how do I stop the kernel from doing this?

echo 'hw.fdt.console="NO"' >> /boot/loader.conf.local

Easy right? It took me more than 24 hours to find this. Most of which was one long Saturday. I could not find much (any) documentation on this parameter. So how did I find it?

One of the embedded device devs from FreeBSD recommended to remove /chosen/stdout-path from the fdt tree. This did not work. After a few hours of messing around with building kernels without baked in uart support and other dead-ends I went back to looking at the fdt stuff.

Older version had this set to serial0 but I switched to FreeBSD 12-APHA2 before my long day of experimentation. This one lists serial1 as the default path… which is odd given bluetooth is still disabled so that the hardware UART is attached to the TX and RX GPIO pins. (That is serial0)

So with the default or with a empty (or missing stdout-path) we still somehow end up using serial0. After about an hour of grokking the source I came to these files.

if hw.fdt.console is not set, /chosen/std{in,out,out-path} are checked

if the config in /chosen/std* was not valid a last ditch effort is done to configure serial0

If hw.fdt.console is set to an invalid path e.g. NO no console will be configured! So this is the solution to disabling the kernel from grabbing uart0! We did it reddit

Now that I knew what to do I managed to find this change D3559. A handy note was left from the developer:

The user could disable the fdt console with this by setting it to an invalid node, e.g. hw.fdt.console="none"

I could not find any other documentation about this parameter so it may stop working in the future. Time will tell.

EDIT: It looks like the internal UART can only run at 115200… I am looking into this as 9600 is what I need for the GPS HAT. I did have the RTC and PPS working without anything fancy aside from adding the dtoverlays and loading the drivers. So that is a small win.

I have also attached a u-boot binary with silent=1 and nulldev configured for people who do not want to recompile u-boot themselves.

UPDATE: the UART can indeed only run at 115200 and FreeBSD’s PL011 driver does not support changing the speed unless running on x86! However u-boot can! Adding the following line to config.txt pins the UART’s baudrate at 9600

I was in the market for a configuration management and remote execution tool. After looking around I didn’t really find any I liked and also supported SmartOS (and illumos).

It quickly became clear that I would need to do some legwork. I’m by no means a great programmer and my language selection is mostly limited to Turbo Pascal, C#, and Java supplemented with shell script (~bash really), perl (long ago), and Python.

My eye fell on SaltStack as it uses mostly Python, the community looked welcoming. I looked at some PR’s and the feedback happening on them was constructive. As a plus, Nahum Shalman already did some legwork to get SaltStack into the SmartOS global zone!

I spend a lot of time getting SmartOS support for managing zones/VMs usable.

vmadm execution module was written as a replacement for the existing ‘virt’ compatible module

smartos state module was written that uses the imgadm and vmadm execution modules, this allows for management of zones/vms, images, and configuration.

I’ve been running these at home for about 3 months. They are pretty solid, I have a few things I want to improve in them but they are certainly usable. If you use them and find any issues, please open an issue on the saltstack github and tag me using @sjorge. I will try and fix them as soon as I can.

After this I started to manage my zones themselves hitting a few roadblocks along the way. Most of these changes also apply to illumos in general. (Sometimes to *BSD’s too)

I spent the last 3 days yak-shaving. I had the intent of looking into deploying SaltStack to monitor my zones at home. Instead I give you asmd AKA “Advanced SmartOS Management Daemon”. Yes I should really get better at naming things.

So what is this asmd you speak of, you may ask? It is my one pythonbash script to replace them all. SmartOS wise anyway. As you know I run a few SmartOS nodes at home, you may also know I really try to push IPv6 everywhere. SmartOS does not support this. After a few months I had collected a few hacks to make my life easier, each had their own smf service… You could see my learning progression in them as the quality improved as I got more familiar with the SmartOS internals.

I wrote a simple “framework” to plug in my little hacks and scripts, this framework is asmd. Once I had the base line I rewrote most of my hacks to leverage this framework. I originally wrote this in python that I pushed to the SmartOS nodes as an esky package. This was powerful but also complete, on day two I rewrote everything in bash.

So how does it work? Each ‘service’ lives in $PREFIX/services/name.service and sets a few variables to describe it self and implements 3 functions:

asmd_service_config :: execute on asmd-setup, this can be used to prepare some files and directories.

asmd_service_start :: runs when the service starts

asmd_service_stop :: runs when the service stops

The following variables are required

ASMD_SERVICE_NAME :: name of the service as it appears under smf

ASMD_SERVICE_DESC :: description use for the smf service

ASMD_SERVICE_TYPE :: for now only ‘transient’ is tested, although ‘daemon’ should also be supported.

ASMD_SERVICE_DEPENDENCIES :: svc identifiers for service dependencies

ASMD_SERVICE_DEPENDENTS :: svc identifiers for services dependent on this service

Functions marked in italic can be omitted, variables marked in italic can be empty.

When asmd-setup is ran, usually once after install or when adding/removing services a smf manifest is generated and placed in /opt/custom/smf so that SmartOS loads it at boot. Each service is a named instance under system/asmd. I decided to use /usbkey/config to store all the configuration individual services need.

Currently the following services are implented:

hostname :: set hostname and/or domain name at boot

profile :: symlinks files and folders into /root to customize the user environment (aka inject bash aliasses like vmadm wrapper that can use aliasses of zones)

exec :: executes each script located in /usbkey/config.inc/exec after network is up. Mostly used for quick and dirty hacks

I’m only targeting the current base64-lts release.
Currently only SmartOS is supported, although it should be compatible with OmniOS using the pkgsrc bootstrap available at http://pkgsrc.joyent.com/ some recent changes (epoll) seem to have broke them as SmartOS supports it but OmniOS and Nexenta Community both seem to be lacking it.

As of now omnios.blackdot.be is deprecated and no further updates will happen. Somewhere later this year it will go offline, I have no date yet but it will probably happen the next time I need to do a big round of updates.

As previously mentioned I will be deprecating omnios.blackdot.be IPS package repository soonish.

Work has started on pkg.blackdot.be, the initial set of packages is up. But most are untested and they need some more love. Once the packages are where I want them to be. I will start rolling packages for omnios also.

Check it out if you want to poke it. Although stuff will change and change often!

Just a heads up, somewhere later this year I will turn down omnios.blackdot.be and will bring up pkg.blackdot.be. There I will host a smaller selection of packages for use in SmartOS zones or on OmniOS once the illumos flavor of pkgsrc is installed.

Not sure when this will happen because I am currently changing jobs. More info will follow.

As it comes as no surprise I migrated my hosting from ESXi Free to SmartOS a year or so ago.
However every major update I spend an hour or so building a new zone from scratch to then switch over.

This is tiresome so now I’m working on a bootstrap script that will rebuild the zone for me from the data on a delegated dataset.
So far 2/4 zones are done and this is AMAZING, a simple vmadm reprovision and all is set.

Anyway, back to the other 2 zones that need some love! I hope to start update more again soon.
I will be switching jobs again and the new one will give me some more free time to write!