This error message comes from /usr/bin/scanimage tool. There is similar upstream bug report like <https://sourceforge.net/p/gscan2pdf/mailman/message/26761830/> that claims this is a bug in the HP sane driver.

I don't have any real scanner neither your one to debug it. It works for me with "test" scanner driver that emulates a basic scanner.

If you run gscan2pdf with --debug option, you should see a lot of debugging messages in the terminal you executed gscan2pdf from. Once you click the "Scan" button, you should see in the terminal something like this:

INFO - rotate reverse 0
INFO - unpaper 
INFO - OCR 1
INFO - threshold-before-ocr 
INFO -  scanimage  --device-name='test:0' --batch --progress --batch-start=1 --batch-count=1
INFO - Forked PID 7897
INFO - Scanning 1 pages from 1 with step 1
DEBUG - signal 'started-process' emitted with message: Scanning page 1 of 1
DEBUG - $VAR1 = [];

DEBUG - Free space in /tmp/gscan2pdf-zWx6 (Mb): 496.32421875 (warning at 10)
INFO - Importing scan with resolution=50
DEBUG - signal 'finished-process' emitted with data: scan_pages
INFO - Waiting to reap process
INFO - Reaped PID -1
INFO - Header suggests 30807
INFO - Expecting 30807, found 30807
INFO - New page filename /tmp/gscan2pdf-zWx6/out1.pnm, format Portable anymap
INFO - Added /tmp/gscan2pdf-zWx6/PV8obpxC0e.pnm at page 1 with resolution 50

The important line is the "scanimage  --device-name=" line and few lines after it. In your case, you should see the same "Error during device I/O" error message there.

If you execute the whole "scanimage" command from terminal, does it also return the same error? If you change the Source in the gscan2pdf interface, the scanimage command in the log should gain a new --source option something like "--source='Normal'" or "--source='ADF'". If you add the option to the scanimage command, does it behaves the same way as gscan2pdf? That means does it fail with the flatbed value, but does it work with the ADF value?

Also you can try change the scanning frontend in the gscan2pdf. There is an option accessible from the main menu Edit → Preferences → Scan Options → Frontend. Try different value other than "scanimage". Maybe "libsane-perl" could help.

