Re: dracut not including udev rules in initramfs

[stan via users]

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 there ought to be a way to include all of the udev rules.
> (Frankly, it seems like that ought to be the default.)
> 
As it happens, I have been having some problems with dracut generated
initramfs' for the last few weeks.  So, I have been looking into the
options.

The default initramfs is built with --hostonly, which puts in the
initramfs only the items needed to boot the particular system that
initramfs will be used for.

You can use --no-hostonly, to get a generic (larger) initramfs that
*should* contain more of the udevd rules.

The module you want is /usr/lib/dracut/modules.d/95udev-rules.  You can
specify explicitly that it be included with
--add 95udev-rules
on the dracut command line.

There is also a rescue package.  That is used to build a rescue kernel,
which is supposed to include everything, and might do what you want.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

dracut not including udev rules in initramfs

[Ian Pilcher]

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 that ought to be the default.)

--

Google  Where SkyNet meets Idiocracy

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UDEV RULES

[Richard England]

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 formatted my backup drive (USB Plug in 
external) as ext4 and it works very well.


~~R


On 7/5/19 7:45 AM, Angelo Moreschini wrote:

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 files that I are in my interest.
I have already successfully used this method, but that time I mounted 
permanently  the HD USB to the computer via the file fstable ( this  
caused  problems) but this time I will do otherwise :

I'll simply mount and unmount  the HD USB via the script .
The only drawback (and it is not a serious inconvenience) will be the 
need to connect and disconnect the HD USB before that l'll launch  the 
script during the time it is running.


Thank you to all that  tried to help me

Angelo

On Thu, Jul 4, 2019 at 9:02 PM Seth Kenlon > wrote:


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 luck
testing individual tasks, one by one. Throw too much stuff at it,
and you can't tell what's not working: udev, your script, or you.

On Thu, Jul 4, 2019 at 3:26 AM Angelo Moreschini
mailto:mrangelo.fed...@gmail.com>> wrote:

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 …) but I still have a doubt that comes from the
division of my HD into partitions (to how this particularity
can influence my particular problem).

_I would like exactly to know if UDEV reveals the existence of
the entire HD USB, or if instead it detects only the
individual existence of the three partitions that are mounted
there .._


Because I read this.., I think that I could be able to  check
the real “work” of UDEV on my computer :

/“Whenever you connect to the system, the kernel detects and
initializes it, and directory with the device name is created
under / sys / directory which stores the device attributes.”./

This could be a great help, but I couldn’t identify “this:
sub-directory…., in the /sys directory, they are there many
directories with many ramifications ,   how I can to identify
the one in which they are stored the attributes of the device
whose presence is detected by UDEV?


Knowing if UDEV only reveals the existenceof the (three)
partitions and not the existence of the entire HD also has
reflections on the script script that uses rsynk to carry out
the bak-up.

This is because (probably) I should write three scripts that
use the utility rsync (one script for each partition) and not
a single script that acts on the three different partitions.


Thank you

regards


Angelo



On Wed, Jul 3, 2019 at 12:40 AM Fred Smith
mailto:fre...@fcshome.stoneham.ma.us>> wrote:

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 create a
> simple timestamp shell script just to confirm that you
can get a shell
> script to do *something* due to a udev event. The more
complex the
> shell script, the more variables you have to debug, so
simplify your
> shell script and work to just get a time stamp (or
something) when a
> udev event occurs.

I've done that by embedding echo commands into the script that
will put debugging statements  a debug file that you can look
at after bootup.

put one statement before anything else in the script and
if you
don't get an

Re: UDEV RULES

[Seth Kenlon]

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 try a new rule. It's nice when it co-operates, but it takes a lot
of work to get there.

Best of luck with bacula.

On Sat, Jul 6, 2019 at 2:46 AM Angelo Moreschini 
wrote:

> 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 files that I are in my interest.
> I have already successfully used this method, but that time I mounted
> permanently  the HD USB to the computer via the file fstable ( this
> caused  problems) but this time I will do otherwise :
> I'll simply mount and unmount  the HD USB via the script .
> The only drawback (and it is not a serious inconvenience) will be the need
> to connect and disconnect the HD USB before that l'll launch  the script
> during the time it is running.
>
> Thank you to all that  tried to help me
>
> Angelo
>
> On Thu, Jul 4, 2019 at 9:02 PM Seth Kenlon  wrote:
>
>> 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 luck testing individual
>> tasks, one by one. Throw too much stuff at it, and you can't tell what's
>> not working: udev, your script, or you.
>>
>> On Thu, Jul 4, 2019 at 3:26 AM Angelo Moreschini <
>> mrangelo.fed...@gmail.com> wrote:
>>
>>> 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
>>> …) but I still have a doubt that comes from the division of my HD into
>>> partitions (to how this particularity can influence my particular problem).
>>>
>>> *I would like exactly to know if UDEV reveals the existence of the
>>> entire HD USB, or if instead it detects only the individual existence of
>>> the three partitions that are mounted there ..*
>>>
>>>
>>> Because I read this.., I think that I could be able to  check the real
>>> “work” of UDEV  on my computer :
>>>
>>> *“Whenever you connect to the system, the kernel detects and initializes
>>> it, and directory with the device name is created under / sys / directory
>>> which stores the device attributes.”.*
>>>
>>> This could be a great help, but I couldn’t identify “this:
>>> sub-directory…., in the  /sys directory, they are there many directories
>>> with many ramifications ,   how I can to identify the one in which they are
>>> stored the attributes of the device whose presence is detected by UDEV?
>>>
>>>
>>> Knowing if UDEV only reveals the existence of the (three) partitions
>>> and not the existence of the entire HD also has reflections on the
>>> script script that uses rsynk to carry out the bak-up.
>>>
>>> This is because (probably) I should write three scripts that use the
>>> utility rsync (one script for each partition) and not a single script
>>> that acts on the three different partitions.
>>>
>>>
>>> Thank you
>>>
>>> regards
>>>
>>>
>>> Angelo
>>>
>>>
>>> On Wed, Jul 3, 2019 at 12:40 AM Fred Smith <
>>> fre...@fcshome.stoneham.ma.us> wrote:
>>>
 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 create a
 > simple timestamp shell script just to confirm that you can get a shell
 > script to do *something* due to a udev event. The more complex the
 > shell script, the more variables you have to debug, so simplify your
 > shell script and work to just get a time stamp (or something) when a
 > udev event occurs.

 I've done that by embedding echo commands into the script that
 will put debugging statements  a debug file that you can look
 at after bootup.

 put one statement before anything else in the script and if you
 don't get any debugoutput you'll know the script isn't being run.

 Fred
 >
 > On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini
 >  wrote:
 > >
 > > thank you Seth,
 > >
 > > I have no problems with the script executed at the UDEV event (if
 this 

Re: UDEV RULES

[Angelo Moreschini]

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
files that I are in my interest.
I have already successfully used this method, but that time I mounted
permanently  the HD USB to the computer via the file fstable ( this
caused  problems) but this time I will do otherwise :
I'll simply mount and unmount  the HD USB via the script .
The only drawback (and it is not a serious inconvenience) will be the need
to connect and disconnect the HD USB before that l'll launch  the script
during the time it is running.

Thank you to all that  tried to help me

Angelo

On Thu, Jul 4, 2019 at 9:02 PM Seth Kenlon  wrote:

> 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 luck testing individual
> tasks, one by one. Throw too much stuff at it, and you can't tell what's
> not working: udev, your script, or you.
>
> On Thu, Jul 4, 2019 at 3:26 AM Angelo Moreschini <
> mrangelo.fed...@gmail.com> wrote:
>
>> 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 …)
>> but I still have a doubt that comes from the division of my HD into
>> partitions (to how this particularity can influence my particular problem).
>>
>> *I would like exactly to know if UDEV reveals the existence of the entire
>> HD USB, or if instead it detects only the individual existence of the three
>> partitions that are mounted there ..*
>>
>>
>> Because I read this.., I think that I could be able to  check the real
>> “work” of UDEV  on my computer :
>>
>> *“Whenever you connect to the system, the kernel detects and initializes
>> it, and directory with the device name is created under / sys / directory
>> which stores the device attributes.”.*
>>
>> This could be a great help, but I couldn’t identify “this:
>> sub-directory…., in the  /sys directory, they are there many directories
>> with many ramifications ,   how I can to identify the one in which they are
>> stored the attributes of the device whose presence is detected by UDEV?
>>
>>
>> Knowing if UDEV only reveals the existence of the (three) partitions and
>> not the existence of the entire HD also has reflections on the script
>> script that uses rsynk to carry out the bak-up.
>>
>> This is because (probably) I should write three scripts that use the
>> utility rsync (one script for each partition) and not a single script
>> that acts on the three different partitions.
>>
>>
>> Thank you
>>
>> regards
>>
>>
>> Angelo
>>
>>
>> On Wed, Jul 3, 2019 at 12:40 AM Fred Smith 
>> wrote:
>>
>>> 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 create a
>>> > simple timestamp shell script just to confirm that you can get a shell
>>> > script to do *something* due to a udev event. The more complex the
>>> > shell script, the more variables you have to debug, so simplify your
>>> > shell script and work to just get a time stamp (or something) when a
>>> > udev event occurs.
>>>
>>> I've done that by embedding echo commands into the script that
>>> will put debugging statements  a debug file that you can look
>>> at after bootup.
>>>
>>> put one statement before anything else in the script and if you
>>> don't get any debugoutput you'll know the script isn't being run.
>>>
>>> Fred
>>> >
>>> > On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini
>>> >  wrote:
>>> > >
>>> > > 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 not executed as a result of the
>>> UDEV event.
>>> > > - - - - - -
>>> > > But maybe there is still something not clear for me that I can ask
>>> you:
>>> > > The HD (USB) that I am using,  is divided into three partitions (in
>>> order to keep the saved data separate):
>>> > > = - = - = - = - = - =
>>> > > the blkid command give  this output ...:
>>> > > / dev / sdc1: LABEL = 

