No /dev/bus/usb/ in Lucid Puppy

[greengeek]

This information:

I just plugged the scanner into my laptop and booted Tahr. Xsane found it and worked with it perfectly (if slow to start) when run as root.

But when run as spot, xsane could NOT find the scanner...

Until I did (as root):

# sane-find-scanner
found USB scanner ... at libusb:002:003 ... [LOTS more text]
# scanimage -L
device 'epson2:libusb:002:003' is a Epson GT-9300 flatbed scanner
# cd /dev/bus/usb/002
# chmod o+rw 003
# cd /dev
# chmod ugo+x bus

And then xsane worked when run as spot!

Now if I could just figure out how to do the same in Lucid -- but it doesn't have the directory /dev/bus. Instead, it has /dev/usbdevX.Y

seems incompatible with the suggestion that in Lucid you have a problem with permissions in /dev/bus - given that you have said (in recent testing) that:

There's no need to change the permissions of /dev, it's already 755 (rwxr-xr-x), so it's searchable by anyone.

The usbdev* files are at the first level under /dev, so there are no directories that would need to be changed.

If you are correct that /dev (and recursive) permissions are already fine for Spot's needs, then I see no need to be wanting to do the chmod things that worked previously. Or have I misinterpreted this? I would have expected setting all /dev files for the permissions you wanted would make Spot happy. If it didn't then surely that requires us to look further afield? Maybe force all /etc files to the permissions you need? Or maybe /proc too?

Or, in your example above, did Spot start to work simply because you had already surmounted the problem by running the scanner as root first?

[ahoppin]

Hi Mike, thanks for the suggestion. I'm conflicted over this. I have a strong preference for open source, which is why I'm using Puppy.

However, I also want to encourage hardware manufacturers to support Linux users, even when (as here) the support is limited to "Here it is, try it; if it doesn't work, you're on your own."

I've used xsane with a Umax scanner (now deceased) for over 6 years, and I've been pretty well satisfied with it. But I downloaded the Epson Image Scan package you suggested anyway. I can load it on a pfix=ram Puppy to see whether I like it better.

FYI, Image Scan may have changed since you installed yours. I'm not sure but I don't think I can just click on the downloaded file to install it. The file I have is iscan-bundle-1.0.4.x64.deb.tar.gz. I think the .deb package will have to be extracted from the archive before I can install it, but that's not a big deal.

[ahoppin]

Hi Greengeek. I really appreciate your taking the time to help with this. Sorry if I'm not explaining what I did and tried clearly.

The commands I listed were ones that I ran as root in Tahr. Before them, spot couldn't use xsane. After them, spot could. Again, though, that was in Tahr.

I hope that makes more sense.

> [the commands seem] incompatible with the suggestion that in
> Lucid you have a problem with permissions in /dev/bus ...

Well, not exactly. Lucid doesn't have a /dev/bus directory. So, those commands don't work on Lucid because the character special device files they change in Tahr, don't exist in Lucid.

Unfortunately, I can't find the equivalent files in Lucid.

I guess that the /dev/bus directory is a change to udev (?) that antedates Lucid (but which Tahr has). I don't know for sure, though.

[Mike Walsh]

Hi again, ahoppin.

> [the commands seem] incompatible with the suggestion that in
> Lucid you have a problem with permissions in /dev/bus ...

Well, not exactly. Lucid doesn't have a /dev/bus directory. So, those commands don't work on Lucid because the character special device files they change in Tahr, don't exist in Lucid.

I decided to have a look in my own install of Lucid (5.2.8.7). I originally only installed this to help somebody else out with a browser query, and it kind of hung around, and I starting playing about with a bit more often, and did some customising, and.....well, TBH I really rather like it now! Getting OpenShot & RecordMyDesktop (both Python apps) installed and running well was the clincher, I must admit. (Works a treat on the old 2002 Dell lappie with the P4.)

I seem to have a /dev/bus/usb directory in Lucid. However, comparing it to the same directory in a few other Pups (Raring, Precise, Slackos 560 & 570, Tahrpup - to name but a few) it doesn't appear to have anywhere near as many of the 'special character' inode files as the others do. But it does exist.

