Breakages after 17.02 STABLE -> 18.03 update


#1

[iirc virtualbox was in AppCaffe, so posting here; apologies if this should be in external, though the general issue of blacklisting might belong here…]

After update, boot fails with trap on load of vboxdrv module.

Still a newb to FreeBSD and couldn’t find startup boot parameters to blacklist modules anywhere in docs.

Tried boot environment from before update and updating again, with same result.

Suggestions?


#2

that issue is back :frowning:

In your /etc/rc.conf file, remove all entries for VirtualBox. This will allow the system to upgrade.

The downside. You will need to re-install VirtualBox after the upgrade.

Looking the title, this was caught and fixed, if I remember correctly, in the 17.12 updates


#3

came back to post that I had found and started that…presently it’s working on the update after reboot.

Before I got to that point, I tried to uninstall virtualbox-ose (which was at 5.2.0 v. 5.2.6 in db) but so far as AppCaffe, pkg and pkg-static were all concerned it wasn’t installed at all and hence couldn’t be removed. Is this a quirk of things before a completed update reboot?


#4

weird. do the following

sudo ee /etc/rc.conf

the edit out the virtualbox entries


#5

Did.

[10 character chaff here]


#6

now upgrade “should” work


#7

after the first reboot, updates proceeded, appeared to complete; it asked for a reboot.

Upon reboot, same trap on vboxdrv. Rebooted into single user and checked rc.conf; vbox stuff was NOT there. pkg info | -i virtual showed not virtualbox installed (even though it was under /usr/local/bin), so as a blind guess I installed it and rebooted.

Now it boots into the updated system.


#8

That sounds like you had a “phantom” installation of Virtualbox - it was there, but not registered as installed via the pkg database.
One of the things that we have to do during the update is to uninstall all packages which install kernel modules before doing the reboot into the system with the new base, because the 3rd-party modules also need to be reinstalled before they will be compatible with the new kernel/etc. If virtualbox is not “registered” as installed, then it will not be removed at the right time and can cause a hang on reboot during the update procedures.


#9

I’ve taken some notes on things I discovered while/after upgrading to/installing 18.03 on various hosts. Haven’t fully looked into all of them (or not at all into some…), as I had to figure out how to fix all our hosts that were stuck at update (-> reinstall) and currently still fighting OpenRC…

  • virtualbox files in /usr/local/lib/virtualbox get wrong user:gruop settings on some hosts: all files are set to be owned by root:wheel instead of root:vboxusers, leading to normal users being unable to run virtualbox unless they are in group wheel. Affected files are VirtualBox VBoxSDL VBoxNetNAT VBoxNetDHCP VBoxNetAdpCtl VBoxHeadless in /usr/local/lib/virtualbox/
  • net-online service got removed, so NIS and other services (nfs) yet again fail at boot, leaving NIS dependent clients completely broken. Still figuring out what dependency can be used instead of net-online to force OpenRC to first properly bring up networking before starting ypbind.
  • boot dependencies/orders are scrambled - some network services get started before network interfaces are brought up or routing is started; so e.g. nfs or ypbind and ypset fail to start properly, which is not correctly detected/handled by OpenRC and leads to even more wreckage along the way
  • openntpd now fails at boot if a hostname is given in /usr/local/etc/ntpd.conf; I suspect this is also related to scrambled startup dependencies. I reverted to use IPs for now, so haven’t looked further into this yet.
  • wlan on the laptop of my boss has become extremely unreliable; i.e. it fails to connect to most networks and just automatically connects to open networks which can’t be disabled. dhcpcd also often fails to become active on (re-)connected interfaces and has to be restarted; occasionally doesn’t set the default route. I suspect broken OpenRC service dependencies are also the culprit here…
  • krdc stopped working - it doesn’t send out any packages on any interface. All other RDP/VNC clients (vncviewer/tigervnc, xrdesktop, remmina) completely mess up key mappings to the remote sides if you use something other than en/US on the client.
  • vim is removed at update
  • red pixel artifacts in black areas with some intel GPUs (kaby lake /w multiple screens)

A note on OpenRC:
I’ve discovered a weird behaviour with services that usually just fire once and then exit - OpenRC reports those as “crashed” if they don’t have a start() section in their service file. This section can even be completely empty ( start() { } ) to get OpenRC correctly report the service as started. This fixes the startup of e.g. openntpd (even with the older, shorter variant of the service file from 17.12) and ypset. I doubt this behaviour is intended, especially because it is completely irrational and not documented.
I’ve abused this bug as a quick fix/workaround for mentioned services for now until I cleaned up other more urgent problems we’ve run into with the 18.03 update, then I’ll take a closer look at this and create a PR with some more data.


#10

I can confirm a few things:

Random wireless connects/disconnects along with dhcp issues. Had to disable wireless.

Concerning virtualbox permissions, even after adding my user account to the vboxusers group [though: does something need to be restarted for changes to take effect?] and
chown root:vboxusers /usr/local/lib/virtualbox/*
it was still necessary to
chmod o+x /usr/local/lib/VirtualBox
to get it to run, which feels really icky (and I’ve yet to run a guest because this browser is in a bhyve guest and apparently vbox guests won’t run while bhyve guests are running…)

The update fixed resume from suspend, which did not work at all in 17.02 [the first version I tried]. That became flaky at one point, which was before I disabled wireless. Since wireless was disabled, it seems to be working again but n < 6. [And I suppose wireless might have been an issue preventing wake before the update but I’ll never know…]

vim wasn’t removed for me.


#11

The wireless issues were discussed in another thread - you need to enable wpa_supplicant to start at boot in the services list, and it should connect to known networks again.


#12

Hello,
I’m newbie and i sorry that my post maybe is in wrong topic.
I have problem that after the first install fresh 18.03 or upgrade from 17.02 and reboot, it doesn’t go to GUI login screen, just to login and terminal (ttyv0, login: ) instead, after a few log lines. I don’t know how to continue initial processes.
Maybe because of issue with dhcpcd:
“exec: /dhcpcd.re0: not found

exec: /dhcpcd.wlan0: not found”
The tty appear after:
“Mounting network filesystems…
Starting local…”
Do we have room chat or prefer to give direct support on telegram? Please let me know more details about it.
I install on laptop HP Probook 2011, UEFI.
Thanks for help!


#13