Diagnosing hardware driver installation issues in Silverblue

[joefidler]

While trying find-my-way with Silverblue I have had issues understanding why a driver install for an Epson scanner using rpm-ostree is failing. The install fails with an error reporting that /var/lib is not writable, but it looks like it is (and isn’t it supposed to be in SilverBlue or I am just getting this all wrong?). The problem appears to be specific to this rpm, but I am not sure how to diagnose that (or even maybe put a case to the vendor) in an rpm-ostree context.

This is what I am trying to do

$ sudo rpm-ostree install iscan-plugin-perfection-v370-1.0.0-2.x86_64.rpm

Which returns this error after running the rpm’s post script

error: Running %post for iscan-plugin-perfection-v370: Executing bwrap(/bin/sh): Child process killed by signal 1; run journalctl -t 'rpm-ostree(iscan-plugin-perfection-v370.post)' for more information

Journalctl shows

Aug 16 07:14:23 silverblue30 rpm-ostree(iscan-plugin-perfection-v370.post)[1481]: mkdir: cannot create directory ‘/var/lib/iscan’: Read-only file system

Aug 16 07:14:23 silverblue30 rpm-ostree(iscan-plugin-perfection-v370.post)[1481]: /usr/sbin/iscan-registry: line 155: /var/lib/iscan/interpreter: No such file or directory

A listing of /var/lib shows that /var/lib/iscan has not been created and hence the interpreter file cannot be written there.

I can manually create the directory.

$ sudo mkdir /var/lib/iscan

$ ls -aol /var/lib/iscan*
/var/lib/iscan:
total 8
drwxr-xr-x. 2 root 4096 Aug 16 07:28 .
drwxr-xr-x. 50 root 4096 Aug 16 07:28 …

/var/lib/iscan-data:
total 8
drwxr-xr-x. 2 root 4096 Aug 15 06:03 .
drwxr-xr-x. 50 root 4096 Aug 16 07:28 …

Looking at the rpm’s the post script

$ rpm -qp --scripts iscan-plugin-perfection-v370-1.0.0-2.x86_64.rpm
postinstall scriptlet (using /bin/sh):
iscan-registry --add interpreter usb 0x04b8 0x014a
/usr/lib64/iscan/libiscan-plugin-perfection-v370
/usr/share/iscan/esfwdd.bin
preuninstall scriptlet (using /bin/sh):
iscan-registry --remove interpreter usb 0x04b8 0x014a
/usr/lib64/iscan/libiscan-plugin-perfection-v370
/usr/share/iscan/esfwdd.bin

Manually executing the command in the post script works and creates the interpreter file.

$ sudo rm -r /var/lib/iscan

$ sudo iscan-registry --add interpreter usb 0x04b8 0x014a /usr/lib64/iscan/libiscan-plugin-perfection-v370 /usr/share/iscan/esfwdd.bin

$ ls -l /var/lib/iscan*
/var/lib/iscan:
total 4
-rw-r–r–. 1 root root 107 Aug 16 07:35 interpreter

/var/lib/iscan-data:
total 0

Because of this I am wondering if the error reported is a “true” message, in that it really relates some to other permissions that are required in an os-tree context. For example using bwrap to spawn the iscan-registry command.

Previous to installing this rpm I was successfully able to install (with rpm-ostree) 2 other packages required to install the scanner, including the one that creates the directory /var/lib/iscan-data. I have used these rpms to sucessfully install and use the Epson scanner in a Toolbox using dnf commands. Currently this is how I am scanning, but for me it seems a bit of a clunky way to do it, and I can’t use flatpak’ed scanning apps (Vuescan etc).

I will probably have a go at editing and re-building the rpm so I can get my scanner setup the way I want (another learning curve for me), but also want to understand a bit about what is the correct approach to dealing and diagnosing with system drivers in a containerized environment. Also Epson is a common scanner brand so it would be good to understand things from a Silverblue point-of-view as well. Any suggestions are very welcome, cheers Joe.

