(old)Puppy Linux Discussion Forum

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?

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.

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

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:

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.

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.

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...

Okay, revised once again.

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.

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.

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......

It just never ends...

http://murga-linux.com/puppy/viewtopic.php?t=17626

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, Doesn't hurt to check /dev for symlinks - edit to correct

Wizards are great, but 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 !

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

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

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.

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.

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

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.

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

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.