On with the migration to FreeBSD amd64 (64 bit version) today. It wasn't easy. I had expected the transition not to be smooth, but I had never expected it to be this bad.
Much of it was related to photo processing, the reason that I started the migration in the first place. I had noticed that the 64 bit version of Hugin had problems that didn't occur on the 32 bit version, and sent mail to the mailing list. One of the replies suggested that this is a known issue that also occurs on Mac OS X, so maybe something will come of that.
But there were other issues. I took my weekly panoramas today, because the weather was suitable, and even reading the images into the computer was a problem:
=== grog@eureka (/dev/pts/6) ~/Photos/20120706/orig 22 -> exiftime P7067432.ORF
/Photos/Tools/exiftime: 1: Syntax error: Unterminated quoted string
/Photos/Tools/exiftime: 11: Syntax error: Error in command substitution
I set the author information there, and the script I use had a bug, a typo that should have rendered it useless under i386 as well:
+++ /Photos/Tools/exiftime 2012/07/06 23:09:47 1.6
@@ -2,13 +2,13 @@
- DATE=`echo $CREATE_DATE | sed s'/.* : //; s/://g; s/ .*//`
- TIME=`echo $CREATE_DATE | sed s'/.* //; s/://; s/:/./`
+ DATE=`echo $CREATE_DATE | sed s'/.* : //; s/://g; s/ .*//'`
+ TIME=`echo $CREATE_DATE | sed s'/.* //; s/://; s/:/./'`
How could that ever have worked? But it seems it has done for a year and a half. And under the present circumstances, it's not the first thing I would look for. That was simple enough, but when running another script, which calls PHP functions, I got a message
That proved to be a configuration file problem:
+++ /usr/local/etc/php.ini 2012/07/06 03:59:15 2.3
@@ -475,7 +475,7 @@
; Whether or not to register the old-style input arrays, HTTP_GET_VARS
; and friends. If you're not using them, it's recommended to turn them off,
; for performance reasons.
-register_long_arrays = On
+register_long_arrays = Off
After that, I got a continual stream of:
Now what's so dangerous about using POSIX regular expressions? But clearly I needed to heed the prayers of those who know better and convert to Perl regular expressions. The documentation of ereg and preg_match was sufficiently different in style that I got the impression that return value in the third parameter was different, but it seems that was a misunderstanding. In the end, discovered that this Emacs command (using different regular expressions again) would do the conversion, at least for my relatively simple regular expressions:
"ereg (\"\([^\"]+\)"
"preg_match (\"~\1~"
nil
(if
(and transient-mark-mode mark-active)
(region-beginning))
(if (and transient-mark-mode mark-active)
(region-end)))
I chose ~ as a delimiter simply because I then didn't need to worry about conflicts.
Finally I got as far as trying to stitch today's panoramas. Again the verandah centre had very poor results with panomatic, so I tried the new cpfind program. It crashed and conveniently shut the log window before I could get a chance to read it. How I wish Hugin would store the log file somewhere where it can be examined. I'll look at that later. Finally, however, I had a fast panorama preview window with something that didn't look too badand discovered that the move controls didn't work.
Back to running on dereel. Got to the fast panorama preview and... the move controls didn't work. It looks as if this is a problem with the X server. OK, I wanted to get the X server working on dereel as well, so attended to that. It now had only the display chip on the motherboard, but that's an nVidia chip as well. But when I configured X, it came up with the free nv driver, which is amazingly restrictive: it couldn't even find a mode line for 1920x1080, the resolution of the display. When I tried to use the proprietary nvidia driver, the one I've been using for years, I once again got the message:
(EE) Jul 07 10:45:02 NVIDIA(0): system's kernel log for additional error messages and
(EE) Jul 07 10:45:02 NVIDIA(0): consult the NVIDIA README for details.
There was nothing in the system log, but on one attempt I got this message:
Why not? It was there and in use until a couple of days ago. Tried rebuilding the module, and ended up with nonsensical messages like:
=== root@dereel (/dev/pts/1) /boot/kernel 29 -> kldunload nvidia
kldunload: can't find file nvidia
=== root@dereel (/dev/pts/1) /boot/kernel 30 -> kldload nvidia
kldload: can't load nvidia: File exists
I know I didn't link the module statically into the kernel, so this suggests to me that the module didn't tidy up behind it on the last reload. When I have time to reboot the system, I'll try again. And maybe the error message from the driver is really trying to tell me that it doesn't support this particular chipset. Another thing to investigate.
OK, so back to the nv module. How do I get a mode line for that? Decades ago I wrote a detailed description of how to do this, which later found its way into The Complete FreeBSD, but nowadays it should be easier. There's xvidtune for that. Or is there? Looking on eureka, I couldn't find it, and it seems that the port has been removed. Why? No time to look now; I had a copy on dereel. But it says:
=== root@dereel (/dev/pts/1) /boot/kernel 32 -> xvidtune
Please install the program before using
What does that mean? No idea. Tried a few alternatives and finally gave up. Still, at a pinch I can make do with this ugly 1280x1024 screen that it gave me. Well, no:
=== grog@dereel (/dev/pts/10) ~ 2 -> hugin
Xlib: extension "GLX" missing on display ":0.0".
Segmentation fault: 11 (core dumped)
It seems that I need GLX, and for GLX I need the nvidia driver. To quote /var/log/Xorg.0.log:
So I'm stuck. I can't run Hugin on eureka because of bugs. I can't run Hugin on dereel and display on eureka because I can't move the images in the fast panorama preview. And I can't run Hugin natively on dereel because I can't get X to run properly. What a pain! I had expected problems, but nothing like this many.
Out of desperation, tried running on dereel and displaying on lagoon, Yvonne's computer. That worked. But it's complicated and slow, and Yvonne would have a word or two to say about tying up her computer for hours at a time.
In the evening, while waiting for Yvonne in the lounge room, tried running things on teevee, the projector driver. And again I couldn't move the image in the move tab. It wasn't until later that I realized that this is another amd64 machine. What is it about that that triggers the problem?
Other strangenesses
As if that wasn't enough, there were various other things that happened that don't appear to be directly related to the upgrade. Every time I saved my diary notes in Emacs, it got displayed on the neighbouring firefox. There's no obvious connection between the two, and the key bindings haven't changed. Closing the file and reopening it stopped the problem.