212,213b USB flash names not retained in Pmount, Univ Inst

Please post any bugs you have found
Post Reply
Message
Author
PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

212,213b USB flash names not retained in Pmount, Univ Inst

#1 Post by PaulBx1 »

I have been having some problems with USB flash devices. I tried an experiment.

I have an old Thinkpad with a single USB1.1 port. A hub is plugged into that, and in the hub is a SanDisk Flash. I also have a USB 2.0 PCMCIA card with two ports (only one of which seems to work by the way, don't know why). I have a PQI Istick flash in that.

When I booted up, the SanDisk was designated sda, the PQI as sdb. MUT, Pmount and Universal Installer agreed.

Then, I pulled the SanDisk out.

MUT showed it (sda) gone, no problem. sdb remained.

Pmount for some reason thought both flash drives were gone.

I then plugged the SanDisk into the same port I pulled it from.

MUT, ever reliable, reported it back again, as sda.

Pmount now showed the SanDisk as sdb, the PQI as sda! Universal Installer did likewise.

Other times moving flash drives around, it seems the system just can't keep up with it. But the above test was a very simple, slow test. It should have managed with that!

Oh, and one other nit to pick with Pmount: if you move the window somewhere, then press the refresh button, it goes back to where it was first!

<later>
BTW probedisk also thinks the disk names got swapped around:

Code: Select all

sh-3.00# probedisk
/dev/hdc|cdrom|MATSHITADVD-ROM SR-8175
/dev/hda|disk|IC25N020ATDA04-0
/dev/sda|Direct-Access|I-Stick2 IntelligentStick 
/dev/sdb|Direct-Access|SanDisk  Cruzer Micro     
Last edited by PaulBx1 on Tue 26 Dec 2006, 06:54, edited 1 time in total.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#2 Post by PaulBx1 »

I repeated the experiment. First I got rid of the hub. Then I replaced the PQI with a Firefly.

The below window shows first "probedisk" right after boot, then again after I pulled out the SanDisk, then again after I plugged it in again. It switched names after pulling it out.

Code: Select all

sh-3.00# probedisk
/dev/hdc|cdrom|MATSHITADVD-ROM SR-8175
/dev/hda|disk|IC25N020ATDA04-0
/dev/sda|Direct-Access|SanDisk  Cruzer Micro     
/dev/sdb|Direct-Access|LEXAR    JD FIREFLY       
sh-3.00# 
sh-3.00# probedisk
/dev/hdc|cdrom|MATSHITADVD-ROM SR-8175
/dev/hda|disk|IC25N020ATDA04-0
/dev/sda|Direct-Access|LEXAR    JD FIREFLY       
sh-3.00# 
sh-3.00# probedisk
/dev/hdc|cdrom|MATSHITADVD-ROM SR-8175
/dev/hda|disk|IC25N020ATDA04-0
/dev/sda|Direct-Access|LEXAR    JD FIREFLY       
/dev/sdb|Direct-Access|SanDisk  Cruzer Micro     
sh-3.00# 
<later>
I tried the same experiment in Puppy 211 by booting to ram, and outside of the fact that Pmount was completely out of the running (as chronicled in my other thread), the results were identical. So, no 212 change caused this problem. It's been with us a while.

Moral of the story seems to be, leave those flash drives plugged in while Puppy is running! :roll:

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#3 Post by Gn2 »

Or - use what has existed since Devfs - then later > Udev rules allow:

http://www.reactivated.net/writing_udev ... ml#builtin

That topic was touched upon just previously !

http://www.murga-linux.com/puppy/viewto ... ght=#80099


(Mounting & remounting Esp. w/multiple devices "claiming resources" -
On > " first found - claims" basis.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#4 Post by PaulBx1 »

Looks like we don't have udev <sigh>. Or at least, it's not being used. Sure would be nice to have automatically generated, but then persistent names for our devices.

On that issue of removing devices that haven't been umounted, it is worst case for flash drives because the writes for them are cached for 30 seconds IIRC to cut down on the write cycles (limited by the memory type of the device).

I think this is why I had an earlier problem with Universal Installer. I must have moved my flash at some point before invoking it.

Fortunately Puppy's fast boot makes it relatively painless to get everything ordered and settled down again, but we don't want Puppy to get a Windows-like reputation of needing frequent reboots. :wink:

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#5 Post by Gn2 »

Udev is now the method of "devices" interface !
Devfs was unmaintained, and oft - :? bit of a "cludge" to implement -
But even then - persistent naming was a user option.
Background RE Scsi:
Devices could be 'daisy chained" > changing mount points, "names" & resources !

Block vs character File systems and all virtual file systems.
Takes a bit of in-depth delving to get head around how kernel must access any file system structure:

Udev is used in all 2.6_xx kernel series -
HOW that standard is applied may vary to distributions goals-

Very unlikely ANY supplied kernel would not include all (common) support !
(When the kernel makefile is included - :cool: check applicable options.)

Hardware - OEM's device specific standards: Flash, pen drives, etc.
All peripherals.... scanners, cameras =new are added daily.
OEM :evil: willingness to support OSS/Linux !

If a better understanding is goal -- a good start would be to follow supplied URLs .

Whenever any O/System offering I.E "wizardy to probes, installs etal;-
Falls short of needs - manual configuration is indicated - or wait for developer to pre-supply Req'd capability !

Beit binary Apps - development tools - documentation.
In Windows - few choices - Linux has Potential for any user
of taking back control > within time, personal interest - practicalities.
(Phew - did I just say all that - musta bin the :P water)

Sum,,, people, if hardware just_"works"...... just_use & enjoy -
Nothing wrong w/THAT !

If it were - Puppy might not exist ?

Best of regards

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#6 Post by PaulBx1 »

I believe you are suggesting udev is already in Puppy, although I'm not sure I catch your drift.

I find no evidence of it. The data structures are not there, etc. I don't think it's just a matter of a user taking control. Perhaps it is in the kernel, and a very knowlegable user could rework Puppy and set up the data structures and get it running, but I'm not up to it, without a huge effort anyway. And I don't want to get too far from a standard Puppy either.

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#7 Post by Gn2 »

Udev is part of all 2.6_xx kernels
Devfs is also included
Following supplied URL's - persistent naming rules may be user set
Using Scsi probe utilities - anything may be located/enabled

If Puppy supplied a (.config) kernel makefile - the support options chosen by developer would be known:

Example

Code: Select all

less /usr/src/linux/.config|grep USB|less
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set

CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_ITMTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
Partial listing only > as can be seen, USB/ Scsi interface/cold<>hotplugging, virtual file systems are all intertwined:

Above is only a sampling - NA to others > I have customized all to own hardware, CPU /Gcc flags & App "use' options enabled by Gentoo

Puppy probes the detected file systems and/or run Level "S"intiates !
If defaults do not enable anything - user has two options - take control or wait for the distribution to change.
Instead of probing Device bus & DMA reports (OEM capabilities)
rework Puppy and set up the data structures
It sounds more intricate than is:
Puppy has own variations & odd scripted probe commands to use
own wizards.
Relaince on Ppy Docs /form are needed if anything does not work.
That is no different than using "official" Linux Docs. and full Bash CLI to configure anything

Once that is tackled (backup all first) confidence to expand further is now yours.

The user then has minimized dependency of distribution developer
All is merely "generic" Linux > why add addtional levels of learning for tools not used by other Linux distribution offerings ?
Linux is the kernel - all else are add-ons

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#8 Post by PaulBx1 »

Well, Gn2, you seem to be saying I (and each of us) can fix this problem in our own copy of Puppy.

While theoretically true, it is less helpful than it seems.

Let's take an example. Say I researched everything, made sure never-before used parts of Puppy's kernel did in fact function (cross my fingers!), and made up a set of rules that turned all my /dev/sdx on the USB into permanently-named /dev/usbx.

Great, what do I have? Some names of devices that not one Puppy script uses! OK, I go though all the scripts and make the changes. A week later a new Puppy revision comes out. Now where am I?

Of course, if it is to be implemented, someone has to do it, and then submit the code to Barry. But it might make sense to ask him first, if he is going to modify all those scripts (or get their owners to modify them) so the new naming scheme can be used. He might not care to expend the effort.

If I am misreading you, please let me know. But it looks like this is more than an individual effort (unless that individual is Barry Kauler :lol: ).

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#9 Post by Gn2 »

Correct - any such naming convention would be based on each individuals' OWN devices & work habits !
Defaults as supplied work for supported hardware & most used tasks -
In same manner as when anyone had an odd wireless device or firewire peripheral - manual config is then needed -or wait & hope !

Puppy has an additional unique requirement - it was intended to be user hands_free and run in RAM mode -
All support pre-configured in initrd & squash file system.

Nobody should ever expect any O/System will ever fulfill all variables possible !
Barry cannot test all > nobody can .

(Better probe techniques may however be in future)
> Ya pays your money & takes how the coin lands.
Or "spend" own time/efforts to take control.

Nothing is free.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#10 Post by PaulBx1 »

Gn2, do you know if existing device names such as sda1, now assigned by the system willy-nilly, can themselves be made permanent with udev? In other words, that the "sd" names could be made permanently available?

If so, I can see a script that does the following:
1) Maintains a database (a simple flat file) of 10 or 15 sd names that correspond to particular USB flash devices - when one of these is detected it is assigned its fixed sd name.
2) If a new device is encountered, it is automatically assigned an unused name by the system and a new entry is put in the database for it.
3) If more devices than that that upper limit of 10 or 15 are encountered, they revert to the current temporary device naming scheme.
4) If a permanently-named device is no longer used, it can be removed from the database by editing, thus freeing up a slot for a new device.

