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

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

#101 Post by PaulBx1 »

I like that missing information too. Maybe most scripts (who knows about pmount) don't need it, but it is nice for us humans. It's pretty easy to add back in, isn't it?

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

#102 Post by plinej »

Yeah, I could add it back in but it doesn't seem to be the problem. Somehow my /dev/hda1 is being reported back to /tmp/probepart as "unknown" instead of "ext3" as it really is. Now I have to figure out why.

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

#103 Post by plinej »

nevermind, it seems to be a grafpup specific problem due to permissions. Running as root I see my partition correctly in pmount.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#104 Post by BarryK »

plinej wrote:nevermind, it seems to be a grafpup specific problem due to permissions. Running as root I see my partition correctly in pmount.
Ah, "good", I was getting quite concerned reading down the thread! The problem still exists for grafpup though.

I've made another change to Pmount. I had a bug displaying the partition mounted on '/' for a full hd install. Attached:
Attachments
pmount.gz
(5.92 KiB) Downloaded 402 times

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

#105 Post by plinej »

I did some more work on the replacement scripts. I was having issues with probedisk thinking my usb external dvdburner was my rio mp3 player. I fixed this by commenting out the section to find extra scsi drives and utilizing test-scsi to find any other drives. Seems to work fine for me.
Attachments
probedisk-probepart-rewrites.tar.gz
(1.62 KiB) Downloaded 426 times

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

#106 Post by plinej »

I'm still encountering weird issues. I had 3 usb drives connected (sda, sdb, sdc). I removed sdb but test-scsi shows that my sdc drive is now my sdb drive (which is not the case per /proc/partitions). I'm going to see if I can't come up with some more revisions to my scripts. I'll probably just cross reference everything against /proc/partitions but in some cases that won't work. My usb dvd burner is not recognized in /proc/partitions. In those cases I'll have to think something else up.

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#107 Post by Dougal »

I say just drop those two apps... it's a shame to waste so much energy on trying to fix them, rather than just modifying Pmount and whatever else uses them...
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

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

#108 Post by plinej »

Okay, revised once again.

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

#109 Post by plinej »

Dougal, I definitely agree. I think with my recent revisions the scripts should work. Although I've proved test-scsi is buggy just like the original probedisk/probepart programs. I think with the cross referencing check with /var/log/messages that I just incorporated it should prove to work better.

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

#110 Post by plinej »

The sg3_utils package seems to be very reliable in getting the correct usb device info.

sg_map -i

is the command that will get the desired info.

You can find their web page here:

http://sg.torque.net/sg/index.html#mozTocId689512

Of course that would be extra overhead but in order to correctly find usb/scsi devices it might be the way to go.

My revised probedisk/probepart scripts still depend on test-scsi from the libhardware package but other than that they don't need any other programs. I'm hoping that I've finally got them good enough to work well. Of course I need people to test them to make sure they work on their systems too.

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

#111 Post by Gn2 »

