Puppy Linux Discussion Forum

[BarryK]

Okay, I think I fixed probedisk...

[pakt]

Same hardware as earlier:

[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]

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):

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

[BarryK]

Heh heh, Jesse may be making all of this history with his "mutt on steroids":
http://www.puppyos.net/forum/?1181868790

(the word "mutt" is slang for a dog, actually a mixed-breed: http://en.wikipedia.org/wiki/Mixed-breed_dog , which kind of describes the multiple-nature of his new MUT -- hey Jess, why not call it "Mutt"?!)

[BarryK]

G2, thanks for that advice about $((...)). Yes, where I have the SIZE in bytes there is potential trouble using expr. I've modified the script.

[jeffrey]

Just as an aside, you can often replace several commands with awk.
For example,

[PaulBx1]

[Jesse]

Hi,

The new mutt will be able to simulate probepart and probedisk through a symlink to the mutt executable, like how busybox does multiple cli apps. If you're not sure what I'm saying there then consider it as another script candidate, but its a compiled binary (from c code).
Its currently working, it does probedisk and probepart, but there are some internal aspects still to tidy up before its ready for alpha/beta testing.

Jesse

[Jesse]

Hi Barry,

I was just checkining out your probepart-bk3,
there is a minor glitch in it, to do with detecting superfloppy format and/or media change.
I recently discovered this in the new mutt, and fixed it there, I'd seen it previously but not realised what was going on.

The problem comes about when the user swaps the media, e.g. usb compact flash is swapped for another compact flash.
The problem can show as an incorrect size for the device, incorect partition name, or as a really confusing diferent filesystem name.
The good news is that on a second execution of the script the hardware is detected/reported correctly.
The problem comes about because the media has been changed and the kernel has not re-read the partition table from the device to update kernel interfaces like /proc/partitions.

Examples: I have a 256Mb CF that was once an ext3 superfloppy, but then I partitioned it to a 256MB part of vfat. I also have a 32MB CF of superfloppy vfat.

(start with 32MB)
sh-3.00# ./probepart-bk3 | grep sdb
/dev/sdb|vfat|62592

(swap to 256MB)
sh-3.00# ./probepart-bk3 | grep sdb
/dev/sdb|ext3|510464
sh-3.00# ./probepart-bk3 | grep sdb
/dev/sdb1|vfat|509992

(back to 32MB)
sh-3.00# ./probepart-bk3 | grep sdb
/dev/sdb1|none|509992
sh-3.00# ./probepart-bk3 | grep sdb
/dev/sdb|vfat|62592

Jesse

[BarryK]

Jesse, so do you mean if probepart is run too soon after a usb drive is changed, it can read /proc/partitions before it has properly updated?
/proc/partitions is not a normal file, we can't read its modify date. How to work around this problem? ...how did you do it in mutt?

I suppose it could be read twice, with one or two second delay, then check that they are identical -- this could be in a while-loop.

[jeffrey]

I don't understand what happens in Puppy when a device is added, but /sbin/hotplug may be called which may create a short-lived 'loading' file via the /etc/hotplug/firmware.agent script, although I couldn't spot one by running "find /sys /proc -name loading" in a loop while plugging a USB drive in.
When a device is plugged in I'd expect /var/log/messages to be updated so perhaps as a rough solution you could check whether its timestamp is the same as the current time.
(Just a few poor thoughts - not very clean I'm afraid...)

[Jesse]

Hi,

In mutt, I use an ioctl to ask the kernel to update its info about the mbr of each drive/device, and I read the partition table direct from the MBR.
But it seems to be possible by reading the first sector and attempting to find the filesystem on the drive, which can be scripted for.
I have just done a quick update to your script and it works for me, I tried to optimise out the duplicate fs scans but guessfs_type is needed for both scans.
Attached is my updates to probepart-bk3, you might want to add comments to it?

sh-3.00# ./probepart-bk3 | grep sdb
/dev/sdb|vfat|62592
sh-3.00# ./probepart-bk3 | grep sdb
/dev/sdb1|vfat|509992
sh-3.00# ./probepart-bk3 | grep sdb
/dev/sdb|vfat|62592

Jesse

[BarryK]

Jesse, I don't quite understand the mods to the script.

1.
What is the effect of just reading and dumping the first 512 bytes of the drive/partition? Does that serve as a wake-up to the kernel?

2.
why do you have to call guess-fstype on both prescan and normal loops?

It would seem 1. and 2. are related somehow.

Apart from the above, note that the case-structure is only entered for drives that do not have partitions. But, isn't this updating problem generic?
In other words, the reading of the first 512 bytes needs to be in a separate case-structure? Like this: