2021-01-25 Josef "Jeff" Sipek

OmniOS Community Edition r151030cm, r151034am, r151036m OmniOS Community Edition

OmniOS weekly releases for w/c 25th of January 2021 are now available.

All supported OmniOS releases have been updated with the following changes:


  • Support for secure RPC for the Netlogon protocol between OmniOS systems and Microsoft Active Directory servers. This is required to fully mitigate CVE-2020-1472, and will shortly be enforced by Windows domain controllers.

    We’re grateful to Matt Barden of Tintri for contributing this feature to illumos.

Security Fixes

  • It was possible for an unprivileged user, including one in a zone, to cause the system to panic.

  • socat updated to fix a potential heap based buffer overflow.

  • sudo updated to fix CVE-2021-3156

Other Changes

  • On r151036 only, OpenJDK 11 now bundles several core fonts and has been updated to 11.0.10+9.

  • OpenJDK 8 has been updated to 1.8.282-b08

  • gcc has been updated so that the -z assert-deflib linker option works correctly for 64-bit objects.

  • ZFS list -t bookmark was not working for zvols.

  • Add support for the IA32_FEATURE_CONTROL MSR in bhyve. This improves support for some guest operating systems.

  • pkg apply-hot-fix could produce error messages during operation.

For further details, please see https://omniosce.org/releasenotes

Any problems or questions, please get in touch.

ZFS send/receive Nahum Shalman

A few weeks back I needed to migrate an entire ZFS pool from one machine to another. I used raw send to keep the stream compressed, and I used mbuffer to smooth out the send/receive (see the reference link at the bottom)

First, prepare the receiving end by creating the pool. If this is not a bootable pool, just create it the simple way:

zpool create ${poolname:?} ${disk:?}

Now start up mbuffer to receive the initial send stream ("-s" is for resumable receive in case the receive gets interrupted part way through)
I'm using a block size of 128k, a buffer size of 1G and listening on port 9090:

mbuffer -s 128k -m 1G -I 9090 | zfs receive -Fs ${poolname:?}

Now switch over to the sending machine. Here we will take a snapshot, and then send it over mbuffer to the receving machine. We'll do a raw and resumable send.

zfs snapshot -r ${poolname:?}@${snapname:?}
zfs send -Rvw ${poolname:?}@${snapname:?} | mbuffer -s 128k -m 1G -O ${receiver:?}:9090

If the sending side has changed since the first snapshot completed sending, do an incremental send/receive to sync up the last changes (repeat as needed)

On receving machine, rerun the receiving command:

mbuffer -s 128k -m 1G -I 9090 | zfs receive -Fs ${poolname:?}

On the sending machine, take another snapshot and send over the incremental stream:

zfs snapshot -r ${poolname:?}@${snap2:?}
zfs send -Rvw ${poolname:?}@${snapname:?} ${poolname:?}@${snap2:?} | mbuffer -s 128k -m 1G -O ${receiver:?}:9090


Using mbuffer to speed up slow zfs send | zfs receive - EveryCity
zfs send | zfs receive stalls the sender, resulting in a bursty and slow transfer process. The solution is to deploy mbuffer into the mix. MBuffer

Pango updated to 1.48.0 openindiana

Pango, the GNOME core text and font handling libraries, has been updated. Since pango-1.44 the support for old bitmap fonts (PCF, BDF) has been dropped. Thus, applications using pango don’t support bitmap fonts anymore. For more details visit https://gitlab.gnome.org/GNOME/pango/-/issues/386

Goodbye 2020 Kebe Says: Dan McD's blog

Pardon my latency

Well, at least I’m staying on track for single-digit blog posts in a year. :)

Okay, seriously, 2020’s pandemic-and-other-chaos tends to distract. Also, I did actually have a few things worth my attention.

RFD 176

The second half of 2020 at work has been primarily about RFD 176 – weaning SmartOS and Triton off of the requirement for a USB key. Phases I (standalone SmartOS) and II (Triton Compute Node) are finished. Phase III (Triton Head Node) is coming along nicely, thanks to real-world testing on Equinix Metal (nee Packet), and I hope to have a dedicated blog post about our work in this space coming in the first quarter 2021.

