Of course I didn't see any instructions for a 2-release upgrade, so the first thing was to upgrade stretch to buster. I basically followed the instructions in this article. As root:
- change “stretch” to “buster” in /etc/apt/sources.list
Casting all caution to the wind, I skipped the part about making a backup - apt-get update; apt-get upgrade; apt-get dist-upgrade
- reboot
26 # A comma separated list of IPs or hosts where to listen in for connections. 27 # "*" listens in all IPv4 interfaces, "::" listens in all IPv6 interfaces. 28 # If you want to specify non-default ports or anything more complex, 29 # edit conf.d/master.conf. 30 #listen = *, :: 31 listen = 127.0.0.2So when I tried "sudo dovecot", it said the ssl key couldn’t be found, and even gave me a pathname. So I commented it out in /etc/dovecot/conf.d/10-ssl.conf:
1 ## 2 ## SSL settings 3 ## 4 5 # SSL/TLS support: yes, no, required.I also decided that we don’t need SSL, since hey, 127.0.0.2.6 ssl = no ←was “yes” 7 8 # PEM encoded X.509 SSL/TLS certificate and private key. They're opened before 9 # dropping root privileges, so keep the key file unreadable by anyone but 10 # root. Included doc/mkcert.sh can be used to easily generate self-signed 11 # certificate, just make sure to update the domains in dovecot-openssl.cnf 12 ssl_cert = </etc/dovecot/private/dovecot.pem 13 #ssl_key = </etc/dovecot/private/dovecot.key ←commented out
I think I’ll have to do something about the scanner, but otherwise i believe phase I (Stretch → Buster) was pretty easy.
Phase II: Buster → Bullseye
The first part was straightforward but took ... a couple hours? As above, all these steps were done as root:- change /etc/apt/sources.list to refer to Bullseye rather than Buster
- apt-get update; apt-get ugrade; apt-get dist-upgrade
- reboot
And then…
“…something about the scanner” ⇐ THIS
So xsane couldn't find the scanner. I got some advice to “sudo scanimage -L” which found only another device (our renter's all-in-one).
A web search on “brother scanners linux” (no quotes) led me to Install the scanner driver (deb) - Linux - BrotherUSA, where I learned what to do, again as root:
collin@p64:~$ brsaneconfig4 -q
← nothing appeared here at all!
collin@p64:~$ sudo brsaneconfig4 -a name=mfc9340 model=MFC-9340CDW ip=192.168.1.40
collin@p64:~$ brsaneconfig4 -q
* *MFC-9340CDW [ 192.168.1.40] mfc9340 ← Now that’s more like it!
collin@p64:~$ sudo scanimage -L
device `brother4:net1;dev0' is a Brother mfc9340 MFC-9340CDW
device `escl:https://192.168.0.235:443' is a HP ENVY 6400 series [BA2627] SSL flatbed scanner
collin@p64:~$
And with that, the scanner works. Mail works. Browsers (both firefox and chrome) work. Maybe something else won’t, but that's all for today.
July 29 update: auto-sleep, crashplan
A new-ish feature in Bullseye (it may have come in with Buster?) is that the box will sleep if I walk away for 20 minutes or so. This is fine, except when I'm logged in over VPN and I'm using vmware horizon (yes i have to use that for work). I need to disable it when I'm at work, so I just leave the Settings app up, with Power settings selected. Then it's front and center and it's obvious to me that auto-sleep is either on or off. Usually I re-enable it when I'm done with work for the day.I got email yesterday or so, saying that my backups haven't happened since the OS upgrade. My first thought was, oh, it's because of being asleep. But then I turned off auto-sleep and tried logging in to the code42 app... no joy. After thrashing for a while, I went to the code42.com support site, where I couldn't login. Oh, I had forgotten that I'd already added google authenticator to firefox! I used it to get my magic rotating number and I was in. I saw the advice to reinstall the app. OK, fine; I downloaded the package, did what came naturally, and said: sudo /usr/local/crashplan/service.sh start
Which didn't work. I looked at /usr/local/crashplan/log/service.log.0 and... something about missing libuaw.so; a web search led me to this post on reddit with the answer: zcat the "CrashPlanSmb_10.0.0.cpi" file (it's in the downloaded tarball), find libuaw.so in the appropriate subdirectory of nlib/ (they didn't have "debian11" but the Reddit-or said ubuntu20, which thankfully worked) and copy it into /usr/local/crashplan/nlib; shazzam! up and running.
August 20 update: convert(1) issue solved; crashplan, not so much
I wanted to convert a ".png" file to PDF, as I have done many times before, but now I get:
convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.How annoying! A web search got me to this stackoverflow post; I followed its advice, but kept the old /etc/ImageMagick-6/policy.xml as /etc/ImageMagick-6/policy.xml-dist; here's the diff:
$ diff -u /etc/ImageMagick-6/policy.xml{-dist,}
--- /etc/ImageMagick-6/policy.xml-dist 2021-04-20 07:37:59.000000000 -0700
+++ /etc/ImageMagick-6/policy.xml 2022-08-20 20:19:06.962756505 -0700
@@ -90,10 +90,12 @@
<!-- in order to avoid to get image with password text -->
<policy domain="path" rights="none" pattern="@*"/>
<!-- disable ghostscript format types -->
- <policy domain="coder" rights="none" pattern="PS" />
+ <!--
And now, convert(1) can do everything I was accustomed to using it for.
Crashplan, though… I thought (from a few weeks back) that the service started so everything was good, but not so much! /usr/local/crashplan/log/engine_output.log ends like this:
Java virtual machine created. Starting service. [08.20.22 10:24:56.599 INFO main com.code42.utils.ClassFinder] Loaded classpaths in 1960 ms # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fc570a458a7, pid=326423, tid=326535 # # JRE version: OpenJDK Runtime Environment Temurin-11.0.12+7 (11.0.12+7) (build 11.0.12+7) # Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (11.0.12+7, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C [libuaw.so+0x1c8a7] std::filesystem::path::~path()+0x7 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /usr/local/crashplan/hs_err_pid326423.log [thread 326523 also had an error] # # If you would like to submit a bug report, please visit: # https://github.com/adoptium/adoptium-support/issues #WHOA, did you see that libuaw.so part up there? Do I maybe have a bad libuaw.so? It's late now, though, so maybe in another day or two I'll…
September 24 update: crashplan solved!
OK, so what happened last month was: I did more searching and read another reddit post which said that in 2019 (!) there was no excuse not to run apps in containers. Good point! But I didn't want to do that without learning more about containers. I mean, I can spell "runc exec -it <CONTAINERNAME> bash" (wait, did I get that right?) but beyond that…
I ordered and waited for my own personal copy of Docker: Up & Running 2/e then procrastinated… today I decided, better get to it. Now, where was that reddit post that pointed me at the container to…? Huh, couldn’t find it. Instead I re-found the reddit article linked above, but this time I noticed this comment:
Thanks a lot! Worked on Debian 10 with the ubuntu18 file and on Debian 11 with the ubuntu20 file.
WHOA; I’ve got debian11; which one did I install last month (which crashed)? Based on this output
$ ls -o /tmp/code42-install/nlib/*/libuaw.so -rw-rw-r-- 1 collin 486008 Aug 21 08:25 /tmp/code42-install/nlib/rhel7/libuaw.so -rw-rw-r-- 1 collin 243440 Aug 21 08:25 /tmp/code42-install/nlib/rhel8/libuaw.so -rw-rw-r-- 1 collin 232944 Aug 21 08:25 /tmp/code42-install/nlib/ubuntu18/libuaw.so -rw-rw-r-- 1 collin 52456 Aug 21 08:25 /tmp/code42-install/nlib/ubuntu20/libuaw.so $I evidently installed the rhel7 one. D’oh! Replacing it by the ubuntu20 one and crashplan is running, without having to do the container thing.
PS: the container thing is https://github.com/jlesage/docker-crashplan