Re: UDEV RULES

[Seth Kenlon]

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 luck testing individual tasks,
one by one. Throw too much stuff at it, and you can't tell what's not
working: udev, your script, or you.

On Thu, Jul 4, 2019 at 3:26 AM Angelo Moreschini 
wrote:

> 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 …)
> but I still have a doubt that comes from the division of my HD into
> partitions (to how this particularity can influence my particular problem).
>
> *I would like exactly to know if UDEV reveals the existence of the entire
> HD USB, or if instead it detects only the individual existence of the three
> partitions that are mounted there ..*
>
>
> Because I read this.., I think that I could be able to  check the real
> “work” of UDEV  on my computer :
>
> *“Whenever you connect to the system, the kernel detects and initializes
> it, and directory with the device name is created under / sys / directory
> which stores the device attributes.”.*
>
> This could be a great help, but I couldn’t identify “this:
> sub-directory…., in the  /sys directory, they are there many directories
> with many ramifications ,   how I can to identify the one in which they are
> stored the attributes of the device whose presence is detected by UDEV?
>
>
> Knowing if UDEV only reveals the existence of the (three) partitions and
> not the existence of the entire HD also has reflections on the script
> script that uses rsynk to carry out the bak-up.
>
> This is because (probably) I should write three scripts that use the
> utility rsync (one script for each partition) and not a single script
> that acts on the three different partitions.
>
>
> Thank you
>
> regards
>
>
> Angelo
>
>
> On Wed, Jul 3, 2019 at 12:40 AM Fred Smith 
> wrote:
>
>> 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 create a
>> > simple timestamp shell script just to confirm that you can get a shell
>> > script to do *something* due to a udev event. The more complex the
>> > shell script, the more variables you have to debug, so simplify your
>> > shell script and work to just get a time stamp (or something) when a
>> > udev event occurs.
>>
>> I've done that by embedding echo commands into the script that
>> will put debugging statements  a debug file that you can look
>> at after bootup.
>>
>> put one statement before anything else in the script and if you
>> don't get any debugoutput you'll know the script isn't being run.
>>
>> Fred
>> >
>> > On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini
>> >  wrote:
>> > >
>> > > 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 not executed as a result of the
>> UDEV event.
>> > > - - - - - -
>> > > But maybe there is still something not clear for me that I can ask
>> you:
>> > > The HD (USB) that I am using,  is divided into three partitions (in
>> order to keep the saved data separate):
>> > > = - = - = - = - = - =
>> > > the blkid command give  this output ...:
>> > > / dev / sdc1: LABEL = "PRTZm_sys-admin" UUID = "1A5CEE7149E4BA81"
>> TYPE = "ntfs" PARTUUID = "0007fd62-01"
>> > > / dev / sdc2: LABEL = "PRTZm_data-common" UUID = "7FB1E3D91206DE1C"
>> TYPE = "ntfs" PARTUUID = "0007fd62-02"
>> > > / dev / sdc3: LABEL = "PRTZm_programming" UUID = "0A69FDE9688969D9"
>> TYPE = "ntfs" PARTUUID = "0007fd62-03"
>> > > = - = - = - = - = - =
>> > > so far, till now, I tried to reveal the montage of the HD without
>> taking into the account of partitions into which the USB HD  is divided ..
>> > > But since the blkid command does not reveal its own UUID I am now
>> thinking that this could be the problem.
>> > >
>> > > IN CONCLUSION, since the USB is divided into partitions, ... will the
>> UDEV event reveal the presence of the entire HD (as the sole unit), or will
>> it instead reveal the presence of the three individual different partitions?
>> > >
>> > > Still I would ask  : this is a good syntax  ?
>> ENV{ID_FS_UUID}=="1A5CEE7149E4BA81"
>> > > and still also,   :-) 
>> >

Re: UDEV RULES

[Angelo Moreschini]

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 …)
but I still have a doubt that comes from the division of my HD into
partitions (to how this particularity can influence my particular problem).

*I would like exactly to know if UDEV reveals the existence of the entire
HD USB, or if instead it detects only the individual existence of the three
partitions that are mounted there ..*


Because I read this.., I think that I could be able to  check the real
“work” of UDEV  on my computer :

*“Whenever you connect to the system, the kernel detects and initializes
it, and directory with the device name is created under / sys / directory
which stores the device attributes.”.*

This could be a great help, but I couldn’t identify “this: sub-directory….,
in the  /sys directory, they are there many directories with many
ramifications ,   how I can to identify the one in which they are stored
the attributes of the device whose presence is detected by UDEV?


Knowing if UDEV only reveals the existence of the (three) partitions and
not the existence of the entire HD also has reflections on the script
script that uses rsynk to carry out the bak-up.

This is because (probably) I should write three scripts that use the
utility rsync (one script for each partition) and not a single script that
acts on the three different partitions.


Thank you

regards


Angelo


On Wed, Jul 3, 2019 at 12:40 AM Fred Smith 
wrote:

> 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 create a
> > simple timestamp shell script just to confirm that you can get a shell
> > script to do *something* due to a udev event. The more complex the
> > shell script, the more variables you have to debug, so simplify your
> > shell script and work to just get a time stamp (or something) when a
> > udev event occurs.
>
> I've done that by embedding echo commands into the script that
> will put debugging statements  a debug file that you can look
> at after bootup.
>
> put one statement before anything else in the script and if you
> don't get any debugoutput you'll know the script isn't being run.
>
> Fred
> >
> > On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini
> >  wrote:
> > >
> > > 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 not executed as a result of the
> UDEV event.
> > > - - - - - -
> > > But maybe there is still something not clear for me that I can ask you:
> > > The HD (USB) that I am using,  is divided into three partitions (in
> order to keep the saved data separate):
> > > = - = - = - = - = - =
> > > the blkid command give  this output ...:
> > > / dev / sdc1: LABEL = "PRTZm_sys-admin" UUID = "1A5CEE7149E4BA81" TYPE
> = "ntfs" PARTUUID = "0007fd62-01"
> > > / dev / sdc2: LABEL = "PRTZm_data-common" UUID = "7FB1E3D91206DE1C"
> TYPE = "ntfs" PARTUUID = "0007fd62-02"
> > > / dev / sdc3: LABEL = "PRTZm_programming" UUID = "0A69FDE9688969D9"
> TYPE = "ntfs" PARTUUID = "0007fd62-03"
> > > = - = - = - = - = - =
> > > so far, till now, I tried to reveal the montage of the HD without
> taking into the account of partitions into which the USB HD  is divided ..
> > > But since the blkid command does not reveal its own UUID I am now
> thinking that this could be the problem.
> > >
> > > IN CONCLUSION, since the USB is divided into partitions, ... will the
> UDEV event reveal the presence of the entire HD (as the sole unit), or will
> it instead reveal the presence of the three individual different partitions?
> > >
> > > Still I would ask  : this is a good syntax  ?
> ENV{ID_FS_UUID}=="1A5CEE7149E4BA81"
> > > and still also,   :-) 
> > > what I have to use the UUID number, or instead the PARTUUID number ?
> > >
> > > thank you very much
> > > Angelo
> > >
> > > On Mon, Jul 1, 2019 at 2:00 PM Seth Kenlon  wrote:
> > >>
> > >> 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 execute a test shell script (such as /usr/local/bin/angelo-test.sh)
> > >> when the drive i

