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

Please post any bugs you have found
Message
Author
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

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

#121 Post by BarryK »

Okay, I think I fixed probedisk...
Attachments
probedisk4-1.gz
(527 Bytes) Downloaded 478 times

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

#122 Post by pakt »

Same hardware as earlier:
# ./probepart-bk3
/dev/hdb1|vfat|2040192
/dev/hdb2|ext2|2008124
/dev/sr0|iso9660|0
/dev/sda1|vfat|249824
#
# ./probedisk4-1
/dev/hdb|disk|KINGSTON
/dev/sr0|cdrom|TSSTcorpCD/DVDW SH-W162C
/dev/sda|Direct-Access|SanDisk Cruzer Mini
#
Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#123 Post by GuestToo »

busybox's expr has a range of -2147483648 to 2147483647

bash's $((...)) has a range of -9223372036854775808 to 9223372036854775807, and the syntax is better looking, to my eye anyway

bc has arbitrary (unlimited) precision

i don't know about busybox's dc ... i think it switches from integers to floating point, and integer mode can't be forced using 0k ... busybox's dc has differences from the real dc, a script that was written using the real dc would probably not work with busybox's dc and vice versa

$((...)) also seems to work in busybox's ash, at least when ash is executed from a bash shell:

# ash

BusyBox v1.01 (2006.08.20-09:28+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

# echo $((3+4))
7
#

i'm not sure if bash is intercepting the $((...)) syntax before it gets to the ash shell or not ... i wouldn't think bash should do that

your script using $((...)) would look something like this:

[ $BSIZE ] && SIZE=$(($BSIZE/1024)) #KB


[ "$SUNITS" = "" ] && SIZE=$(($SIZE*2)) #512 byte blocks.
[ "$SUNITS" = '-m' ] && SIZE=$(($SIZE/1024)) #MB

your script using bc would look something like this:

[ $BSIZE ] && SIZE=`echo "$BSIZE/1024"|bc` #KB


[ "$SUNITS" = "" ] && SIZE=`echo "$SIZE*2"|bc` #512 byte blocks.
[ "$SUNITS" = '-m' ] && SIZE=`echo "$SIZE/1024"|bc` #MB

also, your script prints sizes in mb for -m, 512 byte blocks for $1="" ... any other parameter will print the size in 1k blocks ... i assume that's what you intended

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

HFS/HFSPlus support

#124 Post by John Doe »

Yesterday another Intel-Mac user arrived.

I recall Barry modified 'libhardware' to enable NTFS recognition. Could the same be done for HFS and HFS+? Thereby enabling it to show up in probepart. Which would only leave some tiny modification to MUT and PMOUNT to enable mounting (example).

GUIDs (couldn't figure out which one is plain HFS):

Code: Select all

Hierarchical File System (HFS+) partition 	48465300-0000-11AA-AA11-00306543ECAC
reference:
http://developer.apple.com/technotes/tn ... #SECADVICE
http://en.wikipedia.org/wiki/GUID_Partition_Table

Here is the line for modules.dep for the zdrive and the squash, I put it right after hfs.ko:

Code: Select all

/lib/modules/2.6.18.1/kernel/fs/hfsplus/hfsplus.ko:
mut.tcl would be something like this at around line 285 (right after 'set results ""' in grab_fs_vol):

Code: Select all

if {$fs == "hfs"} {set fs "hfs"}
if {$fs == "hfsplus"} {set fs "hfsplus"}
pmount would be something like this at around line 20 (right after 'FSTYPE="$1"'):

Code: Select all

[ "$FSTYPE" = "HFS" ] && FSTYPE="hfs"
[ "$FSTYPE" = "HFSPlus" ] && FSTYPE="hfsplus"
Also the respective kernel module would need loaded.

Code: Select all

modprobe hfs
modprobe hfsplus
That's about it I think. I have the modules in my zdrive and one hfs+ partition, so I could test the new scrips and libhardware if you upload it here.

*Edit- THat wasn't it, one other thought I forgot. Saving and booting could be a possible after that. :-)
Last edited by John Doe on Sat 16 Jun 2007, 18:57, edited 1 time in total.

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

#125 Post by Dougal »

Oops… I just read Barry's blog.
When I posted that probepart script I made some last-minute change and must have had a typo. I discovered it later but since no-one complained I assumed the script I posted didn't have that modification.

Here're my latest versions of the script, in case they are of any help.
Attachments
probaprt-probedisk-test-scsi.tar.gz
(1.94 KiB) Downloaded 410 times
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

Post Reply