On Fri, Dec 25, 2020 at 11:01:47AM +0200, Adi Ml wrote:
> Hi,
>
> I am trying to generate rules in udev to block mass storage. It seems like
> it only checks the device itself (its class is 00), but not its interface
> classes (one of those is 08, a mass storage). It seems like there is only
> att
Hi,
I am trying to generate rules in udev to block mass storage. It seems like
it only checks the device itself (its class is 00), but not its interface
classes (one of those is 08, a mass storage). It seems like there is only
attr{bDeviceClass} but there is attr{bInterfaceClass} only when I speci
On Sun, Dec 20, 2020, 21:37 Adi Ml wrote:
> Yes. Thats exactly what I mean (what mantas said)- ATTR{authorized}="0".
> I would like to have a usb whitelist via udev and want it to be enforced on
> devices which connected pre boot too.
>
> authorized_default=0- it seems the same like
> ATTR{author
Yes. Thats exactly what I mean (what mantas said)- ATTR{authorized}="0". I
would like to have a usb whitelist via udev and want it to be enforced on
devices which connected pre boot too.
authorized_default=0- it seems the same like
ATTR{authorized}="0", isnt it?
בתאריך יום א׳, 20 בדצמ׳ 2020, 15:5
On Sun, Dec 20, 2020 at 3:49 PM Lennart Poettering
wrote:
> On Sa, 19.12.20 15:37, Adi Ml (maladi1...@gmail.com) wrote:
>
> > I see. so if I have a rule against a certain usb in udev, it should be
> > blocked automatically during the boot.
>
> Hmm, "blocked"? What do you mean by that? I am not fo
On Sa, 19.12.20 15:37, Adi Ml (maladi1...@gmail.com) wrote:
> I see. so if I have a rule against a certain usb in udev, it should be
> blocked automatically during the boot.
Hmm, "blocked"? What do you mean by that? I am not following...
>
> בתאריך שבת, 19 בדצמ׳ 2020, 15:31, מאת Lennart Poetteri
I see. so if I have a rule against a certain usb in udev, it should be
blocked automatically during the boot.
בתאריך שבת, 19 בדצמ׳ 2020, 15:31, מאת Lennart Poettering <
lenn...@poettering.net>:
> On Sa, 19.12.20 15:26, Adi Ml (maladi1...@gmail.com) wrote:
>
> > Hi,
> >
> > Is there a way to enfo
On Sa, 19.12.20 15:26, Adi Ml (maladi1...@gmail.com) wrote:
> Hi,
>
> Is there a way to enforce udev rules on all connected devices (which were
> connected pre-boot) after a reboot?
> I have tried udevadm trigger and seems like its not working
udevadm trigger is invoked atuomatically at boot, in
Hi,
Is there a way to enforce udev rules on all connected devices (which were
connected pre-boot) after a reboot?
I have tried udevadm trigger and seems like its not working
Thank you
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
h
On Tue, Jan 23, 2018 at 2:08 AM, Michael wrote:
> Hi
> why can't the Udev rules be automated or removed? As described here users
> only need to paste infos from lsusb etc.
> https://forums.x-plane.org/index.php?/forums/topic/72733-writing-and-debugging-udev-rules/&page=2
> But such a huge pain in
On Di, 23.01.18 10:08, Michael (scrat_h...@yahoo.com) wrote:
> Hiwhy can't the Udev rules be automated or removed? As described
> here users only need to paste infos from lsusb
> etc.https://forums.x-plane.org/index.php?/forums/topic/72733-writing-and-debugging-udev-rules/&page=2But
> such a huge
Hiwhy can't the Udev rules be automated or removed? As described here users
only need to paste infos from lsusb
etc.https://forums.x-plane.org/index.php?/forums/topic/72733-writing-and-debugging-udev-rules/&page=2But
such a huge pain in the ass that no other os needs.It really holds off many
po
Hello,
Sorry if this is not the right place to raise the question.
I can get return result after run with PROGRAM call, then $result holds
the returned string, but with PROGRAM, I have to use the absolute path
of command.
And sometimes, the command may located in different path for different
di
On Tue, 23.02.16 17:12, Alex Henrie (alexhenri...@gmail.com) wrote:
> 2016-02-22 7:15 GMT-07:00 Lennart Poettering :
> > On Sun, 21.02.16 15:26, Alex Henrie (alexhenri...@gmail.com) wrote:
> >
> >> Hi,
> >>
> >> I recently bought an MCS7715 USB-attached parallel port,[1] but there
> >> seem to be
2016-02-22 7:15 GMT-07:00 Lennart Poettering :
> On Sun, 21.02.16 15:26, Alex Henrie (alexhenri...@gmail.com) wrote:
>
>> Hi,
>>
>> I recently bought an MCS7715 USB-attached parallel port,[1] but there
>> seem to be a couple of problems using it with Linux:
>>
>> 1. The lp, parport, and parport_pc
On Sun, 21.02.16 15:26, Alex Henrie (alexhenri...@gmail.com) wrote:
> Hi,
>
> I recently bought an MCS7715 USB-attached parallel port,[1] but there
> seem to be a couple of problems using it with Linux:
>
> 1. The lp, parport, and parport_pc kernel modules are not loaded when
> the device is plu
Hi,
I recently bought an MCS7715 USB-attached parallel port,[1] but there
seem to be a couple of problems using it with Linux:
1. The lp, parport, and parport_pc kernel modules are not loaded when
the device is plugged in.
2. After manually loading the kernel modules, /dev/lp0 is not deleted
when
On Thu, 05.02.15 15:11, Angelos Ching (angelosch...@clustertech.com) wrote:
> Hi guys,
>
> I'm not exactly sure if I'm asking the right question in the right place,
> please let me know if this is not the right place for this question.
>
> I'm setting up SR-IOV for my Intel I350 igb on CentOS 6.
Hi guys,
I'm not exactly sure if I'm asking the right question in the right
place, please let me know if this is not the right place for this question.
I'm setting up SR-IOV for my Intel I350 igb on CentOS 6.6
(2.6.32-504.el6.x86_64, udev 147) using udev. I have modified a rule I
used in Cen
On Sun, 2014-11-09 at 22:39 +0100, Patrick Häcker wrote:
>
> > I really don't know. Some other operating system relies on a whitelist
> > due to all of the horrible devices out there that can't handle suspend
> > (keyboards and mice are notorious for being bad.)
>
> Thanks for your input. Do y
> > IIRC there used to be a kernel bug that caused autosuspend
> > to mostly not work on Linux, which they however blamed on crappy
> > devices for a long time. After that kernel bug got fixed I think
> > autosuspend works on most devices now, hence we only need a blacklist?
> >
> > I figure Greg
On Fri, 07.11.14 13:07, Oliver Neukum (oneu...@suse.de) wrote:
> On Fri, 2014-11-07 at 12:55 +0100, Lennart Poettering wrote:
> > On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote:
>
> > > It is inconsistent. That is at least partially to the inability to find
> > > general rules.
> >
On Fri, 2014-11-07 at 12:55 +0100, Lennart Poettering wrote:
> On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote:
> > It is inconsistent. That is at least partially to the inability to find
> > general rules.
>
> So what would you recommend we do?
>
> Experiment with turning auto-sus
On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote:
> > By coincidence I recently noticed something interesting in sysfs: My
> > USB devices seem to have an attribute "supports_autosuspend". These
>
> They are from the kernel and tell you that the drivers for the devices
> support auto
On Fri, 2014-11-07 at 08:26 +0100, Martin Pitt wrote:
> Patrick Häcker [2014-11-05 16:55 +0100]:
> > I you want to have permanent power saving activated for your devices, the
> > recommended way is to use udev (e.g.
> > https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some
> >
Patrick Häcker [2014-11-05 16:55 +0100]:
> I you want to have permanent power saving activated for your devices, the
> recommended way is to use udev (e.g.
> https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some
> [...]
> - Is there already something like this?
By coincidence
On Thu, Nov 06, 2014 at 07:49:38PM +0100, Lennart Poettering wrote:
> On Wed, 05.11.14 16:55, Patrick Häcker (pa...@web.de) wrote:
>
> heya,
>
> > sorry if this list is not the correct one for my post. In this case please
> > just point me to the correct list.
>
> It is the correct list.
>
> >
On Wed, 05.11.14 16:55, Patrick Häcker (pa...@web.de) wrote:
heya,
> sorry if this list is not the correct one for my post. In this case please
> just point me to the correct list.
It is the correct list.
> I you want to have permanent power saving activated for your devices, the
> recommende
On Wed, Nov 05, 2014 at 04:55:52PM +0100, Patrick Häcker wrote:
> - If not, is udev the correct piece in the Linux stack to put this?
Most likely the kernel should do this by itself.
What where the devices that you had to disable power saving on?
> - What is the general way to contribute udev rul
Dear all,
sorry if this list is not the correct one for my post. In this case please
just point me to the correct list.
I you want to have permanent power saving activated for your devices, the
recommended way is to use udev (e.g.
https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspe
> let the rule check also attrs of _parent_ devices using
> ATTRS{} instead of ATTR
ATTRS did the trick - thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mar 27, 2014 8:48 AM, "Satz Klauer" wrote:
>
> So...hopefully this is really the udev mailing list...
>
> I use CentoOS 6.5, an embedded device that is connected via USB and
> shows up as /dev/ttyACMx (in my case it is always /dev/ttyACM0). To
> have it read/writable for everybody and to avoid
So...hopefully this is really the udev mailing list...
I use CentoOS 6.5, an embedded device that is connected via USB and
shows up as /dev/ttyACMx (in my case it is always /dev/ttyACM0). To
have it read/writable for everybody and to avoid the modem-manager is
accessing it I created following rule
В Wed, 18 Dec 2013 02:52:01 +0100
Kay Sievers пишет:
> On Tue, Dec 17, 2013 at 8:14 PM, Andrey Borzenkov wrote:
> > В Tue, 17 Dec 2013 19:59:47 +0100 Kay Sievers пишет:
>
> >> # modprobe dummy
> >
> > dummy is not renamed.
>
> > UDEV [80256.274447] move /devices/pci:00/:00:03.0/n
В Wed, 18 Dec 2013 13:36:52 +0100
Robert Milasan пишет:
>
> So basically it doesn't really work ?!
>
It does not always work for net device as it looks like.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.
On Wed, 18 Dec 2013 14:39:57 +0100
"Kay Sievers" wrote:
> On Wed, Dec 18, 2013 at 2:07 PM, Robert Milasan
> wrote:
>
> > One more question: Where exactly is 'test_device' variable saved, I
> > mean physically? I suppose it should be in /run/udev/data or
> > something similar no?
>
> Yes, in th
On Wed, Dec 18, 2013 at 2:07 PM, Robert Milasan wrote:
> One more question: Where exactly is 'test_device' variable saved, I
> mean physically? I suppose it should be in /run/udev/data or something
> similar no?
Yes, in the udev database at /run/udev/data/.
It's plain text, just look into it. T
On Wed, 18 Dec 2013 02:52:01 +0100
"Kay Sievers" wrote:
> On Tue, Dec 17, 2013 at 8:14 PM, Andrey Borzenkov
> wrote:
> > В Tue, 17 Dec 2013 19:59:47 +0100 Kay Sievers пишет:
>
> >> # modprobe dummy
> >
> > dummy is not renamed.
>
> > UDEV [80256.274447]
> > move /devices/pci:00/:
On Tue, 17 Dec 2013 23:14:12 +0400
"Andrey Borzenkov" wrote:
> В Tue, 17 Dec 2013 19:59:47 +0100
> Kay Sievers пишет:
>
> >
> > Works just fine here as expected, it's probably something in your
> > setup.
> >
>
> No, it *your* default interface renaming :)
>
> > Kay
> >
> > # head -2 /etc/
On Tue, Dec 17, 2013 at 8:14 PM, Andrey Borzenkov wrote:
> В Tue, 17 Dec 2013 19:59:47 +0100 Kay Sievers пишет:
>> # modprobe dummy
>
> dummy is not renamed.
> UDEV [80256.274447] move /devices/pci:00/:00:03.0/net/ens3 (net)
> ACTION=move
> ...
> INTERFACE=ens3
> SEQNUM=1452
> ...
On Tue, Dec 17, 2013 at 6:57 PM, Robert Milasan wrote:
> On Tue, 17 Dec 2013 17:36:21 +0100
> "Kay Sievers" wrote:
>
>> On Tue, Dec 17, 2013 at 2:05 PM, Robert Milasan
>> wrote:
>> > On Tue, 17 Dec 2013 13:54:34 +0100
>> > "Martin Pitt" wrote:
>> >
>> >> Robert Milasan [2013-12-17 12:44 +0100]:
В Tue, 17 Dec 2013 19:59:47 +0100
Kay Sievers пишет:
>
> Works just fine here as expected, it's probably something in your setup.
>
No, it *your* default interface renaming :)
> Kay
>
> # head -2 /etc/udev/rules.d/10-local.rules
> ACTION=="add", SUBSYSTEM=="net", ENV{test_device}="1"
> ACTIO
On Tue, 17 Dec 2013 17:36:21 +0100
"Kay Sievers" wrote:
> On Tue, Dec 17, 2013 at 2:05 PM, Robert Milasan
> wrote:
> > On Tue, 17 Dec 2013 13:54:34 +0100
> > "Martin Pitt" wrote:
> >
> >> Robert Milasan [2013-12-17 12:44 +0100]:
> >> > I have this rule as a test, but doesn't do squat (meaning i
В Tue, 17 Dec 2013 14:05:56 +0100
Robert Milasan пишет:
> On Tue, 17 Dec 2013 13:54:34 +0100
> "Martin Pitt" wrote:
>
> > Robert Milasan [2013-12-17 12:44 +0100]:
> > > I have this rule as a test, but doesn't do squat (meaning it doesnt
> > > work) :)
> > >
> > > ACTION=="add", SUBSYSTEM=="net
On Tue, Dec 17, 2013 at 2:05 PM, Robert Milasan wrote:
> On Tue, 17 Dec 2013 13:54:34 +0100
> "Martin Pitt" wrote:
>
>> Robert Milasan [2013-12-17 12:44 +0100]:
>> > I have this rule as a test, but doesn't do squat (meaning it doesnt
>> > work) :)
>> >
>> > ACTION=="add", SUBSYSTEM=="net", KERNEL
On Tue, 17 Dec 2013 13:54:34 +0100
"Martin Pitt" wrote:
> Robert Milasan [2013-12-17 12:44 +0100]:
> > I have this rule as a test, but doesn't do squat (meaning it doesnt
> > work) :)
> >
> > ACTION=="add", SUBSYSTEM=="net", KERNEL=="?*", ENV{test_device}="1"
> >
> > ACTION=="remove", SUBSYSTEM
Robert Milasan [2013-12-17 12:44 +0100]:
> I have this rule as a test, but doesn't do squat (meaning it doesnt
> work) :)
>
> ACTION=="add", SUBSYSTEM=="net", KERNEL=="?*", ENV{test_device}="1"
>
> ACTION=="remove", SUBSYSTEM=="net", KERNEL=="?*", ENV{test_device}=="1",
> RUN+="/bin/sh -c 'echo
On Tue, 17 Dec 2013 11:52:15 +0100
"Kay Sievers" wrote:
> On Tue, Dec 17, 2013 at 8:56 AM, Hannes Reinecke wrote:
> > On 12/17/2013 08:52 AM, Robert Milasan wrote:
> >> Hello,
> >> got a small question about creating a rule, like this:
> >>
> >> ACTION=="add", , ENV{test_device}="1"
> >>
>
On Tue, Dec 17, 2013 at 11:58 AM, Hannes Reinecke wrote:
> On 12/17/2013 11:52 AM, Kay Sievers wrote:
>> On Tue, Dec 17, 2013 at 8:56 AM, Hannes Reinecke wrote:
>>> On 12/17/2013 08:52 AM, Robert Milasan wrote:
Hello,
got a small question about creating a rule, like this:
AC
On 12/17/2013 11:52 AM, Kay Sievers wrote:
> On Tue, Dec 17, 2013 at 8:56 AM, Hannes Reinecke wrote:
>> On 12/17/2013 08:52 AM, Robert Milasan wrote:
>>> Hello,
>>> got a small question about creating a rule, like this:
>>>
>>> ACTION=="add", , ENV{test_device}="1"
>>>
>>> ACTION=="remove, .
On Tue, Dec 17, 2013 at 8:56 AM, Hannes Reinecke wrote:
> On 12/17/2013 08:52 AM, Robert Milasan wrote:
>> Hello,
>> got a small question about creating a rule, like this:
>>
>> ACTION=="add", , ENV{test_device}="1"
>>
>> ACTION=="remove, , ENV{test_device}=="1",
>> RUN+="/path/to/some/s
On 12/17/2013 08:52 AM, Robert Milasan wrote:
> Hello,
> got a small question about creating a rule, like this:
>
> ACTION=="add", , ENV{test_device}="1"
>
> ACTION=="remove, , ENV{test_device}=="1",
> RUN+="/path/to/some/script"
>
> Does udev save test_device variable someplace and th
Hello,
got a small question about creating a rule, like this:
ACTION=="add", , ENV{test_device}="1"
ACTION=="remove, , ENV{test_device}=="1",
RUN+="/path/to/some/script"
Does udev save test_device variable someplace and then it can be used
later on, when have ACTION=="remove" ?
--
R
53 matches
Mail list logo