Re: UDEV RULES

[Fred Smith]

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 create a
> simple timestamp shell script just to confirm that you can get a shell
> script to do *something* due to a udev event. The more complex the
> shell script, the more variables you have to debug, so simplify your
> shell script and work to just get a time stamp (or something) when a
> udev event occurs.

I've done that by embedding echo commands into the script that
will put debugging statements  a debug file that you can look
at after bootup.

put one statement before anything else in the script and if you 
don't get any debugoutput you'll know the script isn't being run.

Fred
> 
> On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini
>  wrote:
> >
> > 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 not executed as a result of the UDEV 
> > event.
> > - - - - - -
> > But maybe there is still something not clear for me that I can ask you:
> > The HD (USB) that I am using,  is divided into three partitions (in order 
> > to keep the saved data separate):
> > = - = - = - = - = - =
> > the blkid command give  this output ...:
> > / dev / sdc1: LABEL = "PRTZm_sys-admin" UUID = "1A5CEE7149E4BA81" TYPE = 
> > "ntfs" PARTUUID = "0007fd62-01"
> > / dev / sdc2: LABEL = "PRTZm_data-common" UUID = "7FB1E3D91206DE1C" TYPE = 
> > "ntfs" PARTUUID = "0007fd62-02"
> > / dev / sdc3: LABEL = "PRTZm_programming" UUID = "0A69FDE9688969D9" TYPE = 
> > "ntfs" PARTUUID = "0007fd62-03"
> > = - = - = - = - = - =
> > so far, till now, I tried to reveal the montage of the HD without taking 
> > into the account of partitions into which the USB HD  is divided ..
> > But since the blkid command does not reveal its own UUID I am now thinking 
> > that this could be the problem.
> >
> > IN CONCLUSION, since the USB is divided into partitions, ... will the UDEV 
> > event reveal the presence of the entire HD (as the sole unit), or will it 
> > instead reveal the presence of the three individual different partitions?
> >
> > Still I would ask  : this is a good syntax  ?
> > ENV{ID_FS_UUID}=="1A5CEE7149E4BA81"
> > and still also,   :-) 
> > what I have to use the UUID number, or instead the PARTUUID number ?
> >
> > thank you very much
> > Angelo
> >
> > On Mon, Jul 1, 2019 at 2:00 PM Seth Kenlon  wrote:
> >>
> >> 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 execute a test shell script (such as /usr/local/bin/angelo-test.sh)
> >> when the drive is attached
> >> 2. Create the script /usr/local/bin/angelo-test.sh to do something
> >> very simle, like echo `date` >> /tmp/backup.log, and make it
> >> executable
> >> 3. Reboot
> >> 4. Attach your drive, and then look for the execution of your test
> >> script. If there was a /tmp/backup.log created with the correct date
> >> and time in it.
> >> 5. Look in /media to ensure that your drive has been mounted as a
> >> unique and persistent entitiy.
> >>
> >> If it worked, then change the script to your real backup script.
> >> Continue to test.
> >>
> >> If it failed, review your udev script, use `udevadm monitor` to
> >> discover why your drive isn't triggering your script.
> >> ___
> >> users mailing list -- users@lists.fedoraproject.org
> >> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> >
> > ___
> > users mailing list -- users@lists.fedoraproject.org
> > To unsubscribe send an email to users-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedor

Re: UDEV RULES

[Seth Kenlon]

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 a shell
script to do *something* due to a udev event. The more complex the
shell script, the more variables you have to debug, so simplify your
shell script and work to just get a time stamp (or something) when a
udev event occurs.

On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini
 wrote:
>
> 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 not executed as a result of the UDEV event.
> - - - - - -
> But maybe there is still something not clear for me that I can ask you:
> The HD (USB) that I am using,  is divided into three partitions (in order to 
> keep the saved data separate):
> = - = - = - = - = - =
> the blkid command give  this output ...:
> / dev / sdc1: LABEL = "PRTZm_sys-admin" UUID = "1A5CEE7149E4BA81" TYPE = 
> "ntfs" PARTUUID = "0007fd62-01"
> / dev / sdc2: LABEL = "PRTZm_data-common" UUID = "7FB1E3D91206DE1C" TYPE = 
> "ntfs" PARTUUID = "0007fd62-02"
> / dev / sdc3: LABEL = "PRTZm_programming" UUID = "0A69FDE9688969D9" TYPE = 
> "ntfs" PARTUUID = "0007fd62-03"
> = - = - = - = - = - =
> so far, till now, I tried to reveal the montage of the HD without taking into 
> the account of partitions into which the USB HD  is divided ..
> But since the blkid command does not reveal its own UUID I am now thinking 
> that this could be the problem.
>
> IN CONCLUSION, since the USB is divided into partitions, ... will the UDEV 
> event reveal the presence of the entire HD (as the sole unit), or will it 
> instead reveal the presence of the three individual different partitions?
>
> Still I would ask  : this is a good syntax  ?
> ENV{ID_FS_UUID}=="1A5CEE7149E4BA81"
> and still also,   :-) 
> what I have to use the UUID number, or instead the PARTUUID number ?
>
> thank you very much
> Angelo
>
> On Mon, Jul 1, 2019 at 2:00 PM Seth Kenlon  wrote:
>>
>> 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 execute a test shell script (such as /usr/local/bin/angelo-test.sh)
>> when the drive is attached
>> 2. Create the script /usr/local/bin/angelo-test.sh to do something
>> very simle, like echo `date` >> /tmp/backup.log, and make it
>> executable
>> 3. Reboot
>> 4. Attach your drive, and then look for the execution of your test
>> script. If there was a /tmp/backup.log created with the correct date
>> and time in it.
>> 5. Look in /media to ensure that your drive has been mounted as a
>> unique and persistent entitiy.
>>
>> If it worked, then change the script to your real backup script.
>> Continue to test.
>>
>> If it failed, review your udev script, use `udevadm monitor` to
>> discover why your drive isn't triggering your script.
>> ___
>> users mailing list -- users@lists.fedoraproject.org
>> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: UDEV RULES

[Angelo Moreschini]

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 not executed as a result of the UDEV
event.
- - - - - -
But maybe there is still something not clear for me that I can ask you:
The HD (USB) that I am using,  is divided into three partitions (in order
to keep the saved data separate):
= - = - = - = - = - =
the blkid command give  this output ...:
/ dev / sdc1: LABEL = "PRTZm_sys-admin" UUID = "1A5CEE7149E4BA81" TYPE =
"ntfs" PARTUUID = "0007fd62-01"
/ dev / sdc2: LABEL = "PRTZm_data-common" UUID = "7FB1E3D91206DE1C" TYPE =
"ntfs" PARTUUID = "0007fd62-02"
/ dev / sdc3: LABEL = "PRTZm_programming" UUID = "0A69FDE9688969D9" TYPE =
"ntfs" PARTUUID = "0007fd62-03"
= - = - = - = - = - =
so far, till now, I tried to reveal the montage of the HD without taking
into the account of partitions into which the USB HD  is divided ..
But since the blkid command does not reveal its own UUID I am now thinking
that this could be the problem.

IN CONCLUSION, since the USB is divided into partitions, ... will the UDEV
event reveal the presence of the entire HD (as the sole unit), or will it
instead reveal the presence of the three individual different partitions?

Still I would ask  : this is a good syntax  ?
*ENV{ID_FS_UUID}=="1A5CEE7149E4BA81"
*
and still also,   :-) 
what I have to use the *UUID *number, or instead the *PARTUUID* number ?

thank you very much
Angelo

On Mon, Jul 1, 2019 at 2:00 PM Seth Kenlon  wrote:

> 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 execute a test shell script (such as /usr/local/bin/angelo-test.sh)
> when the drive is attached
> 2. Create the script /usr/local/bin/angelo-test.sh to do something
> very simle, like echo `date` >> /tmp/backup.log, and make it
> executable
> 3. Reboot
> 4. Attach your drive, and then look for the execution of your test
> script. If there was a /tmp/backup.log created with the correct date
> and time in it.
> 5. Look in /media to ensure that your drive has been mounted as a
> unique and persistent entitiy.
>
> If it worked, then change the script to your real backup script.
> Continue to test.
>
> If it failed, review your udev script, use `udevadm monitor` to
> discover why your drive isn't triggering your script.
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: UDEV RULES

