Category: opensuse

I dread upgrading OpenSuSE to a new version

This time is no different. Ugh.

It always breaks so much stuff.

I don’t understand why it’s so hard to keep the list of Image Magick delegates from one version to the next.

I don’t understand why it’s so hard to find how to add the delegates that were removed during the upgrade.

Today, I need to convert a PDF to a PNG and convert -version tells me I have support for

  • bzlib
  • lzma
  • x
  • xml
  • zlib

none of which are image related.

Of course, this work I need to do is time-sensitive, and instead of being able to get events published to the web site for this coming weekend, I’m having debug why Image Magick is broken again.

I’m an hour in, and it’s still broken, and there’s zero information on how to fix the problem. One person said “just install from xxxx and it just works” – no, it doesn’t.

It shouldn’t take an more than an hour to convert one file from PDF to PNG.

Sometimes I hate being on OpenSuSE.

To be fair, SuSE was always more geared to be a server operating system, on which one could install a desktop environment. And with server environments, one needs to be a little more careful than with a desktop environment. If I break something on a desktop: one person (me) is affected. If I break something on a server: a thousand people are affected. So SuSE doesn’t tend to rush to implement the latest / newest thing. It also imposes defaults that are more secure (less permissive) than you might find on something else.

But apparently during the upgrade, something was reset to not allow me to execute magick filename.pdf filename.png and I’m having a damned time figuring out how to fix that. There doesn’t seem to be a README file anywhere that explains it.

I assumed that when I went into YaST and added ImageMagick and Ghostscript that things would work. You know what you get when you assume, correct?

Wow OpenSuSE is terrible at iPhone photos

At first, it didn’t work. So I did some searching, and found that I needed to add ifuse musmuxd libplist and libimobiledevice. Okay, did that. It still doesn’t work.

I should mention that when I connected the iPhone, Gwenview would recognize a device had been plugged in, but would spit at me that protocol capture:/ was not recognized – both before and after the addition of these packages. This appears to have been a problem seven years ago.

Eventually I find that perhaps digiKam will do what Gwenview will not. Okay, add that.

DigiKam does see the photographs on the iPhone. Great! I should be able to download them now, right?

😝

All attempts to download (backup) the photos result in the question of “to where?” This is very reasonable.

Since this is a new installation of digiKam, there is no Album defined. The download dialog box has a button “New Album” but it does nothing. Probably in a log file somewhere, some programmer wrote out LOL, dumbass.

In the main digiKam window, the Album menu has all items greyed out (including the “New” album choice with Ctrl-N for the shortcut). LOL, dumbass.

Eventually, I learn to do Settings+Configure digiKam, Collections menu and choose Add Collection. Apparently a collection is the same as an album, or not, but it appears I now have a backup copy of one of the iPhone groups of photos. I’m just kind of amazed it was this hard, and by the way, KDE isn’t telling me anything about the progress of files copies (which in the olden days, it would).

Up in the upper right corner, though, is this really cool looking text, digiKam.org which has each letter in the domain name highlighted, from left to right. That’s cool – it’s like a throbber, but for the help button. Other than the Cancel button being lit up on the Apple Inc. iPhone window, I cannot tell if file transfers are happening or not.

And of course, hooray for random crashes while stuff is doing work.

Putting an image on a Raspberry Pi

  1. Download a .raw.xz file
    1. In this case, it was https://download.opensuse.org/distribution/leap/15.4/appliances/openSUSE-Leap-15.4-ARM-KDE-raspberrypi.aarch64.raw.xz
    2. Yes, I also downloaded the .sha256 file and ran sha256sum against the downloaded image to make sure the image file was not damaged during transfer.
  2. Open a terminal session and become root
  3. Determine which device the SD card is
    1. In this case, it was /dev/sdc
  4. Copy the image file to the SD card
 xzcat /home/david/Downloads/openSUSE-Leap-15.4-ARM-KDE-raspberrypi.aarch64.raw.xz | dd bs=4M of=/dev/sdc iflag=fullblock oflag=direct status=progress; sync

LibreOffice is working better now (somewhat), and I don’t know why

Okay, so I had a theme that wasn’t installed correctly, which made automatic updates for all of OpenSUSE complain they wouldn’t work. I did a re-install of everything KDE, and the missing theme dependency no longer prevents automatic updating from working seamlessly. Cool.

But, I saw the full re-install of KDE “upgraded” LibreOffice. Sure enough, I’m back to running version 7.1

Well, at least I have version 6.4 on disk, and could pretty easily downgrade if needed. Might as well try it out and see.

At first blush, I didn’t appear to have the problem. But, I’d seen that before. I moved the window to the secondary monitor, and the problem returned. Not cool.

