From b0a3a5525df2c4aec28d80cde67cc70a7fd484ba Mon Sep 17 00:00:00 2001 From: Thomas Quinot Date: Thu, 5 Mar 2015 23:10:44 +0100 Subject: [PATCH] Update --- ...upgrading-to-freebsd-10-1-release.markdown | 100 ++++++++++++++++-- 1 file changed, 89 insertions(+), 11 deletions(-) diff --git a/source/_posts/2015-02-18-upgrading-to-freebsd-10-1-release.markdown b/source/_posts/2015-02-18-upgrading-to-freebsd-10-1-release.markdown index bff003e..df18e0c 100644 --- a/source/_posts/2015-02-18-upgrading-to-freebsd-10-1-release.markdown +++ b/source/_posts/2015-02-18-upgrading-to-freebsd-10-1-release.markdown @@ -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 +(if the month name in the current date contains an accent, +the greeter will abort). Time to bite the UTF-8 bullet, then. - * `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` +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: -http://www.ping.de/sites/kite/xorg-hal-migration.html +```xml /usr/local/share/hal/fdi/policy/99local/10-x11-keymap.fdi + + + + + fr + terminate:ctrl_alt_bksp,compose:rctrl + fr + terminate:ctrl_alt_bksp,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". +```