Damn Small Linux (DSL) Forums
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 20, 2014, 12:15:34 AM

Login with username, password and session length
News
The new DSL forums are now open.
Stats
297849 Posts in 294161 Topics by 222 Members
Latest Member: garith89
Search:     Advanced search
* Home Help Search Login Register
Get The Official Damn Small Linux Book. Great VPS hosting provided by Tektonic

+  Damn Small Linux (DSL) Forums
|-+  Damn Small Linux
| |-+  User Feedback
| | |-+  mounting a loop fs at offset=xxx fails
« previous next »
Pages: [1] Print
Author Topic: mounting a loop fs at offset=xxx fails  (Read 2141 times)
kswoodsman
Newbie
*
Posts: 8


View Profile
« on: September 06, 2012, 07:06:01 PM »

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.
Logged
kswoodsman
Newbie
*
Posts: 8


View Profile
« Reply #1 on: January 03, 2013, 01:09:41 AM »

hmmmmm , no follow ups ?
no ideas from anyone ?

Has ANYONE had any luck mounting a loop filesytem ?
Logged
Laptop98
Newbie
*
Posts: 10


View Profile
« Reply #2 on: December 30, 2013, 08:56:54 PM »

hmmmmm , no follow ups ?
no ideas from anyone ?

Has ANYONE had any luck mounting a loop filesytem ?
Nope. I couldn't mount a loop file system either.

I think the problem is the offset=32256

Older versions of Linux can't handle an offset with a high value more than 32bits. Use a lower value for the offset is the answer.
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by SMF 1.1.19 | SMF © 2013, Simple Machines
Mercury design by Bloc