[Seth Kenlon]

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 execute a test shell script (such as /usr/local/bin/angelo-test.sh)
when the drive is attached
2. Create the script /usr/local/bin/angelo-test.sh to do something
very simle, like echo `date` >> /tmp/backup.log, and make it
executable
3. Reboot
4. Attach your drive, and then look for the execution of your test
script. If there was a /tmp/backup.log created with the correct date
and time in it.
5. Look in /media to ensure that your drive has been mounted as a
unique and persistent entitiy.

If it worked, then change the script to your real backup script.
Continue to test.

If it failed, review your udev script, use `udevadm monitor` to
discover why your drive isn't triggering your script.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: UDEV RULES

[Angelo Moreschini]

Hi Seth,
after reading the answer from Tom, (the duration of the tread) I am no
longer sure that a scrpt acting at the event to connect an HD USB to the
computer to back up the data may be the best solution for me .

I'm dealing with the problem of backing up data on my computer for a long
time.
I had it solved years ago by launching a script (both from the terminal and
through the graphical menu) that used the linux  command.

I used this method for months (maybe more than one year), but over time the
back-up directories on the USB HD were considered and used by Fedora as an
integral  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 UDEV rules to exclude the automatic mounting of the USB
HD, but without access. Reading the TecMint article made me think I had
a possible solution ...

I also took interest in using bacula ... and I lost some time figuring out
how this tool (bacula) works .., but in the end I gave up, because I got
the idea that bacula has a different goal (much bigger) of what I propose:
my objective is to save my work (I am a programmer) once a day or at least
a few times a week.

Having seen that you have experience in the field, I kindly ask you to give
me your guidance regarding the solution of my back-up problem.

thank you
Angelo

On Mon, Jul 1, 2019 at 8:18 AM Angelo Moreschini 
wrote:

