On 08/15/2011 06:55 PM, Arno Schuring wrote:
> Enclosed are the dumps, They are all created in the same way:
> # gdisk /dev/sdX
> Command (? for help): b
> Enter backup filename to save: sdX-0.N.gpt
> The dumps do not change if I recreate the protective MBR (x-n) before
> dumping. And with version 0.7, if I choose 'v' from the main menu, it
> immediately gives the "0xEE partition doesn't start on sector 1" error.
> I've taken a (cursory) look at the diffs, version 0.7's MBR is always
> all-zeroes. I did get to try these disks on i386 as well, and there it
> works fine, so it's not disk-related. I guess it's either an
> architecture-specific bug or a compiler gotcha.
> If there's anything I can do test, please let me know. But the disks
> are now in use, so I won't be able to do write-tests. From the results
> above, I guess that won't be necessary.
If it works on i386 but not on armel, then it does sound like an
architecture-specific issue. I've been unable to reproduce the problem
on i386, x86-64, or PowerPC systems. My understanding is that Debian's
armel support is little-endian, like the i386 and x86-64 platforms, so
this doesn't seem to be an endianness bug. (My PowerPC tests should have
exposed such a bug, too.) My guess would be a compiler options issue.
Can the computer that exhibits these problems use USB flash drives or
some other "scratch" disk (an old hard disk, say)? If so, doing test
compiles of gdisk with various g++ options and testing on the "scratch"
disk might turn up a set of options that would work. (Search the gcc man
page for "ARM Options" to turn up a list of options.)
Unfortunately, I don't have any ARM hardware myself. I'll look into
setting up a virtual ARM machine using QEMU, but it may be a few days
before I can get to that....