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.
		
		
		
		
		
			
		
			
				
	
	
		
			129 lines
		
	
	
		
			3.9 KiB
		
	
	
	
		
			Markdown
		
	
			
		
		
	
	
			129 lines
		
	
	
		
			3.9 KiB
		
	
	
	
		
			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.
 | 
						|
 | 
						|
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".
 | 
						|
```
 | 
						|
 |