> 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 line . I'll
> change his content at right moment..
>
> Hi Seth,
> I understand what you say,  ... and thank you for yours advice.
>
> As well I have not experience with this kind of problem I'll begin do do
> what you already suggested me...
> I'll post again a massage if I need help
>
> thank you
>  Angelo
>
> On Sun, Jun 30, 2019 at 10:34 PM Seth Kenlon  wrote:
>
>> 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 script
>> do whatever you like.  https://gitlab.com/slackermedia/attachup
>>
>> ```
>> KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
>> IMPORT{program}="/sbin/blkid -o udev -p %N"
>> # Get label or create one
>> ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
>> ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"
>> # mount
>> ACTION=="add", ENV{mount_options}="relatime"
>> ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs",
>> ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
>> # mount and start backup script##
>> ## replace UUID_OF_PARTITION with the UUID of your destination partition
>> ACTION=="add", ENV{ID_FS_UUID}=="UUID_OF_PARTITION", RUN+="/bin/mkdir
>> -p /media/%E{dir_name}", RUN+="/sbin/mount -o $env{mount_options}
>> /dev/%k /media/%E{dir_name}", MODE="0770", GROUP="users",
>> RUN+="/usr/bin/mrs-auto_backup.sh"
>> # Clean up after removal
>> ACTION=="remove", ENV{dir_name}!="", RUN+="/sbin/umount -l
>> /media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"
>> # Exit
>> LABEL="media_by_label_auto_mount_end"
>> ```
>>
>> Replace UUID_OF_PARTITION with the UUID of the partition that you want
>> to backup to. You can obtain the UUID with the ``blkid`` command (make
>> sure the drive is attached at the time).
>>
>> Make sure you are in the ``users`` group (or else use a group that you
>> ARE in).
>>
>> Install that code as a udev rule, and then reboot (I still don't trust
>> udevadm control --reload).
>>
>> When you attach your drive, it will get mounted to /media.
>>
>> Change your backup script (/usr/bin/mrs-auto_backup.sh) so that it
>> back-ups to what gets mounted in /media. I find that this helps ensure
>> a reliable and unique location for your backup destination.
>>
>> Make sure your backup script (/usr/bin/mrs-auto_backup.sh

Re: UDEV RULES

[Angelo Moreschini]

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 line . I'll
change his content at right moment..

Hi Seth,
I understand what you say,  ... and thank you for yours advice.

As well I have not experience with this kind of problem I'll begin do do
what you already suggested me...
I'll post again a massage if I need help

thank you
 Angelo

On Sun, Jun 30, 2019 at 10:34 PM Seth Kenlon  wrote:

> 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 script
> do whatever you like.  https://gitlab.com/slackermedia/attachup
>
> ```
> KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
> IMPORT{program}="/sbin/blkid -o udev -p %N"
> # Get label or create one
> ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
> ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"
> # mount
> ACTION=="add", ENV{mount_options}="relatime"
> ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs",
> ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
> # mount and start backup script##
> ## replace UUID_OF_PARTITION with the UUID of your destination partition
> ACTION=="add", ENV{ID_FS_UUID}=="UUID_OF_PARTITION", RUN+="/bin/mkdir
> -p /media/%E{dir_name}", RUN+="/sbin/mount -o $env{mount_options}
> /dev/%k /media/%E{dir_name}", MODE="0770", GROUP="users",
> RUN+="/usr/bin/mrs-auto_backup.sh"
> # Clean up after removal
> ACTION=="remove", ENV{dir_name}!="", RUN+="/sbin/umount -l
> /media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"
> # Exit
> LABEL="media_by_label_auto_mount_end"
> ```
>
> Replace UUID_OF_PARTITION with the UUID of the partition that you want
> to backup to. You can obtain the UUID with the ``blkid`` command (make
> sure the drive is attached at the time).
>
> Make sure you are in the ``users`` group (or else use a group that you ARE
> in).
>
> Install that code as a udev rule, and then reboot (I still don't trust
> udevadm control --reload).
>
> When you attach your drive, it will get mounted to /media.
>
> Change your backup script (/usr/bin/mrs-auto_backup.sh) so that it
> back-ups to what gets mounted in /media. I find that this helps ensure
> a reliable and unique location for your backup destination.
>
> Make sure your backup script (/usr/bin/mrs-auto_backup.sh) is executable.
>
> Good luck!
>
> On Mon, Jul 1, 2019 at 12:40 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{vendor}=="152d",
> ATTRS{model}=="0578",  SYMLINK+="external%n",
> RUN+="/usr/bin/mrs-auto_backup.sh"
> > ---
> > the rule is the content of the file :
> /etc/udev/rules.d/10.autobackup.rules
> > that I self created .
> >
> > I learned this method at the link :
> https://www.tecmint.com/auto-backup-files-to-usb-media-in-linux/  ("How
> to backup files to USB media when connected")
> >
> > As well I tried in many different combinations and parameters values,
> never I was able to execute the script inside the rule.
> >
> > -
> > In order to get the USB HD characteristic of the USB Hard Disk to use
> for backing-up the data I used the command :
> > 
> > and its output is transcribed below
> >
> > Could someone help me to understand because this rule doesn't works ?
> >
> > thank you
> > regards
> > Angelo
> > ---
> > features (attributes) of the USB Hrd Disk that I got with the above
> command:
> > [angelo_dev@localhost ~]$ sudo udevadm info -q all -n /dev/sdc
> >
> > P:
> /devices/pci:00/:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc
> > N: sdc
> > L: 0
> > S: external
> > S: disk/by-path/pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
> > S: disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0
> > E:
> DEVPATH=/devices/pci:00/:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc
> > E: DEVNAME=/dev/sdc
> > E: DEVTYPE=disk
> > E: MAJOR=8
> > E: MINOR=32
> > E: SUBSYSTEM=block
> > E: USEC_INITIALIZED=11404758453
> > E: ID_VENDOR=JMicron
> > E: ID_VENDOR_ENC=JMicron\x20
> > E: ID_VENDOR_ID=152d
> > E: ID_MODEL=Tech
> > E: ID_MODEL_ENC=Tech\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
> > E: ID_MODEL_ID=0578
> > E: ID_REVISION=0203
> > E: ID_SERIAL=JMicron_Tech_DB12345681BC-0:0
> > E: ID_SERIAL_SHORT=DB12345681BC
> > E: ID_TYPE=disk
> > E: ID_INSTANCE=0:0
> > E: ID_BUS=usb
> > E

Re: UDEV RULES

[Seth Kenlon]

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 script
do whatever you like.  https://gitlab.com/slackermedia/attachup

```
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
IMPORT{program}="/sbin/blkid -o udev -p %N"
# Get label or create one
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"
# mount
ACTION=="add", ENV{mount_options}="relatime"
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs",
ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
# mount and start backup script##
## replace UUID_OF_PARTITION with the UUID of your destination partition
ACTION=="add", ENV{ID_FS_UUID}=="UUID_OF_PARTITION", RUN+="/bin/mkdir
-p /media/%E{dir_name}", RUN+="/sbin/mount -o $env{mount_options}
/dev/%k /media/%E{dir_name}", MODE="0770", GROUP="users",
RUN+="/usr/bin/mrs-auto_backup.sh"
# Clean up after removal
ACTION=="remove", ENV{dir_name}!="", RUN+="/sbin/umount -l
/media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"
# Exit
LABEL="media_by_label_auto_mount_end"
```

Replace UUID_OF_PARTITION with the UUID of the partition that you want
to backup to. You can obtain the UUID with the ``blkid`` command (make
sure the drive is attached at the time).

Make sure you are in the ``users`` group (or else use a group that you ARE in).

Install that code as a udev rule, and then reboot (I still don't trust
udevadm control --reload).

When you attach your drive, it will get mounted to /media.

Change your backup script (/usr/bin/mrs-auto_backup.sh) so that it
back-ups to what gets mounted in /media. I find that this helps ensure
a reliable and unique location for your backup destination.

Make sure your backup script (/usr/bin/mrs-auto_backup.sh) is executable.

Good luck!

On Mon, Jul 1, 2019 at 12:40 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{vendor}=="152d", 
> ATTRS{model}=="0578",  SYMLINK+="external%n", 
> RUN+="/usr/bin/mrs-auto_backup.sh"
> ---
> the rule is the content of the file : /etc/udev/rules.d/10.autobackup.rules
> that I self created .
>
> I learned this method at the link : 
> https://www.tecmint.com/auto-backup-files-to-usb-media-in-linux/  ("How to 
> backup files to USB media when connected")
>
> As well I tried in many different combinations and parameters values, never I 
> was able to execute the script inside the rule.
>
> -
> In order to get the USB HD characteristic of the USB Hard Disk to use for 
> backing-up the data I used the command :
> 
> and its output is transcribed below
>
> Could someone help me to understand because this rule doesn't works ?
>
> thank you
> regards
> Angelo
> ---
> features (attributes) of the USB Hrd Disk that I got with the above command   
>  :
> [angelo_dev@localhost ~]$ sudo udevadm info -q all -n /dev/sdc
>
> P: 
> /devices/pci:00/:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc
> N: sdc
> L: 0
> S: external
> S: disk/by-path/pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
> S: disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0
> E: 
> DEVPATH=/devices/pci:00/:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc
> E: DEVNAME=/dev/sdc
> E: DEVTYPE=disk
> E: MAJOR=8
> E: MINOR=32
> E: SUBSYSTEM=block
> E: USEC_INITIALIZED=11404758453
> E: ID_VENDOR=JMicron
> E: ID_VENDOR_ENC=JMicron\x20
> E: ID_VENDOR_ID=152d
> E: ID_MODEL=Tech
> E: ID_MODEL_ENC=Tech\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
> E: ID_MODEL_ID=0578
> E: ID_REVISION=0203
> E: ID_SERIAL=JMicron_Tech_DB12345681BC-0:0
> E: ID_SERIAL_SHORT=DB12345681BC
> E: ID_TYPE=disk
> E: ID_INSTANCE=0:0
> E: ID_BUS=usb
> E: ID_USB_INTERFACES=:080650:080662:
> E: ID_USB_INTERFACE_NUM=00
> E: ID_USB_DRIVER=uas
> E: ID_PATH=pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
> E: ID_PATH_TAG=pci-_00_14_0-usb-0_5_1_2_1_0-scsi-0_0_0_0
> E: ID_PART_TABLE_UUID=0007fd62
> E: ID_PART_TABLE_TYPE=dos
> E: DEVLINKS=/dev/external 
> /dev/disk/by-path/pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0 
> /dev/disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0
> E: TAGS=:systemd:
>
>
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/arc

Re: UDEV RULES

[Tom Horsley]

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/do-the-backup/script
HERE

That will very quickly arrange for a different thread
of control to run the actual backup, and avoid systemd
killing it off because it is too slow.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: UDEV RULES

[Robert Moskowitz]

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{vendor}=="152d", 
ATTRS{model}=="0578",  SYMLINK+="external%n", 
RUN+="/usr/bin/mrs-auto_backup.sh"

---
the rule is the content of the file 
:_*/etc/udev/rules.d/10.autobackup.rules *_

that I self created .

I learned this method at the link 
:https://www.tecmint.com/auto-backup-files-to-usb-media-in-linux/ 
 
*("How to backup files to USB media when connected*")


As well I tried in many different combinations and parameters values, 
never I was able to execute the script inside the rule.


-
In order to get the USB HD characteristic of the USB Hard Disk to use 
for backing-up the data I used the command :

_**_
and its output is transcribed below

Could someone help me to understand because this rule doesn't works ?

thank you
regards
Angelo
---
*features (attributes) of the USB Hrd Disk that I got with the above 
command *:

[angelo_dev@localhost ~]$ sudo udevadm info -q all -n /dev/sdc

/P: 
/devices/pci:00/:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc

N: sdc
L: 0
S: external
S: disk/by-path/pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
S: disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0
E: 
DEVPATH=/devices/pci:00/:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc

E: DEVNAME=/dev/sdc
E: DEVTYPE=disk
E: MAJOR=8
E: MINOR=32
E: SUBSYSTEM=block
E: USEC_INITIALIZED=11404758453
E: ID_VENDOR=JMicron
E: ID_VENDOR_ENC=JMicron\x20
E: ID_VENDOR_ID=152d
E: ID_MODEL=Tech
E: ID_MODEL_ENC=Tech\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=0578
E: ID_REVISION=0203
E: ID_SERIAL=JMicron_Tech_DB12345681BC-0:0
E: ID_SERIAL_SHORT=DB12345681BC
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:080662:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=uas
E: ID_PATH=pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-_00_14_0-usb-0_5_1_2_1_0-scsi-0_0_0_0
E: ID_PART_TABLE_UUID=0007fd62
E: ID_PART_TABLE_TYPE=dos
E: DEVLINKS=/dev/external 
/dev/disk/by-path/pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0 
/dev/disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0

E: TAGS=:systemd:/



___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

UDEV RULES

[Angelo Moreschini]

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_backup.sh"
---
the rule is the content of the file :*
/etc/udev/rules.d/10.autobackup.rules *
that I self created .

I learned this method at the link :
https://www.tecmint.com/auto-backup-files-to-usb-media-in-linux/  *("How to
backup files to USB media when connected*")

As well I tried in many different combinations and parameters values, never
I was able to execute the script inside the rule.

-
In order to get the USB HD characteristic of the USB Hard Disk to use for
backing-up the data I used the command :
**
and its output is transcribed below

Could someone help me to understand because this rule doesn't works ?

thank you
regards
Angelo
---
*features (attributes) of the USB Hrd Disk that I got with the above
command*:
[angelo_dev@localhost ~]$ sudo udevadm info -q all -n /dev/sdc


































*P:
/devices/pci:00/:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdcN:
sdcL: 0S: externalS:
disk/by-path/pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0S:
disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0E:
DEVPATH=/devices/pci:00/:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdcE:
DEVNAME=/dev/sdcE: DEVTYPE=diskE: MAJOR=8E: MINOR=32E: SUBSYSTEM=blockE:
USEC_INITIALIZED=11404758453E: ID_VENDOR=JMicronE:
ID_VENDOR_ENC=JMicron\x20E: ID_VENDOR_ID=152dE: ID_MODEL=TechE:
ID_MODEL_ENC=Tech\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20E:
ID_MODEL_ID=0578E: ID_REVISION=0203E:
ID_SERIAL=JMicron_Tech_DB12345681BC-0:0E: ID_SERIAL_SHORT=DB12345681BCE:
ID_TYPE=diskE: ID_INSTANCE=0:0E: ID_BUS=usbE:
ID_USB_INTERFACES=:080650:080662:E: ID_USB_INTERFACE_NUM=00E:
ID_USB_DRIVER=uasE: ID_PATH=pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0E:
ID_PATH_TAG=pci-_00_14_0-usb-0_5_1_2_1_0-scsi-0_0_0_0E:
ID_PART_TABLE_UUID=0007fd62E: ID_PART_TABLE_TYPE=dosE:
DEVLINKS=/dev/external
/dev/disk/by-path/pci-:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
/dev/disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0E: TAGS=:systemd:*
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: auto mount and unmount using udev rules

[Danishka Navin]

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 probably need to verify
> that your drive has a label, because this rule uses the UUID and label
> to identify the drive.
>
> I save this as 80.local-rules in /etc/udev/rules.d
> Supposedly you can do a `udevadm control reload` to force the rules to
> be reloaded, but I usually reboot just to make sure udev is on top of
> its game.
>
> KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
> IMPORT{program}="/sbin/blkid -o udev -p %N"
> # Get label or create one
> ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
> ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"
> # mount
> ACTION=="add", ENV{mount_options}="relatime"
> ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs",
> ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
> # Clean up after removal
> ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l
> /media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"
> # Exit
> LABEL="media_by_label_auto_mount_end"
> #mount
>
> ACTION=="add",ENV{ID_FS_UUID}=="165f84bc-1d70-47a4-9fdc-7a588fa457c4",RUN+="/bin/mkdir
> -p /media/%E{dir_name}",RUN+="/bin/mount -o $env{mount_options}
> /dev/%k /media/%E{dir_name}",MODE="0770",GROUP="users"
>

I tried with your udev rule but no luck.


[root@hanthana ~]# cat /etc/udev/rules.d/81-hnt-usb-rule.rules
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
IMPORT{program}="/sbin/blkid -o udev -p %N"

# Get label or create one
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
ENV{ID_FS_LABEL}=="", ENV{dir_name}="backup-%k"
# mount
ACTION=="add", ENV{mount_options}="relatime"
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs|ext4",
ENV{mount_options}="$env{mount_options},utf8,umask=002"
# Clean up after removal
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l
/media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"
# Exit
LABEL="media_by_label_auto_mount_end"
#mount
ACTION=="add",ENV{ID_FS_UUID}=="7720-13E1",RUN+="/bin/mkdir -p
/media/%E{dir_name}",RUN+="/bin/mount -o $env{mount_options} /dev/%k
/media/%E{dir_name}",MODE="0770"
[root@hanthana ~]#
[root@hanthana ~]#
[root@hanthana ~]# udevadm control --reload
[root@hanthana ~]#

I noticed that udev rule create the given directory but it won't mount the
device under given directory but usual direcotry /run/meda//.
[root@hanthana ~]# ls /media/backup/
[root@hanthana ~]#
[root@hanthana ~]# df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda116G  5.5G  9.7G  37% /run/media/danishka/LIVE


I did test the rule.

run: '/bin/mkdir -p /media/backup'
run: '/bin/mount -o relatime,utf8,umask=002 /dev/sdb1 /media/backup'
Unload module index
Unloaded link configuration context.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: auto mount and unmount using udev rules

[Seth Kenlon]

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 UUID and label
to identify the drive.

I save this as 80.local-rules in /etc/udev/rules.d
Supposedly you can do a `udevadm control reload` to force the rules to
be reloaded, but I usually reboot just to make sure udev is on top of
its game.

KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
IMPORT{program}="/sbin/blkid -o udev -p %N"
# Get label or create one
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"
# mount
ACTION=="add", ENV{mount_options}="relatime"
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs",
ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
# Clean up after removal
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l
/media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"
# Exit
LABEL="media_by_label_auto_mount_end"
#mount
ACTION=="add",ENV{ID_FS_UUID}=="165f84bc-1d70-47a4-9fdc-7a588fa457c4",RUN+="/bin/mkdir
-p /media/%E{dir_name}",RUN+="/bin/mount -o $env{mount_options}
/dev/%k /media/%E{dir_name}",MODE="0770",GROUP="users"

On Wed, May 15, 2019 at 11:37 PM Danishka Navin  wrote:
>
> 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+="hanthana%n", ENV{SYSTEMD_WANTS}="hnt-usb-rule.service"
>
> ACTION=="remove",  RUN+="/usr/bin/umount $(/usr/bin/mount | grep backup | 
> /usr/bin/awk '{print $1}')"
>
> 
> [danishka@hanthana ~]$ cat /etc/systemd/system/hnt-usb-rule.service
> [Unit]
> Description=USB Mount
>
>
> [Service]
> Type=oneshot
> ExecStart=/root/hnt.sh
>
> [Install]
> WantedBy=default.target
> --
> cat /root/hnt.sh
> #!/bin/bash
> mkdir /backup
> lsblk > /var/log/hnt.log
> /usr/bin/mount /dev/hanthana1 /backup
>
> 
>
> ACTION=="remove",  RUN+="/usr/bin/umount $(/usr/bin/mount | grep backup | 
> /usr/bin/awk '{print $1}')"
>
>
> [root@hanthana ~]# echo $(/usr/bin/mount | grep backup | /usr/bin/awk '{print 
> $1}')
> /dev/sda1
>
> Even though you can't access /backup after removing the USB, mount command 
> shows following results (After plugin the usb and remove several times). I 
> wonder why it automatically remove these entries as fedora normally mount 
> USBs on default location.
>
> /dev/sda1 on /backup type ext4 (rw, relatime, seclabel)
> /dev/sdb1 on /backup type ext4 (rw, relatime, seclabel)
> /dev/sdc1 on /backup type ext4 (rw, relatime, seclabel)
> /dev/sdd1 on /backup type ext4 (rw, relatime, seclabel)
>
> I was testing on both Fedora 28 Gnome and LXDE.
>
> Regards,
> --
> Danishka Navin
>
>
>
>
>
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

