mystery file - Hardware

This is a discussion on mystery file - Hardware ; 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: ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: mystery file

  1. 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 QebWenE01R@vTerYizUonI.nOetP http://royalty.mine.nu:81
    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_

  2. Re: mystery file

    Hactar staggered into the Black Sun and said:
    > 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?


    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]

    > If I knew what the major/minor numbers of /dev/loop2p[12] were I could
    > recreate them.


    They don't have device numbers.

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


    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

  3. Re: mystery file

    In article ,
    Dances With Crows wrote:
    > Hactar staggered into the Black Sun and said:
    > > 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?

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


    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.

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


    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

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

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


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

    --
    -eben QebWenE01R@vTerYizUonI.nOetP
    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

  4. Re: mystery file

    Hactar staggered into the Black Sun and said:
    > Dances With Crows wrote:
    >> Hactar staggered into the Black Sun and said:
    >> > root@pc:~# fdisk -l /dev/loop2
    >> > /dev/loop2p2 5136 15017 79377165 7 HPFS/NTFS

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

    > Normally, I would do what you said, since recreating the boot block is
    > a simple matter. It isn't, on a Windows-only system.


    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.

    >> /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

    > 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


    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

  5. Re: mystery file

    On Sun, 10 Feb 2008 02:27:35 UTC in comp.os.linux.hardware, Dances With Crows
    wrote:

    > > root@pc:/mnt/temp2# mount hda /mnt/temp3 -o ro,offset=422368131072,loop
    > > ioctl: LOOP_SET_STATUS64: File too large

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


    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

+ Reply to Thread