But this time, if I move the LibreOffice window back to my primary monitor, the problem vanishes; the window returns to normal. That used to never happen: once the window layout was corrupted, no matter where I placed it, it remained corrupted.

So I can use the current version LibreOffice – I just need to use it on my secondary monitor. I’m okay with that. If that’s the worst thing I have to put up with this month, I’m a lucky guy.

Actually, I just started doing some SharePoint work. Already, I have way worse going on, and it has nothing to do with LibreOffice or KDE or OpenSUSE. 😉

LibreOffice broken – it’s version 7 that is broken, and the problem is multiple monitors

What confused me before is that sometimes it appeared to work, but then it would break again. I finally figured out that it was sliding the window from one monitor to the other that invoked the broken behavior.

I went back to the earliest version of LibreOffice that is “official”, and it was still broken. I went and got the latest version of LibreOffice 6, and it is no longer broken.

LibreOffice has been painfully broken on OpenSUSE KDE for a couple months now

And the solution was to install libreoffice-gtk3

I’m rather surprised that it remained so painful for so long. If I were a new user, I’d still be broken.

I don’t know what it takes to figure out that this package should be in the “required” list. Perhaps I installed something else that added GTK3, and now that it’s there, the LibreOffice UI became significantly damaged? Perhaps LibreOffice sees some GTK3 component and then runs as if libreoffice-gtk3 is present?

The result is that every LibreOffice document would open with a split in the middle of the document, and, the main menu was gone.

I had found a document that said that perhaps KDE dark themes were to blame, or were out of date. Man I fouled some things up chasing that wild goose. I also lost some documents I had built, as tried to delete bad configuration files that seemed they might be the problem.

Anyway, if your LibreOffice looks like this:

And you want it to look like this (with File menu and everything):

install the libreoffice-gtk3 module.

Need to print + OpenSUSE 15.3 upgrade – What could go wrong?

I needed to go to a new doctor yesterday. The day before, they had called and left a message that I would also need to bring along a list of my current pharmaceutical prescriptions. I got the bright idea to log in to the online pharmacy web page and print my current list. This is about 40 minutes before I need to step in to the home office to report to work.

It went poorly.

Still, if this is the worst thing to happen to me this month, I am a fortunate man. I’m a fortunate man who cannot print from Linux, but I’m still a fortunate man.

Certainly part of the problem is my fault; I had upgraded from OpenSUSE 15.2 to 15.3. 15.3 was released two weeks ago; I upgraded about ten days ago. This was not enough bake time. I should have listened to my own advice: do less yeet and more tootle. But yeeted I had, so the story unfolds ….

Okay, so I logged in to the pharmacy web page, and used the browser to print. Got no printer noises, but no error about anything, either.

The print driver I’m using is from OpenPrinting.org and it did previously work. I did print something three weeks ago. But today, nada.

Go into the printer manager in OpenSUSE 15.3 and do a test print. No printer noise, but no error alert either. It asks if the print worked; (no) so says do journalctl to see what went wrong.

I don’t like journalctl. It spits at me about permissions, and I used to just be able to just grep a log file – any log file – and search for terms like “error” or “warn” or “cups”. I just want to print, man.

Okay, dig in and find that there is an error with the driver. Reinstall the driver. The driver will not install.

The driver is dependent on LSB. LSB = Linux Standard Base, which was the idea that the various packagers of Linux would all agree on what should be in a base install of Linux (that supports LSB). Software vendors could count on the base packages being there, or worst case say, “this software needs LSB, please install it”.

I had previously installed LSB (to get the printer to work), but now it’s missing. That must have happened during the 15.2 to 15.3 upgrade.

Okay, no big deal: zypper in lsb

Problem: nothing provides ‘/usr/bin/pidof’ needed by the to be installed lsb-foo

Well that’s darling. It’s a bug, and it is fixed in OpenSUSE Factory. I just want to print, man, and it’s now 20 minutes before work.

Okay, go to the fallback position: print to PDF, copy the file to a Winders box, and print from there.

I have Nextcloud client installed and running on most of my machines. Copy the file to my Nextcloud folder. Go to a Windows machine – there are no new files in the Nextcloud folder. Machine is acting wonky anyway, so I reboot (yeet!)

  1. Microsoft decided I needed a Weather widget in my taskbar, so they inserted one without asking. I need to lose some time praying to remove the murderous rage I have toward Microsoft for being so un-invitingly forcefully helpful.
  2. Nextcloud client has an update, would I like to install? Yes, please. What was that about less yeet and more tootle?
  3. Nextcloud client version 3.2.2 is no longer compatible with your older Nextcloud server. Have a nice day!
  4. It is now 10 minutes before work. I just want to print, man; my travel time to the doctor did not pad with lead time for print fixing, and as the famous mage once said: “Outlook not so good”.