auto mount and unmount using udev rules

[Danishka Navin]

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+="hanthana%n", ENV{SYSTEMD_WANTS}="hnt-usb-rule.service"

ACTION=="remove",  RUN+="/usr/bin/umount $(/usr/bin/mount | grep backup |
/usr/bin/awk '{print $1}')"


[danishka@hanthana ~]$ cat /etc/systemd/system/hnt-usb-rule.service
[Unit]
Description=USB Mount


[Service]
Type=oneshot
ExecStart=/root/hnt.sh

[Install]
WantedBy=default.target
--
cat /root/hnt.sh
#!/bin/bash
mkdir /backup
lsblk > /var/log/hnt.log
/usr/bin/mount /dev/hanthana1 /backup



ACTION=="remove",  RUN+="/usr/bin/umount $(/usr/bin/mount | grep backup |
/usr/bin/awk '{print $1}')"


[root@hanthana ~]# echo $(/usr/bin/mount | grep backup | /usr/bin/awk
'{print $1}')
/dev/sda1

Even though you can't access /backup after removing the USB, mount command
shows following results (After plugin the usb and remove several times). I
wonder why it automatically remove these entries as fedora normally mount
USBs on default location.

/dev/sda1 on /backup type ext4 (rw, relatime, seclabel)
/dev/sdb1 on /backup type ext4 (rw, relatime, seclabel)
/dev/sdc1 on /backup type ext4 (rw, relatime, seclabel)
/dev/sdd1 on /backup type ext4 (rw, relatime, seclabel)

I was testing on both Fedora 28 Gnome and LXDE.

Regards,
-- 
Danishka Navin
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: udev rules for webcam

[Fred Smith]

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 predictable /dev/video.
> 
> Did you try looking in /dev/v4l?  My laptop builtin webcam leaves
> entries in there.  The v4l directory has 2 sub-directories: by-id and
> by-path which contain entries for my webcam.

Hi Kev!

Yes, late yesterday I learned enough about udev to find the files
there, so I've modified my script to use those files to figure out
which /dev entry is the webcam I'm interested in. I suppose I could
use those files directly, too, and save a bit of computation.

an excerpt from the script that operates the camera:

  # figure out which /dev/video entry is the camera we want.
  foo=`ls -l --dereference-command-line-symlink-to-dir 
/dev/v4l/by-id/usb-046d_0825*`
  devnode=`echo $foo | sed -e "s;^.*> \.\./\.\./;;"`
  # then snap it
  ${progdir}/fswebcam --png 9 -d /dev/${devnode} -r 800x600 -F 2 --save 
${day}/img-%Y%m%d-%H%M%S.png


-- 
 Fred Smith -- fre...@fcshome.stoneham.ma.us -
