You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

3.8 KiB

Raw Blame History

layout	title	date	comments	categories
post	Upgrading to FreeBSD 10.1-RELEASE	2015-02-18 23:06:46 +0100	true

I endeavoured to upgrade my old FreeBSD 9.3-RELEASE system to brand new 10.1. As expected, this was a quite bumpy process, and below are a few things I had to find out the hard way.

Ports

Neither pkg update nor portupgrade can update all ports. I had to dump all origins, remove all ports, then reinstall everything manually.

Linuxulator

New CentOS-6 based linux_base requires sysctl:

compat.linux.osrelease=2.6.18

X11

New Xorg

As of Apr. 16, 2014, the X server has been upgraded to a new release. From https://wiki.freebsd.org/Graphics/WITH_NEW_XORG:

Note that there's a know regression with syscons and kernel video
drivers: you can't switch back to a console once an X.Org session is
started. A new console driver called vt(4) fixes this issue while
bringing nice features. It's available in FreeBSD 9.3-RELEASE and
10.1-RELEASE but isn't enabled by default. To enable it, put the
following line in your /boot/loader.conf:
    kern.vty=vt

It is a real shame that users essentially have no choice but switching from the default syscons to the "new" (unfinished, far from functionally complete) vt console driver.

DRI

Both GDM and the GNOME desktop now require DRI access. At least for ATI video cards, this means that user gdm, as well as anyone logging in to a GNOME session, must have access to /dev/dri/card0:

add path 'dri/card0 mode 0666

GDM

Gdm won't work out of the box (black screen): gdm_lang cannot be set to a non-UTF-8 locale anymore (if the month name in the current date contains an accent, the greeter will abort). Time to bite the UTF-8 bullet, then.

Oh, and I can't just remove the variable altogether, see below.

Keymap

Interesting issue for GNOME users. I found out that the GDM login screen would always revert to US layout, no matter what. Initially I thought the X server had an incorrect keymap due to HAL device enumeration, so I added the following to my setup:

<?xml version="1.0" encoding="ISO-8859-1"?>

<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keyboard">
      <merge key="input.x11_options.XkbLayout" type="string">fr</merge>
      <merge key="input.x11_options.XkbOptions" type="string">terminate:ctrl_alt_bksp,compose:rctrl</merge>
      <merge key="input.xkb.layout" type="string">fr</merge>
      <merge key="input.xkb.options" type="string">terminate:ctrl_alt_bksp,compose:rctrl</merge>
    </match>
  </device>
</deviceinfo>

<!-- Legacy X11 options:
	Option	"XkbRules"	"xorg"
	Option	"XkbModel"	"pc105"
	Option	"XkbLayout"	"fr"
	Option	"XkbOptions"	"terminate:ctrl_alt_bksp" 
	Option	"XkbOptions"	"compose:rctrl" 
  -->

However this happened to be a total red herring, as by default the port configures Xorg to use devd, not HAL.

It appears that the X server setup is actually just fine. And indeed, starting it with startx yields the expected French layout.

However, it appears that gnome-shell considers that whatever keymap is configured in the X server probably must be unsuitable, and changes it on its own to a better default based on the current locale (or "us" if no locale is set for gdm).

Printing

I am using an HP MFP1217nfw network printer, which requires the proprietary print/hplip and print/hplip-plugin packages. These install print/cups as a dependency. print/cups-filters is not installed as a dependency, but is required anyway, or all print operations will fail with:

D [02/Mar/2015:22:24:01 +0100] Print-Job client-error-document-format-not-supported: Unsupported format "application/pdf".

3.8 KiB Raw Blame History