Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have under linux:

       Device   Boot      Start         End      Blocks   Id  System
/filename.img      *         63     1007999      503968+  a5  FreeBsd

Under above partition i have two slices: ufs filesystem and swap. I don't know, how I can determine mount offset to mount ufs partition.

mount -r -t ufs -o loop,offset=32256,ufstype=ufs2 filename.img /test/

dmesg output

ufs_read_super: bad magic number

It's not working.

share|improve this question
    
The fdisk you pasted does not show the partition layout you describe. Try using parted or partx to display the layout and if that fails, try testdisk on the file, since the partition table may be corrupt. –  rozcietrzewiacz Oct 26 '11 at 15:11
    
@rozcietrzewiacz If you assume that “two slices” was a mistake for “two BSD partitions”, then the text is consistent with the output. –  Gilles Oct 26 '11 at 19:53
    
@Gilles Actually, I was a bit imprecise - I meant that the provided fdisk output does not show the BSD disklabel partitions. I also see now that my later mention of partition table was misleading, since here also the disklabel is subject to verification. –  rozcietrzewiacz Oct 26 '11 at 20:32
    
@rozcietrzewiacz The fdisk output is clearly Linux's fdisk, showing what in PC/Linux terminology is one partition, and in BSD terminology is one slice. Inside that PC partition a.k.a BSD slice, it is plausible that there are two BSD partitions, root and swap. –  Gilles Oct 26 '11 at 20:40
    
@Gilles That is exactly the problem I was trying to point at - that linux fdisk would not see the BSD (disklabel) partitions, so another tool should be used. –  rozcietrzewiacz Oct 26 '11 at 20:49
add comment

migrated from stackoverflow.com Oct 26 '11 at 14:39

This question came from our site for professional and enthusiast programmers.

2 Answers

Thank you for all hints.

# partx -l filename.iso
HDIO_GETGEO: Inappropriate ioctl for device

I added filename mapping which created logical mapping in /dev/mapper directory

# kpartx -a filename.iso

# ls -l /dev/mapper/
control  loop0p1

the last one check

# partx -l /dev/mapper/loop0p1 
1:         0-       -1 (        0 sectors,      0 MB)
2:         0-       -1 (        0 sectors,      0 MB)
3:         0-       -1 (        0 sectors,      0 MB)
4:         0-    49999 (    50000 sectors,     25 MB)
1:   8388671-142078859 (133690189 sectors,  68449 MB)
2:        63-  8388670 (  8388608 sectors,   4294 MB)

and the last one with success

mount -r -t ufs -o loop,offset=$((8388671*512)),ufstype=ufs2 filename.iso /test/

Regards!

share|improve this answer
add comment

I suspect it's

mount -r -o loop,offset=32768,ufstype=ufs2 filename.img /test/

If I remember correctly, the first BSD partition starts on a 32kB boundary relative to the whole disk. That's 64 sectors of 512B. Relative to the PC partition, the offset of the BSD partition is 63 sectors, because the PC partition starts at an offset of 1 sector relative to the whole disk: the first sector of the disk contains the partition table.

As suggested by rozcietrzewiacz, you can confirm the offset of the BSD partition with

partx -l filename.img

There's a patch for the Linux kernel to support automatic access to partitions of loop devices. Debian applies it in their kernels. If you have this patch, then make sure the loop driver has a sufficiently large max_part parameter (you may need to do rmmod loop; modprobe max_part=63). Then the BSD partitions will appear as something like /dev/loop0p5 and /dev/loop0p6.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.