If you are using an HP network scanner on Ubuntu and experiencing unstable behavior during scanning (especially multi-page scans failing partway through), you are not alone.

A common issue with HP LaserJet MFP devices on Linux is that scanning appears to work initially but then fails after several pages. The scanner physically runs, but no output is produced in the software, and the system often only recovers after a reboot.

This article explains the real cause of the problem and how to permanently fix it by switching from the legacy HP driver stack to AirScan.

Symptoms of the Problem

The issue typically looks like this:

• Scanner is correctly detected in Ubuntu
• Single-page scans work normally
• Multi-page scans fail after a few successful pages (often around 8–10)
• The scanner physically scans the document, but no image appears in the application
• Restarting the scanning application does not help
• Only a full system reboot temporarily restores functionality

At first glance, this looks like a network or hardware issue. In reality, it is caused by the scanning backend configuration.

Understanding the Cause

On Ubuntu, HP scanners can be accessed through multiple backends at the same time:

• AirScan (modern eSCL-based network scanning)
• ESCL (raw eSCL interface)
• HPLIP / hpaio (legacy HP scanning backend)

The key issue is that the system may default to using the legacy HPLIP backend even when a modern AirScan interface is available.

The real problem: HPLIP instability

The HP Linux Imaging and Printing system (HPLIP) includes a scanning backend called hp / hpaio. While historically important, it is increasingly problematic for modern network-connected HP devices.

In this case, the issues observed were caused by the HPLIP backend:

• It maintains internal session state across scans
• It can fail after repeated scan jobs
• It may corrupt or lose the image data stream
• It can leave the scanner backend in a broken state until system restart

This explains the key symptom: the scan physically completes, but no data is returned to the system.

Why AirScan Works

AirScan uses the modern eSCL protocol (used by most newer HP network printers). Unlike HPLIP, it works in a much simpler and more reliable way:

• Each scan is stateless
• Communication is handled over standard HTTP
• No persistent session state is required
• No vendor-specific backend logic is involved

Because of this, AirScan avoids the instability seen in the HPLIP stack.

How the Issue Was Diagnosed

The first step was to identify which scanner backends were active:

scanimage -L

This showed multiple available backends, including:

• airscan (eSCL-based)
• escl (raw interface)
• hpaio (HPLIP backend)

To isolate the issue, each backend was tested directly.

AirScan test

scanimage -d airscan:e0:DEVICE_NAME --format=png > test.png

Result: stable and reliable scanning.

HPLIP test

scanimage -d hpaio:... --format=png > test.png

Result: immediate failure or I/O errors.

This confirmed that the issue was not related to the scanner hardware or network, but specifically to the HPLIP backend.

The Fix

The solution was to remove the legacy HP scanning backend and rely exclusively on AirScan.

Step 1: Remove HPLIP scanning components

sudo apt remove hplip libsane-hpaio

Step 2: Verify available scanners

scanimage -L

After removal, only AirScan-based devices should remain.

Step 3: Confirm stable operation

scanimage -d airscan:e0:DEVICE_NAME --format=png > test.png

At this point, scanning becomes stable even for multi-page documents.

Results After Fix

Once the HPLIP backend was removed:

• Multi-page scanning became stable
• No more silent scan failures
• No need to reboot the system
• Ubuntu scanning applications worked normally again
• Only AirScan was used as the scanning backend

Key Takeaways

• Seeing multiple scanner backends in Ubuntu is normal
• The presence of HPLIP does not mean it is the best option
• Modern HP network scanners should use AirScan whenever available
• HPLIP scanning backend can cause instability on repeated or multi-page scans
• Removing legacy backends can significantly improve reliability

Conclusion

This issue was not caused by Ubuntu, the scanner hardware, or the network connection. The root cause was the interaction between a modern HP network scanner and a legacy scanning backend (HPLIP) that is no longer well suited for this type of device.

Switching fully to AirScan resolved the instability completely and restored reliable scanning behavior.