Okay, what about the web page version of the Nextcloud server? Right, dang, I forgot I was going to need my physical 2nd Factor authentication key. Back to the living room to get it.

Logged in on the Windows box. The file is not there.

Dang it! The Nextcloud client on my Linux box has the same version problem. Back to the living room, open up the Nextcloud files web portal, do the physical physical 2nd Factor authentication thing and copy the file up. Back to the home office, open the PDF in the Nextcloud files web portal in Firefox and hit the print button. Finally, noise from the printer in the living room.

Put on a shirt and my shorts, get an energy drink out of the refrigerator, and I’ve got 30 seconds to spare.

“One does not simply press print”

Next week, I’m going to install a firewall router!

OpenSUSE 15.1 → 15.2 upgrade; with nVidia it’s a disaster due to nouveau

Upshot is, the installer has two different options depending on if you are in graphical mode (init 5) versus text mode (init 3). Graphical mode (which was not recommended) at least had the possibility of working.

Back story: at work more than a decade ago, the whole team got new computers, but one of my co-workers preferred his MacBook laptop. After his PC sat unused for a couple years, I got the idea to ask him if he minded me having his dual monitors. He was okay with that. Of course, to drive those two monitors, one needs a dual monitor video card, so I took that too.

Now my machine had two identical video cards and four identical monitors. It was pretty sweet. The nVidia drivers had handled that just fine. Well, until ….

Then some upgrade happened (in 2017), and suddenly the nVidia driver could only light up one of the two video cards. I really liked having four screens, so I went and bought a single nVidia card with four outputs – NVIDIA Quadro P600. Life was good.

However, with this configuration, all the upgrades to OpenSUSE since then are just miserable. This weekend, I tried again. Awful, as usual.

The problem is that the install wants to replace the nVidia (proprietary) driver with the nouveau (open source) driver, but that never works right.

The other, bigger, problem is that if (in text mode) you don’t agree to let nouveau foul over your machine, you don’t get to upgrade at all.

I’ll try to illustrate the steps:

In text only mode: zypper dup, and at the end I was warned that the nouveau driver was going to be used. The prompt says “do you agree? yes/no: “

If you type “no”, the upgrade stops.

If you type “yes”, the upgrade continues and then trashes the graphical mode configuration. It installs the nouveau driver which doesn’t work with a single card and four monitors.

After banging my head against the problem for too long, it gets time to give up, download the ISO, burn a DVD, boot off the DVD, and choose “install” – completely wiping out all sorts of needed stuff. 🙁

But doing that (a fresh install), I get a graphical install. I get to the point where one of the prompts warned that the nouveau driver was going to be used. The prompt says “do you agree?” There are two buttons: “I agree” and “I disagree”. But most importantly, there is a checkbox for “Install using software emulation only”

That checkbox disables nouveau from breaking the system. Well, it disables nouveau completely, which prevents the system from being broken by nouveau. During the install, I saw a log line that nouveau was being locked from zypper updates, and that a blacklist entry was being added for nouveau to prevent start up.

Finally, I had a system that would boot. It wasn’t particularly stable, but at least it could boot and present the graphical login prompt. The graphical session wasn’t stable or working well, but at least it wasn’t booting to a single blinking text cursor in the corner of one monitor.

It turned out it was easiest to ssh in from a different machine, run the zypper command to add the nVidia repository, and install the nVidia proprietary drivers.

One more reboot later, and I’ve got a stable, four monitor, graphical environment once again. Hooray! 😀

One thing a person should always to with Linux: use a separate hard drive for /home

This way, installing a new operating system (whether it is Mint, OpenSUSE, Kubuntu) does not mess with your files. The new install sticks to the Operating System disk, and doesn’t mess with your /home disk.

So, all my VM guests are fine, my Perl scripts are fine, my login environment (KDE) is fine. That’s all good.

What’s bad about replacing the OS because the upgrade trashed the system is that my personal crontab file is not stored under /home.

I didn’t remember to go find and back up that file, so now it’s gone. I’m going to have to re-invent it from memory. All the scripts I write output log files; but, those get written to /var/tmp – which also gets wiped out when a fresh install happens.

Although I had printed the names of all the repositories I use (and put that file on /home) I was in a hurry and didn’t realize that the screen didn’t list the URLs. Whoops.

And of course, since the way out of the broken system was a fresh install, all the Perl modules I’ve installed in the last few years need to be discovered and installed again.

But, I’m running OpenSUSE Leap 15.2 now. Leap 15.1 is planned to go end-of-life next month, so I thought it about time to get to 15.2. That’s done, but man was it painful.