Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 18 Apr 2014, 01:39
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
212,213b USB flash names not retained in Pmount, Univ Inst
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 10 [144 Posts]   Goto page: 1, 2, 3, ..., 8, 9, 10 Next
Author Message
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 30 Nov 2006, 00:08    Post subject:  212,213b USB flash names not retained in Pmount, Univ Inst  

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:
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, 02:54; edited 1 time in total
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 30 Nov 2006, 00:59    Post subject:  

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:
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! Rolling Eyes
Back to top
View user's profile Send private message 
Gn2


Joined: 16 Oct 2006
Posts: 936
Location: virtual - Veni vidi, nihil est adpulerit

PostPosted: Thu 30 Nov 2006, 02:14    Post subject:  

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

http://www.reactivated.net/writing_udev_rules.html#builtin

That topic was touched upon just previously !

http://www.murga-linux.com/puppy/viewtopic.php?p=80099&highlight=#80099


(Mounting & remounting Esp. w/multiple devices "claiming resources" -
On > " first found - claims" basis.
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 30 Nov 2006, 11:27    Post subject:  

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
Back to top
View user's profile Send private message 
Gn2


Joined: 16 Oct 2006
Posts: 936
Location: virtual - Veni vidi, nihil est adpulerit

PostPosted: Fri 01 Dec 2006, 02:15    Post subject:  

Udev is now the method of "devices" interface !
Devfs was unmaintained, and oft - Confused 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 or Very Mad 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 Razz water)

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

If it were - Puppy might not exist ?

Best of regards
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Mon 04 Dec 2006, 11:39    Post subject:  

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.
Back to top
View user's profile Send private message 
Gn2


Joined: 16 Oct 2006
Posts: 936
Location: virtual - Veni vidi, nihil est adpulerit

PostPosted: Mon 04 Dec 2006, 21:54    Post subject:  

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:
less /usr/src/linux/.config|grep USB|less

Quote:
# 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)
Quote:
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
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Mon 04 Dec 2006, 22:22    Post subject:  

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 Laughing ).
Back to top
View user's profile Send private message 
Gn2


Joined: 16 Oct 2006
Posts: 936
Location: virtual - Veni vidi, nihil est adpulerit

PostPosted: Mon 04 Dec 2006, 22:48    Post subject:  

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.
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 07 Dec 2006, 23:08    Post subject:  

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.
Back to top
View user's profile Send private message 
Gn2


Joined: 16 Oct 2006
Posts: 936
Location: virtual - Veni vidi, nihil est adpulerit

PostPosted: Fri 08 Dec 2006, 01:01    Post subject:  

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 Laughing 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 Razz sure won't )
Back to top
View user's profile Send private message 
Gn2


Joined: 16 Oct 2006
Posts: 936
Location: virtual - Veni vidi, nihil est adpulerit

PostPosted: Tue 12 Dec 2006, 03:19    Post subject:  

http://www.gentoo.org/news/en/gwn/20061204-newsletter.xml

Udev - rules/ordered loading

http://www.reactivated.net/writing_udev_rules.html#example-netif
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Tue 26 Dec 2006, 02:48    Post subject:  

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.
Back to top
View user's profile Send private message 
plinej

Joined: 13 Aug 2006
Posts: 1522

PostPosted: Thu 28 Dec 2006, 23:14    Post subject:  

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

http://freshmeat.net/projects/libhardware/?branch_id=16175&release_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.
probedisk-probepart.tar.gz
Description 
gz

 Download 
Filename  probedisk-probepart.tar.gz 
Filesize  8.37 KB 
Downloaded  715 Time(s) 
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Fri 29 Dec 2006, 11:59    Post subject:  

Nope, still broken:
Code:
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? Rolling Eyes If so, we should just chuck probedisk and replace it with these commands in the scripts where probedisk is used.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 10 [144 Posts]   Goto page: 1, 2, 3, ..., 8, 9, 10 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1065s ][ Queries: 13 (0.0097s) ][ GZIP on ]