Current: Since the May 20 upgrade of hplip from 3.13.3/2 to 3.13.5/1 I experience a longish hiccup at system boot, after which the following text is displayed on the console:
This command comes from /lib/udev/rules.d/56-hpmud.rules; commenting out the pertinent line therein eliminates the hiccup, while printing and scanning are not affected.

systemctl... sigh.

I have no /usr/bin/systemctl, but for sure I have a /usr/bin/hp-config_usb_printer -> ../share/hplip/config_usb_printer.py*

Yech. Seems like the (n)ew package also snuck in a systemd service file as well:

Check the source's makefile with "make --configure" to see if the package for systemd can be disabled on build with a switch, like --disable-systemd.

I think the problem really isn't directly to do with systemd, although changes made to support systemd may have brought it about. When exactly does this "hiccup" occur? Is it possibly during the initrd execution? If that's the case the fix will be blacklisting that rule from being copied to an initrd.

A good test to see if this is the case would be to leave the rule on the main system, but delete it from under /boot/initrd-tree, and then use mkinitrd (with no options) to rebuild the initrd without the rule. Reinstall lilo, reboot, and if it doesn't happen we know what the deal was.

I'm wondering where /etc/udev/rules.d/56-hpmud.rules came from. My hplip on 14.0 installed /etc/udev/rules.d/86-hpmud-hp_laserjet_*.rules files (as I'm using an old P1505n here at $WORK,) so I suspect the proprietary stuff that one downloads upon installing the printerr may be the culprit.

The hiccup occurs on the main system, not in the initrd.

Actually this specific rule would make no sense in an initrd - not only is there no /usr/bin/systemctl but there is no /usr/bin/hp-config_usb_printer as well.

Things bring me to the more fundamental observation that udev does not seem to run at all in the initrd. I have an "all modules" kernel and if I do not specify the block and filesystem drivers via "mkinitrd -c -m ahci:ata_piix:ext3 -k 3.9.2-burdi64" booting will fail.

Of course the modules cannot be loaded when they are not there. The "/lib/modules/" directory on the main system is not available before the main system is mounted.

Udev is run indeed. You can open "/boot/initrd-tree/init" with a text editor and see.

As a longtime Slacker using an initrd I opened "/boot/initrd-tree/init" with a text editor to see many, many times. Of course udevd is run, but in my opinion it does not do anything:
-- setting /etc/udev/udev.conf > udev_log="debug" shows output
-- in /init commenting out the /load_kernel_modules invocation makes booting fail
-- in /init commenting out the udevd invocation instead makes booting successful.

In other words: (At least in my use case) including udev in the initrd is superfluous.

To recap: This thread has two subthreads:
a. The hiccup at boot;
b. Udev in the initrd.

Ad a:
I am still running with the pertinent line in /lib/udev/rules.d/56-hpmud.rules commented out. I have not seen any effects on printing and/or scanning.

Ad b:
To me it seems that udev in the initrd does run, but does not do anything. At least in my use case this has no consequences.

I just got finished troubleshooting this for a package for MEPIS 12 (now in beta).
If your system was using systemd instead of some version of sysvinit, the hplip udev rule wouldn't block udev on startup causing the delay. The second branch launching hp-config_usb_printer does block. It sits in a 12x loop with a wait(5) in each trying to delete extraneous printer queues, so it blocks udev for 1:05

If your printer doesn't use a plugin, commenting out the line works fine. If your HP does use a plugin you may need hp-config_usb_printer to run.

I solved the issue by detaching hp-config_usb_printer from udev by starting it with nohup like so:
Redirecting the error messages with the 2> was necessary to keep it from blocking even though none are produced...

There's also a typo in line 260 of hplip3.13.5/config_usb_printer.py where they spelled utils as utlis. This will keep some printers from loading their plugins. If you rebuild might as well fix this too
And there are added debugging messages left in HPCupsFilter.cpp that flood the syslog with messages when you print...

So my LaserJet 3020 does not need a plugin.
Nevertheless I applied your two fixes. And indeed the hiccup does not occur.
Thank you very much.

Timkb4cq's patch is included in ap/hplip-3.13.5-i486-2.txz as published on Tue Jun 4 23:30:57 UTC 2013.

@burdi01,

Many thanks. I had the same hiccup with hplip-3.13.8.