gptfdisk-general — General discussions of GPT fdisk

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

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

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

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 (ael...@ho... 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 it
>> works fine, so it's not disk-related. I guess it's either an
>> architecture-specific bug or a compiler gotcha.
>
> I've been unable to reproduce this. The local compile on the arm box
> produces a correctly functioning executable, so I've not yet been
> playing with compile-time options and such.
>
> My (very basic) approach has been:
> # apt-get build-dep gdisk/testing
> $ apt-get source gdisk/testing
> $ cd gdisk-0.7.2
> $ dh_auto_build
> # ./gdisk /dev/sda
>
> This is with gcc version 4.4.5 (Debian 4.4.5-8) on an up-to-date
> Squeeze install. Gdisk is from testing, and from the QA logs I can see
> that the package is built with gcc 4.6.
>
> 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 :)

This certainly sounds like an issue that's specific to GCC 4.6. (I'm not 
implying that GCC 4.6 is buggy, necessarily; it's more likely that it's 
just doing something subtly different from other versions of GCC and my 
code is assuming a different behavior.) I don't currently have GCC 4.6 
installed on any of my computers, but I'll get it up and running on one 
of them. With any luck that'll enable me to reproduce and fix the bug.

In the meantime, the workaround for you is obvious: Use your 
locally-compiled (with GCC 4.4.5) version of gdisk!

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

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

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

(replying to myself because I seem to have lost your message, apologies
Rob)

Arno Schuring (ael...@ho... 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 it
> works fine, so it's not disk-related. I guess it's either an
> architecture-specific bug or a compiler gotcha.

I've been unable to reproduce this. The local compile on the arm box
produces a correctly functioning executable, so I've not yet been
playing with compile-time options and such.

My (very basic) approach has been:
# apt-get build-dep gdisk/testing
$ apt-get source gdisk/testing
$ cd gdisk-0.7.2
$ dh_auto_build
# ./gdisk /dev/sda

This is with gcc version 4.4.5 (Debian 4.4.5-8) on an up-to-date
Squeeze install. Gdisk is from testing, and from the QA logs I can see
that the package is built with gcc 4.6.

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 :)


To be continued,
Arno

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

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

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
rod...@ro...
http://www.rodsbooks.com

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

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

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.

Many thanks,
Arno

[Gptfdisk-general] Protective MBR problem

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

Hello,

A Debian user reported a problem with protective MBR:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637572

Version 0.6.14 appears to work as expected.

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

[Gptfdisk-general] Functionalities tests for gdisk binaries

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

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.

Thanks in advance.

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

[Gptfdisk-general] gdisk in gcc 4.6

[KESHAV P.R. <sko...@gm...>]

Hi,
     There seems to be small warnings with gptfdisk compilation (from
git - 0.7.1 tag) with gcc 4.6 in Archlinux x86_64. Below is the output

rm -f core *.o *~ gdisk sgdisk fixparts
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o crc32.o crc32.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o support.o support.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o guid.o guid.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o gptpart.o gptpart.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o mbrpart.o mbrpart.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o basicmbr.o basicmbr.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o mbr.o mbr.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o gpt.o gpt.cc
gpt.cc: In member function ‘int GPTData::CheckHeaderCRC(GPTHeader*)’:
gpt.cc:403:29: warning: variable ‘hSize’ set but not used
[-Wunused-but-set-variable]
gpt.cc: In member function ‘int GPTData::SaveGPTData(int)’:
gpt.cc:930:19: warning: variable ‘littleEndian’ set but not used
[-Wunused-but-set-variable]
gpt.cc: In member function ‘int GPTData::LoadGPTBackup(const string&)’:
gpt.cc:1134:13: warning: variable ‘sizeOfEntries’ set but not used
[-Wunused-but-set-variable]
gpt.cc:1135:8: warning: variable ‘littleEndian’ set but not used
[-Wunused-but-set-variable]
gpt.cc: In member function ‘int GPTData::Align(uint64_t*)’:
gpt.cc:1854:41: warning: variable ‘original’ set but not used
[-Wunused-but-set-variable]
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o bsd.o bsd.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o parttypes.o parttypes.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o attributes.o attributes.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o diskio.o diskio.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o diskio-unix.o diskio-unix.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o gdisk.o gdisk.cc
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o gpttext.o gpttext.cc
g++ crc32.o support.o guid.o gptpart.o mbrpart.o basicmbr.o mbr.o
gpt.o bsd.o parttypes.o attributes.o diskio.o diskio-unix.o gdisk.o
gpttext.o -Wl,--hash-style=gnu -Wl,--as-needed  -licuio -luuid -o
gdisk
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o sgdisk.o sgdisk.cc
g++ crc32.o support.o guid.o gptpart.o mbrpart.o basicmbr.o mbr.o
gpt.o bsd.o parttypes.o attributes.o diskio.o diskio-unix.o sgdisk.o
-Wl,--hash-style=gnu -Wl,--as-needed  -licuio -luuid -lpopt -o sgdisk
g++ -march=x86-64 -mtune=native -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64
  -c -o fixparts.o fixparts.cc
