(old)Puppy Linux Discussion Forum

@GG

Switch to the wizard. The first one is just a demo that shows proof of concept.

Read the README ..

I am not aware of name length restrictions on devices. You might just be afflicted by voodoo at your outpost ..

TyroBGinner wrote:there any way to modify this utility so that drive uniqueness can be preserved with fanout devices like usb hubs and multi-drive HDD "docks"? I gather that is a lot to ask since the udev rules seem to correspond to the device immediately in contact with the computer's usb connection.

It works with USB hubs as long as you plug them in one at a time to create the initial ".rules" file. After that you can plug a bunch into the hub and they seem to mount ok. Anyways, they do for me. I can get two identical Sandisk Cruisers to work right in a hub.

I may spend some time later working with the udevadm info dumps to try to tweak that.

As far as the HD cradles are concerned, one would have to do a bunch more research on how to grab those. Maybe grab events from dmesg or something ..

jafadmin wrote:
Now just plug in the USB disk you want to use for this, then open a console in /root/bin and type: "./mkrule /dev/sdX" (where X is your usb device). This will create the udev rule and put it where it needs to go.

At this point all partitions on your USB disk should be mounted at: /MyUSB

From now on, that, and only that USB disk, will always mount as /MyUSB/MyUSB-1, /MyUSB/MyUSB-2, etc ..

Drag a link to /MyUSB to your desktop.

Prosper.

That is all.

On my Bionipup64, after typing in the command ./mkrule /dev/sdg there is no error but no /MyUSB directory is created.

What am I doing wrong?

gychang wrote:On my Bionipup64, after typing in the command ./mkrule /dev/sdg there is no error but no /MyUSB directory is created.

What am I doing wrong?

Greg:-

You're not looking for a /MyUSB 'directory', as such. What you're looking for is a 'mount-point'.....and you won't find it in /root.

IF 'MyUSB' is the name you've used for your drive (it's really just an example - you could use any name you like), then you should see it by doing the following.

In ROX's /root 'window', click on the upward-pointing arrow at the far left end of the menu bar - this'll take you up a level into the main file-system. You should see MyUSB alongside /root, /var, /lib, /bin, /usr, etc.

The instructions for this are a wee bit misleading, unfortunately. There's no /root/bin directory. What you're looking for is the /root/udev directory. Like this:-





Click on that to open it:-





Mine has 3 files; the middle one is my personal 'mount-point'. It's a Seagate Expansion Desktop drive, so I've named it SeaDesk. You should only see the two outside ones, because the 3rd one won't exist until you've run the command in the terminal.

After you've done that, you should then see the new 'mount-point' alongside the other system files, under '/'. Like this:-





I've dressed it up with a drive icon, to make it more obvious what it is. From this point on, this drive will always mount to the new mount-point that you've just created.


Mike.

Mike Walsh wrote:

gychang wrote:On my Bionipup64, after typing in the command ./mkrule /dev/sdg there is no error but no /MyUSB directory is created.

What am I doing wrong?

Greg:-

You're not looking for a /MyUSB 'directory', as such. What you're looking for is a 'mount-point'.....and you won't find it in /root.

IF 'MyUSB' is the name you've used for your drive (it's really just an example - you could use any name you like), then you should see it by doing the following.

Mike.

MIke I really appreciate your effort, now working fine.

The device naming lottery can be a pain when some hard code device names into scripts and the kernel decides that after another reboot to swap those names all around. Personally I tend to manually mount things

mkdir /mnt/usb
mount /dev/sdb1 /mnt/usb

where usually I use fdisk -l to quickly review devices

In some cases I do script based mounting and when so I tend to include a identity file on devices, where the script loops through mounting things and looking for a particular unique filename that I've pre-created on that device, and when found it creates a /mnt/xxx folder and mounts the device to that mount point.

Other approaches are to use UUID, or device label (disk label), or device name. For instance in gparted there's a option to set a partitions label and once you've done that, such as setting a usb with a single partition to have a label of 'whiteusb' (perhaps for a white coloured usb stick), then you can mount that using

mkdir /mnt/whiteusb
mount -L whiteusb /mnt/whiteusb

If you use that consistently, then your scripts can reference that reliably

cd /mnt/whiteusb
.... etc.

Mount points don't have to be under the /mnt folder. You could for instance mount it to a folder within /root

mkdir /root/whiteusb
mount -L whiteusb /root/whiteusb

To umount when done ... umount /root/whiteusb

Labels are nice in that they remain consistent, under certain conditions for instance UUID's can change.

/etc/fstab is the list of devices that get mounted at bootup. For mounting using labels the format is something like

LABEL=whiteusb /mnt/whiteusb ext3 defaults 0 0

UPDATE NOTE

Older versions of udev are more problematic when implementing the unplug event. The 'MkRule' wizard
doesn't produce a 'remove' rule that works.

It is necessary to run the command: 'udevadm monitor --environment --udev | grep PRODUCT' with the usb
device plugged in, then removing the device and looking for the "PRODUCT=xxx/xxxx/x' line, then use that
information to change the 'remove' rule.

Change the 'ENV{ID_SERIAL_SHORT}==?????????' to read: 'ENV{PRODUCT}==xxx/xxxx/x' as revealed by the
command you ran.

Unfortunately, this environment variable can only be revealed by running the udev monitor in realtime which
makes it difficult to script .

.

jafadmin wrote:
It assumes you have a /root/bin directory. if you don't, create one. Put the "mkrule" and "mnt-MyUSB" files in that directory. Put the "trigger-udev" file in /root/Startup. Make sure they are all executable.

