Installing iscan drivers for Epson XP-225 Printer

Ask Fedora
1

I am trying to install on FD43 the iscan-bundle-2.30.4.x64.rpm from Epson as follows -

tar xaf iscan-bundle-2.30.4.x64.rpm.tar.gz
cd iscan-bundle-2.30.4.x64.rpm
./install.sh
But it fails as follows -

Installing:
iscan x86_64 2.30.4-2 @commandline 1.3 MiB
iscan-network-nt x86_64 1.1.2-1 @commandline 121.3 KiB

Transaction Summary:
Installing: 2 packages

Total size of inbound packages is 461 KiB. Need to download 0 B.
After this operation, 1 MiB extra will be used (install 1 MiB, remove 0 B).
Running transaction
Transaction failed: Rpm transaction failed.
Warning: skipped OpenPGP checks for 2 packages from repository: @commandline

  • package iscan-2.30.4-2.x86_64 does not verify: no digest
  • package iscan-network-nt-1.1.2-1.x86_64 does not verify: no digest

Any help would be appreciated

2 
tar -x -f iscan-bundle-*.tar.gz
sudo dnf install iscan-bundle-*.rpm/*/*.rpm \
    --no-gpgchecks --setopt=tsflags=nocrypto
3

iscan-bundle-2.30.4.x64.rpm has now loaded but Epson Scan 2 fails as follows b UID: 1000 (phil)
GID: 1000 (phil)
Signal: 6 (ABRT)
Timestamp: Sun 2026-08-30 11:37:36 BST (7s ago)
Command Line: epsonscan2
Executable: /app/bin/epsonscan2
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-flatpak-net.epson.epsonscan2-2060000338.scope
Unit: user@1000.service
User Unit: app-flatpak-net.epson.epsonscan2-2060000338.scope
Slice: user-1000.slice
Owner UID: 1000 (phil)
Boot ID: 7b15c7cf9eca4d6a9914ee7c25517c49
Machine ID: 1907d850afed42d7bbdb09f5c467181b
Hostname: fedora
Storage: /var/lib/systemd/coredump/core.epsonscan2.1000.7b15c7cf9eca4d6a9914ee7c25517c49.5842.1788086256000000.zst (present)
Size on Disk: 4M
Message: Process 5842 (epsonscan2) of user 1000 dumped core.

            Stack trace of thread 49:
            #0  0x00007f19b429d51c n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x9c51c)
            #1  0x00007f19b42433be n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x423be)
            #2  0x00007f19b422a8ed n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x298ed)
            #3  0x00007f19b422b958 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x2a958)
            #4  0x00007f19b432a889 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x129889)
            #5  0x00007f19b432a1e4 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x1291e4)
            #6  0x00007f19b432bcfb n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x12acfb)
            #7  0x00007f19b5d648b2 n/a (/app/lib/x86_64-linux-gnu/epsonscan2/libcommonutility.so + 0x608b2)
            #8  0x00007f19b5d66f1a n/a (/app/lib/x86_64-linux-gnu/epsonscan2/libcommonutility.so + 0x62f1a)
            #9  0x00007f19b5d63f45 n/a (/app/lib/x86_64-linux-gnu/epsonscan2/libcommonutility.so + 0x5ff45)
            #10 0x00007f19b5d64102 n/a (/app/lib/x86_64-linux-gnu/epsonscan2/libcommonutility.so + 0x60102)
            #11 0x00007f197d970e1c n/a (/app/lib/x86_64-linux-gnu/epsonscan2/libes2command.so + 0x186e1c)
            #12 0x00007f197d8b33bd n/a (/app/lib/x86_64-linux-gnu/epsonscan2/libes2command.so + 0xc93bd)
            #13 0x00007f197d8b3912 n/a (/app/lib/x86_64-linux-gnu/epsonscan2/libes2command.so + 0xc9912)
            #14 0x00007f197d8b3fe5 n/a (/app/lib/x86_64-linux-gnu/epsonscan2/libes2command.so + 0xc9fe5)
            #15 0x00007f197d8858c4 n/a (/app/lib/x86_64-linux-gnu/epsonscan2/libes2command.so + 0x9b8c4)
            #16 0x00007f19b429b56a n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x9a56a)
            #17 0x00007f19b431ee54 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x11de54)
            ELF object binary architecture: AMD x86-64
4

Check if the issue persists in permissive SELinux mode:

sudo setenforce 0
gtk-launch iscan.desktop
5

Thank you very much for your help sudo setenforce 0 fixed it scans o/k now

6

That puts selinux into permissive mode. It should still log entries when selinux sees something it would block when in enforcing mode, and that should lead you to the actual factor that was previously preventing scanning.

The command sudo setenforce=0 is a temporary fix that only lasts until the next boot so it is, at best, only a temporary workaround.

You can usually look at the selinux messages in journalctl with
journalctl -b -N -g audit where you replace the N with the actual boot session you want to review. N for the current boot is 0, the previous boot is -1 and so on back to earlier boots.