Plse bear in mind the sg driver is primarily for low level access to virtual file systems using the more powerful Scsi interface vs ATA subset
It was NOT initially to probe the M/Brd bus ( altho' it has proven useful there also Thnx in large part to new sg3 command set utilities)
One strange quirk is that the /proc/scsi/sg directory will not appear if there are no SCSI devices (or pseudo devices such as USB
mass storage) attached to the system. The reason for this is that in the absence of SCSI devices, the SCSI mid level does not initialize the
sg driver (even if it has been loaded as a module). When the sg driver is a module and the rmmod sg is successfully executed then the
/proc/scsi/sg directory and its contents are removed.
http://www.linux.com/howtos/SCSI-2.4-HOWTO/arch.shtml

Many prior virtual file system (proc proc & /dev/shm in fstab) methods changed when devfs was deprecated, Udev now the standard
However, either MAY be used ( edit kernel makefile support)
Many of the utilities in the sg3_utils package use the SG_IO ioctl (rather than the older write()/read() interface) in the sg driver.
In the lk 2.6 series the SG_IO ioctl (or at least a stripped down version of it) has been implemented in the block subsystem. That means
that commands that previously only worked on sg device names will now work on block device names as well (e.g. "sg_inq /dev/sda"). To use
this facility safely version sg3_utils-1.02 or later should be used. Note that SCSI tape devices (both st and osst device drivers) are char
devices and support the SG_IO ioctl from lk 2.6.6 onwards.
The SCSI generic (sg) interface still represents a cleaner interface than the primary device names. This occurs since the drivers
behind primary device names have their own policies and may interfere with error processing and run their own state machines (e.g. the cdrom
driver interferes with attempts to prevent media removal with sg_prevent)
SG driver used on Udev (kernel 2.6_xx) systems:
That kmod is used in conjuntion to udev - as such it "expects" (user space syscal intercept) a Scsi device to be plugged in
This works differently than devfs which had few alternatives to persistent naming of devicecs I.E when unplugged & replugged

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

If your revamped new Gui's now work in all instances of use - heres - hoping no more bugs appear

But knowing how OEMs have own implementations of firmware......

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#112 Post by Dougal »

What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

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

#113 Post by Gn2 »

Yeah damn OEM's !

I find if any device is not automatically probed correctly ( Pup utilities ?) and icon created -
First check dmesg, then (when hot-pugged devices are the problem)
Plug in device, tail the log files - once device is identified,
manually create mount point (fstab) & mkdir under /

I use the correct device block file name I.E.
/dev/hdc -d -e, etc
I also do not set fstab to automount ~ just as long as there is a correct entry,

Code: Select all

mount -a <or> (full path,F/Sys type) 
Doesn't hurt to check /dev for symlinks - edit to correct

Wizards are great, but :lol: the magic often gets hexed.
IF above fails - time to resort to CLI probes, using whatever tools work (lspci/lsusb/cdrecord -scanbus/SG3 tools) - & Esp >
A working assortment of cuss words !

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

#114 Post by plinej »

There was a bug in my scripts, here's another attempt.

http://www.murga-linux.com/puppy/viewto ... ch&id=3811

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#115 Post by BarryK »

A little while before Puppy 2.16 was released, there were apparently some unresolved issues with plinej's scripts so they never made it into that release. Yesterday I decided to checkout the last update from plinej (April 26) as well as 'probepart3' (May 3) from Dougal. Dougal's script is here:
http://www.murga-linux.com/puppy/viewto ... &start=255

As Dougal's scripts look like enhancements of plinej's, I tried probepart3, but was alarmed when it spat out many lines of meaningless stuff. Something very wrong, probably just a small oversight in the last version.

Anyway, I decided not to fix it. I looked through the scripts and decided that a fresh approach is needed. So I have written my own 'probepart' from scratch. It's about 45 lines, half the size of the others. My script also supports MMC/SD cards (but you need Puppy 2.17 for that!). Try it out, let me know of any problems ...it does have at least one "compromise" to keep it small ...and of course I may have missed something vital.

'probepart-bk1' attached. gunzip itand set permission to executable.
Attachments
probepart-bk1.gz
(831 Bytes) Downloaded 699 times

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#116 Post by BarryK »

Okay, I've already upgraded it. I have overcome a "compromise" that was in the first version, also hopefully now recognising the interchangeable device names scd* and sr*.

probepart-bk2 attached.

Especially if you have a SATA or USB CD/DVD drive could you please test this.
Attachments
probepart-bk2.gz
(748 Bytes) Downloaded 702 times

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

#117 Post by pakt »

Tested on a thin client with Puppy 2.14 on a CF card and a USB CD/DVD drive.
# dmesg | grep -E '^sr|^scd'
sr0: scsi3-mmc drive: 62x/48x writer cd/rw xa/form2 cdda tray
sr 1:0:0:0: Attached scsi CD-ROM sr0
sr 1:0:0:0: Attached scsi generic sg0 type 5
#
# cat /proc/partitions
major minor #blocks name

7 0 68548 loop0
7 1 524288 loop1
3 64 2030616 hdb
3 65 1020096 hdb1
3 66 1004062 hdb2

# ./probepart-bk2
/dev/hdb1|vfat|2040192|
/dev/hdb2|ext2|2008124|
/dev/sr0|iso9660|0|

#
Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#118 Post by BarryK »

pakt, thanks for that. The file devices.txt in the kernel source has stated from the 2.4 kernel days that /dev/sr i deprecated, but the kernel itself still uses it. I googled around and came across someone else expressing the same puzzlement.
I can make probepart return scd0 rather than sr0, but I'm really uncomfortable with doing that if other places like dmesg, /proc/partitions and so on report it as sr0 (*&^$#@!)

I have been looking at Dougal's probedisk3, very nice, works perfectly, and small. I couldn't resist making some small changes, and probedisk4 is attached.
Attachments
probedisk4.gz
(493 Bytes) Downloaded 686 times

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

#119 Post by pakt »

Results from same thin client above with additional USB stick attached:

# ./probedisk4
/dev/hdb|disk|KINGSTON
/dev/sda|Direct-Access|SanDisk Cruzer Mini
#

Using Dougal's probedisk (in header: 'Last update: June 9th'):

# probedisk
/dev/hdb|disk|KINGSTON
/dev/sda|Direct-Access|SanDisk Cruzer Mini
/dev/sr0|cdrom|TSSTcorpCD/DVDW SH-W162C
#

Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#120 Post by BarryK »

Ah yes, silly me, I messed up Dougal's probedisk3. I'll fix it.

For probepart, I have yet another, attached. Unlike the original probepart, this returns info about filesystem on a superfloppy-formated drive. I have just added size-info -- the probepart-bk2 as just returning '0' for the size.

This superfloppy info makes it incompatible with Pmount.
Attachments
probepart-bk3.gz
(856 Bytes) Downloaded 704 times

Post Reply