 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Does anybody here know how to read C?
Basically, my problem is this:
root# fdisk -l /dev/sdc
Disk /dev/sdc: 320.1 GB, 320072932864 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142447 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdc1 63 128519 64228+ af HFS / HFS+
root# mount /dev/sdc1 /mnt
root# echo $?
0
root# umount /mnt
root# mount --ro -o offset=32256,sizelimit=6576994 /dev/sdc /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop20,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
root# dmesg | tail
[164258.208493] hfs: unable to find HFS+ superblock
[164398.983651] hfs: invalid secondary volume header
[164398.983654] hfs: unable to find HFS+ superblock
[164404.235785] hfs: invalid secondary volume header
[164404.235787] hfs: unable to find HFS+ superblock
[164407.461400] hfs: invalid secondary volume header
[164407.461404] hfs: unable to find HFS+ superblock
In order words, if I mount /dev/sdc1, it works perfectly. But if I mount
/dev/sdc, passing in the byte offsets to the start and end of the first
partition, it doesn't work at all.
By pointing my web browser at kernel.org and wandering aimlessly through
the Linux kernel source code, I was eventually able to discover that the
first message ("unable to find HFS+ superblock") appears on line 410 of
fs/hfsplus/super.c - which seems like a logical enough place for
superblock-reading code to live.
My question: Can anybody figure out why the code is actually failing?
What is it unhappy about? What has it expecting to find that wasn't
there? (I guess it's kinda hard to conclusively pin this down without a
copy of the disk...)
For me, just figuring out where the various functions are defined is
quite hard. (C has this wonderful arrangement where any part of the code
can refer to any other part of the code, with no algorithm for ever
discovered WHERE that code is actually defined - except for
whole-program analysis, obviously.) Also fun is that some of the
"functions" are actually macros. Just to mess with your head.
OTOH, considering this is an OS kernel... it's not as awful as I had
expected.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 01/05/2014 20:16, Orchid Win7 v1 nous fit lire :
> Does anybody here know how to read C?
>
> Basically, my problem is this:
>
> root# fdisk -l /dev/sdc
>
> Disk /dev/sdc: 320.1 GB, 320072932864 bytes
> 255 heads, 63 sectors/track, 38913 cylinders, total 625142447 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
> Device Boot Start End Blocks Id System
> /dev/sdc1 63 128519 64228+ af HFS / HFS+
> root# mount /dev/sdc1 /mnt
> root# echo $?
> 0
> root# umount /mnt
> root# mount --ro -o offset=32256,sizelimit=6576994 /dev/sdc /mnt
> mount: wrong fs type, bad option, bad superblock on /dev/loop20,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so
> root# dmesg | tail
> [164258.208493] hfs: unable to find HFS+ superblock
> [164398.983651] hfs: invalid secondary volume header
> [164398.983654] hfs: unable to find HFS+ superblock
> [164404.235785] hfs: invalid secondary volume header
> [164404.235787] hfs: unable to find HFS+ superblock
> [164407.461400] hfs: invalid secondary volume header
> [164407.461404] hfs: unable to find HFS+ superblock
>
> In order words, if I mount /dev/sdc1, it works perfectly. But if I mount
> /dev/sdc, passing in the byte offsets to the start and end of the first
> partition, it doesn't work at all.
And why do you want to use sdc instead of sdc1 ?
Offset seems an option for the loop device only (aka: the disk is
actually a file). Never heard of it for normal disk. Same for sizelimit.
>
> By pointing my web browser at kernel.org and wandering aimlessly through
> the Linux kernel source code, I was eventually able to discover that the
> first message ("unable to find HFS+ superblock") appears on line 410 of
> fs/hfsplus/super.c - which seems like a logical enough place for
> superblock-reading code to live.
>
> My question: Can anybody figure out why the code is actually failing?
> What is it unhappy about? What has it expecting to find that wasn't
> there? (I guess it's kinda hard to conclusively pin this down without a
> copy of the disk...)
>
Mount is tricky, but it's nothing when compared to fsck mega jumbo
trampoline.
the option for hfs are only (from man page): creator, uid, dir_umask,
file_umask, umask, session, part and quiet.
If you really want to access the content from /dev/sdc, you would need
first to copy it as a file (on another bigger disk) (with
"dd if=/dev/sdc of=whatever_file_not_on_sdc" ), and then
mount -t hfs -o ro,loop,offset=32256,sizelimit=6576994
/whatever_file_not_on_sdc /mnt
(absolute path of the file is needed by mount)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/05/2014 07:16 PM, Orchid Win7 v1 wrote:
> Does anybody here know how to read C?
>
> Basically, my problem is this:
>
> root# mount /dev/sdc1 /mnt
> root# echo $?
> 0
> root# umount /mnt
> root# mount --ro -o offset=32256,sizelimit=6576994 /dev/sdc /mnt
> mount: wrong fs type, bad option, bad superblock on /dev/loop20,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so
It turns out that updating to the next release of OpenSUSE completely
fixes the issue. So that should be a five-minute job...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
