Exploring CPUs, motherboards, overclocking, building your own PC, case mods, PC brands, handhelds, peripherals of all types, DVDs, CD burners, hardware-specific software, device drivers, and anything else related to hardware.
The The Restaurant at the Edge of the Universe, previously known as The Water Cooler, is a place to post stuff that has absolutely nothing at all to do with computers, broadband, Scot's Newsletter, or anything that's "supposed" to be here.
Okay, there appears to be nothing wrong with the scanner portion of the printer. I decided to start from scratch on my backup laptop, which I don't use too often and which usually doesn't have a printer connected. The system auto-configured the printer when it was detected and I decided to see what that got me. Scanimage -L found the scanner, and when I scanned a document from CLI I was able to do six(!) consecutive scans without an issue. I haven't been able to get more than two with the printer connected to the main laptop, and that was rare as it was usually only one.
When I have a few minutes I'm going to delete all the printer/scanner definitions from my main laptop and see if the process that worked on the backup laptop gives the same results on the main laptop. I did see something briefly when I was searching for info on the error message about certain motherboards having some difficulty with something to do with the error message, but I can't remember any details unfortunately. I'll be interested to see if I can get a working scan setup on the main laptop.
It's some progress anyway. Thanks for your input, Eric.
I'm wondering if this isn't helpful information:
The section "uncommon paths" seems applicable. I took a look inside the referenced file and see this section:
# for hostdev
deny /dev/sd* r,
deny /dev/vd* r,
deny /dev/dm-* r,
deny /dev/drbd[0-9]* r,
deny /dev/dasd* r,
deny /dev/nvme* r,
deny /dev/zd[0-9]* r,
deny /dev/mapper/ r,
deny /dev/mapper/* r,
If I'm understanding correctly (and it's debatable whether I am), it looks like my virtual disk storage path /media/jim.... is being blocked by the line deny/dev/sd* r,
You said you're not familiar with apparmor, so wondering if you even have that directory & file. Would be nice to compare contents if you did...
Don't want to seem pushy for a resolution, just trying to continue researching for myself. And if it helps you with a diagnosis and proposed solution...even better!
As I understand it.
At start up from the bios the pc looks for a "boot manager" whose job it is to look for possible "boot loaders" whose job it is to boot the system.
The rEFind program looks for boot loaders and shows them on the screen, that is all it does until you make a choice of which boot loader to use then it tells the boot loader to proceed.
On a single os pc rEFind would usually give you a main choice, your standard normal use initramfs. Then it usually has several other options like fallback initramfs.
On my dual boot set up rEFind shows me my Arch and my Windows boot loaders. If I have a live so on a stick inserted like MX-19 on boot up then rEFind shows me Arch,Windows and MX-19 along with all their secondary options.
So rEFind simply scans folders and files it is given access to for ".efi" files as they are the "boot loaders".
My dual boot shows that I have in the Windows folder three .efi files,
bootmgfw.efi, bootmgfw.efi, and bootmgfw.efi,
for Arch there is simply refind_x64.efi, all of these .efi files have the ability to boot the pc. They could exist anywhere on the pc as long as their path is know in the rEFind .config file.There are two of these, a simple to set (the one I use) and a more elaborate one which I have only researched a little.
. I like that rEFind finds and shows all the os's available at boot with no extra work needed for usb or externaly mounted hdd/ssd's etc. Also the more elaborate .config is pretty easy to navigate and set up allowing you to easily choose which icons to use for instance. The standard showing on the screen is pretty nice and I could see with a tiny tweak here and there it would be very neat indeed. All in all as a new user I found it much easier to use than Grub.
Hope that helps a tad. 😎
What's the Problem?
"As described in EFI Boot Principles, the EFI boot process relies on both EFI boot loaders on the ESP and pointers to those boot loaders in the computer's NVRAM. Unfortunately, many circumstances can break the link between these two components—some EFIs have bugs, or the NVRAM entries can become damaged or lost; some EFIs deliberately delete invalid NVRAM entries, which can cause them to disappear if you deliberately (but temporarily) unplug a hard disk; you might intentionally or accidentally move a boot loader file; and so on. Such common occurrences can render a computer unbootable and necessitate using a recovery disk to restore bootability by re-creating the NVRAM entry with a tool such as efibootmgr, as described in EFI Boot Loader Installation. Such a repair can be beyond the abilities of the average user, or at least, can require following (not to mention first locating!) technical instructions that the user may find challenging.
Windows is not greatly affected by this problem. Because Windows is the 800-pound gorilla of the OS world, many EFIs are designed to look for the Windows boot loader (EFI/Microsoft/Boot/bootmgfw.efi) if nothing else is available. Windows also installs a copy of this boot loader in the fallback position of EFI/BOOT/bootx64.efi (or similar names for other architectures). Thus, Windows tends to keep booting even if its NVRAM entry is lost. Linux distributions, though, are another matter; if their NVRAM entries are lost, they tend to stop booting—or perhaps the computer will begin booting straight to Windows, which can be as frustrating to users."
"bootmgr.efi the Windows boot manager on systems with BIOS firmware. This file will be loaded as part of the BIOS boot process - typically the boot device is set in the BIOS. Assuming the boot device is a hard disk type device then the Master Boot Record is loaded > the Active Partition is identified in the Partition Table > the Partition Boot Record (PBR) on the Active Partition is loaded > code in the PBR loads bootmgr > bootmgr loads the BCD file.
bootmgfw.efi - the Windows boot manager on systems with UEFI firmware. This file is loaded directly from the Windows Boot Manager entry in the Firmware Boot Menu stored in NVRAM. Typical boot process is Firmware Boot Manager > \EFI\Microsoft\boot\bootmgfw.efi on the EFI System Partition is loaded via the Windows Boot Manager entry > bootmgfw.efi loads the BCD file (path to BCD file - \EFI\Microsoft\boot\BCD)."
I do have a "bootx64.efi" but did not mention it as it might have caused a nit of confusion into a straightforward affair. The "refind_x64.efi" is the one for my Arch os though.