The Lord detests the way of the wicked 
  but he loves those who pursue righteousness.
- Proverbs 15:9 (niv) -
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: udev rules for webcam

[Kevin Cummings]

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 leaves
entries in there.  The v4l directory has 2 sub-directories: by-id and
by-path which contain entries for my webcam.

> I did something similar to recognize my 3D printer when I plug it
> in, and it was quite challenging to make all my code work
> because systemd runs things in magic "cgroups" that get killed
> quickly and have limited permissions. I eventually got all the
> complex stuff I wanted to do working. The full story is here:
> 
> http://home.comcast.net/~tomhorsley/hardware/solidoodle/solidoodle-udev.html
> 

-- 
Kevin J. Cummings
kjch...@verizon.net
cummi...@kjchome.homeip.net
cummi...@kjc386.framingham.ma.us
Registered Linux User #1232 (http://www.linuxcounter.net/)
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: udev rules for webcam

[Tom Horsley]

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 all my code work
because systemd runs things in magic "cgroups" that get killed
quickly and have limited permissions. I eventually got all the
complex stuff I wanted to do working. The full story is here:

http://home.comcast.net/~tomhorsley/hardware/solidoodle/solidoodle-udev.html
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

udev rules for webcam

[Fred Smith]

Hi all!

I've got an old eeepc 901 set up with Fedora 20, in a captive situation
where it operates a USB web cam (not the built-in one, but something a
good deal better, though modestly priced) snapping an image once per
minute.

Unfortunately, on the rare occasions when the eeepc gets rebooted, the
location in /dev of the particular web cam I'm interested in sometimes
changes from /dev/video0 to /dev/video1, or sometimes the other way.

I was looking to see if I could grope /proc files to find out which 
one was the camera I'm interested in, so the script that runs it
could 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 'em:

lsusb:
Bus 001 Device 002: ID 046d:0825 Logitech, Inc. Webcam C270

so, according to one of the recipes I found, if I make a rule like this
it should work:

SUBSYSTEM=="video4linux", SUBSYSTEM=="usb", ATTRS{idVendor}=="0x046d", 
ATTRS{idProduct}=="0x0825", SYMLINK+="logitechcam"

if I understand it, this should make the camera appear as "/dev/logitechcam".

If I'm off-base here I hope someone will straighten me out.

this rule is stored in a file in /etc/udev/rules.d/25.rules.

unplug/replug the camera elicits no change, and no /dev/logitechcam node,
either. neither does a reboot.

Advice will be gladly accepted! Thanks in advance.

Fred
-- 
 Fred Smith -- fre...@fcshome.stoneham.ma.us -
"Not everyone who says to me, 'Lord, Lord,' will enter the kingdom of
 heaven, but only he who does the will of my Father who is in heaven."
-- Matthew 7:21 (niv) -
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

udev rules fails with last fedora update

[Ambrogio De Lorenzo]

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-udevd[494]: renamed network interface eth0 to 
p3p1

Booting with the old Kernel it works well.

Do you know if the rule has to be changed (and how)?

Thanks
 Ambrogio
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Excluding devices from udev rules?

[Konstantin Svist]

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",
ATTRS{idProduct}!="c529", TEST=="power/control",
ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}!="046d",
ATTRS{idProduct}!="c529", TEST=="power/autosuspend",
ATTR{power/autosuspend}="2"

For some reason that doesn't work.. udevadm test ... clearly shows that
the rule matches. I've tried matching only by idProduct and still same
result...
is != just broken?


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: how to change udev rules in Fedora

[lee]

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 the file system it has on it

I ended up removing the udisks2 and udisks packages, and after killing
udisks2, /dev/sda is finally asleep.


Why is the smart data requested all the time?  Is something processing
this data to send a warning if there is an indication that a disk might
fail?

Besides removing this udisks stuff, what is the proposed way of
disabling these daemons?

There isn't even any decent documentation about these things.


-- 
Fedora release 19 (Schrödinger’s Cat)
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: how to change udev rules in Fedora

[lee]

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 know how this works.  I'm sure that there are others on
>>> this list who could take advantage of the information.
>> This won't work because when I delete everything else from the copy of
>> the file and leave only what I want, it would mean that everything I
>> might want will not be in effect because my copy of the file would
>> wholly replace the file provided as default.
>>
>> So I can't do this.
>>
>
> Then try this.
>
> Make a new file with a new name in /etc/udev/rules.d with only your
> specific rules?

Which rules do I need to make for what I'm trying to achieve?

> So, to me, the question would be what is more appropriate.
> 10-mystuff.rules or 99-mystuff.rules.

The man page of udev says:


