On 08/15/2011 06:55 PM, Arno Schuring wrote:
Hi,
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....
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to