g++ support.o diskio.o diskio-unix.o basicmbr.o mbrpart.o fixparts.o
-Wl,--hash-style=gnu -Wl,--as-needed  -o fixparts


GCC version

keshav_pr@keshav-laptop% x86_64-unknown-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.6.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++
--enable-shared --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --enable-gnu-unique-object
--enable-linker-build-id --with-ppl --enable-cloog-backend=isl
--enable-lto --enable-gold --enable-ld=default --enable-plugin
--with-plugin-ld=ld.gold --enable-multilib --disable-libstdcxx-pch
--enable-checking=release
Thread model: posix
gcc version 4.6.0 (GCC)


I will try compiling the same in mingw-w64 gcc 4.6 for Windows 7 x64
and come back to you. Thanks in advance.

Regards.

Keshav

Re: [Gptfdisk-general] gdisk UTF16 check

[KESHAV P.R. <sko...@gm...>]

On Sat, Mar 19, 2011 at 02:49, Rod Smith <rod...@ro...> wrote:
> On 03/18/2011 02:24 PM, KESHAV P.R. wrote:
>>
>> On Thu, Mar 17, 2011 at 23:56, Rod Smith<rod...@ro...>  wrote:
>>>
>>> I've just posted a new version to the git repositories
>>> on SourceForge. This version (0.7.1-pre2) adds proper UTF-16LE support
>>> for
>>> the partition name fields.
>>
>> I tested my gpt disk by changing name of 1 partition with 'செய்திகள்'
>> (without quotes) (tamil word for News). It looks weird in my terminal
>> though (locale en_US.UTF-8 with us keymap). Tamil uses dravidian
>> script.
>
> I tried the cut-and-paste method using the word from your e-mail and got
> similar results; however, long story short, I found that if I changed my
> terminal's font from Monospace to almost anything else, the word suddenly
> displayed correctly. Thus, I think it's a font issue with Monospace, or
> perhaps some issue in the terminal program (I'm using Xfce's) that's
> preventing it from working until the font is changed.
>

Changing fonts does not solve the issue of viewing the text prfoperly
in terminal. But copying the text from terminal to firefox showed the
proper text so i guess internally gdisk stores the text properly. So I
also think its a font/locale issue.

> Results were similar with two of the GPT backup files you provided, but I
> had problems with the Rupee symbol. Maybe that's a locale issue...?
>
>> Sorry I couldn't test it in non-US locales or keyboard as I have never
>> used any other language apart from english in computers itself.
>
> I may just have to release it without much more testing.
>
>> I don't know how many of the european languages use non-roman
>> letters but i can assure you plenty of asian languages have their own
>> scripts.
>
> Many of them have at least a few characters with umlauts or the like. Greek,
> of course, has its own alphabet. I've been using Cyrillic for testing, since
> I took a semester of Russian in college and so can at least understand the
> characters.
>
>> I think it is best for you to try it yourself as i did the same thing
>> you did - copy-paste from websites. Anyway i will test new versions as
>> an when you update git (i personally do not follow your release
>> versions in this regard). For archlinux, use this package
>> http://aur.archlinux.org/packages.php?ID=39338 .
>
> I appreciate your (and others') efforts to distribute GPT fdisk in official
> distributions' package systems, but I'd appreciate it if you NOT distribute
> the git version in this way. I occasionally upload code to git that's not
> been well tested, or even that has known bugs, just so that others can take
> a look at it (as for example with the Unicode support). When I make a full
> regular release, I'm more careful about squashing all the known bugs,
> updating the version string, removing debugging output, etc. In other words,
> the git version should be considered an "alpha test" for the next final
> release. (FWIW, the current git version has two known bugs in the Unicode
> support: You can't create an empty partition name or a partition name with
> more than one consecutive space in it. These are minor bugs, and I may be
> forced to leave one or both bugs in place, although I have ideas about how
> to work around them both.) If you must distribute the git version, please at
> least clearly label it with a word like "alpha", "testing", or "prerelease,"
> and make the regular version available, too. Thanks.

Archlinux has 2 kinds of repos, one being the official repos
containing binary packages and another being AUR containing user
submitted BUILD SCRIPTS alone (in this case PKGBUILD - similar to rpm
spec file). Since AUR consists of user submitted content, it is
considered 'unsupported' and it is the user's job to compile the
package using the provided build script. All info about AUR at
https://wiki.archlinux.org/index.php/AUR .

In this case the stable gdisk is maintained by archlinux devs in the
official repos while the gptfdisk-git package in AUR is maintained by
me (a user). The naming of the AUR package tells the user that it
compiles from git checkout and not from release tarballs. Some of the
notable VCS packages in AUR are util-linux-git
http://aur.archlinux.org/packages.php?ID=45540 ,
grub2-bios-bzr http://aur.archlinux.org/packages.php?ID=41055 ,
kernel26-git http://aur.archlinux.org/packages.php?ID=25304 (Linux
Kernel package compiled directly from git checkout - how stable is
that?). Anyway I created that package to help users using
bleeding-edge packages in their system. Thanks for your help and gdisk
documentation.