,
| All rules files are collectively sorted and processed in lexical
| order, regardless of the directories in which they live.
`


Something like '-blah.rule' might be executed last.  Since file
names can contain all kinds of characters and there isn't any way to
close this security hole, like by limiting the characters allowed in
file names, the rule would have to have an unlimited number of whatever
character no. 65535 is as its file name.


So now I have made
/etc/udev/rules.d/-yun-disable-media-polling.rules:


# disable in-kernel media-presence polling
ACTION=="add", SUBSYSTEM=="module", KERNEL=="block", 
ATTR{parameters/events_dfl_poll_msecs}!="0", 
ATTR{parameters/events_dfl_poll_msecs}="0"


I don't know if this is a good idea.  If some software wants to poll
some block device now, it could do so nonetheless and might employ a
worse way of doing it.  OTOH, I don't see any reason why devices should
be polled every 2 seconds like the default rule specifies.  Why would
anyone want that??

How do I apply this rule?  Can udev be somehow restarted?


There is another problem with this:  My new rule doesn't disable a
default one, it merely overrides the default one.  That probably works
in this case, but there's also /usr/lib/udev/rules.d/80-udisks.rules
which has:


# Check if a disk is ATA SMART capable
#

# USB ATA enclosures with a SAT layer
KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="usb", 
ENV{DEVTYPE}=="disk", IMPORT{program}="udisks-probe-ata-smart $tempnode"

# ATA disks driven by libata
KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="ata", 
ENV{DEVTYPE}=="disk", IMPORT{program}="udisks-probe-ata-smart $tempnode"

# ATA disks connected via SAS (not driven by libata)
KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="scsi", 
ENV{DEVTYPE}=="disk", ENV{ID_VENDOR}=="ATA", 
IMPORT{program}="udisks-probe-ata-smart $tempnode"


If this is what I want to disable, how would I do that?


-- 
Fedora release 19 (Schrödinger’s Cat)
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: how to change udev rules in Fedora

[Ed Greshko]

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 that there are others on
>> this list who could take advantage of the information.
> This won't work because when I delete everything else from the copy of
> the file and leave only what I want, it would mean that everything I
> might want will not be in effect because my copy of the file would
> wholly replace the file provided as default.
>
> So I can't do this.
>

Then try this.

Make a new file with a new name in /etc/udev/rules.d with only your specific 
rules?  The one thing that isn't clear to me is if you should have a higher 
number or a lower number than a rule which may also match the condition you're 
trying to catch.  I can't tell, from the documentation, if rules processing 
stops when a match is made or if rules are processed in order such that the 
last match is what is used.

So, to me, the question would be what is more appropriate.   10-mystuff.rules 
or 99-mystuff.rules.

-- 
The only thing worse than a poorly asked question is a cryptic answer.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: how to change udev rules in Fedora

[Joe Zeff]

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 that there are others on
>this list who could take advantage of the information.

This won't work because when I delete everything else from the copy of
the file and leave only what I want, it would mean that everything I
might want will not be in effect because my copy of the file would
wholly replace the file provided as default.


Thank you.  Even knowing that your idea won't work as originally 
suggested is better than nothing.  Let's all hope that your new idea 
works out.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: how to change udev rules in Fedora

[lee]

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 who could take advantage of the information.

This won't work because when I delete everything else from the copy of
the file and leave only what I want, it would mean that everything I
might want will not be in effect because my copy of the file would
wholly replace the file provided as default.

So I can't do this.

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 the file system it has on it


I have made a service file for systemd so that 'hdparm -S 240 /dev/sda'
is being run automatically --- it could use some improvement so that it
goes by UUID rather than by the device name, but that's a different
problem.

Any ideas on how to achieve this?

Trying to do anything related to udev is like trying to read 500 pages
of a pgp encrypted binary file without being able to decrypt it and
without even knowing what kind of file it is :(


In case it might be useful for someone:


[Unit]
Description=enable power saving for hard disk(s)
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
User=root
Group=root
ExecStart=/sbin/hdparm -S 240
ExecReload=/sbin/hdparm -S 240
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target


-- 
Fedora release 19 (Schrödinger’s Cat)
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: how to change udev rules in Fedora

[Joe Zeff]

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 information.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: how to change udev rules in Fedora

[lee]

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".
>>
>>
>
> From "man 7 udev"
>with the same name in /lib. This can be used to override a
>system-supplied rules file with a local file if needed; a symlink in
>/etc with the same name as a rules file in /lib, pointing to /dev/null,
>disables the rules file entirely.

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 ...


-- 
Fedora release 19 (Schrödinger’s Cat)
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: how to change udev rules in Fedora

[Ed Greshko]

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"

   The udev rules are read from the files located in the system rules
   directory /usr/lib/udev/rules.d, the volatile runtime directory
   /run/udev/rules.d and the local administration directory
   /etc/udev/rules.d. All rules files are collectively sorted and processed
   in lexical order, regardless of the directories in which they live.
   However, files with identical file names replace each other. Files in
   /etc have the highest priority, files in /run take precedence over files
   with the same name in /lib. This can be used to override a
   system-supplied rules file with a local file if needed; a symlink in
   /etc with the same name as a rules file in /lib, pointing to /dev/null,
   disables the rules file entirely.



-- 
The only thing worse than a poorly asked question is a cryptic answer.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

how to change udev rules in Fedora

[lee]

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 unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: udev rules + adb insufficient permission

[Rahul Sundaram]

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 not because google won't
> wiggle the rubber chicken three times the exact way the
> kernel developers want them to. Perhaps it fell victim
> to that?

Android patches were never really in the mainstream kernel.  It was in
the staging tree which is like a experimental branch for dumping random
patches in for a while and hoping that it will get picked up, reviewed
and merged eventually.  Sometimes it works but other patches get dropped
routinely.  Android patches were dropped after Google developers didn't
respond to patch reviews discussing technical issues for a while.

Rahul
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: udev rules + adb insufficient permission

[slamp slamp]

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 kernel and wot not because google won't
> wiggle the rubber chicken three times the exact way the
> kernel developers want them to. Perhaps it fell victim
> to that?
>
> P.S. Where do you find info on android development on
> fedora? I've been considering if I want to start dabbling
> in it, but 99% of the info is for windows and (barf) eclipse.
> --

i am no developer. i really only use adb to push tweaks to my Droid. i
do not have one site i go to for info, i just search google and the
forums (droidforums.net).

for those curious and also having the issue i had, here's the udev rule.


$ cat /etc/udev/rules.d/51-android.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="22b8", ATTRS{idProduct} =="41db",
MODE="0666"

The idVendor and the idProduct is seen when running lsusb:

$ lsusb
Bus 002 Device 003: ID 22b8:41db Motorola PCS Motorola Droid (USB Debug)
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: udev rules + adb insufficient permission

[Tom Horsley]

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 three times the exact way the
kernel developers want them to. Perhaps it fell victim
to that?

P.S. Where do you find info on android development on
fedora? I've been considering if I want to start dabbling
in it, but 99% of the info is for windows and (barf) eclipse.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

udev rules + adb insufficient permission

[slamp slamp]

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 latest updates. i checked my yum
log and did not see anything pertaining to udev.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Changing permissions to LVM block device using udev rules

[Roberto Fichera]

 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 so that they become persistent across reboots.
>>
>> Does anyone give me some hints.
>>
>> Thanks in advance.
>>
>> Roberto Fichera.
> Are you facing some particular problem with it?

It seems that any rule doesn't work.

> For common theory of udev rules I found this page (first google
> result, by the way) very usuful:
> http://www.reactivated.net/writing_udev_rules.html

Yes! It know this page, but also there is the file

/usr/share/doc/device-mapper-1.02.44/12-dm-permissions.rules

that should cover such requirement once copied in /etc/udev/rules.d.

I mean, I copied and changed it to cover my requirements, but nothing happen,
the allocated LVM block device still owned by root:disk. Furthermore I forgot
to say that the users that should own their LVM partition are NIS users, so may 
be
that the above rules wouldn't work because it will be triggered too early. 
Dunno!

> All the best,

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Changing permissions to LVM block device using udev rules

[Hiisi]

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 anyone give me some hints.
>
> Thanks in advance.
>
> Roberto Fichera.

Are you facing some particular problem with it?
For common theory of udev rules I found this page (first google
result, by the way) very usuful:
http://www.reactivated.net/writing_udev_rules.html
All the best,
-- 
Hiisi.
Registered Linux User #487982. Be counted at: http://counter.li.org/
--
Spandex is a privilege, not a right.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Changing permissions to LVM block device using udev rules

[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 anyone give me some hints.

Thanks in advance.

Roberto Fichera.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: FC12 udev rules

[T. Horsnell]

Patrick O'Callaghan wrote:
> On Wed, 2010-03-03 at 10:54 +, T. Horsnell wrote:
>>> That rule has moved into /lib/udev/rules.d/.  And AFAIK udev reads
>> all
>>> rules in and evaluates all the matches in order.  Honestly I'm not
>> an
>>> expert, so don't take this as gospel, but I'm pretty 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/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
>/etc/udev/rules.d/ and the temporary rules directory 
> /dev/.udev/rules.d/. All rule files are sorted and processed in lexical
>order, regardless in which of these directories they live.
> 
> IOW, RTFM :-)
> 
> poc
> 

Thanks and apologies for being a timewaster!

Cheers,
Terry
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: FC12 udev rules

[Patrick O'Callaghan]

On Wed, 2010-03-03 at 10:54 +, T. Horsnell wrote:
> > That rule has moved into /lib/udev/rules.d/.  And AFAIK udev reads
> all
> > rules in and evaluates all the matches in order.  Honestly I'm not
> an
> > expert, so don't take this as gospel, but I'm pretty 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/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
   /etc/udev/rules.d/ and the temporary rules directory 
/dev/.udev/rules.d/. All rule files are sorted and processed in lexical
   order, regardless in which of these directories they live.

IOW, RTFM :-)

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: FC12 udev rules

[T. Horsnell]

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 at
>> the libusb entry (I know this was not the 'correct' way, but I could never
>> understand udev enough to work out what *was* the correct way).
>>
>> Now that I've moved to FC12, this 50- rulest doesnt exist, and I cant find
>> where the libusb stuff is now handled. Can someone please tell me how to
>> correctly add a custom rule. Presumably I have to use a filename which causes
>> it to be executed in the right order. Does udev stop processing subsequent
>> rules files when it hits a rule which matches?
>>
>> In ruleset 50-udev-default.rules I used to have:
>>
>> ###SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", 
>> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
>> SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", 
>> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0666"
> 
> 
> That rule has moved into /lib/udev/rules.d/.  And AFAIK udev reads all
> rules in and evaluates all the matches in order.  Honestly I'm not an
> expert, so don't take this as gospel, but I'm pretty 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/rules.d/ used for I wonder...

Cheers,
Terry

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: FC12 udev rules

[Paul W. Frields]

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 know this was not the 'correct' way, but I could never
> understand udev enough to work out what *was* the correct way).
> 
> Now that I've moved to FC12, this 50- rulest doesnt exist, and I cant find
> where the libusb stuff is now handled. Can someone please tell me how to
> correctly add a custom rule. Presumably I have to use a filename which causes
> it to be executed in the right order. Does udev stop processing subsequent
> rules files when it hits a rule which matches?
> 
> In ruleset 50-udev-default.rules I used to have:
> 
> ###SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", 
> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
> SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", 
> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0666"


That rule has moved into /lib/udev/rules.d/.  And AFAIK udev reads all
rules in and evaluates all the matches in order.  Honestly I'm not an
expert, so don't take this as gospel, but I'm pretty sure you have to
explicitly do something to make udev bail completely partway through
those evaluations.


-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
  Where open source multiplies: http://opensource.com
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

FC12 udev rules

[T. Horsnell]

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 enough to work out what *was* the correct way).

Now that I've moved to FC12, this 50- rulest doesnt exist, and I cant find
where the libusb stuff is now handled. Can someone please tell me how to
correctly add a custom rule. Presumably I have to use a filename which causes
it to be executed in the right order. Does udev stop processing subsequent
rules files when it hits a rule which matches?

In ruleset 50-udev-default.rules I used to have:

###SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", 
NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", 
NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0666"

Thanks,
Terry




-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines