On 08/24/2011 02:08 PM, Arno Schuring wrote:
(replying to myself because I seem to have lost your message, apologies
Rob)
Arno Schuring (aelschur...@hotmail.com on 2011-08-16 00:55 +0200):
Hi,
I've taken a (cursory) look at the diffs, version 0.7's MBR is always
all-zeroes. I did get to try t
(replying to myself because I seem to have lost your message, apologies
Rob)
Arno Schuring (aelschur...@hotmail.com on 2011-08-16 00:55 +0200):
> Hi,
>
>
> 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
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 versi
Upstream request a copy of the MBR to try to reproduce your issue.
Could you provide this attached to this bug ?
This can be made by using "b" option (called back up GPT) in gdisk.
After, firsts attempts to reproduce this bug, it could be an issue with
the arm binary version (unreproducible on x86
forwarded 637572
"http://sourceforge.net/mailarchive/message.php?msg_id=27947780";
thanks
Hello,
I've forwarded this to upstream.
Le vendredi 12 août 2011 à 19:38 +0200, aelschur...@hotmail.com a
écrit :
> Package: gdisk
> Version: 0.7.2-1
> Severity: normal
>
> It appears that the new gdisk re
Package: gdisk
Version: 0.7.2-1
Severity: normal
It appears that the new gdisk release confuses itself when it needs to write a
protective MBR:
===
# gdisk /dev/sde
GPT fdisk (gdisk) version 0.7.2
Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: present
Fo
6 matches
Mail list logo
