7:38 a.m.
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 :
*<sudo udevadm info -q all -n /dev/sdc>*
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/pci0000:00/0000: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-0000: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/pci0000:00/0000: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-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0E:
ID_PATH_TAG=pci-0000_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-0000: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:*
8:56 a.m.
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/
<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 :
_*<sudo udevadm info -q all -n /dev/sdc>*_
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/pci0000:00/0000: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-0000: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/pci0000:00/0000: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-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_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-0000: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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
9:52 a.m.
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.
1:44 p.m.
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
<mrangelo.fedora(a)gmail.com> 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 :
> <sudo udevadm info -q all -n /dev/sdc>
> 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/pci0000:00/0000: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-0000: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/pci0000:00/0000: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-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
> E: ID_PATH_TAG=pci-0000_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-0000: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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
12:18 a.m.
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 :
<touch ~ / Documents / new-touch_filet >
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 <skenlon(a)redhat.com> 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
<mrangelo.fedora(a)gmail.com> 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 :
> <sudo udevadm info -q all -n /dev/sdc>
> 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/pci0000:00/0000: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-0000: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/pci0000:00/0000: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-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
> E: ID_PATH_TAG=pci-0000_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-0000: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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
2:25 a.m.
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 <rsync> 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 <stable> 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 <find> 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 <mrangelo.fedora(a)gmail.com>
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 : <touch ~ / Documents / new-touch_filet >
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 <skenlon(a)redhat.com> 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
> <mrangelo.fedora(a)gmail.com> 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 :
> > <sudo udevadm info -q all -n /dev/sdc>
> > 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/pci0000:00/0000: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-0000: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/pci0000:00/0000: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-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
> > E: ID_PATH_TAG=pci-0000_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-0000: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(a)lists.fedoraproject.org
> > To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
>
5:11 a.m.
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.
10:06 a.m.
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 <UDEV script>).
I've already done this script that works, if run from a terminal.
If by the term <UDEV script> 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 <skenlon(a)redhat.com> 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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
2:16 p.m.
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
<mrangelo.fedora(a)gmail.com> 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 <UDEV script>).
> I've already done this script that works, if run from a terminal.
> If by the term <UDEV script> 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 <skenlon(a)redhat.com> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
4:04 p.m.
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
<mrangelo.fedora(a)gmail.com> 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 <UDEV script>).
> I've already done this script that works, if run from a terminal.
> If by the term <UDEV script> 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 <skenlon(a)redhat.com> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
--
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us -----------------------------
"For him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy--to the only God our Savior
be glory, majesty, power and authority, through Jesus Christ our Lord, before
all ages, now and forevermore! Amen."
----------------------------- Jude 1:24,25 (niv) -----------------------------
10:24 a.m.
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 <fredex(a)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
> <mrangelo.fedora(a)gmail.com> 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 <UDEV script>).
> > I've already done this script that works, if run from a terminal.
> > If by the term <UDEV script> 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 <skenlon(a)redhat.com> 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(a)lists.fedoraproject.org
> >> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
> > To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
--
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us
-----------------------------
"For him who is able to keep you from falling and to present you before
his
glorious presence without fault and with great joy--to the only God our
Savior
be glory, majesty, power and authority, through Jesus Christ our Lord,
before
all ages, now and forevermore! Amen."
----------------------------- Jude 1:24,25 (niv)
-----------------------------
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
12:12 p.m.
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.fedora(a)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 <fredex(a)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
> > <mrangelo.fedora(a)gmail.com> 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 <UDEV script>).
> > > I've already done this script that works, if run from a terminal.
> > > If by the term <UDEV script> 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 <skenlon(a)redhat.com>
> 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(a)lists.fedoraproject.org
> > >> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
> > > To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
> > To unsubscribe send an email to users-leave(a)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
>
> --
> ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us
> -----------------------------
> "For him who is able to keep you from falling and to present you before
> his
> glorious presence without fault and with great joy--to the only God our
> Savior
> be glory, majesty, power and authority, through Jesus Christ our Lord,
> before
> all ages, now and forevermore! Amen."
> ----------------------------- Jude 1:24,25 (niv)
> -----------------------------
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
9:45 a.m.
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 <skenlon(a)redhat.com> 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.fedora(a)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 <fredex(a)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
>> > <mrangelo.fedora(a)gmail.com> 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 <UDEV script>).
>> > > I've already done this script that works, if run from a terminal.
>> > > If by the term <UDEV script> 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 <skenlon(a)redhat.com>
>> 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(a)lists.fedoraproject.org
>> > >> To unsubscribe send an email to
users-leave(a)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(a)lists.fedoraproject.org
>> > > To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
>> > To unsubscribe send an email to users-leave(a)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
>>
>> --
>> ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us
>> -----------------------------
>> "For him who is able to keep you from falling and to present you
>> before his
>> glorious presence without fault and with great joy--to the only God our
>> Savior
>> be glory, majesty, power and authority, through Jesus Christ our Lord,
>> before
>> all ages, now and forevermore! Amen."
>> ----------------------------- Jude 1:24,25 (niv)
>> -----------------------------
>> _______________________________________________
>> users mailing list -- users(a)lists.fedoraproject.org
>> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
11:37 p.m.
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 <mrangelo.fedora(a)gmail.com>
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 <skenlon(a)redhat.com> 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.fedora(a)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 <
>> fredex(a)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
>>> > <mrangelo.fedora(a)gmail.com> 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 <UDEV script>).
>>> > > I've already done this script that works, if run from a
terminal.
>>> > > If by the term <UDEV script> 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
<skenlon(a)redhat.com>
>>> 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(a)lists.fedoraproject.org
>>> > >> To unsubscribe send an email to
>>> users-leave(a)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(a)lists.fedoraproject.org
>>> > > To unsubscribe send an email to
users-leave(a)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(a)lists.fedoraproject.org
>>> > To unsubscribe send an email to users-leave(a)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
>>>
>>> --
>>> ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us
>>> -----------------------------
>>> "For him who is able to keep you from falling and to present you
>>> before his
>>> glorious presence without fault and with great joy--to the only God
>>> our Savior
>>> be glory, majesty, power and authority, through Jesus Christ our Lord,
>>> before
>>> all ages, now and forevermore! Amen."
>>> ----------------------------- Jude 1:24,25 (niv)
>>> -----------------------------
>>> _______________________________________________
>>> users mailing list -- users(a)lists.fedoraproject.org
>>> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
1:43 a.m.
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 <skenlon(a)redhat.com
<mailto:skenlon@redhat.com>> 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.fedora(a)gmail.com <mailto:mrangelo.fedora@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
<fredex(a)fcshome.stoneham.ma.us
<mailto:fredex@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
> <mrangelo.fedora(a)gmail.com
<mailto:mrangelo.fedora@gmail.com>> 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 <UDEV script>).
> > I've already done this script that works, if run from
a terminal.
> > If by the term <UDEV script> 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
<skenlon(a)redhat.com <mailto:skenlon@redhat.com>> 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(a)lists.fedoraproject.org
<mailto:users@lists.fedoraproject.org>
> >> To unsubscribe send an email to
users-leave(a)lists.fedoraproject.org
<mailto:users-leave@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(a)lists.fedoraproject.org
<mailto:users@lists.fedoraproject.org>
> > To unsubscribe send an email to
users-leave(a)lists.fedoraproject.org
<mailto:users-leave@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(a)lists.fedoraproject.org
<mailto:users@lists.fedoraproject.org>
> To unsubscribe send an email to
users-leave(a)lists.fedoraproject.org
<mailto:users-leave@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
--
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us
<mailto:fredex@fcshome.stoneham.ma.us>
-----------------------------
"For him who is able to keep you from falling and to
present you before his
glorious presence without fault and with great joy--to
the only God our Savior
be glory, majesty, power and authority, through Jesus
Christ our Lord, before
all ages, now and forevermore! Amen."
----------------------------- Jude 1:24,25 (niv)
-----------------------------
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
<mailto:users@lists.fedoraproject.org>
To unsubscribe send an email to
users-leave(a)lists.fedoraproject.org
<mailto:users-leave@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(a)lists.fedoraproject.org
<mailto:users@lists.fedoraproject.org>
To unsubscribe send an email to
users-leave(a)lists.fedoraproject.org
<mailto:users-leave@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(a)lists.fedoraproject.org
<mailto:users@lists.fedoraproject.org>
To unsubscribe send an email to
users-leave(a)lists.fedoraproject.org
<mailto:users-leave@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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
1754
days inactive
1760
days old
14 comments
6 participants
participants (6)
-
Angelo Moreschini -
Fred Smith -
Richard England -
Robert Moskowitz -
Seth Kenlon -
Tom Horsley