[expectation (John Rory O'Dwyer)]

Hi Joe

Here is the solution I am using with my V600 Epson scanner.

Like you I installed the iscan-plugin in toolbox. I like to use the simple-scan application and so I installed this in toolbox as well.

toolbox enter
sudo dnf install simple-scan

I found it annoying to have to go to the command line and enter toolbox and then run simple-scan from there

toolbox enter
simple-scan

So I found the following away around this.

I created a desktop file in ~/.local/share/applications/ in my home directory called simple-scan.desktop.

Here’s the contents:

[Desktop Entry]
Version=3.34
Type=Application
Name=Simple Scan
Comment=Access and use your scanners
Icon=scanner.png
DBusActivatable=true
Exec=toolbox run bash -c “simple-scan”
Actions=
Categories=Scanner;Core;GNOME;GTK;
Keywords=Scanner;
StartupNotify=true

Note the line above in the desktop file:

Exec=toolbox run bash -c “simple-scan”

You can also use this line instead:

Exec=toolbox run -c simple-scan %f

This will call simple-scan for me from toolbox.

I also copied the gnome icon set folder from /usr/share/icons/ to ~/.local/shar/icons/ in my home directory

There is a scanner icon called scanner.png in this icon set hence the line

Icon=scanner.png

So now I have a nice icon in overview in gnome

that launches simple-scan for me

I hope this information is useful to you or anyone coming across this thread.

[joefidler]

Hi gn0mish,
I ended up using the toolbox run --container command as a work around for this issue (but didn’t take the time to do a great write-up like you have). I used this method for several months and fully agree it gives a nice clean solution to this issue. Problem was I started depending on Toolboxes. So when my toolboxes regularly stopped working - requiring re-installs etc, I had to go back to regular Fedora. I haven’t looked recently at how things are going with toolboxes but if they are getting more stable I may be heading back into Silverblue in a few months.
Thanks again for documenting this - it’s a very useful method for getting around all sorts of issues in a containerized environment.

[jakfrost (Stephen Douglas Snow)]

Hello @joefidler,

The issues around toolbox are normally due to buildah and podman being out of sync, also a recent issue was related to a change in crun. I have been blessed for some time with no issues with my toolbox containers (likely jynxed it now), although others seem to be finding all sorts of problems, that ultimately boil down to an update of one of either podman/buildah/crun breaking something and seem to get fixed pretty quickly right now. You can imagine that would be the case since Silverblue is presented as a Fedora workstation with a container workflow. I think as things mature, stability wil ensue.

[joefidler]

Hi jakfrost, Yes that was my experience with toolboxes - an update would break something and I would have to re-create the toolbox container - from scratch. Sometimes that process can involve extensive installs of drivers, dependencies etc. I wish there was a more robust process for managing toolbox containers. That way we could create backups, portable copies and even document the contents of toolboxes (what has been installed etc). For me the concept of a containerized environment that a user can create and customize, is very cool.

[jakfrost (Stephen Douglas Snow)]

I haven’t explored any of podman plugins or near enough of it’s commands, but I know that if you update it’s version you usually have to use podman system migrate <option> to migrate your containers to the new podman version, the only option is for a --new-runtime <runtime>. This command was needed by me recently (I think a month ago or there abouts) for the changes done to podman. There is also skopeo which is used for inspecting/deleting/copying your images.
If you were to be ultimately satisfied with a particular toolbox you created, you could use podman export to even export that containers filesystem contents as a tar file. Later, you could import that filesystem tarball into any other container with podman thus restoring your filesystem to it’s desired state, or so I am led to believe not having tried it yet.

[joefidler]

Good idea - until you mentioned it jakfrost I hadn’t though of using Podman to migrate a toolbox (seems obvious now). Problem was that the way my toolboxes broke meant I could not start/enter them - and I had now way of knowing that would happen until it did, or what had caused the issue. The Podman migrate option may have worked however - thanks for the suggestion on that. Was not aware of skopeo which also sounds interesting - again thanks - more stuff for me to look into when I try SB again.