|
|
|
|
@ -6,11 +6,16 @@ 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.
|
|
|
|
|
Dump all origins, then reinstall manually.
|
|
|
|
|
I had to dump all origins, remove all ports, then reinstall
|
|
|
|
|
everything manually.
|
|
|
|
|
|
|
|
|
|
Linuxulator
|
|
|
|
|
===========
|
|
|
|
|
@ -23,25 +28,98 @@ 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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
`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).
|
|
|
|
|
* (at least when using an ATI video card,) user `gdm` needs to be
|
|
|
|
|
able to access `/dev/dri/card0`:
|
|
|
|
|
* create group `dri` containing user `gdm`
|
|
|
|
|
* add devs rules to give it r/w access to `/dev/dri/card0`
|
|
|
|
|
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
|
|
|
|
|
------
|
|
|
|
|
|
|
|
|
|
X will now ignore keymap settings from xorg.conf. Keymap settings must
|
|
|
|
|
now be supplied through HAL policy (`/usr/local/share/hal/fdi/policy/99local/10-x11-keymap.fdi`).
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
http://www.ping.de/sites/kite/xorg-hal-migration.html
|
|
|
|
|
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".
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
Thomas Quinot
10 years ago