This will get rid of this problem while remaining invisible to users.

I understand your bias toward "taking control", but most of our users are Windows refugees, and they need this stuff to be taken care of for them. Those who really do want to take control can simply look at the script to see what it is doing (as with all scripts in Puppy) and modify or discard as they like.

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#11 Post by Gn2 »

Sadly there is a vast difference to enabling own needs vs trying to
supply any wizardy for others that always "just works" ?

Hence the present varied distribution approaches towards easing our pains.

Yes sir - you do have the ability to use present Linux tools - (some are add-ins) to develop own solutions.

I am lazy - tend to "side-step" any glitch (unless cannot live w/ any subsequent system failures) ;
As a direct result of anything I MAY be able to alter to suit own needs.
So yes, seems to me - we can take control, but often the end results just do not justify all the added hassles ?
As you found..... a "work-around" ease of merely leaving devices plugged in during a session !

Since the whole topic of How_best_to handle is readily apparent
Yet no distribution has come up with a widely_acceptable solution -
Despite the fact.... a great many very talented coders are focused on working on the problems -

Hard enough to cope with "mainstream" hard install esoterics - let alone Puppy's unique requirements ?

Personally speaking - I can barely cope w/my own errmm..... uniquely "creative" ways of:
(DUHH) NOW what did I do - = THAT twern't :lol: supozed ta_happen ?

