mounting a loop fs at offset=xxx fails

To the developer I send my many thanks !!!
My frugal install went without a hitch, thank you for including LILO.

I did have a problem , initially, with the kernel freezing at boottime. It is a 1GHz early Celeron in a Gateway 300 flexatxstc. The CPU doesn't seem to handle SMP kernels well. I had to add the boot-time kernel option "no-hlt" .

After the install I added a second HD thinking I was going to play around a bit loop mounting the fs's on the device.
After MANY failed attempts trying to mount known partittions as loop devices.

#mount -t ext2 -o loop,offset=32256,ro /dev/hdb /mnt/hdb1

I decided to write a small script to probe the first 10,000 512 byte sectors for filesystems thinking maybe my math skills were failing. This would(should) also pick up on the next 2 partitions if successful and mount them over the top of the first one.

it was something like :
#! /bin/bash
for a in 0 1 2 3 4 5 6 7 8 9
do for b in 0 1 2 3 4 5 6 7 8 9
do for c in 0 1 2 3 4 5 6 7 8 9
do for d in 0 1 2 3 4 5 6 7 8 9
do for e in 0 1 2 3 4 5 6 7 8 9
do echo "sector $a$b$c$d$e at offset $[512*$[$[$a*10000]+$[$b*1000]+$[$c*100]+$[$d*10]+$[$e]]]"
losetup -d /dev/loop0 # was added later thinking the loop wasn't resset
mount -t ext2 -o loop,offset=$[512*$[$[$a*10000]+$[$b*1000]+$[$c*100]+$[$d*10]+$[$e]]] /dev/hda \ /mnt/hda1 && echo SUCCESS ! ! ! && break
done ; done ; done ; done ; done
# end of script

This lilttle script works with varying distros but seemed to bomb out with DSL 4.11 rc1.
The first run of the batch script ran without finding anything. The first line of output from it was as expected. It probed the MBR and gave an error from mount that no fs was found. Every successive probe returned "ioctl: LOOP_SET STATUS: Invalid Argument" . hmmm sounds like the loop wasn't unconfigured. So I drop a line in to delete the loop settings on every attempt. #losetup -d /dev/loop0. Still no luck with this. I now get the error that no such address for that loop device. That wasn't it. The next thought was a typo in the $[$[$]] 's. no , I tried it by hand figuring the location and entering it at the command line using both mount -o and losetup -o.

Changing the bs from 512 to smaller values gave similar results. Till it was reduced below 16 bytes. With a bs from 1 byte to 16 bytes it gave the same errors as the first. As it probed the first 32 bytes of the MBR the error was as expected. After that it gave the LOOP_SET_STATUS error. I also tried setting the script to start on the known partittion and in an area filled with zeros. no luck. it still gave the same LOOP_SET_STATUS error.

I tried a few different hardrives including several usb thumb drives with the same result. The partitions could be mounted straightforward but mounting an image of them fails as does trying to mount a fs at a particular offset from the actual device.

During the process I 'forked' my train of thought to try encrypted filesystems using aes encryption and played with that a bit but couldnt tell that actual encryption was taking place. While running hexdump on the encrypted image all the content seemed to be completely visible. Mounting the fs without encryption also yeilded the same results. The files were readable. The only obfuscation seemed to be in how the image was created. The command :
#dd if=/dev/urandom of=encrypted.img bs=1M count=100
filled the file with random characters instead of all 00 00 00 00 00 00 00 00's.

I'm not sure if the 2 loop issues are related but thought to mention them both to make people aware a problem may exist if they are expecting to keep private data private or if they are trying to recover a partittion after a corupted MBR. Being aware that other tools exist for this purpose , this was the one I had at hand and wanted to give it a go.

I have my doubts I will check back in on this forum to answer questions or continue the discussion but hope I have provided enough information to make this a repeatable exercize for others.