gptfdisk-general — General discussions of GPT fdisk

[Gptfdisk-general] cgdisk: blank disk warning confusing (wishlist)

[David L. <lio...@co...>]

When I use gdisk on a new disk, it correctly detects there is nothing there:

# gdisk /dev/sdae
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
   MBR: not present
   BSD: not present
   APM: not present
   GPT: not present

Creating new GPT entries.

Command (? for help):

(Incidentally, the message "Creating new GPT entries" is confusing; 
presumably the program does nothing until asked.
A better wording might be "Ready to create new GPT entries.")

In contrast, when I use cgdisk 0.8.5 on the same new disk, I get a loud 
warning:

cgdisk /dev/sdae

Warning! Non-GPT or damaged disk detected! This program will attempt to
convert to GPT form or repair damage to GPT data structures, but may not
succeed. Use gdisk or another disk repair tool if you have a damaged GPT
disk.


Wishlist: cgdisk should not needlessly induce heart attacks, but like 
gdisk confidently recognize a blank disk.

Cheers,
Dave

[Gptfdisk-general] cgdisk: accept current partition alignment as default (wishlist)

[David L. <lio...@co...>]

Greetings!

When selecting "Alignment" in cgdisk, I get:


Disk Drive: /dev/sdn
Size: 3907029168, 1.8 TiB

Part. #     Size        Partition Type            Partition Name
----------------------------------------------------------------
             1.8 TiB     free space


Current partition alignment, in sectors, is 2048.
Type new alignment value, in sectors:

There is no default value, and the user is forced to enter something. 
This seems more risky than keeping the current value as a default!

Cheers,
Dave

Re: [Gptfdisk-general] Compiling gptfdisk on cygwin fails

[Rod S. <rod...@ro...>]

On 07/24/2012 01:21 PM, notstop wrote:
> Trying to compile gdisk only on cygwin:
>
> $ make gdisk
...
> g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o diskio-unix.o
> diskio-unix.cc
> diskio-unix.cc: In member function ‘int DiskIO::OpenForRead()’:
> diskio-unix.cc:48:18: error: aggregate ‘DiskIO::OpenForRead()::stat64
> st’ has incomplete type and cannot be defined
...
> make: *** [diskio-unix.o] Error 1
...
> Any patch to solve it?

I'm afraid not. I don't support compiling gdisk under Cygwin. You're 
likely to have better luck with either MinGW or Microsoft's C++ 
compiler. Both are free and both can produce Windows executables. (I've 
only used MinGW as a cross-compiler under Linux, though; you may need to 
jump through some hoops to get the Windows version to work.)

That said, if you must use Cygwin, be aware that the diskio-unix.cc file 
provides Unix-specific support functions. You might have better luck 
with diskio-windows.cc, even under Cygwin; or you might need to examine 
the various #ifdef and #include statements in diskio-unix.cc to come up 
with an appropriate way to #include something in Cygwin that defines the 
stat64 structure definition. I'm not familiar enough with Cygwin to make 
any specific recommendations.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] Compiling gptfdisk on cygwin fails

[notstop <no...@li...>]

Trying to compile gdisk only on cygwin:

$ make gdisk
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o gptpart.o gptpart.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o mbrpart.o mbrpart.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o basicmbr.o basicmbr.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o mbr.o mbr.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o gpt.o gpt.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o bsd.o bsd.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o parttypes.o 
parttypes.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o attributes.o 
attributes.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o diskio.o diskio.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16   -c -o diskio-unix.o 
diskio-unix.cc
diskio-unix.cc: In member function ‘int DiskIO::OpenForRead()’:
diskio-unix.cc:48:18: error: aggregate ‘DiskIO::OpenForRead()::stat64 
st’ has incomplete type and cannot be defined
diskio-unix.cc:73:29: error: ‘fstat64’ was not declared in this scope
diskio-unix.cc: In member function ‘int DiskIO::DiskSync()’:
diskio-unix.cc:211:8: warning: unused variable ‘i’
diskio-unix.cc: In member function ‘int DiskIO::Seek(uint64_t)’:
diskio-unix.cc:269:44: error: ‘lseek64’ was not declared in this scope
diskio-unix.cc: In member function ‘uint64_t DiskIO::DiskSize(int*)’:
diskio-unix.cc:378:18: error: aggregate ‘DiskIO::DiskSize(int*)::stat64 
st’ has incomplete type and cannot be defined
diskio-unix.cc:428:29: error: ‘fstat64’ was not declared in this scope
<builtin>: recipe for target `diskio-unix.o' failed
make: *** [diskio-unix.o] Error 1

Please take a look at:

http://cygwin.com/ml/cygwin/2004-10/msg00346.html

Any patch to solve it?

Regards,

Re: [Gptfdisk-general] [PATCH] Fix creating of two 0xEE partitions in hybrid MBR

[Rod S. <rod...@ro...>]

On 06/17/2012 01:39 PM, Kirill Elagin wrote:
> Imagine, that I want to hybridize two partitions and I don't want to put
> 0xEE partition first in the table (it's a flash drive to be used with
> Windows). In my particular case the layout is the following:
>
>      Number  Start (sector)    End (sector)  Size       Code  Name
>         1            2048         7243775   3.5 GiB     8E00  Linux LVM
>         2         7243776        11438079   2.0 GiB     8300  Linux
> filesystem
>         3        11438080        15633374   2.0 GiB     0700  Microsoft
> basic data
>
> Original code will make hybridized partitions #1 and #2 in the MBR
> partition table, then it will create an 0xEE partition #4, then it will
> ask me if I want to cover unused space (sure, I want to cover backup GPT
> at the end of the disk), and then it will make partition #4 cover the
> end of the disk. So I end up with main GPT structures unprotected and
> one empty slot in MBR GPT like this:
>
>      Number  Boot  Start Sector   End Sector   Status      Code
>         1              11438080     15633374   primary     0x0C
>         2               7243776     11438079   primary     0x83
>         4              15633375     15633407   primary     0xEE
>
> Modified code does this:
>
>      Number  Boot  Start Sector   End Sector   Status      Code
>         1              11438080     15633374   primary     0x0C
>         2               7243776     11438079   primary     0x83
>         3                     1      7243775   primary     0xEE
>         4              15633375     15633407   primary     0xEE

OK, thanks for the clarification. I'm accepting this patch into the next 
version of the program.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

Re: [Gptfdisk-general] gdisk or cgdisk change name of partition UTF-16 problem

[Rod S. <rod...@ro...>]

On 06/08/2012 12:19 AM, Joe van Tunen wrote:
> I'm running gdisk 0.8.5 on Mac OS X 10.7.4.
>
> I get errors when attempting to change a partition name. If I don't get an
> error, the partition appears to have no name after the change.
>
> Command (? for help): p
>    15       936110296       937134295   500.0 MiB   AF00  Shell
>
> Command (? for help): c
> Partition number (1-15): 15
> Enter name: My New Name
> Bogus UTF-16 name found in GPTPart::SetName()! Name not changed!

Sorry for the delay in responding. I plan to release a new version of 
gdisk soon (maybe today, or at least in the next week or so), and this 
will be fixed; however, I'm doing this by disabling UTF-16 support for 
partition names on OS X, which has proven problematic.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

Re: [Gptfdisk-general] [PATCH] Fix creating of two 0xEE partitions in hybrid MBR

[Rod S. <rod...@ro...>]

On 06/15/2012 01:15 PM, Kirill Elagin wrote:
> This makes gfdisk create two protective EFI GPT partitions with
> eeFirst='N' if user hybridized less than three partitions.

Thanks for the patch; however, all it does according to my reading of 
the code and in my tests is to change the partition number of the 0xEE 
partition from partition 4 to the lowest-available partition number when 
the user opts to not place 0xEE first in the table. AFAIK, this is an 
irrelevant detail. If you can point out a problem caused by the original 
code, I'll consider including your patch, but if not, I'll stick with 
the current code.

> ---
>   gpttext.cc |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gpttext.cc b/gpttext.cc
> index 506c0f1..474b23b 100644
> --- a/gpttext.cc
> +++ b/gpttext.cc
> @@ -452,7 +452,7 @@ void GPTDataTextUI::MakeHybrid(void) {
>         if (eeFirst == 'Y') {
>            hybridMBR.AddPart(0, hybridPart);
>         } else {
> -         hybridMBR.AddPart(3, hybridPart);
> +         hybridMBR.AddPart(numPartsToCvt, hybridPart);
>         } // else
>         hybridMBR.SetHybrid();
>


-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] [PATCH] Fix creating of two 0xEE partitions in hybrid MBR

[Kirill E. <kir...@gm...>]

This makes gfdisk create two protective EFI GPT partitions with
eeFirst='N' if user hybridized less than three partitions.
---
 gpttext.cc |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gpttext.cc b/gpttext.cc
index 506c0f1..474b23b 100644
--- a/gpttext.cc
+++ b/gpttext.cc
@@ -452,7 +452,7 @@ void GPTDataTextUI::MakeHybrid(void) {
       if (eeFirst == 'Y') {
          hybridMBR.AddPart(0, hybridPart);
       } else {
-         hybridMBR.AddPart(3, hybridPart);
+         hybridMBR.AddPart(numPartsToCvt, hybridPart);
       } // else
       hybridMBR.SetHybrid();

-- 
1.7.9.2


--
Кирилл Елагин

[Gptfdisk-general] gdisk or cgdisk change name of partition UTF-16 problem

[Joe v. T. <jo...@sh...>]

I'm running gdisk 0.8.5 on Mac OS X 10.7.4.

I get errors when attempting to change a partition name. If I don't get an
error, the partition appears to have no name after the change.

Command (? for help): p
  15       936110296       937134295   500.0 MiB   AF00  Shell

Command (? for help): c
Partition number (1-15): 15
Enter name: My New Name
Bogus UTF-16 name found in GPTPart::SetName()! Name not changed!

Command (? for help): c
Partition number (1-15): 15
Enter name: MyNewName
Bogus UTF-16 name found in GPTPart::SetName()! Name not changed!

Command (? for help): c
Partition number (1-15): 15
Enter name: Shell2

Command (? for help): p
  15       936110296       937134295   500.0 MiB   AF00  

Re: [Gptfdisk-general] Windows Vista 32-bit Warning gdisk 0.7.1 - 0.8.4

[Rod S. <rod...@ro...>]

On 05/28/2012 09:48 PM, Alan wrote:
> I have a Windows Vista 32-bit computer with an added Corsair Force 3 SSD
> that came factory partitioned GPT, the microprocessor is a 64-bit Intel
> Core 2 E6300. I am working on my first computer build and will transfer
> this SSD to it as the C: System drive by loading an OS on it in the new
> computer. I want to end up dual booting with Linux and Windows. I will
> wait for Windows 8 later this year. In the meantime I will use Linux to
> set up btrfs partitions to store my data safely from corruption/"bit
> rot". I have not used Linux before and am slowly learning. I have
> decided to use the Linux kernal efi stub to boot with, which currently
> limits me to Ubunto Quantal Quetzal ISOs. In my research I have found
> that GPT fdisk should safely allow me to setup the partitions for GPT
> boot (ESP = EFI System Partition) and MSR (MicroSoft Reserved partition)
> ahead of time so neither install of Linux or Windows will corrupt or
> disturb the other partitions. I have tried to create both the ESP and a
> regular Windows basic partition in the correct spot using gdisk versions
> from 0.7.1 through 0.8.4 with the same result. I can setup either
> partition and verify it with "v" with no errors, but when subsequently
> doing "w" to write the partition to unallocated space (per Microsoft
> Management Console's Disk Management and gdisk) I get the following
> warning and no created partition.
> OK; writing new GUID partition table (GPT) to \\.\physicaldrive2.
> Warning! An error was reported when writing the partition table! This error
> MIGHT be harmless, but you may have trashed the disk!
> Command ( ? for help):
> This same error also happens when trying to delete a partition created
> in gdisk or one I created in Windows as a filler and disposable
> partition. No partitions are ever created or deleted.
>  From what I know gdisk should be able to create a generic data
> partition on this non-boot/data SSD. The SSD has a protective MBR, and
> is partitioned as GPT per both gdisk and Windows. Are there any
> diagnostic tests I can run to determine where the write of the new GPT
> partition is failing?

That is peculiar. Did you see an error that reads:

Unable to save backup partition table! Perhaps the 'e' option on the 
menu will resolve this problem.

If not, then that means that the first write operation succeeded, but at 
least one subsequent operation failed. To further diagnose the problem 
would require either running a version with debug messages inserted or 
running the program via a debugger. I can send you a version with debug 
messages, if you like.

If you don't want to debug this further and just want to get it working, 
you could try a Linux version of the program. The disk I/O functions for 
the two platforms are of course entirely different. I haven't seen any 
recent bug reports about errors like this under Linux, so my suspicion 
is that it'll work for you.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] Windows Vista 32-bit Warning gdisk 0.7.1 - 0.8.4

[Alan <ar...@ya...>]

I have a Windows Vista 32-bit computer with an added Corsair Force 3 SSD that came factory partitioned GPT, the microprocessor is a 64-bit Intel Core 2 E6300.  I am working on my first computer build and will transfer this SSD to it as the C: System drive by loading an OS on it in the new computer.  I want to end up dual booting with Linux and Windows.  I will wait for Windows 8 later this year.  In the meantime I will use Linux to set up btrfs partitions to store my data safely from corruption/"bit rot".  I have not used Linux before and am slowly learning.  I have decided to use the Linux kernal efi stub to boot with, which currently limits me to Ubunto Quantal Quetzal ISOs.  In my research I have found that GPT fdisk should safely allow me to setup the partitions for GPT boot (ESP = EFI System Partition) and MSR (MicroSoft Reserved partition) ahead of time so neither install of Linux or Windows will corrupt or disturb the other partitions.  I
 have tried to create both the ESP and a regular Windows basic partition in the correct spot using gdisk versions from 0.7.1 through 0.8.4 with the same result.  I can setup either partition and verify it with "v" with no errors, but when subsequently doing "w" to write the partition to unallocated space (per Microsoft Management Console's Disk Management and gdisk) I get the following warning and no created partition. OK; writing new GUID partition table (GPT) to \\.\physicaldrive2.
Warning!  An error was reported when writing the partition table!  This error 
MIGHT be harmless, but you may have trashed the disk!
 Command  ( ? for help): 
 
This same error also happens when trying to delete a partition created in gdisk or one I created in Windows as a filler and disposable partition.  No partitions are ever created or deleted.
From what I know gdisk should be able to create a generic data partition on this non-boot/data SSD.  The SSD has a protective MBR, and is partitioned as GPT per both gdisk and Windows.  Are there any diagnostic tests I can run to determine where the write of the new GPT partition is failing?
 
Alan

Re: [Gptfdisk-general] GPT fdisk output feature request

[Guillaume D. <gu...@ir...>]

Hello,

Le jeudi 22 mars 2012 à 06:29 -0700, David Liontooth a écrit :
> Thanks for a fantastic program, and to Guillaume Delacour for the 
> debian-mentors packages, which work great!

You're welcome, but please prefer using packages in the archive
(testing, backports) instead of using debian-mentors.

> 
> Cheers,
> David
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Gptfdisk-general mailing list
> Gpt...@li...
> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general

-- 
Guillaume Delacour <gu...@ir...>

Re: [Gptfdisk-general] GPT fdisk output feature request

[Rod S. <rod...@ro...>]

On 03/22/2012 09:29 AM, David Liontooth wrote:
>
> Thanks for a fantastic program, and to Guillaume Delacour for the
> debian-mentors packages, which work great!
>
> I have a very minor request. The feedback for w runs like this:

Thanks for the suggestion. I've just made this change in my local code, 
and I expect to make a new release (as GPT fdisk 0.8.3) soon.

> Command (? for help): w
>
> Final checks complete. About to write GPT data. THIS WILL OVERWRITE
> EXISTING
> PARTITIONS!!
>
> Do you want to proceed? (Y/N): Y
> OK; writing new GUID partition table (GPT).
> The operation has completed successfully.
>
> Note that it does not mention the partition name; on a crowded system,
> this can make it hard to track. I'd like to see this instead:
>
> "Final checks complete. About to write GPT data to /dev/sdf. THIS WILL
> OVERWRITE EXISTING
> PARTITIONS!!"
>
> "OK; writing new GUID partition table (GPT) to /dev/sdf."
>
> That way the user can track which drive was just partitioned.
>
> Thanks!
>
> Cheers,
> David
>
>


-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] GPT fdisk output feature request

[David L. <lio...@co...>]

Thanks for a fantastic program, and to Guillaume Delacour for the 
debian-mentors packages, which work great!

I have a very minor request. The feedback for w runs like this:

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT).
The operation has completed successfully.

Note that it does not mention the partition name; on a crowded system, 
this can make it hard to track. I'd like to see this instead:

"Final checks complete. About to write GPT data to /dev/sdf. THIS WILL 
OVERWRITE EXISTING
PARTITIONS!!"

"OK; writing new GUID partition table (GPT) to /dev/sdf."

That way the user can track which drive was just partitioned.

Thanks!

Cheers,
David

[Gptfdisk-general] EOF stdin infinite loop (partially fixed in 0.8.2)

[Guillaume D. <gu...@ir...>]

Hi,

Please find attached a patch provided by a Debian user [1] that
completely fix the EOF stdin problem that generate an infinite loop;
before that we could cause an infinite loop by sending ^D to gdisk.
I also added a test case in gdisk_test.sh in this patch.

[1]: http://bugs.debian.org/660815

-- 
Guillaume Delacour <gu...@ir...>

Re: [Gptfdisk-general] Bug#649054: cgdisk says: "Partition 1 doesn't begin on a 4149778177-sector boundary."

[Rod S. <rod...@ro...>]

On 01/03/2012 05:43 PM, Guillaume Delacour wrote:

Sorry for taking so long to reply; this message arrived when I was busy, 
so I put it off, and then forgot about it....

>> If you choose align from the menu, then hit enter without typing anything it
>> thinks you want a "4149778177-sector" alignment (and if you go back to the
>> option it thinks it's a -145320191 sector alignment).
>>
>> The strange alignment only seems to show up when you do verify - if you
>> actually add a partition it doesn't seem to use the alignment, but I didn't
>> test extensively.
>
> I didn't reproduce this with the same version on sid. I'm not sure
> you've encountered the bug with cgdisk but maybe with gdisk (as you
> describe the scenario).

I haven't been able to reproduce this bug. It would help if I knew:

- Which program was involved (gdisk, cgdisk, etc.).

- What platform is involved (i386, x86-64, etc.). (The below system
   information is confusing; it states both i386 and x86-64.)

>> I would expect hitting enter without typing anything to leave the old alignment.
>
> It actually select the default value (which is "hardcoded" at 2048 in
> gpt.h: #define DEFAULT_ALIGNMENT 2048).

Correct, at least for gdisk. (cgdisk doesn't accept an empty input; you 
MUST type something with it.)

>> And if I can add a side bug, on gdisk it properly detects the alignment (8 in
>> my case), but then when you go to change it, it says "default = 2048" which is
>> not what the old alignment was.
>
> I've Cced upstream user list, as i can't test with a real device but
> only with a test file i've generated with dd (maybe people have ideas on
> your issue).

That's not a bug; that's the design intent. Most partitioning tools use 
1 MiB alignment by default, so that's what gdisk sets uses as the input 
default, even if something else was detected when the program launched.

>> -- System Information:
>> Debian Release: 6.0.3
>>    APT prefers stable
>>    APT policy: (990, 'stable'), (500, 'oldstable'), (1, 'experimental')
>> Architecture: i386 (x86_64)
>>
>> Kernel: Linux 2.6.32 (SMP w/8 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/bash
>>
>> Versions of packages gdisk depends on:
>> ii  groff-base                1.20.1-10      GNU troff text-formatting system (
>> ii  libc6                     2.13-10        Embedded GNU C Library: Shared lib
>> ii  libgcc1                   1:4.6.1-4      GCC support library
>> ii  libicu44                  4.4.1-7        International Components for Unico
>> ii  libncurses5               5.7+20100313-5 shared libraries for terminal hand
>> ii  libpopt0                  1.16-1         lib for parsing cmdline parameters
>> ii  libstdc++6                4.6.1-4        GNU Standard C++ Library v3
>> ii  libuuid1                  2.17.2-9       Universally Unique ID library
>>
>> gdisk recommends no packages.
>>
>> gdisk suggests no packages.
>>
>> -- no debconf information
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
>
>
>
> _______________________________________________
> Gptfdisk-general mailing list
> Gpt...@li...
> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general


-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

Re: [Gptfdisk-general] Bug#649054: cgdisk says: "Partition 1 doesn't begin on a 4149778177-sector boundary."

[Guillaume D. <gu...@ir...>]

Le jeudi 17 novembre 2011 à 02:02 -0500, Ariel a écrit :
> Package: gdisk
> Version: 0.8.1-1~bpo60+1
> Severity: normal

Hello,

> 
> If you choose align from the menu, then hit enter without typing anything it
> thinks you want a "4149778177-sector" alignment (and if you go back to the
> option it thinks it's a -145320191 sector alignment).
> 
> The strange alignment only seems to show up when you do verify - if you
> actually add a partition it doesn't seem to use the alignment, but I didn't
> test extensively.

I didn't reproduce this with the same version on sid. I'm not sure
you've encountered the bug with cgdisk but maybe with gdisk (as you
describe the scenario).

> 
> I would expect hitting enter without typing anything to leave the old alignment.

It actually select the default value (which is "hardcoded" at 2048 in
gpt.h: #define DEFAULT_ALIGNMENT 2048).

> 
> And if I can add a side bug, on gdisk it properly detects the alignment (8 in
> my case), but then when you go to change it, it says "default = 2048" which is
> not what the old alignment was.

I've Cced upstream user list, as i can't test with a real device but
only with a test file i've generated with dd (maybe people have ideas on
your issue).

> 
> -- System Information:
> Debian Release: 6.0.3
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'oldstable'), (1, 'experimental')
> Architecture: i386 (x86_64)
> 
> Kernel: Linux 2.6.32 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages gdisk depends on:
> ii  groff-base                1.20.1-10      GNU troff text-formatting system (
> ii  libc6                     2.13-10        Embedded GNU C Library: Shared lib
> ii  libgcc1                   1:4.6.1-4      GCC support library
> ii  libicu44                  4.4.1-7        International Components for Unico
> ii  libncurses5               5.7+20100313-5 shared libraries for terminal hand
> ii  libpopt0                  1.16-1         lib for parsing cmdline parameters
> ii  libstdc++6                4.6.1-4        GNU Standard C++ Library v3
> ii  libuuid1                  2.17.2-9       Universally Unique ID library
> 
> gdisk recommends no packages.
> 
> gdisk suggests no packages.
> 
> -- no debconf information
> 
> 

-- 
Guillaume Delacour <gu...@ir...>

Re: [Gptfdisk-general] gdisk error

[Rod S. <rod...@ro...>]

On 12/01/2011 01:05 PM, Conrad G T Yoder wrote:
> 
> On Dec 1, 2011, at 12:02 PM, Rod Smith wrote:
> 
>> On 11/30/2011 10:42 PM, Conrad G T Yoder wrote:
>>> I have a MacBook Pro, running OS X 10.6 with, of course, a GPT Disk.
>>> The OS X Disk Utility reports no problems with the drive, but when I
>>> try to repartition the drive, Disk Utility does not allow me to
>>> resize partitions. When I try to use the OS X command-line tool, I
>>> get the error, "Error: -9939: The partition cannot be resized."
>>>
>>> So I downloaded GPT fdisk and ran gdisk. Upon starting it, I get the
>>> messages:
>>>
>>>
>>>
>>> GPT fdisk (gdisk) version 0.8.1
>>>
>>> Type device filename, or press <Enter> to exit: /dev/disk0
>>> Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
>>> on the recovery & transformation menu to examine the two tables.
>>>
>>> Warning! One or more CRCs don't match. You should repair the disk!
>>>
>>> Partition table scan:
>>>  MBR: hybrid
>>>  BSD: not present
>>>  APM: not present
>>>  GPT: damaged
>>>
>>> Found valid MBR and corrupt GPT. Which do you want to use? (Using the
>>> GPT MAY permit recovery of GPT data.)
>>> 1 - MBR
>>> 2 - GPT
>>> 3 - Create blank GPT
>>>
>>> Your answer: 
>>>
>>>
>>>
>>> And I'm not sure what the next best step here is. Any suggestions?
>>> Let me know if you would like more info.
>>
>> At this point, you should definitely select option 2 (GPT). After this
>> point, though, you may encounter problems because there's been damage to
>> one of the partition tables. You should probably check both partition
>> tables by using the 'c' and 'e' options on the recovery & transformation
>> menu, as the program suggests, to see which one is correct. (Use 'p'
>> after loading each table to view it, and use your own knowledge of what
>> the partition table SHOULD look like to determine which is correct.)
>>
>> For more on recovering GPT data, see my Web page on the topic:
>>
>> http://www.rodsbooks.com/gdisk/repairing.html
>>
>> It's also conceivable you'll need to re-create the hybrid MBR; but you
>> shouldn't worry about that just yet. You'll know you'll need to do that
>> if a 'v' operation reports a mismatch between the GPT and MBR data or if
>> you can't boot Windows after you make your repairs to the GPT data.
>>
>> As a side comment, it's possible that this damage was caused by Windows
>> disk encryption tools or a GPT-unaware boot loader. If you've used such
>> tools, you should uninstall them ASAP. I recommend first repairing the
>> disk, then backing up the GPT data (using 'b' on gdisk's main menu),
>> then removing the offending software, then checking the disk again for
>> damage (since removing the software could cause more damage to the disk).
>>
>> If you need more advice, feel free to send another e-mail to the list,
>> or to me directly.
> 
> Rod,
> 
> Thanks much for the info.  I did the steps (r, p, c, p, e, p, q) and the current partition table is "correct" - at least more correct than the backup (backup has none of my data partitions and only lists the "EFI System Partition" partition).  But of course the current partition map still has problems.  Here is the output of the 'v' command:
> 
> Command (? for help): v
> 
> Caution: The CRC for the backup partition table is invalid. This table may
> be corrupt. This program will automatically create a new backup partition
> table when you save your partitions.
> 
> Problem: main header's disk GUID (9A22DB81-C298-4CFD-A064-ADAAE4D5C859) doesn't
> match the backup GPT header's disk GUID (A64224D6-475A-4A35-BC7B-3F0184268F0B)
> You should use the 'b' or 'd' option on the recovery & transformation menu to
> select one or the other header.
> 
> Identified 2 problems!
> 
> Command (? for help): 

Chances are you'll be OK by selecting the main header and table and then
using 'w' to save your changes to disk; however, there's a remote chance
that the problem is even worse than it seems. You might want to perform
a backup of your important data from the disk, on the off chance that
using gdisk to re-write good data will cause more problems.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

Re: [Gptfdisk-general] gdisk error

[Conrad G T Y. <cgt...@al...>]

On Dec 1, 2011, at 12:02 PM, Rod Smith wrote:

> On 11/30/2011 10:42 PM, Conrad G T Yoder wrote:
>> I have a MacBook Pro, running OS X 10.6 with, of course, a GPT Disk.
>> The OS X Disk Utility reports no problems with the drive, but when I
>> try to repartition the drive, Disk Utility does not allow me to
>> resize partitions. When I try to use the OS X command-line tool, I
>> get the error, "Error: -9939: The partition cannot be resized."
>> 
>> So I downloaded GPT fdisk and ran gdisk. Upon starting it, I get the
>> messages:
>> 
>> 
>> 
>> GPT fdisk (gdisk) version 0.8.1
>> 
>> Type device filename, or press <Enter> to exit: /dev/disk0
>> Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
>> on the recovery & transformation menu to examine the two tables.
>> 
>> Warning! One or more CRCs don't match. You should repair the disk!
>> 
>> Partition table scan:
>>  MBR: hybrid
>>  BSD: not present
>>  APM: not present
>>  GPT: damaged
>> 
>> Found valid MBR and corrupt GPT. Which do you want to use? (Using the
>> GPT MAY permit recovery of GPT data.)
>> 1 - MBR
>> 2 - GPT
>> 3 - Create blank GPT
>> 
>> Your answer: 
>> 
>> 
>> 
>> And I'm not sure what the next best step here is. Any suggestions?
>> Let me know if you would like more info.
> 
> At this point, you should definitely select option 2 (GPT). After this
> point, though, you may encounter problems because there's been damage to
> one of the partition tables. You should probably check both partition
> tables by using the 'c' and 'e' options on the recovery & transformation
> menu, as the program suggests, to see which one is correct. (Use 'p'
> after loading each table to view it, and use your own knowledge of what
> the partition table SHOULD look like to determine which is correct.)
> 
> For more on recovering GPT data, see my Web page on the topic:
> 
> http://www.rodsbooks.com/gdisk/repairing.html
> 
> It's also conceivable you'll need to re-create the hybrid MBR; but you
> shouldn't worry about that just yet. You'll know you'll need to do that
> if a 'v' operation reports a mismatch between the GPT and MBR data or if
> you can't boot Windows after you make your repairs to the GPT data.
> 
> As a side comment, it's possible that this damage was caused by Windows
> disk encryption tools or a GPT-unaware boot loader. If you've used such
> tools, you should uninstall them ASAP. I recommend first repairing the
> disk, then backing up the GPT data (using 'b' on gdisk's main menu),
> then removing the offending software, then checking the disk again for
> damage (since removing the software could cause more damage to the disk).
> 
> If you need more advice, feel free to send another e-mail to the list,
> or to me directly.

Rod,

Thanks much for the info.  I did the steps (r, p, c, p, e, p, q) and the current partition table is "correct" - at least more correct than the backup (backup has none of my data partitions and only lists the "EFI System Partition" partition).  But of course the current partition map still has problems.  Here is the output of the 'v' command:

Command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: main header's disk GUID (9A22DB81-C298-4CFD-A064-ADAAE4D5C859) doesn't
match the backup GPT header's disk GUID (A64224D6-475A-4A35-BC7B-3F0184268F0B)
You should use the 'b' or 'd' option on the recovery & transformation menu to
select one or the other header.

Identified 2 problems!

Command (? for help): 


Let me know if any other info will help - thanks again!

-Conrad

Re: [Gptfdisk-general] gdisk error

[Rod S. <rod...@ro...>]

On 11/30/2011 10:42 PM, Conrad G T Yoder wrote:
> I have a MacBook Pro, running OS X 10.6 with, of course, a GPT Disk.
> The OS X Disk Utility reports no problems with the drive, but when I
> try to repartition the drive, Disk Utility does not allow me to
> resize partitions. When I try to use the OS X command-line tool, I
> get the error, "Error: -9939: The partition cannot be resized."
> 
> So I downloaded GPT fdisk and ran gdisk. Upon starting it, I get the
> messages:
> 
> 
> 
> GPT fdisk (gdisk) version 0.8.1
> 
> Type device filename, or press <Enter> to exit: /dev/disk0
> Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
> on the recovery & transformation menu to examine the two tables.
> 
> Warning! One or more CRCs don't match. You should repair the disk!
> 
> Partition table scan:
>   MBR: hybrid
>   BSD: not present
>   APM: not present
>   GPT: damaged
> 
> Found valid MBR and corrupt GPT. Which do you want to use? (Using the
> GPT MAY permit recovery of GPT data.)
>  1 - MBR
>  2 - GPT
>  3 - Create blank GPT
> 
> Your answer: 
> 
> 
> 
> And I'm not sure what the next best step here is. Any suggestions?
> Let me know if you would like more info.

At this point, you should definitely select option 2 (GPT). After this
point, though, you may encounter problems because there's been damage to
one of the partition tables. You should probably check both partition
tables by using the 'c' and 'e' options on the recovery & transformation
menu, as the program suggests, to see which one is correct. (Use 'p'
after loading each table to view it, and use your own knowledge of what
the partition table SHOULD look like to determine which is correct.)

For more on recovering GPT data, see my Web page on the topic:

http://www.rodsbooks.com/gdisk/repairing.html

It's also conceivable you'll need to re-create the hybrid MBR; but you
shouldn't worry about that just yet. You'll know you'll need to do that
if a 'v' operation reports a mismatch between the GPT and MBR data or if
you can't boot Windows after you make your repairs to the GPT data.

As a side comment, it's possible that this damage was caused by Windows
disk encryption tools or a GPT-unaware boot loader. If you've used such
tools, you should uninstall them ASAP. I recommend first repairing the
disk, then backing up the GPT data (using 'b' on gdisk's main menu),
then removing the offending software, then checking the disk again for
damage (since removing the software could cause more damage to the disk).

If you need more advice, feel free to send another e-mail to the list,
or to me directly.

Good luck!

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] gdisk error

[Conrad G T Y. <cgt...@al...>]

I have a MacBook Pro, running OS X 10.6 with, of course, a GPT Disk. The OS X Disk Utility reports no problems with the drive, but when I try to repartition the drive, Disk Utility does not allow me to resize partitions. When I try to use the OS X command-line tool, I get the error, "Error: -9939: The partition cannot be resized." 

So I downloaded GPT fdisk and ran gdisk. Upon starting it, I get the messages: 



GPT fdisk (gdisk) version 0.8.1

Type device filename, or press <Enter> to exit: /dev/disk0
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: damaged

Found valid MBR and corrupt GPT. Which do you want to use? (Using the
GPT MAY permit recovery of GPT data.)
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 



And I'm not sure what the next best step here is. Any suggestions? Let me know if you would like more info.

-Conrad

-- 
DO NOT FOLD, SPINDLE, MUTILATE

[Gptfdisk-general] Debian package available on stable (through backports)

[Guillaume D. <gu...@ir...>]

Hello,

If you don't know yet, gdisk has been rebuilt and uploaded to the Debian
backport repository [1]. As i didn't have found a sponsor a few month
ago for the current stable release, the package wasn't visible...it's
not the case for now; even if backports is not enabled by default, but
could be used if users wants.

I also saw that the project download page [2] doesn't mention the
existence of Debian (and Ubuntu) official packages, please consider
pointing users to them [3] instead of OBS generated packages for these
plateforms.

Thanks.

[1]: http://packages.qa.debian.org/g/gdisk.html
[2]: http://www.rodsbooks.com/gdisk/download.html
[3]: http://packages.debian.org/gdisk
     http://packages.ubuntu.com/gdisk

-- 
Guillaume Delacour <gu...@ir...>

[Gptfdisk-general] Hyphen as minus in the manpage

[Guillaume D. <gu...@ir...>]

Hello,

Please find attached a patch (from the Debian package) that escape '-'
in the gdisk manpage.

-- 
Guillaume Delacour <gu...@ir...>

Re: [Gptfdisk-general] Bug#637572: gdisk: fails to write protective MBR

[Arno S. <ael...@ho...>]

Hi Rod, Guillaume,

> Arno Schuring (ael...@ho... on 2011-08-16 00:55 +0200):
>
[..]
> Upgrading to 4.6 on this box is not possible (it requires me to
> upgrade libc6), I'll pursue this once I have a working cross-compiler
> or chroot. Pointers welcome :)

Version 0.8.1 no longer exhibits the behaviour. Whether that is due to
a change in gdisk or a newer compiler I can't say. But at the least the
problem is solved.


Regards,
Arno

Re: [Gptfdisk-general] Functionalities tests for gdisk binaries

[Rod S. <rod...@ro...>]

On 07/20/2011 06:48 PM, Guillaume Delacour wrote:
> Hi,
>
> As Debian maintainer of the gdisk package, i would like to automatically
> test gdisk binaries after build time to ensure that they works correctly
> before uploading it in the archive.
>
> I've start to work on a shell script that test the binaries by doing
> several operations on a dd generated file (attached).
>
> I think it would be interesting to have a complete test procedure for
> gdisk.
>
> Other ideas (such as convert MBR to GPT, restore, see TODO, etc...) or
> criticism welcome.

Sorry to take so long to respond; I've just been occupied with more 
pressing matters.

Your test script certainly looks useful, so I'd like to include it in 
the next GPT fdisk package, which I expect to release this weekend. 
FWIW, this version will include a new cgdisk program, modeled after 
cfdisk. I'm not sure if a curses-based program could be tested 
automatically, though. Fortunately, all the core functionality comes 
from the same code, so if gdisk and sgdisk pass, I'd expect cgdisk to 
pass, too, unless there's a user interface bug.

Certainly the number of things that could be tested is huge, 
particularly if recovery from error conditions (damaged GPT headers, 
etc.) is included. For such conditions, I'd prioritize the program's 
actions when the protective MBR is replaced by a conventional MBR (as 
might happen if the disk were repartioned with fdisk) or if the 
protective MBR and entire first set of GPT structures were overwritten 
(as might happen in an accident with dd).

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com