Anyways, enjoy the first article, more to follow soon :) (or in a couple of months, we'll see ;) )

The C64 users always had an inconvenient little problem with the machine – lack of convenient reset button. They devised a lot of different minor and major modifications to solve that problem. There’s a lot to say about all of them, but one has speciffically caught my attention and I decided to apply it in my own modded C64C.

I’m talking about a small project, that I’ve found while browsing through C64 websites. It’s author cleverly used  a cheap and highly available Atmega microcontroler circuit – Arduino Pro Mini.

Original article can be located here: http://www.breadbox64.com/blog/switchless-reset-mod/, but I’ll describe a version that I’ve updated with a few minor tweaks.

The concept is simple, we upload a program into the circuit, which based on input signals (in this case the RESTORE button press) controls the signals sent to Commodore`s motherboard resulting in warm or cold reset and state changing on an address line of optionally installed EEPROM memory.

Beware! Before you grab a soldering iron and happily decide to install the modification in your favourite C64 remember, that any hardware alteration can lead to unintended damage.

What will be required for this project?

A USB capable PC, which will run the official Arduino toolkit (https://www.arduino.cc/). Of course the Arduino Pro Mini circuit is the key element of this project. When purchasing, take care to select the correct version. There are two variants, one runs on 5V and the other on 3.3V. Since the Commodore 64 also uses 5V, it’s necessary to choose that version.

To be able to program the circuit we’ll also need an USB to RS232 adapter (don’t confuse one with UART programmer, which looks almost identically). I recommend FDTI232 programmers, which work without a hitch on the latest OS’es and are also equipped with DTR output,  allowing automatically reset the Arduino before programming begins. Unfortunately most of available tutorials fail to mention that and asks the user to manually press reset button in a very speciffic moment, which is very tedious and can cause a rageous reaction, when you’re attempting to sync it correctly for the twentieth time.

Aside those two devices we’ll also need 5 or 6 wires to connect all the necessary signals, depending on if we also want to use the rom selector.

Programming the Arduino

After installing the toolkit and adapter driver, start up the Arduino IDE and paste in the code listing attached with this article.

Now let’s connect the Arduino Pro Mini in a following fashion:

- ground on the adapter to ground of Arduino,

- Vcc on the adapter to Vcc on Arduino,

- Rx on the adapter to Tx on Arduino,

- Tx on the adapter to Rx on Arduino,

- DTR on the adapter to DTR or Reset on Arduino.

Next select propper circuit board from the menu Tools > Circuit board… > Arduino Pro or Pro Mini. The processor we’re using Tools > Processor… > Atmega 328p (5V, 16MHz) and the adapter Tools > Programmer > AVRISP mk II.

If everything was configured and connected correctly, after pressing Upload button, the Arduino should blink it’s diodes a few times and the IDE will notify us that the upload was successful. If any error occurs, make sure all the steps up to now were done correctly.

Installation

Now it’s time to proceed with the hardware part of the solution. We have to connect the board accoarding to the following scheme:

• Vcc on Arduino to +5V line on the C64 motherboard,
• GND on Arduino to GND on the C64 motherboard,
• A0 analog I/O line to RESTORE button line on the C64 motherboard,
• digital I/O line 3 to CPU Reset line on the C64 motherboard,
• digital I/O line 4 to /EXROM line on the C64 motherboard,
• digital I/O line 5 to leg 27 of the EEPROM memory (optionally).

Sounds complicated? Unfortunatelly that’s the hardest part of the whole mod and because a lot of different versions of the C64 motherboard exsist, it’s very probable that you’ll need some aid from the service manual to find where exactly are all the signals on the one you have.

Anyway, for now we’ll use a popular C64C motherboard variant as an example – Assy No. 250469 Rev. B.

First we need to supply 5V to the circuitboard, which we’ll find in a lot of places all over the C64 board. I went with a comfortable location right beside the POWER LED pins. Looking at the motherboard from the usual spot we take when we use the Commodore, +5V can be located on the first free soldering point on the left of the LED pins.  In the same line just beside there’s also a point with ground. It’s worth to make sure and confirm the correct values with a Voltometer.

The RESTORE signal is also relatively easy to find on this motherboard. We’ll locate it almost at the bottom edge of the board, on one of the R17 resistor legs (the one near the neighbouring capacitor). Why use the RESTORE button? Because it’s the only one that’s has a direct connection on the motherboard and isn’t in any way coded.

The RESET line can be located on the anode of CR5 diode, which you’ll find just above the character ROM. Unfortunately it’s difficult to solder a wire in from the upper side of the board, which gives us two options, either to move the diode, or to solder the wire from the backside, which I did.

The most difficult to locate for me was the /EXROM line. On my motherboard the soldering point was covered up by a sticker. Also near the bottom edge between PLA and the VIC-II chips you’ll find five soldering points in a row. Counting from the left, the fourth one is the /EXROM line.

If your C64 is also equipped with a dual ROM, it’s possible to connect one of it’s legs to the I/O line 5. The attached code allows to switch between two ROM locations, but it’s possible to add in support for four. Keep also in mind that in the old C64 models Basic and Kernal were located in separate ROM chips, unlike the C64C where they only use one.

If everything was connected correctly, you can test the solution.

How does it work?

The mod adds a few functions to our C64, depending on how long we’ll press the RESTORE button. Pressing it for two to four seconds, executes a so called warm reset, which starts the Basic setup routine and redraws the screen. If that’s not sufficient, because let’s say part of the memory was overwritten by users code, it’s possible to do a longer, four to seven seconds press and execute a cold reset instead. This takes the Commodore through the complete startup routine and works in a same fashion as a reset button on a cartridge. If the computer has the dual ROM installed and connected, it’s also possible to press RESTORE for seven to ten seconds and this in turn will do a cold reset and additionally switch the currently used ROM location.

For cartridge compatibility purposes I’ve also added the ability to start up the machine using the second ROM, by pressing the RESTORE button during the power on.

And voila! This way we’ve supplied our good old C64 with a neat CTRL+ALT+DELETE equivalent without drilling any holes or damaging the housing. To make the solution more elegant and easier to dismount it’s possible to use goldpin connector instead of directly soldering in the wires.