Question

Problems after upgrading to freebsd 13.0

Hey

I upgraded to freeBSD 13.0 and it seem to have broken the DO network configurations, I am forced to go to the console and run /usr/local/rc.d/digitalocean restart and then I have network again…

When the server boots up I get the following:

DigitalOcean: expected hostID xxxx(edited out) DigitalOcean: resizing the disk… vtbd0 recovering is not needed vtbd0p3 resized DigitalOcean: expanding the ZFS pool DigitalOcean: mount configdrive could not determine starting sector, using very first session DigitalOcean: applying droplet configuration DigitalOcean: reading meta-data ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” DigitalOcean: hostname is set in /etc/rc.conf, skipping setting hostname ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” DigitalOcean: adding public IPv4 configuration ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” DigitalOcean: adding anchor ipv4 configuration ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” DigitalOcean: adding private IPv4 configration ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” ld-elf.so.1: Shared object “libonig.so.5” not found, required by “jq” DigitalOcean: adding IPv6 configuration DigitalOcean: finished droplet configuration DigitalOcean: re-starting networking Created clone interfaces: lo1. lo0: link state changed to UP ifconfig: ‘netmask’ requires argument ifconfig: ‘prefixlen’ requires argument vtnet0: link state changed to UP ifconfig: alias: bad value ifconfig: ‘netmask’ requires argument vtnet1: link state changed to UP

anyone else had the same problem and now how to fix it?


Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

I’ve had some issues with jq before (my ignorance), but didn’t run into issues until the 13.1 RCs (where I was cutting over from 13.0-p#).

The LD_LIBRARY_PATH addition fixed the libonig problem, but I also needed the “BEFORE: hostid” bit because the hostname wasn’t getting set. My VM at digitialocean doesn’t get rebooted that much (releng per-patch), but it didn’t seem to be totally reliable so I wonder if it is a race condition in the rc scripts that is now more reliably failing in 13.1.

The start of my /usr/local/etc/rc.d/digitalocean script now looks like:

#!/bin/sh

# PROVIDE: digitalocean
# REQUIRE: FILESYSTEMS cloudinit digitaloceanpre
# BEFORE: hostid

. /etc/rc.subr

name="digitalocean"
start_cmd="${name}_start"
stop_cmd=":"

export LD_LIBRARY_PATH="/usr/local/lib/"

digitalocean_start()
{
...

I had the same issue. Upgraded from 12 to 13, and IP was non-existent. Opened a ticket, no fix.

I hacked around it and let it simmer for a couple of weeks, hoping DO would fix their automation. Nope.

So tonight I dug into it, and worked out the problem. At the time that “digitalocean” script is run, ldconfig has not been initialized. So no dynamically-linked binaries can run. At least, the “jq” tool they rely on doesn’t run. (Had to add code to that script to write things to /tmp so I could reboot and get the debug results.)

What I did to fix it was to add this line at the top of the script (global scope):

export LD_LIBRARY_PATH=“/usr/local/lib/”

Now when ‘jq’ runs, it can find that pesky libonig shared object file.

This also explains why you were able to get it working by running the digitalocean script after the VM had booted.

I have no idea why the upgrade would not have this problem for everyone. A bug in FreeBSD’s upgrade instructions? Or something odd about DO?

Oh, and if one of you could explain how you managed to capture the boot messages that were output on the Recovery Console, I’d be happy to learn. I could see the errors as the flew by, but not read them. And grepping for ‘jq’ in the logs gave no hits.

Be aware that DO will “refresh” that script without warning, so this fix may not stay fixed. It may be better to just add your own initscript to hard-code your droplet’s info directly.

Cheers!

Looks like the jq package is using the older ABI. Hardcode the network config, and make sure all packages are updated to the 13* ABI. Then jq should work and you can remove the hardcoded network config.

see: https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-upgrading-freebsdupdate 24.2.3.2. Upgrading Packages After a Major Version Upgrade