labnotes/_source/_posts/2015-02-18-upgrading-to-freebsd-10-1-release.markdown

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

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:

```plain linenos:false
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.

The X mouse cursor occasionnally disappears for some unidentified
reason. Alt-Tab brings it back.

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`:

``` plain /etc/devfs.rules linenos:false
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 /usr/local/share/hal/fdi/policy/99local/10-x11-keymap.fdi
<?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. For devd, I
[found out](http://olivier.cochard.me/bidouillage/installation-et-configuration-de-freebsd-comme-poste-de-travail#TOC-Configuration-de-la-langue-du-clavier-sans-HAL)
this is achieved
using xorg.conf options:

```
Section "InputClass"
        Identifier "Keyboard Defauls"
        Driver "keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "fr"
EndSection
```

But all of this was mostly irrelevant for my setup since I add
AutoAddDevices turned off in the X server setup, and the correct
layout was hardcoded in xorg.conf. 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".
```