mystery file

So I've got this file:

-r-------- 1 root root 116G Feb 21 2007 /mnt/temp2/hda

(BTW, /mnt/temp2 is itself a mounted partition on a USB drive.)

So far I've done this:

root@pc:~# losetup /dev/loop2 /mnt/temp2/hda
root@pc:~# fdisk -l /dev/loop2

Disk /dev/loop2: 123.5 GB, 123522416640 bytes
255 heads, 63 sectors/track, 15017 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/loop2p1 * 1 5135 41246856 7 HPFS/NTFS
/dev/loop2p2 5136 15017 79377165 7 HPFS/NTFS

OK, how do I mount them (read-only is fine, I just want to see what's
there)? If I knew what the major/minor numbers of /dev/loop2p[12] were
I could recreate them. Probably the file is merely a CYA backup before
I resized the partitions.

I have a feeling it's something akin to

root@pc:~# mount /dev/loop2 /mnt/temp3 -t ntfs -o ro,offset=8225280

but I don't know what the offset should be. If I can get rid of that file,
it would free up >100 GB.

--
-eben [email]QebWenE01R@vTerYizUonI.nOet[/email]P [url]http://royalty.mine.nu:81[/url]
AQUARIUS: There's travel in your future when your tongue freezes to the
back of a speeding bus. Fill the void in your pathetic life by playing
Whack-a-Mole 17 hours a day. -- Weird Al, _Your Horoscope for Today_

Hactar staggered into the Black Sun and said:[color=blue]
> root@pc:~# losetup /dev/loop2 /mnt/temp2/hda
> root@pc:~# fdisk -l /dev/loop2
>
> /dev/loop2p1 * 1 5135 41246856 7 HPFS/NTFS
> /dev/loop2p2 5136 15017 79377165 7 HPFS/NTFS
>
> OK, how do I mount them?[/color]

Why did you dd the whole disk into one file? Always dd the partitions
separately, or better yet, use partimage.

mallory:# dd if=/dev/sdc of=sdc.raw bs=32k
mallory:# losetup /dev/loop3 sdc.raw
mallory:# fdisk -lu /dev/loop3
Device Boot Start End Blocks Id System
/dev/loop3p1 51 257804 128877 6 FAT16

....51 sectors or (51*512=26112) bytes in. So:

mallory:# mount -t vfat -o loop,offset=26112 sdc.raw /mnt/other
mallory:# ls /mnt/other
[file listing of what's on there]
[color=blue]
> If I knew what the major/minor numbers of /dev/loop2p[12] were I could
> recreate them.[/color]

They don't have device numbers.
[color=blue]
> root@pc:~# mount /dev/loop2 /mnt/temp3 -t ntfs -o ro,offset=8225280
> but I don't know what the offset should be.[/color]

You can find out with fdisk -lu, though. HTH,

--
You have me mixed up with more creative ways of being stupid.
--MegaHAL, trained on random gibberish
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see

In article <slrnfqrmu0.vbr.danceswithcrows@crow202.dyndns.org>,
Dances With Crows <danceswithcrows@usa.net> wrote:[color=blue]
> Hactar staggered into the Black Sun and said:[color=green]
> > root@pc:~# losetup /dev/loop2 /mnt/temp2/hda
> > root@pc:~# fdisk -l /dev/loop2
> >
> > /dev/loop2p1 * 1 5135 41246856 7 HPFS/NTFS
> > /dev/loop2p2 5136 15017 79377165 7 HPFS/NTFS
> >
> > OK, how do I mount them?[/color]
>
> Why did you dd the whole disk into one file? Always dd the partitions
> separately, or better yet, use partimage.[/color]

If it is what I think it is, the plan was to write it back to the source
disk if the partition resize failed, and everything would be as it was
before. Normally, I would do what you said, since recreating the boot
block is a simple matter. It isn't, on a Windows-only system.
[color=blue]
> mallory:# fdisk -lu /dev/loop3
> Device Boot Start End Blocks Id System
> /dev/loop3p1 51 257804 128877 6 FAT16
>
> ...51 sectors or (51*512=26112) bytes in. So:
>
> mallory:# mount -t vfat -o loop,offset=26112 sdc.raw /mnt/other
> mallory:# ls /mnt/other
> [file listing of what's on there][/color]

FTR:

root@pc:/mnt/temp2# fdisk -lu /dev/loop2
....
/dev/loop2p2 82493775 241248104 79377165 7 HPFS/NTFS

82493775 * 512 = 422368131072 (~40 GB)

root@pc:/mnt/temp2# mount hda /mnt/temp3 -o ro,offset=422368131072,loop
ioctl: LOOP_SET_STATUS64: File too large
[color=blue][color=green]
> > root@pc:~# mount /dev/loop2 /mnt/temp3 -t ntfs -o ro,offset=8225280
> > but I don't know what the offset should be.[/color]
>
> You can find out with fdisk -lu, though. HTH,[/color]

Thanks, noted. (It was what I thought it was, so I freed up 100+ GB of
disk space.)

--
-eben [email]QebWenE01R@vTerYizUonI.nOet[/email]P
1101000 1110100 1110100 1110000 0111010 0101111 0101111 1110010 1101111
1111001 1100001 1101100 1110100 1111001 0101110 1101101 1101001 1101110
1100101 0101110 1101110 1110101 0111010 0111000 0110001 0101111

Hactar staggered into the Black Sun and said:[color=blue]
> Dances With Crows wrote:[color=green]
>> Hactar staggered into the Black Sun and said:[color=darkred]
>> > root@pc:~# fdisk -l /dev/loop2
>> > /dev/loop2p2 5136 15017 79377165 7 HPFS/NTFS[/color]
>> Why did you dd the whole disk into one file? Always dd the
>> partitions separately, or better yet, use partimage.[/color]
> Normally, I would do what you said, since recreating the boot block is
> a simple matter. It isn't, on a Windows-only system.[/color]

partimage backs up the MBR and partition table. It's trivial to dd the
first 62 sectors of a disk to another file if you want to back up the
MBR (and any GRUB-like loader in the slack space) manually.
[color=blue][color=green]
>> /dev/loop3p1 51 257804 128877 6 FAT16
>> ...51 sectors or (51*512=26112) bytes in. So:
>> mallory:# mount -t vfat -o loop,offset=26112 sdc.raw /mnt/other[/color]
> root@pc:/mnt/temp2# fdisk -lu /dev/loop2
> /dev/loop2p2 82493775 241248104 79377165 7 HPFS/NTFS
> 82493775 * 512 = 422368131072 (~40 GB)
>
> root@pc:/mnt/temp2# mount hda /mnt/temp3 -o ro,offset=422368131072,loop
> ioctl: LOOP_SET_STATUS64: File too large[/color]

Oh. Wow. Could be a bug of some sort. The offset is a u64 in the
kernel data structures in loop.h, so userspace may be doing something
dumb somewhere.

--
"Bother," said Pooh. "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump; Piglet, meet me in transporter room three."
--Robert Billing
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see

On Sun, 10 Feb 2008 02:27:35 UTC in comp.os.linux.hardware, Dances With Crows
<danceswithcrows@usa.net> wrote:
[color=blue][color=green]
> > root@pc:/mnt/temp2# mount hda /mnt/temp3 -o ro,offset=422368131072,loop
> > ioctl: LOOP_SET_STATUS64: File too large[/color]
>
> Oh. Wow. Could be a bug of some sort. The offset is a u64 in the
> kernel data structures in loop.h, so userspace may be doing something
> dumb somewhere.[/color]

Might be worth trying to use lomount to mount this instead of plain mount.
Lomount is something that's owned by the xen rpm on my Centos5/RHEL5 systems and
does all this for you - e.g. lomount -diskimage /mnt/temp2/hda -partition 1
/mnt/temp3

--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com