On Sat, 6 Aug 2022 10:59:06 -0500
Ian Pilcher wrote:
> Anyone know the trick to getting dracut to include the udev rules in
> /etc/udev/rules.d in the initramfs that it builds?
>
> I'm sure that there's a way to include a specific file, but it really
> seems like t
Anyone know the trick to getting dracut to include the udev rules in
/etc/udev/rules.d in the initramfs that it builds?
I'm sure that there's a way to include a specific file, but it really
seems like there ought to be a way to include all of the udev rules.
(Frankly, it seems like tha
Angelo,
You might look at "Back in time"
https://backintime.readthedocs.io/en/latest/mainwindow.html This is a
Python script that uses rsync as the backup mechanism but has GUI front
end to allow configuration. The only caveat is that it does not seem to
work with NTFS file systems. I form
Your experience with udev matches mine. I'm not sure if it's just a really
complex process, or if it doesn't actually work the way it says it works,
but it seems that using it successfully rarely takes fewer than 19
attempts. And I don't believe that ``--reload`` works at all; I always
reboot to tr
Hi,
although I did a lot of tests with many engagement I was not able to catch
the UDEV event
Having exhausted my trust ... I give up.
I will not try bacula which (perhaps) is excessive for my purposes, and so
I'll try with a simple script that uses the rsynk utility to copy the only
file
You should be using the UUID of the partition to detect and mount your
target. Detecting the "whole" drive is immaterial, since you want udev to
mount a partition, not a drive.
I would try to get one partition working first, then proceed to the others.
With udev testing, I've always had far more l
HI Seth,
I'm sorry to still bother you ..., but your help could save me a lot of
useless tests (since there are many parameters to manage and knowing what I
really have to do could, this trigger me the use of useless ones).
I think that I understood the crux of the problem ... (the UDEV theory …
On Wed, Jul 03, 2019 at 07:16:17AM +1200, Seth Kenlon wrote:
> Using the UUID is correct.
>
> If the script isn't being executed by udev but you can confirm that
> udev is correctl mounting your target partition, and the shell script
> functions as expected when you run it manually, then I would c
Using the UUID is correct.
If the script isn't being executed by udev but you can confirm that
udev is correctl mounting your target partition, and the shell script
functions as expected when you run it manually, then I would create a
simple timestamp shell script just to confirm that you can get
thank you Seth,
I have no problems with the script executed at the UDEV event (if this is
the meaning you attribute to the term ).
I've already done this script that works, if run from a terminal.
If by the term you mean something different, please tell me.
The problem is that this script is no
Angelo,
I agree with Tom's analysis, but my udev script accounts for it by
mounting your drive with a very specific designator.
Here is how I have tested this sort of thing before:
0. Get the UUID of your drive with blkid
1. Write a udev script to detect your drive by UUID when attached, and
to e
part of the computer causing problems .. one of which
(the most annoying) was the request to access the USB HD.
I remember that this always happened when I used the command and at
the end I also had a data leak (a back-up HD partition got corrupted and
became inaccessible).
I tried to use the
Thank you Tom,
OK,I hadn't consider, at the moment, the threat duration aspect,.
The script (to execute for the UDEV 'event) cannot be affected by this kind
on problem because it have only to write a small file, his content is :
This script carries out its task when performed from the command l
That tecmint article has several serious issues with it (this is
reflected in the comments, too).
You need a slightly more complex script for what you are attempting.
This is based on Attachup, a pyudev srcipt that backs-up a thumbdrive
to a computer upon attaching it - but you can make your shell
In general I have no ideas, but I do know that scripts executed
in udev rules have to run "fast", or they are automatically
killed off. You might want to consider having the script
do something like:
/usr/bin/at -M now <<'HERE' > /dev/null 2>&1
/full/path/to/
I use crontab to run an rsync command...
On 6/30/19 8:38 AM, Angelo Moreschini wrote:
Hi,
in order to backing up data when I connect to computer an USB HD, I
wrote the follow UDEV rule :
--
SUBSYSTEM=="block", ACTION=="add", ATTRS
Hi,
in order to backing up data when I connect to computer an USB HD, I wrote
the follow UDEV rule :
--
SUBSYSTEM=="block", ACTION=="add", ATTRS{vendor}=="152d",
ATTRS{model}=="0578", SYMLINK+="external%n",
RUN+="/usr/bin/mrs-auto_bac
Hi Seth,
On Thu, May 16, 2019 at 3:23 AM Seth Kenlon wrote:
> Here's what I use for my automated backup script (see
> https://gitlab.com/slackermedia/attachup for context):
>
> If you adapt this, you'll need to update the path (I use /media),
> you'll need to update the UUID, and you'll probabl
Here's what I use for my automated backup script (see
https://gitlab.com/slackermedia/attachup for context):
If you adapt this, you'll need to update the path (I use /media),
you'll need to update the UUID, and you'll probably need to verify
that your drive has a label, because this rule uses the
Hi,
I am trying to mount a USB drive to given symlink and mount it to a given
mount point.
Mount is working but when the device removed, I can still see the mount
cat /etc/udev/rules.d/81-hnt-usb-rule.rules
ACTION=="add", KERNEL=="sd?1", SUBSYSTEM=="block", ENV{ID_BUS}=="usb", \
SYMLINK+="hant
On Fri, Nov 07, 2014 at 03:20:20PM -0500, Kevin Cummings wrote:
> On 11/06/2014 06:53 PM, Tom Horsley wrote:
> > On Thu, 6 Nov 2014 18:47:23 -0500
> > Fred Smith wrote:
> >
> >> not finding anything on that, I hit on writing a udev rule for the
> >> USB device to make sure it appeared as a predict
On 11/06/2014 06:53 PM, Tom Horsley wrote:
> On Thu, 6 Nov 2014 18:47:23 -0500
> Fred Smith wrote:
>
>> not finding anything on that, I hit on writing a udev rule for the
>> USB device to make sure it appeared as a predictable /dev/video.
Did you try looking in /dev/v4l? My laptop builtin webcam
On Thu, 6 Nov 2014 18:47:23 -0500
Fred Smith wrote:
> not finding anything on that, I hit on writing a udev rule for the
> USB device to make sure it appeared as a predictable /dev/video.
I did something similar to recognize my 3D printer when I plug it
in, and it was quite challenging to make al
uld adapt.
not finding anything on that, I hit on writing a udev rule for the
USB device to make sure it appeared as a predictable /dev/video.
So, I found a bunch of advice on the web, and tried two rather
different udev rules, neither of which works in any way I can confirm.
Here's one of 'e
Hi all,
I'm running Fedora 20 and I have a rules in 70-persistent-net.rules to
have eth0 to my ethernet card.
Today I updated and so I installed the new
kernel-3.13.9-200.fc20.x86_64.
With this kernel the udev do a rename from eth0 to p3p1.
In the messages I see
Apr 10 09:28:07 pc-delo systemd-ud
I've been trying to set up rules suggested by powertop to be applied by
default.
Unfortunately, the wireless mouse receiver gets shut down randomly when
the usb powerdown rules are applied to it -- so I tried excluding it
from the udev rule:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}!="046d
lee writes:
> What I'm trying to do is three things:
>
>
> + make it so that smart information is not being polled from /dev/sda
>
> + make it so that DVD drives are not being polled for media changes
>
> + make sure that /dev/sda can go into sleep mode without being woken up
> unless I mount t
Ed Greshko writes:
> On 07/17/13 12:32, lee wrote:
>> Joe Zeff writes:
>>
>>> On 07/16/2013 08:39 PM, lee wrote:
Thank you! So I'll just copy the file I want to modify into
/etc/udev/rules.d/ and delete everything I don't want to modify, that
should work ...
>>> Please let us kn
On 07/17/13 12:32, lee wrote:
> Joe Zeff writes:
>
>> On 07/16/2013 08:39 PM, lee wrote:
>>> Thank you! So I'll just copy the file I want to modify into
>>> /etc/udev/rules.d/ and delete everything I don't want to modify, that
>>> should work ...
>> Please let us know how this works. I'm sure t
On 07/16/2013 09:32 PM, lee wrote:
Joe Zeff writes:
>On 07/16/2013 08:39 PM, lee wrote:
>>Thank you! So I'll just copy the file I want to modify into
>>/etc/udev/rules.d/ and delete everything I don't want to modify, that
>>should work ...
>
>Please let us know how this works. I'm sure t
Joe Zeff writes:
> On 07/16/2013 08:39 PM, lee wrote:
>> Thank you! So I'll just copy the file I want to modify into
>> /etc/udev/rules.d/ and delete everything I don't want to modify, that
>> should work ...
>
> Please let us know how this works. I'm sure that there are others on
> this list
On 07/16/2013 08:39 PM, lee wrote:
Thank you! So I'll just copy the file I want to modify into
/etc/udev/rules.d/ and delete everything I don't want to modify, that
should work ...
Please let us know how this works. I'm sure that there are others on
this list who could take advantage of the
Ed Greshko writes:
> On 07/17/13 08:07, lee wrote:
>> Hi,
>>
>> what's the proposed way to permanently change udev rules in Fedora?
>>
>> The file I need to edit has a comment in it: "do not edit this file, it
>> will be overwritten on update&quo
On 07/17/13 08:07, lee wrote:
> Hi,
>
> what's the proposed way to permanently change udev rules in Fedora?
>
> The file I need to edit has a comment in it: "do not edit this file, it
> will be overwritten on update".
>
>
From "man 7 udev"
Hi,
what's the proposed way to permanently change udev rules in Fedora?
The file I need to edit has a comment in it: "do not edit this file, it
will be overwritten on update".
--
Fedora release 19 (Schrödinger’s Cat)
--
users mailing list
users@lists.fedoraproject.org
To
On 01/23/2011 03:46 AM, Tom Horsley wrote:
> On Sat, 22 Jan 2011 17:01:00 -0500
> slamp slamp wrote:
>
>> did anything change on how udev creates devices for usb's?
>> specifically debugging device for adb?
> I thought they had been eradicating all the google android
> patches in the kernel and wot
On Sat, Jan 22, 2011 at 5:16 PM, Tom Horsley wrote:
> On Sat, 22 Jan 2011 17:01:00 -0500
> slamp slamp wrote:
>
>> did anything change on how udev creates devices for usb's?
>> specifically debugging device for adb?
>
> I thought they had been eradicating all the google android
> patches in the ke
On Sat, 22 Jan 2011 17:01:00 -0500
slamp slamp wrote:
> did anything change on how udev creates devices for usb's?
> specifically debugging device for adb?
I thought they had been eradicating all the google android
patches in the kernel and wot not because google won't
wiggle the rubber chicken t
did anything change on how udev creates devices for usb's?
specifically debugging device for adb? i dont know when this changed
but all of the sudden i did not have permission to my adb device. i
had to create a udev rule to specify the proper permission. i am
running fedora 14 x86 with all the lat
On 09/02/2010 10:41 PM, Hiisi wrote:
> 2010/9/1 Roberto Fichera :
>> Hi All in the list,
>>
>> I'm just fighting with udev rules in a F13 environment about setting
>> permissions (group, owner and mode) to certain block devices created
>> from a LVM storage
2010/9/1 Roberto Fichera :
> Hi All in the list,
>
> I'm just fighting with udev rules in a F13 environment about setting
> permissions (group, owner and mode) to certain block devices created
> from a LVM storage so that they become persistent across reboots.
>
> Does
Hi All in the list,
I'm just fighting with udev rules in a F13 environment about setting
permissions (group, owner and mode) to certain block devices created
from a LVM storage so that they become persistent across reboots.
Does anyone give me some hints.
Thanks in advance.
Roberto Fi
in /lib/udev/rules.d.
>> But what is the stuff still in /etc/udev/rules.d/ used for I wonder...
>
> Take a look at udev(7), where it says:
>
> The udev rules are read from the files located in the default rules directory
> /lib/udev/rules.d/, the custom rules directory
retty sure you have
> to
> > explicitly do something to make udev bail completely partway through
> > those evaluations.
> >
> >
>
> Many thanks for that info. The file I need is right there
> in /lib/udev/rules.d.
> But what is the stuff still in /etc/udev/r
Paul W. Frields wrote:
> On Thu, Feb 25, 2010 at 09:42:15AM +, T. Horsnell wrote:
>> Hi all,
>> I need to set up a custom rule to give me mode 666 on a custom USB device
>> (or on all the otherwise un-handled USB devices).
>> I used to do this (in FC9) by modifying ruleset 50-udev-default.rules
On Thu, Feb 25, 2010 at 09:42:15AM +, T. Horsnell wrote:
> Hi all,
> I need to set up a custom rule to give me mode 666 on a custom USB device
> (or on all the otherwise un-handled USB devices).
> I used to do this (in FC9) by modifying ruleset 50-udev-default.rules at
> the libusb entry (I kno
Hi all,
I need to set up a custom rule to give me mode 666 on a custom USB device
(or on all the otherwise un-handled USB devices).
I used to do this (in FC9) by modifying ruleset 50-udev-default.rules at
the libusb entry (I know this was not the 'correct' way, but I could never
understand udev eno
47 matches
Mail list logo