Regards.

Keshav

PS: Please reply to gpt...@li... .

[Gptfdisk-general] gdisk UTF16 check

[KESHAV P.R. <sko...@gm...>]

On Thu, Mar 17, 2011 at 23:56, Rod Smith <rod...@ro...> wrote:
>
> I've just posted a new version to the git repositories
> on SourceForge. This version (0.7.1-pre2) adds proper UTF-16LE support for
> the partition name fields. Previous versions have used a "quick-and-dirty"
> method of encoding ASCII characters in the name field, which I originally
> thought worked only for plain ASCII. I realize now that previous versions
> have allowed at least some non-ASCII characters in the partition names, but
> that used local encodings, not UTF-16LE, which is what the GPT
> specifications call for.
>
> Anyhow, I've tested this support as well as I can, but as an American with
> nothing but US keyboards, I'm limited to cutting-and-pasting text from Web
> pages and the like. If you could download that and check it out, I'd
> appreciate it. In theory, you should be able to create partition names in
> whatever non-Roman alphabets you like, although there may be restrictions
> based on your locale. If you see any weird behaviors, please tell me, and
> perhaps include a GPT backup for me to experiment with. Note that non-ASCII
> characters entered with the old version will display improperly with the new
> one, and vice-versa. There's nothing to be done about that, I'm afraid; the
> old version was buggy on this score (and this bug was noted in the man
> pages).
>
> Note that GNU Parted gets this wrong, too. I haven't checked its source
> code, but I suspect they used the same "quick-and-dirty" method of
> ASCII-to-UTF16LE encoding that I originally used. Apple's diskutil shows the
> correct partition names under OS X. I'm not sure about Windows utilities.
>
> Note that you'll need the ICU library (http://site.icu-project.org) and its
> development headers to compile the new version. Most Linux distributions
> install the library by default, but you may need to install the headers as a
> separate package.
>

I tested my gpt disk by changing name of 1 partition with 'செய்திகள்'
(without quotes) (tamil word for News). It looks weird in my terminal
though (locale en_US.UTF-8 with us keymap). Tamil uses dravidian
script.

Sorry I couldn't test it in non-US locales or keyboard as I have never
used any other language apart from english in computers itself. I
copied this word from Google India webpage in tamil (
http://www.google.co.in/setprefs?sig=0_uJKWo_XeWHl4zdqYpkdPoZ8TT4I=&hl=ta
) . The same can be done for hindi (devanagiri script) also (
http://www.google.co.in/setprefs?sig=0_uJKWo_XeWHl4zdqYpkdPoZ8TT4I=&hl=hi
). I don't know how many of the european languages use non-roman
letters but i can assure you plenty of asian languages have their own
scripts.

For different tamil words go to
http://news.google.co.in/nwshp?hl=ta&tab=wn and for hindi go to
http://news.google.co.in/nwshp?hl=hi&tab=wn . I have attached all the
GPT backup files , 1 for each tamil and hindi and one with Indian
Rupee symbol ( http://en.wikipedia.org/wiki/Indian_rupee_sign ).

I think it is best for you to try it yourself as i did the same thing
you did - copy-paste from websites. Anyway i will test new versions as
an when you update git (i personally do not follow your release
versions in this regard). For archlinux, use this package
http://aur.archlinux.org/packages.php?ID=39338 . Thanks in advance.

Regards.

Keshav

PS: GPT backup files sent to rod...@ro... since mailing-list
complained about crossing 40KB mail size limit.