Follow our progress in the rfd176 branches of smartos-live and sdc-headnode.

Twins & College

My twins are US High School seniors, meaning they’re off to college/university next fall, modulo pandemic-and-other-chaos. This means applications, a little stress, and generally folding in pandemic-and-other-chaos issues into the normal flow of things as well. Out of respect for their privacy and autonomy, I’ll stop here to avoid details each of them can spill on their own terms.

On 2021

Both “distractions” mentioned above will continue into 2021, so I apologize in advance for any lack of content here for my half-dozen readers. You can follow me on any of the socials mentioned on the right, because I’ll post there if the spirit moves me (especially on issues of the moment).

Running Eclipse on current illumos The Trouble with Tribbles...

You can run a slightly old version of Eclipse on illumos. The download is here.

Later Eclipse (and SWT) versions didn't have Solaris support. Or any unix variant such AIX or HPUX either, or certain hardware platforms, come to that.

However, if you try and run that eclipse on current Tribblix or OpenIndiana, you'll find it doesn't work and you get a Java crash.

The way I found to fix this is to edit the eclipse.ini file to force the use of GTK2, by adding the following 2 lines in the middle


so that the full eclipse.ini looks like:


The reason this is necessary is because we now have GTK3, and if you don't explicitly force GTK2 you end up with both GTK2 and GTK3 loaded and chaos ensues.

The failure with GTK3 is slightly ironic, given that the reason for dropping Solaris support in eclipse was that we were stuck on GTK2.

Installing OmniOS on Vultr with iPXE The Trouble with Tribbles...

A while ago, I wrote about booting Tribblix on Vultr using iPXE.

Naturally, the question arises - is this possible for other illumos distributions, like OmniOS?

First, though, a note about why this might be interesting. Imagine I have some servers in a remote datacenter, and I need to install an OS. Most servers have some sort of remote managamenet capbility that includes mounting an ISO image. That's fine, but if you're at home then you're having to transfer the ISO image the wrong way across an asymmetric network connection. It's very slow, quite unreliable, and sometimes plain doesn't work. On the other hand, booting iPXE is very quick and very reliable, because the bootable image is so small. And the same benefits mean you can repeat the process until you've got it right.

Based on that, Vultr is just a very convenient way to test this out.

Because of the way that the OmniOS media are built, a straight copy of the Tribblix procedure won't work. This is what you need to do instead.

First, you need an accessible web server. I'm using the Tribblix repo server, but it really can be any server. It doesn't need to be illumos, as long as it responds to http requests you're good.

In the document root, create a directory. I'm going to call it 'kayak', because that's what the OmniOS network installer is called, and that's what we're going to leverage.

There are 3 files from the OmniOS distribution or media that we need.

You can't use the boot archive from the ISO. You need a custom boot archive for this. Download the miniroot file from the https://downloads.omniosce.org/media/ location. If you look in each release directory, you should find a gzipped miniroot file. Put that in the kayak directory, and gunzip it. I normally rename this to be platform/i86pc/amd64/boot_archive. This is going to be the initrd file in your ipxe configuration.

The next thing you need is the corresponding kernel, aka unix. You need to extract this either from the ISO image or the miniroot. The ISO image might be easier; the miniroot contains a UFS filesystem. You could mount this up using lofi and copy the file out of it. You need the file /platform/i86pc/kernel/amd64/unix, and it needs to be located at platform/i86pc/kernel/amd64/unix.

