212,213b USB flash names not retained in Pmount, Univ Inst
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Ah, "good", I was getting quite concerned reading down the thread! The problem still exists for grafpup though.plinej wrote:nevermind, it seems to be a grafpup specific problem due to permissions. Running as root I see my partition correctly in pmount.
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 405 times
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 429 times
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.
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.
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)
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)
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 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)
http://www.linux.com/howtos/SCSI-2.4-HOWTO/arch.shtmlOne 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.
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.
SG driver used on Udev (kernel 2.6_xx) systems: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)
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......
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 !
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)
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
http://www.murga-linux.com/puppy/viewto ... ch&id=3811
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
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.
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 701 times
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
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.
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 704 times
Tested on a thin client with Puppy 2.14 on a CF card and a USB CD/DVD drive.
Paul# 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|
#
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
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.
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 687 times
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
# ./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
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
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.
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 705 times