(In reply to Petr Pisar from comment #1)
> If you execute the whole "scanimage" command from terminal, does it also
> return the same error? 

Yes.

> If you change the Source in the gscan2pdf interface,
> the scanimage command in the log should gain a new --source option something
> like "--source='Normal'" or "--source='ADF'". If you add the option to the
> scanimage command, does it behaves the same way as gscan2pdf? That means
> does it fail with the flatbed value, but does it work with the ADF value?

Yes.

Case 1: When scanning using the ADF feature via the GUI, the debug output shows the following command as having been issued:

scanimage  --device-name='hp:libusb:005:005' -y 279 --source='ADF' --batch --progress --batch-start=1 --batch-count=1
Scanning 1 pages, incrementing by 1, numbering from 1
Scanning page 1
Scanned page 1. (scanner status = 5)

The result is the same regardless of whether this command is generated by the GUI or whether I issue it at the command line.  The scan is successful.


Case 2: When scanning using the "Normal" source via the GUI (aka scanning from the flatbed), the debug output shows the following command as having been issued:

scanimage  --device-name='hp:libusb:005:005' -y 279 --batch --progress --batch-start=1 --batch-count=1
Scanning 1 pages, incrementing by 1, numbering from 1
Scanning page 1
scanimage: sane_start: Error during device I/O

The result is the same regardless of whether this command is generated by the GUI or whether I issue it at the command line.  The scan fails.


Case 3:  I noticed that the command in Case 2 looks just like the command in Case 1, with the notable exception that "--source='normal'" is missing.  I tried adding it to yield the following command, issued from the command line:

scanimage  --device-name='hp:libusb:005:005' -y 279 --source='normal' --batch --progress --batch-start=1 --batch-count=1
Scanning 1 pages, incrementing by 1, numbering from 1
Scanning page 1
scanimage: sane_start: Error during device I/O

The result in Case 3 was failure as in Case 2; adding "--source='normal'" didn't have any effect.

Thank you for confirming my hypothesis. Indeed it's a bug in the /usr/bin/scanimage or in the hp driver. Both of them are delivered by sane-backends package. Therefore I move this bug report there.

More information:

With the default backend (scanadf) I was able to use the ADF on the scanner but not the flatbed.

I changed to scanimage and got the same result.

I changed to libsane-perl and now both the ADF and the flatbed are working -- with a new bug that has resurfaced, which has been present for a long time.  When using the ADF, I have to click on the Scan button twice.  The first time always produces the following error:

"gscan2pdf: sane_start: Error during device I/O"

Simply closing the pop-up dialog and clicking the Scan button in the GUI fixes the problem.  This happens every time that I use the program, and this problem cropped up in F23's version of gscan2pdf.  With older versions of Fedora, clicking on Scan goes right to scanning.  With newer versions I have to click twice, first to get the error, then close the pop-up, then again to actually do the scan.  Subsequent scans only require 1 click.  It would seem that there is a bug in the libsane-perl handshake with the device.

Hi Bob,

it seems as if your scanner is server by the "hp" backend, which unfortunately is unmaintained upstream so we can't expect much help debugging the issue there. As it's a USB device, changes in the kernel stack could also come into play, with the driver unmaintained (and assuming it hasn't been changed much or at all), this could be a probable source for your problem, too.

Can you say with which Fedora, kernel and sane-backends versions your device still worked properly?

Just to clarify about the status of the two bugs:

1. The bug where ADF works but the flatbed does not:  this bug is fixed with the workaround provided in the version update that was pushed to stable.  Thanks.

2. The bug where establishing the USB comm link with the scanner itself fails initialization on the first attempt to click the on-screen "scan" button, but works after closing the resultant error dialog and clicking the "scan" button a second time:  this bug remains following the version update.

Regarding which Fedora, which kernel, and which sane-backends versions I was using when the device worked properly:

This is a difficult question to answer.  I never kept detailed logs about this problem.  Realistically speaking, bug #2 above, where I'm required to click on the scan button, close the error dialog, and click on the scan button a second time -- my best recollection is that this bug came along somewhere around F20 or F21.  Because there was a workaround that involved just closing the error dialog and clicking "scan" a second time, I never worried too much about it, documenting it, or reporting it.  I just jumped through the hoops every time I needed to use the scanner.

The problem where the backends "Scanadf" and "scanimage" fail to work with the device have been a problem for as long as I can remember ... probably going back to F17 if not farther.  To my recollection HP support has never worked out of the box and has always required a manual change of the backend.  This is the kind of thing that I keep forgetting, and I have to look it up on the forums every time that I do a verison upgrade/reinstall.  AFICT from the errors and forum solutions, the HP scanners have always in recent history required the use of the libsane-perl backends.  It would be quite helpful if the program could be modded to automatically select the libsane-perl backend when an HP scanner is detected, as IME no other backend will work with an HP scanner.

To try to get a better handle on the Which Fedora, Which Kernel, Which Backend question, I tried reinstalling some hardware on bare metal/blank drives.  

* I was hoping that I could test the software on RHEL 7.2 (actually, Scientific 7.2) but gscan2pdf isn't in the standard repo so install was not an option.

* I would like to go back and try loading F20, F21 and F22 to give you the answer, but I'm trapped by the unfortunate circumstance I now have hardware that which effectively blocks installs of those releases due to video driver support issues. Anaconda/nouveau yielded a lot of blank screens with those releases.

Sorry for the late response.

As to the use of "libsane-perl" as the default frontend in gscan2pdf, it looks as if this is the case with  both gscan2pdf-1.3.9-3.fc24.noarch and gscan2pdf-1.6.0-1.fc25.noarch (I've tried this on Fedora 24 and 25, respectively). That leaves the issue that other frontends that don't use libsane-perl as an intermediate (e.g. scanimage) don't work with your scanner, right?

If so, then I'd say comparing what libsane-perl as an intermediate layer does differently is more promising than trying to resurrect some age-old Fedora version on your hardware.

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

needinfo request was answered in comment 6.