Another way if you have the iso-read command installed (on Tribblix it's in the TRIBlibcdio package) is

mkdir -p platform/i86pc/kernel/amd64
iso-read -i omniosce-r151030.iso \
  -e platform/i86pc/kernel/amd64/unix \
  -o platform/i86pc/kernel/amd64/unix

The third thing you need is the image to install. This is a compressed zfs send stream. You can download these from https://downloads.omniosce.org/media/ for most releases - look for the .zfs.xz file. Make sure not to use the ones with ngz in the name - they're for zones.

If you're trying r151030, then there isn't a downloadable file, but you can pull this file out of the ISO too. For example

iso-read -i omniosce-r151030.iso \
  -e kayak/kayak_r151030.zfs.xz \
  -o kayak_r151030.zfs.xz

Then you need to create a client configuration script. The instructions at https://omniosce.org/setup/pxe.html are a good start. For example, it might be:

BuildRpool c1t0d0
RootPW '$5$JQkyMDvv$pPzEUsvP/rLwURyrpwz5i1SfVqx2QiEoIdDA9ZrG271'
SetHostname omnios30
SetTimezone UTC
Postboot '/sbin/ipadm create-if vioif0'
Postboot '/sbin/ipadm create-addr -T dhcp vioif0/v4'

Obviously, you need to use the correct disk device (c1t0d0) and network interface (vioif0) appropriate to your system. These are the right values for Vultr.

The installer will look for this file using its (uppercased) MAC address, and then go for shorter parts of the MAC address. As I don't know what that is yet, I simply create a file and create symlinks 0-9 and A-F pointing to it, as it will eventuially get to the first letter of the MAC address and one of them will match. If you know the actual MAC address of the system, you can create a file with the exact match.

What you end up with is an ipxe.txt (and this is the one I'm using at http://pkgs.tribblix.org/kayak/ipxe.txt) file that looks like this:

kernel /kayak/platform/i86pc/kernel/amd64/unix -B install_media=,install_config=
initrd /kayak/platform/i86pc/amd64/boot_archive

To recap:

  • The initrd file points at the location of the gunzipped miniroot file you downloaded.
  • The kernel line refers to the unix file you extracted.
  • The kernel line supplies boot arguments with the -B flag. There are two of them.
  • NOTE: the kernel line is just one line, despite how its gets formatted here.
  • The install_media argument is a URL to the ZFS send stream file you downloaded. Note that I'm using the IP address of the server rather than its DNS name, as you can't guarantee that DNS resolution will work.
  • The install_config argument is the URL of the directory that the client configuration scripts are put in. The installer will look for files based on (a substring of) the client's MAC address in this directory

With that all set, you're ready to boot a machine on Vultr.

Go to instances, and click on 'Deploy instance'.

Choose a server. Cloud Compute is the basic starter, I normally use London as it's close to me to minimize latency.

For Server Type, go to the Upload ISO tab, choose iPXE isntaed of My
ISOs, and enter the URL of your ipxe file, ipxe.txt


Then select your server size - even the smallest 1024MB instance will work fine, and hit the Deploy Now button.

It should show as Installing for a few moments, and then change to Running. If you click on Running you get to the page for that instance, and the view the console link does exactly that using VNC.

The install is pretty quick:


(You can see it trying the variant client configuration scripts.)

And it will then reboot into the installed system.

This is a typical minimalist OmniOS install. You'll probably have to set DNS up (if you didn't do it in your client confiiguration script), add a user, and then you'll be able to ssh in remotely.

OmniOS Community Edition r151030cf, r151034af, r151036f OmniOS Community Edition

OmniOS weekly releases for w/c 14th of December 2020 are now available.

All supported OmniOS releases have been updated with the following changes:

Security Fixes

Bug Fixes

  • MacOS Big Sur clients would experience read hangs when accessing OmniOS SMB shares.

  • The pkg apply-hot-fix command, in conjunction with the creation of a new boot environment, would sometimes leave extra origins configured in non-global zones. This caused problems for subsequent package updates.

  • Compiling with gcc -pg did not produce a working profiling binary.

Other Changes

  • The Intel CPU microcode update for some Core (Gen. 11) Mobile processors has been removed as it was reported to cause problems on some platforms.

Additionally in both the r151034 and r151036 releases:

  • In rare cases, a system could crash shortly after boot while maintaining ZFS user quota information (particularly if a zfs recv was running at the same time).

and in r151036 only:

  • The pciutils package tools were unable to enumerate PCI devices.

  • A file’s modification time would change twice when the file was modified from an SMB client. This caused problems for some Windows utilities.

  • Restore the NDMP ZFS backup and restore method which was inadvertently broken in the r151036 release.

For further details, please see https://omniosce.org/releasenotes

Any problems or questions, please get in touch.