Pine64, NetBSD, XFCE, and a year

My how time flys… it has been about 10 months since I installed NetBSD on my Pine64 board. Then it went in a box for a while as pandemic crap hit.

Today I finally got my round tuit, and added XFCE as a desktop. It was easier than expected.

The formal directions have you do a load of stuff, including installing X. But much of it is already done.

I checked what was already there, and skipped down to step 5:

5) Update the pkgin database and install XFCE.
> pkgin update
> pkgin install xfce4
calculating dependencies…done.

139 packages to install:

I think I had more packages than that, but whatever… in maybe an hour it was all done. Running “startxfce4” failed, so I rebooted, and then it worked.

I tried “pkgin libreoffice” and it is installing now. Later I’ll try a browser. If that works, I’ve got 95% of everything I need on a never SystemD platform.

So far, much easier than Gentoo or Slackware. We’ll see how complete things are over time.

So far, running xfce is the same user experience as Linux. The big issues are with different management methods and breadth of applications TBD.

As of now, I’m happy with it as a generic server base and desktop, but will need a browser and GIMP to round out the applications.

Subscribe to feed


About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits. Bookmark the permalink.

12 Responses to Pine64, NetBSD, XFCE, and a year

  1. E.M.Smith says:

    Well that was quick. Libreoffice finished the install and is working.

    Next up, GIMP for image editing. I was able to edit a file in Libreoffice with almost nothing in swap, about 500 MB used on a 1 GB board.

  2. E.M.Smith says:

    Well, GIMP installed quickly, and is working. 508 MB active, 248 MB inactive total memory in use. 195 MB for X, 236 MB for Gimp, looks like most of the rest is xfce.

    I tried pkgin firefox, but it didn’t like me. While “pkgin search Firefox” claimed firefox52 exists. So I guess next is figuring out what magic incantation installs it.

  3. E.M.Smith says:

    Got Firefox installed. Looks like there is no metapackage firefox, so you need to look in the repository and install things in parts:
    > vi /usr/pkg/etc/pkgin/repositories.conf and see the path:

    Then in a browser on another machine, put that in and scroll down to firefox:


    Those three got installed directly, like:

    pkgin install firefox_decrypt-0.7.0

    Note that the .tgz is left off the end.

    It gets installed as nightbrowser or some such, under the “internet” menu not the “browser” menu, but is Firefox when launched.

    I’ve had it crash a couple of times and work a couple, so needs something. Perhaps those other bits starting with “fire” firelib-1.0.1.tgz or maybe since the pine64 has no heat sink and is running hot, that is destabilizing.

    I’m happy enough with the ease of install, performance and general look and feel, that I’m going to try it on some other boards too. There are ports to several of my boards including the Rock64 RockPro64, Orange Pi One, and several Odroids including the XU4.

    So a port to one of them will answer the heat question. If any one of them has a stable browser, I’m moving to it. I only need one with a stable browser. I can easily move the file server function over even without a browser, so one less systeD based board as my Orange Pi One is on Armbian now.

  4. E.M.Smith says:

    Well, the binary is named “firefox52” so to start it in “safe mode” one does:

    firefox52 -safe-mode

    So far, no crash. That may point to an extensions issue. We’ll see. I’ve only been up once for a few pages now in safe mode. BUT it works enough for causal use in any case!

    So I’m living on NetBSD for a while, and going to try it on a bigger, faster better cooled board next.

    Unix folks tend to be particularly fussy about doing anything that causes increased security risks, greater complications, or gratuitous code bloat, so SystemD will never come here. I’m good with that. The downside is they are slow to embrace a lot of stuff deemed intemperate. So you don’t get 20 different file systems supported. The newest Linux file system supported is ext2 (not even ext3.). OTOH, I’d never be bit by the “file conversion incompatibly without your consent” bug in the ext4 “improvement” nor the “change fstab and your board looks unbootably dead silently” systemD bad interaction with fstab.

    Oh, and I’ve learned that my Pure Unix Skills are a bit rusty (from about 20 years ago now) but still all is familiar and working fine… That’s how Unix is supposed to be. Predictable. Stable. Secure.

  5. E.M.Smith says:

    Looks like it is a sporadic bug. This was the error text in my command terminal window:

    arm64# firefox52 -safe-mode
    (firefox:271): GVFS-RemoteVolumeMonitor-WARNING **: 04:40:05.822: cannot open directory /usr/pkg/share/gvfs/remote-volume-monitors: Error opening directory ?/usr/pkg/share/gvfs/remote-volume-monitors?: No such file or directory
    (/usr/pkg/lib/firefox52/firefox:1021): GVFS-RemoteVolumeMonitor-WARNING **: 04:40:44.975: cannot open directory /usr/pkg/share/gvfs/remote-volume-monitors: Error opening directory ?/usr/pkg/share/gvfs/remote-volume-monitors?: No such file or directory
    too much recursion
    ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0083,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
    (/usr/pkg/lib/firefox52/firefox:1556): GVFS-RemoteVolumeMonitor-WARNING **: 04:41:44.390: cannot open directory /usr/pkg/share/gvfs/remote-volume-monitors: Error opening directory ?/usr/pkg/share/gvfs/remote-volume-monitors?: No such file or directory
    (firefox:271): Gtk-CRITICAL **: 04:54:14.308: gtk_clipboard_set_with_data: assertion 'targets != NULL' failed

    Re-launched in safe mode, crashed tab repeatedly with the same repeating error each time the tab crashed:

    ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0001,name=PBrowser::Msg_AsyncMessage) Channel error: cannot send/recv
    ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0083,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
    too much recursion
    ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0083,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
    too much recursion
    ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0083,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
    too much recursion
    ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0083,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

    Exiting and reloading, now it is behaving again. Don’t know if I’ll bother trying to debug this fat beast sucker, or not. But at least I’ve got error message text to search on.

  6. E.M.Smith says:

    FWIW, a place to download NetBSD images for particular SBC boards (instead of rolling your own from NetBSD base code)

  7. Taz says:

    Went a different route, but am watching your trailblazing carefully. Ended up buying a pile of used Atom boards….containing no Spectre vulnerabilities.

    And while it’s not as pure as your own hack, I find that Zorin variant of Ubuntu to be highly maintainable. Most of the problems others seem to find have bypassed us.

    Atoms are not very powerful. We retained our old Pentium M VPN gateways because the Atoms could only deliver 75%. Surprised me – because I expected at least parity.

    Excluding Spectre can be painful. Spectre weakness was introduced for a reason.

  8. E.M.Smith says:


    I’ve thought about going Atom just to avoid the “not on Intel” software desert problem. I might still for some things. Looks like ARM browsers on ARM may be a problem. Im going to check out Brave next.


    The install of NetBSD to the RockPro64 was relatively painless. Just dd the image to SD card and boot. It plays with itself for several minutes (do not interrupt, go get coffee & donut)

    I had to start the process from the slice site link at step one, install of pkgin, likely because I had done that on the Pine64 last year already…

    Then just “pkgin FOO” where FOO was gimp, libreoffice, htop, etc.

    I did find that “firefox52” was enough to get it installed, though without the language packs or other pkgs.

    Launching FireFox still gives me the tabs crashing bug, so not a heat or memory size on the Pine64 problem. IMHO, confirms a bug in a poorly QA checked port of Firefox. That is “hey, it compiled without aborting, so ship it”.

    Trying the Odroid XU3 port on the XU4 just never light up the screen on boot. Supposedly the 2 are 100% software compatible… so writing to serial consol or just not working?

    I’m going to try a v7 (32 bit) image next, likely the Pi or … to see if it is an aarch64 (v8 64bit) bug they didn’t catch in the port. If it works, I can likely install the v7 FireFox on the aarch64 OS.

    I’m also going to try FreeBSD on some board to see if they have a working Firefox. I’m not hung up on any particular BSD, it’s just that NetBSD runs on more platforms. Also, FreeBSD was still running v7 on most v8 systems last I looked (but maybe that’s a feature ;-)

    While I had originally intended to run heterogeneous hardware with homogeneous software of Debian: since SystemD (isaster) came along, that’s not possible. No one SystemD Free OS runs across most of my hardware / SBCs.

    So I’m going to run divergent software outside my cluster (and it will have fewer boards as libraries must match for distributed compiles. )

    I’m happy with some BSD for general server and systems management, plus desktop (other than browser). I’m leaving the file server Linux just to avoid converting 12 TB of disks to ufs from ext file systems.

    IFF I can get distcc, sql, Python all playing well together on some BSD, then the climate data and analysis stuff will go there on a small cluster. Oh, and FORTRAN ;-)

    So basically, Devuan on what is supported, BSD where it works well, Slackware on others, “whatever” everywhere else.

  9. E.M.Smith says:


    Logging in as an ordinary user, I’ve had a lot less crashed tabs. So far, only one and only when I was trying to simultaneously load this page AND the main page of (that is heavy with adds and other stuff).

    So maybe, just maybe, the FireFox bug is minor / only on heavy activity for ordinary users?

    We’ll see. I can live with loading one page at a time ;-)

  10. Taz says:

    Believe this was the last production Atom which was Spectre free.

    It’s no hotrod, but it’s no slouch either. Previously, Pentium Ms were my favorite GOTO for single board PCs. These Atoms are just a bit less powerful. I get full line speeds out of Pentium M VPN gateways…but only 70-80% with the Atoms. Believe the single threaded OpenVPN just demands too much from the Atom. OTOH, Atoms seem to like I2P. No problems there – very steady. Ditto Tor relays.Works fine as a router too.

    Haven’t tested exhaustively, but OS compatibility seems excellent. Comes with high end Realtek Gigabit – but I would have much preferred Intel. Realtec drivers are a PITA, and word on the street suggests they still aren’t competitive. Don’t have anything here capable of testing at that level tho.

  11. Taz says:

    Illian Omar ballot harvesting. Just spotted:

    [video src="" /]

  12. E.M.Smith says:

    Funny … I was planning to convert more to BSD what with SystemD screwing my home dir
    and Devuan moving ARM to community ported… so wanted a refresh on installing xfce… found a pingback to myself on the NetBSD site :-)

    So now “former me” is reminding “current me” how to do it and issues encountered….

    Basicslly I’m planning to abandon my (limited) use of Armbian on systems without Devuan. Armbuan had been protecting me from most SystemD screwage, but failed on home dirs. That implies all SystemD versions will do the same when next I update…. so my next non-Devuan updates are likely to be BSD.

Comments are closed.