Food for thought, perhaps? (BTW, what do these 'special character' files actually do? Do you happen to know? I have a sneaking suspicion these get created whenever a new piece of USB hardware is detected; if you were using a parallel port scanner, and no other USB devices, could be why the directory doesn't seem to exist...)

Of course, that immediately shoots holes in my own theory of how they're created, since the moment you plugged the Epson in via USB, some of these should have appeared in the /dev/bus/usb directory. So perhaps my theory doesn't hold water!

-----------------------------------

As for I-Scan, yes; it needs extracting first.....then the debs are inside that. Looks like you still need to install two packages to get things working. (They've simply combined the individual .debs into a 'bundle'. At least it's a step in the right direction; previously, you had to download each .deb individually. It's 'progress' - I suppose!)

Anyway:-

First, install the .deb inside the 'data' directory. Then, install the .deb inside the 'core' directory. (Don't bother with the contents of the 'plugins' directory; that's strictly for networking.....if you want to try and control the scanner remotely. I've never found this to work with Puppy anyway.)

And I could be wrong, but I think you've accidentally downloaded the 64-bit package:-

The file I have is iscan-bundle-1.0.4.x64.deb.tar.gz.

AFAIK, that won't work for Lucid..!




Mike.

[ahoppin]

Warning, long and somewhat rambling post!

> I decided to have a look in my own install of Lucid (5.2.8.7)...
> I seem to have a /dev/bus/usb directory...

I saw that in Lucid 5.2.8, too. IIRC, it had both the /dev/bus/usb and the /dev/usbdev* files.

> what do these 'special character' files actually do?

A character special file is a way for Linux (or Unix) to write to and read from a device that transfers data one character at a time.

The printer devices /dev/lp0 and /dev/lp1 are also character special files. If you open a console window and issue the command

ls -l /dev/lp?

you'll see them. The c in the first column of the permissions field says they're character special files.

Now if you type in that same window

ls -l /dev/sd*

you'll get a list of your computer's disks. The b in the first column means they're block special files. A block special file is an interface with a block-oriented device (one which transfers data to/from the kernel in large blocks or chunks), such as a disk drive or its file system.

If you're old enough to remember MSDOS, you might remember using CON, PRN, LPT1, COM1, NUL, and other similar device files that you could write to and/or read from. Similar principle.

> I have a sneaking suspicion these get created whenever a new piece
> of USB hardware is detected

That could be. I do see /dev/bus/usb in Tahr on a fresh boot. However, that might be because the laptop I'm experimenting with has an always-connected USB device, a fingerprint sensor.

Also, the /dev/usbdev* files in Lucid 5.2.5 are always there. lsusb returns 12 addresses. But again, I never boot this Lucid machine with no USB devices plugged in.

What I DO notice is that the USB device files, whether /dev/bus/usb/* or /dev/usbdev*, get their time and date stamps updated when you plug in a USB device.

Just for comparison, I booted Puppy 4.3.1. No /dev/bus directory, and no /dev/usbdev files at all. That seemed strange. Maybe it couldn't see the fingerprint sensor? Just a guess. It did have a file /dev/usbmouse, however.

Plugged in the scanner. Sill no /dev/bus/usb directory, but /dev/usbdev2.2, /dev/usbdev2.2_ep00, /dev/usbdev2.2_ep01, /dev/usbdev2.2_ep02, and /dev/usbdev2.2_ep81 all showed up. They all had the current time stamp.

I'm afraid that all this is just adding to the confusion. :-(

I *think* that whatever changed in Puppy that made the /dev/bus/usb directory appear, it changed with Lucid 5.2.8. However, I suspect that this is more related to the Linux kernel's evolution than to Puppy's growth.

> if you were using a parallel port scanner, and no other USB devices,
> could be why the directory doesn't seem to exist.

Do you mean /dev/bus/usb? If so, I would think it should exist if I booted Lucid 5.2.5 with the scanner connected. That doesn't happen. No matter what, I *never* see /dev/bus/usb in Lucid 5.2.5.

This has me intrigued. I think I need to do some research on the evolution of Linux's usb subsystem.

PS - thanks for catching that downloading error! I'll try again.

[ahoppin]

One more question, Mike -- do you know for sure that the Epson Linux package doesn't phone home to Epson and update your printer/scanner's firmware?

Not that it's likely to be a problem with a dedicated scanner, but I ask because some folks who have the MFP machines are avoiding Epson firmware updates. IIRC a while back Epson started adding firmware functions to make the printers reject third-party ink.

Don't get me started on manufacturers that treat their users like potential enemies, to be spied on, and punished if they do something that might hurt the manufacturers' profits.

[Mike Walsh]

One more question, Mike -- do you know for sure that the Epson Linux package doesn't phone home to Epson and update your printer/scanner's firmware?

Not that it's likely to be a problem with a dedicated scanner, but I ask because some folks who have the MFP machines are avoiding Epson firmware updates. IIRC a while back Epson started adding firmware functions to make the printers reject third-party ink.

Don't get me started on manufacturers that treat their users like potential enemies, to be spied on, and punished if they do something that might hurt the manufacturers' profits.

TBH, I wouldn't think so. Although I can't say for sure with the newer stuff; my old SX218 must be getting on for 9-10 years old now. Too old for them to bother with, I should imagine!

(I'm in Tahr 606 ATM, my most recent addition to the kennels (just a couple of months back), and less than 5 minutes ago I printed a document off, using third-party ink.....)

(*shrug*)

And your scanner is, by your own admission, quite an old one. D'you know, what you say about this is the first I've heard of it.....but with the way the price of OEM ink is going, it's hardly surprising, I suppose.

I somehow doubt you and I will have any problems with that one. Especially not your scanner; they don't use ink, so I can't see what Epson would stand to gain from such an excercise.....


Mike.

[ahoppin]

Could be that you're right, that your printer is old enough that Epson has mostly forgotten about it. You never know though...

If you search the web you'll find plenty of info about the ink wars. HP was the most recent "bad guy," but Epson has been named too.

It's an older discussion, but try this one as an example:

https://www.printerknowledge.com/thread ... ning.6614/

or https://v.gd/KIjECw

It seems that keeping third-party ink working with many inkjet printers, including Epsons, is a cat and mouse game. The Chinese chip techs reverse-engineer the factory ink cart chips, and sell clones to the refillers. Recycled ink carts using those clone chips then work -- until the cat (the printer maker) pushes a new firmware update to the printer to block them. Then the updated printer gripes that your carts "can't be recognized," and the Chinese mice go to work again.

I think there are now some legal restrictions on this practice of limiting third-party ink use in the EU. However, here in the US, the laws are usually not as strongly pro-consumer.

For Epsons specifically, it appears that the firmware updater is built into the Windows (and presumably Mac) drivers. That's why I'm suspicious that Epson might also added this functionality to their Linux driver, at least to the printing driver.

Again, it's probably not a concern for standalone scanners, but folks with MFPs and standalone printers, at least relatively new ones, will probably want to pay attention.

To bring this marginally back on topic, I found this thread on the board:

http://murga-linux.com/puppy/viewtopic.php?t=61885

It seems that rcrsn51 has written a utility that converts Epson's proprietary Linux printer drivers to native Puppy .pet packages, a great idea. I would hope that his utility would install just what's necessary for printing, omitting any spyware or updaters, but I can't tell for sure from the thread.

[greengeek]

In Lucid 5.25 and Lucid 5.28 could you post the output of

cat /etc/group

both before and after plugging in the scanner?

Then maybe the same in Tahr before and after you do the chmod stuff.
cheers!

[greengeek]

And maybe also:

cat /etc/sane.d/epson2.conf

[ahoppin]

/etc/group and /etc/sane.d/epson2.conf are static files, so AFAIK there's no way they can or will change on hotplug events.

I'm pretty sure that when udev (the usb hotplug daemon, if I understand it right) sees a USB device plugged in, it creates or updates the device files in /dev with reference to configuration files in /etc/udev/rules.d. I suppose those rules may read the contents of /etc/group (among other files), but I don't know for sure.

In the specific context of USB scanners and sane, in most cases you want the rules to create scanner device files in /dev so that they're rw for the scanner or lp group. Then if spot (or other regular non-root user) is a member of the scanner or lp group, the non-root user can (if all goes well) use xsane.

Or you can just cheat and tell udev to make the device files rw for everyone, and not worry about the users' group membership.

Or do what I did before, and use a shell script to chmod them after they're created. As I said way back in this thread, that worked great for SCSI device files in Lucid 5.2.5, but I couldn't make it work for USB in that version. I still don't know why not.

Now, though, I have a version of xsane that doesn't complain about being run as root, so my problem is effectively solved.

But I remain curious about USB in Puppy. If you want to join me in experimenting with the different ways these different pups handle USB devices, you can download the iso files back to version 2.16 from http://distro.ibiblio.org/puppylinux/

[greengeek]

/etc/group and /etc/sane.d/epson2.conf are static files, so AFAIK there's no way they can or will change on hotplug events.

I think you are assuming that the reason Spot can't scan is because it doesn't have permission to access a device port. It may be that it does not have permission to access a file in /etc (eg /etc/sane.d) or maybe that it does not have permission to access a newly plugged device like a scanner (as is the norm for non root users wanting to access a newly plugged device) - in which case part of the answer may be to ensure that Spot is added to /etc/group as having access to scanner devices.

Or you can just cheat and tell udev to make the device files rw for everyone, and not worry about the users' group membership.

Or do what I did before, and use a shell script to chmod them after they're created. As I said way back in this thread, that worked great for SCSI device files in Lucid 5.2.5, but I couldn't make it work for USB in that version. I still don't know why not.

But you also said that all of the files in /dev were already accessible to Spot. I probably misunderstood, but I never grasped why you thought it was successful to chmod /dev files, while also saying "There's no need to change the permissions of /dev, it's already 755 (rwxr-xr-x), so it's searchable by anyone.
The usbdev* files are at the first level under /dev, so there are no directories that would need to be changed."

Surely it can't be both ways? Either all /dev files are available to Spot or they are not. If all of the /dev files and /etc fles are accessible to Spot but you still can't access the backend then the problem must be somewhere else?

But I remain curious about USB in Puppy

Hotplug changed from Puppy to Puppy and I guess that changes the specifics of the usb detection - sometimes there are conflicts with kernel drivers apparently.

I think Bigpup summed it up though - Spot was intended for internet protections and as a result it will be a longwinded bughunt to work out which file is preventing Spot from accessing the specific hardware resource.

Sorry I couldn't be of any help
cheers!

[Mike Walsh]

Hi, ahoppin.

For Epsons specifically, it appears that the firmware updater is built into the Windows (and presumably Mac) drivers. That's why I'm suspicious that Epson might also added this functionality to their Linux driver, at least to the printing driver.

Again, it's probably not a concern for standalone scanners, but folks with MFPs and standalone printers, at least relatively new ones, will probably want to pay attention.

Which is why I keep using the same set of drivers that were current at the time when I first bought the SX218 several years ago. They still install, they still give me full functionality, I can still use 3rd-party ink.....where's the point in updating them? Especially if these firmware updates are being pushed out via the updated driver packages?

I'll stick with what works for me, thank you very much..! And, er....thanks for the heads-up on Epson pulling the same stunt as HP; I wasn't aware of that, I must admit. (My practice of using the same set of drivers indefinitely probably shielded me from that one...)


Mike.

[ahoppin]

> It may be that it does not have permission to access a file in
> /etc (eg /etc/sane.d)

I checked that when you mentioned it before, and it didn't fix the problem. Good analysis though.

> or maybe that it does not have permission
> to access a newly plugged device like a scanner (as is the norm for
> non root users wanting to access a newly plugged device) - in which
> case part of the answer may be to ensure that Spot is added
> to /etc/group as having access to scanner devices.

That would probably work, if the SANE udev rules were in place the way they seem to be for other distros. Search around or look at some of the forums I linked to before, and you'll see these scanner group rules quoted.

But you won't see them in Puppy's /etc/udev/rules.d.

Nor is there a scanner group in /etc/group.

My guess is that BK and the Puppy programming team didn't include them because normally all Puppy users run as root, so permissions don't matter for them.

I think the above idea probably would work if you created the scanner group, made spot a member of it, and manually added all the necessary udev rules. I haven't tried it, though.

> I never grasped why you thought it was successful to chmod /dev
> files, while also saying "There's no need to change the permissions of
> /dev...
>
> Surely it can't be both ways? Either all /dev files are available to
> Spot or they are not.

"Available" doesn't necessarily mean "usable."

Since /dev is mode 755 (rwxr-xr-x), it's *searchable* by anyone. Spot's programs, in this case xsane, scanimage, etc, can thus find the files they need in /dev.

But just *finding* the device files isn't enough. Spot's program (SANE) also has to be able to open them for reading and writing. So the files in /dev have to either be owned or in the same group as Spot, or they have to be read/write for anyone.

So both conditions have to exist. Sorry if that wasn't clear.

[greengeek]

But just *finding* the device files isn't enough. Spot's program (SANE) also has to be able to open them for reading and writing. So the files in /dev have to either be owned or in the same group as Spot, or they have to be read/write for anyone.

So both conditions have to exist. Sorry if that wasn't clear.

No - it's just my ignorance in play

I thought that "chown"ing was the same thing as offering "all permissions".

What I meant was - that if you give Spot total control of everything in /dev and /etc (recursively) it would show whether or not that is where the "resource denied" bottleneck was.

I just figured that the "bus" directories (or their alternatives) would most likely be in /etc or /dev. Unless they exist only in /proc - which is possible depending on the structure of the kernel modules.

Of course - even if setting full Spot permissions for /etc and /dev was successful - it would not pin down specifically where the problem lay, but I just hoped it might remove the roadblocks and provide somewhere to focus the lens.

Good luck!