You are not logged in.
libgnutls-deb0-28.so.28 ?
You can install eudev=220:3.2.2-devuan1 from experimental on Jessie, but you need to make sure to also install libudev1=220:3.2.2-devuan1, which is its companion (despite the name). The latter might be noted as a downgrade (relative jessie-backports), but that's nothing to worry about.
Thank you, and welcome. Good practice for another time, when you run into something harder.
Nothing to worry about. I'm pretty sure it's the right pathname.
But it just made me think about the Bellman.
You mention /usr/lib/mozilla/plugins/flash-mozilla.so twice already, so if I mention it once more, it'll sure be the right place
To be sure, each rule is on a single line. Refer to
man udev
for details.
I'm not too well versed in this, but I might be able to help.
Firstly, I think that your /etc/udev/rules.d/10-scanner.rules should have a single rule line. It should be read "if the vendor is 0x04f9 and the product is 0x0330, then make the /dev/whatever pathname have group scanner". All that needs to be on a single line.
What you have done is rather three independent statements: "if the vendor is 0x04f9, then eeh nothing", "if the product is 0x0330, then ehh nothing", "if whatever, then set /dev/whatever to have group scanner". That last one in particular is quite "destructive" (although there might be some kind of protection in udev for that kind of mistake).
But, when I look at the libsane rules (i.e., /lib/udev/rules.d/60-libsane.rules) it suggests that you should rather have the assignment
..., ENV{libsane_matched}="yes"
as effect instead of setting access group. I think the deal is that the scanner dev's (for whatever [expletive] reason) have decided to use "acl" rather than unix file protection, and they also have programmed their rules to use a common, actual effect via the setting of the libsane_matched variable.
So, if making it a single line doesn't work, you might try replacing the GROUP assignment with that assignment.
EDIT: note the comma (",") between the terms; i.e., when you join your lines, you need to add "," comma between them.
Make a failed login attempt and see that btmp has grown
man last
man lastb
If I may suggest a couple of "improvements" within that scheme, to in particular simplify the picture for the helpee.
Firstly that you set up key based authentication for helpee, to ssh to you without password.
Secondly that you set up ~/.ssh/config for helpee with a short logical hostname to your host. In that you would also reverse forward to both ports 22 and 5900 in the single ssh link. E.g. like the following stanza
Host help
hostname ...
user ...
identityfile ...
remoteforward 7000 localhost:22
remoteforward 5901 localhost:5900
Thirdly a script for the helpee to run the two things as one:
ssh help & x11vnc
With the second forwarding, you, the helper, would only need to run vinagre against localhost:5901, or indeed xvnc4viewer against :1, and also have the ssh back link on localhost:7000.
... a bit sad to learn there was no magic
As for the reverse port forwarding, you might have overlooked the option of reverse-forwarding port 5900, which is the default port vnc uses for the :0 display. Though, with gitso working for you, there's no need to pursue this.
I suppose x11vnc accessed with xvnc4viewer via ssh is too old-fashioned?
If it's similar to my problem, https://dev1galaxy.org/viewtopic.php?pid=4135#p4135, then that xhci quirk setting might be a good thing for you as well.
There's also sshfs, which is more secure, but won't work right for audio/video (it plays on the server instead of the client.)
What does that mean? afaik sshfs is just a mounted (remote) file system for the client??
In fact as recent as last week, I used it with my mplayer on the client.
According to the hopefully relevant web page, here, you need to add a udev rule, which they provide a script for. That script however seems to concern a different idVendor:idProduct device from yours, and it would therefore not be immediately applicable.
However, since the script merely creates a new file to the udev configurations, /etc/udev/rules.d/73-beaglebone.rules, it is safe to try it, but first edit the script: replace the two occurrences of 0403 with your idVendor code, 1d6b, and the two occurrences of a6d0 with your idProduct code, 0104, before running the script (as root).
If it's helpful, it's all good, and if not, you can just remove the file.
Also, you should check permissions on /dev/bus/usb/001/00[56]
If udev doesn't recognize their vendor/product id, it'll just set up "generic" nodes, which probably are not accessible by a user.
Sometimes jmtpfs is sufficient.
This is a quick note that might help someone, although I haven't worked out the proper solution yet.
The deal is that recently my laptop stopped suspending properly. It suspends on closing the lid, but then immediately wakes up. It has Jessie installed since beta, then occasionally upgraded, and it has linux-image-4.9.0-0.bpo.2-amd64 from jessie-backports installed.
Eventually I worked out that apparently it is the xhci_pci module that gets a phantom signal from somewhere, and wakes up the system. I believe the module handles USB transport (esp. 3.0), and it is brought in when I plug in a USB stick.
So, my laptop is sleeping fine until I plug one in, and thereafter it keeps bouncing up, refusing to sleep, until I unload that module.
Perhaps there's some module option to avoid the misbehaviour. I'll add an edit here if I find something.
EDIT 1: I've realized this to be an age old problem, though ascribed to the xhci_hcd module rather.
EDIT 2: See https://bugzilla.kernel.org/show_bug.cgi?id=66171#c67 which suggests the fix of having
options xhci-hcd quirks=270336
in an /etc/modprobe.d/ file, so as to make the module load with that parameter. I'll try that for a while...
Some people would use "code" blocks to make their posts readable.
Other people don't bother and don't get read.
The original poster does that by editing the "subject" line of the first post. You can try it out on this topic, if you think this answered your question.
a) any hardware loggging in /var/log/syslog or /var/log/kern.log ?
b) is Trash and file on the one and same partition ?
c) which actual program is it? ("mv" or "rm" or gui dnd)
E.g., by hearsay I think on an ext* file system, "rm" of a huge file will stall the system because it locks the directory while reclaiming the blocks, whereas an intra-partition "mv" however is instantaneous, being just some top level pointer juggling in the directory tables.
Yeah. By the looks of it, it's all set up perfectly fine, and renewal should have happened nicely and smoothly already last month. It didn't. As the "certbot" is something opaque in too many lines of python, it's become a matter of tracing it more tightly for the next time...
I'm afraid I overlooked the importance of having a working event declaration file in /etc/acpi/events. Mine is:
event=button[ /]lid
action=/etc/acpi/lidbtn-suspend.sh %e
and my script is named accordingly.
Especially the %e on the invoked command is important; it gets replaced with the triggering input line from acpid
button/lid LID close
or
button/lid LID open
or
any other acpid event lines
and it thus gives three arguments to the script, the third of which is the lid action. The script I suggested peeps a those, and requires the third to be close in order to suspend.
Note that your alternative pattern lines are all ok, I think, in the sense of matching the event line. An observation though (irrelevant as it is), since the pattern is a regular expression, an ending of d* says that there must be zero or more d at that match point. I guess you intended it to be d.* (saying "a d followed by whatever"). But "followed by whatever" is implied unless there is a $ at the end.
Hopefully that can make it work for you.
I'm not sure what that "obscure" scripting attempts to do, but you really only need the following script as /etc/acpi/lid.sh:
#!/bin/bash
if [ "$3" = "close" ] ; then
/usr/sbin/pm-suspend
fi
The program pm-suspend is from the pm-utils package.
Of course, if you want screen lock, the script needs some more, and it depends of which screen locking you are using.
"Everything is possible, though some things cost more."
It's far from immediately apparent to me that it'd be an advantage to anyone, although I must admit that I don't really see much advantage in the having of that information either. But a quick glance at a couple of other forums suggests that the common practice is to tell who are logged on to everyone.
Perhaps you have a compelling reason for us to be different?
You may note that everything previously ascribed to the old user id is now ascribed to the new user id, except where it occurs within posts (unless the poser used the "user" markup).
Cheers.