Sorry, I have no more to offer - this particular Linux glitch - is
too personal to user's own unique requirements - for me to hastily suggest any pre-supplied solutions .

Besides- as well suited as Puppy is for most - it is NOT well taylored for mine

The innovations however, will be folded in to good advantage
(me hopes - only time will tell > I :P sure won't )

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#12 Post by Gn2 »


PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#13 Post by PaulBx1 »

I have tried the experiment in 213beta with the same result.

However, I have discovered that while what I reported was correct, my interpretation of it was wrong.

It turns out pmount and MUT do NOT lose track of the sda, sdb, etc names in conducting this experiment. Instead, pmount loses track of which device has which vendor description.

That is, if I mount sda either in MUT or in pmount (leaving sdb unmounted), I find the same files on that drive - even though MUT thought sda was the SanDisk while pmount thought it was the PQI.

So it appears, this is entirely a pmount problem.

Pmount also still has the very annoying habit of moving its window around when you hit the refresh button.

<later>
I just realized, from looking at the pmount code, that pmount depends on probedisk. Since probedisk also loses track of the description, so does pmount. I have sent an email to Antonio Gallo who wrote probedisk, to see if he has a later version that does not have this problem. There appears to be no way to get version info off the current probedisk.

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#14 Post by plinej »

Try these. I just compiled from the 0.74 source package of libhardware found at:

http://freshmeat.net/projects/libhardwa ... _id=139716

I have no idea if it'll fix the problem just thought I'd see if I could find the most recent version.
Attachments
probedisk-probepart.tar.gz
(8.37 KiB) Downloaded 888 times

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#15 Post by PaulBx1 »

Nope, still broken:

Code: Select all

sh-3.00# #flash drives as booted
sh-3.00# /root/probedisk
/dev/hdc|cdrom|MATSHITADVD-ROM SR-8175
/dev/hda|disk|IC25N020ATDA04-0
/dev/sda|Direct-Access|I-Stick2 IntelligentStick 
/dev/sdb|Direct-Access|LEXAR    JD FIREFLY       
sh-3.00# /root/probepart
/dev/hdc|iso9660|0|MATSHITADVD-ROM SR-8175
/dev/hda1|vfat|36968337|Win95 FAT32 (LBA)
/dev/hda2|swap|2086560|Linux Swap
/dev/sda1|msdos|1991997|DOS 16-bit FAT >=32M
/dev/sdb1|msdos|2030560|DOS 16-bit FAT <32M
sh-3.00# 
sh-3.00# mount -t vfat /dev/sda1 /mnt/sda1
sh-3.00# ls /mnt/sda1/this*
/mnt/sda1/this_is_intelligentstick
sh-3.00# umount /mnt/sda1
sh-3.00# 
sh-3.00# mount -t vfat /dev/sdb1 /mnt/sdb1
sh-3.00# ls /mnt/sdb1/this*
/mnt/sdb1/this_is_firefly
sh-3.00# umount /mnt/sdb1
sh-3.00# 
sh-3.00# #pulling out intelligentstick now
sh-3.00# /root/probedisk
/dev/hdc|cdrom|MATSHITADVD-ROM SR-8175
/dev/hda|disk|IC25N020ATDA04-0
/dev/sda|Direct-Access|LEXAR    JD FIREFLY       
sh-3.00# /root/probepart
libcfdisk: unable to open /dev/sda 
/dev/hdc|iso9660|0|MATSHITADVD-ROM SR-8175
/dev/hda1|vfat|36968337|Win95 FAT32 (LBA)
/dev/hda2|swap|2086560|Linux Swap
sh-3.00# 
sh-3.00# 
sh-3.00# mount -t vfat /dev/sda1 /mnt/sda1
mount: Mounting /dev/sda1 on /mnt/sda1 failed: No such device or address
sh-3.00# mount -t vfat /dev/sdb1 /mnt/sdb1
sh-3.00# ls /mnt/sdb1/this*
/mnt/sdb1/this_is_firefly
sh-3.00# umount /mnt/sdb1
sh-3.00# 
sh-3.00# /root/probedisk
/dev/hdc|cdrom|MATSHITADVD-ROM SR-8175
/dev/hda|disk|IC25N020ATDA04-0
/dev/sda|Direct-Access|LEXAR    JD FIREFLY       
sh-3.00# 
Notice, I had put a blank file "this_is_intelligentstick" on the IntelligentStick, and similarly on the Firefly, just to identify them properly.

Hmmm, looks like the error is different from what I reported last (of course I didn't plug in again to see what would happen further, as it seemed pointless). It's that probedisk gets the manufacturer info right, and the system knows what drive is really still there, but probisk reports the actual drive letter wrong.

If you have two flash drives, you can check this yourself. I don't think it is anything peculiar to my hardware.

BTW, I checked this on 2.11, hope that does not matter (212/213b broke my wireless, one of the ndiswrapper cases).

Isn't there an ordinary shell command, or set of commands, that will yield the same information that probedisk does - only correctly? :roll: If so, we should just chuck probedisk and replace it with these commands in the scripts where probedisk is used.

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#16 Post by plinej »

I was messing around with that new probepart and noticed it shows my ext3 partitions as ext2 so there's definitely a problem with this version.

User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

#17 Post by pakt »

PaulBx1 wrote:Isn't there an ordinary shell command, or set of commands, that will yield the same information that probedisk does - only correctly? :roll: If so, we should just chuck probedisk and replace it with these commands in the scripts where probedisk is used.
The only thing I've been able to find that retains the USB mass storage device reference when removing/re-inserting them is
# cat /proc/partitions
Perhaps that can be used in the pmount script somehow.

Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#18 Post by Gn2 »

The really good way (cat /proc/partitions) works -
Reads all devices found, major & minor numbers, size in blocks.
If a hot-plug device such as a pen drive is plugged in- it is found.
Unplugging it is safe - IF not mounted (use df to confirm)
Process events are dynamic.
Use of cat may obviate running (tail) to find latest logged system messages.

But (tail) will output other data - & as we all know more tail is always nice.

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#19 Post by plinej »

I'm sure we can modify pmount with these other ideas. I'd look into it right now but have got another project going. On a side note I've revised dougal's revised pmount to include a rox launcher and a couple of other minor things and sent it off to pakt.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#20 Post by PaulBx1 »

We can also look to see how MUT does it, since MUT keeps things straight.

This fix also needs to be put in Universal Installer, and anything else that uses probedisk or probepart.

Post Reply