Now just plug in the USB disk you want to use for this, then open a console in /root/bin and type: "./mkrule /dev/sdX" (where X is your usb device). This will create the udev rule and put it where it needs to go.

At this point all partitions on your USB disk should be mounted at: /MyUSB

From now on, that, and only that USB disk, will always mount as /MyUSB/MyUSB-1, /MyUSB/MyUSB-2, etc ..

Drag a link to /MyUSB to your desktop.

Prosper.

That is all.

I am trying to follow this since my BionicPup64 v8.0 is not recognizing my internal SD card reader. I am unclear how to get/create "mnt-MyUSB" file to place in bin directory... Does it automatically get created after reboot?

jafadmin wrote: It assumes you have a /root/bin directory. if you don't, create one. Put the "mkrule" and "mnt-MyUSB" files in that directory. Put the "trigger-udev" file in /root/Startup. Make sure they are all executable.

Now just plug in the USB disk you want to use for this, then open a console in /root/bin and type: "./mkrule /dev/sdX" (where X is your usb device). This will create the udev rule and put it where it needs to go.

At this point all partitions on your USB disk should be mounted at: /MyUSB

From now on, that, and only that USB disk, will always mount as /MyUSB/MyUSB-1, /MyUSB/MyUSB-2, etc ..

Drag a link to /MyUSB to your desktop.

Prosper.

That is all.

I am trying to follow this to get my internal SD card working in BionicPup64, v8.0. Recognizes and works fine on XenialPup64. When I boot with SD card in BP64, I see it /dev/sdf. But does not work properly when removed and reinserted. Anyway I am confused how the "mnt-MyUSB" file in root/bin directory is created, since I don't see it as the part of downloaded zip file.

sorry, please delete this.

@gychang

Greg, go to the SECOND post in this thread, download the wizard, and follow the instructions in the README file on how to install the wizard. That should work better for you.

rufwoof wrote:Labels are nice in that they remain consistent, under certain conditions for instance UUID's can change.

Hi Rufwoof - obviously if a partition is manually reformatted the UUID will change - but are there other circumstances beyond the user's control where UUID may change without user's knowledge or intervention?

For some reason, this doesn't work with my CnMemory Spaceloop 64GB USB memory stick (it works fine with a Kingston Datatraveller 8GB USB memory stick and a WD MyPassport X 2TB USB HDD). So I ran "man rules.d" from within Puppy, which led me to https://linux.die.net/man/8/udev. However, the .rules files created by this wizard do not seem to correspond to the documentation I found, so does Puppy use a proprietary version of udev and where is the documentation for it?

3guesses wrote:For some reason, this doesn't work with my CnMemory Spaceloop 64GB USB memory stick (it works fine with a Kingston Datatraveller 8GB USB memory stick and a WD MyPassport X 2TB USB HDD). So I ran "man rules.d" from within Puppy, which led me to https://linux.die.net/man/8/udev. However, the .rules files created by this wizard do not seem to correspond to the documentation I found, so does Puppy use a proprietary version of udev and where is the documentation for it?

Post the rules file ( /etc/udev/rules.d/70-'YourDevice'.rules ) it created and the version of puppy involved. We'll see what happened.

udev is a standard unix/linux system utility.

UPDATE:
Please replace the line in the "unplug-template" & "unplug-YourDevice" files in your /root/udev directory that says: with: It will work better with device names that have hyphens in them.

jafadmin wrote:

3guesses wrote:For some reason, this doesn't work with my CnMemory Spaceloop 64GB USB memory stick (it works fine with a Kingston Datatraveller 8GB USB memory stick and a WD MyPassport X 2TB USB HDD). So I ran "man rules.d" from within Puppy, which led me to https://linux.die.net/man/8/udev. However, the .rules files created by this wizard do not seem to correspond to the documentation I found, so does Puppy use a proprietary version of udev and where is the documentation for it?

Post the rules file ( /etc/udev/rules.d/70-'YourDevice'.rules ) it created and the version of puppy involved. We'll see what happened.

udev is a standard unix/linux system utility.

OK, here are the rules files created for my Kingston DataTraveller (KDT) and CnMemory (CnM) memory sticks, and the output from "udevadm info -a /dev/sdc1" for each.

The rules files simply don't have lines like the examples given in the documentation (eg. BUS="scsi", SYSFS{vendor}="IBM", SYSFS{model}="ST336", etc).

Yeah, the output from the "info" command has a bagillion times more data than matters. Kinda like running 'dmesg' ..

Anyways, try this and see what happens. First, back up, then edit the 'rules' file first line to read: This is a USB3 device and might need some shoehorning ..

Also, is it possible for the udev rules to match by UUID?

jafadmin wrote:Yeah, the output from the "info" command has a bagillion times more data than matters. Kinda like running 'dmesg' ..

Anyways, try this and see what happens. First, back up, then edit the 'rules' file first line to read:

Code: Select all

SUBSYSTEMS=="usb", DRIVERS=="usb", ENV{DEVTYPE}=="partition", ATTRS{serial}=="12061907001113", SYMLINK+="CnM-%n", RUN+="/root/udev/mnt-CnM"

This is a USB3 device and might need some shoehorning ..

No, it's a USB 2.0 device, but I might have connected it to a USB 3 port rather than a USB 2 port. I think I have the same problem in a USB 2 port.

This also doesn't answer why the rules file does not match the documentation.