Bug 829960

What does the output look like if you don't pass -s?

><rescue> parted -- /dev/vda mklabel gpt
Warning: The existing disk label on /dev/vda will be destroyed and all data on
this disk will be lost. Do you want to continue?
Yes/No? y                                                                 
><rescue> echo $?
1

Just getting the stack trace on exit ...

gdb --args parted -s -- /dev/vda mklabel gpt

#0  __GI_exit (status=1) at exit.c:99
#1  0x000000804b0bf5fc in generic_start_main (
    main=@0x100302e8: 0x10005020 <main>, argc=<optimized out>, 
    ubp_av=0xffffffffcb8, auxvec=0xffffffffd60, init=<optimized out>, 
    rtld_fini=<optimized out>, 
    stack_end=<error reading variable: Unhandled dwarf expression opcode 0xfa>, fini=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
    at ../csu/libc-start.c:258
#2  0x000000804b0bf7f0 in __libc_start_main (argc=<optimized out>, 
    ubp_av=<optimized out>, ubp_ev=<optimized out>, auxvec=<optimized out>, 
    rtld_fini=<optimized out>, stinfo=<optimized out>, 
    stack_on_entry=<optimized out>)
    at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:92
#3  0x0000000000000000 in ?? ()


It doesn't make sense to me.  Is it longjmp-ing?

Actually the stack trace does make sense.  It's falling off the
end of 'main' (return !status;).

Tracing through the code laboriously with gdb:

In ped_disk_commit_to_os:
        if (!ped_architecture->disk_ops->disk_commit (disk))
                goto error_close_dev;

disk_commit (really linux_disk_commit) returns 0.

In linux_disk_commit:
                if (!_disk_sync_part_table (disk))
                        return 0;

_disk_sync_part_table returns an error.

Unfortunately it looks like _disk_sync_part_table is inlined
and gdb refuses to let me set any breakpoints within this function.

Seems to be an endianness problem in this function (note
that ppc64 is big-endian).

static bool
gpt_get_max_supported_partition_count (const PedDisk *disk, int *max_n)
{
  GuidPartitionTableHeader_t *pth = NULL;
  uint8_t *pth_raw = ped_malloc (pth_get_size (disk->dev));

  if (ped_device_read (disk->dev, pth_raw, 1, GPT_HEADER_SECTORS)
      || ped_device_read (disk->dev, pth_raw,
                          disk->dev->length, GPT_HEADER_SECTORS))
    pth = pth_new_from_raw (disk->dev, pth_raw);
  free (pth_raw);

  if (pth == NULL)
    return false;

  if (!_header_is_valid (disk, pth, 1))
    {
      pth->FirstUsableLBA = 34;
      pth->SizeOfPartitionEntry
        = PED_CPU_TO_LE32 (sizeof (GuidPartitionEntry_t));
    }

  *max_n = (disk->dev->sector_size * (pth->FirstUsableLBA - 2)
            / PED_LE32_TO_CPU (pth->SizeOfPartitionEntry));

(gdb) print/x *max_n
$8 = 0xfffffff8
(gdb) print *max_n
$9 = -8
(gdb) print disk->dev->sector_size
$10 = 512
(gdb) print pth->FirstUsableLBA
$11 = 2449958197289549824
(gdb) print *pth
$12 = {Signature = 4991757640121012820, Revision = 256, 
  HeaderSize = 1543503872, HeaderCRC32 = 4229723108, Reserved1 = 0, 
  MyLBA = 72057594037927936, AlternateLBA = 18446531872260358144, 
  FirstUsableLBA = 2449958197289549824, LastUsableLBA = 16068631269008736256, 
  DiskGUID = {time_low = 848090160, time_mid = 8231, 
    time_hi_and_version = 30530, clock_seq_hi_and_reserved = 128 '\200', 
    clock_seq_low = 112 'p', node = "B\376\214{\333 "}, 
  PartitionEntryLBA = 144115188075855872, 
  NumberOfPartitionEntries = 2147483648, SizeOfPartitionEntry = 2147483648, 
  PartitionEntryArrayCRC32 = 2261931179, Reserved2 = 0x10047000 ""}
(gdb) print/x pth->FirstUsableLBA
$13 = 0x2200000000000000
(gdb)

Created attachment 590418 [details]
gpt patch to fix endianness issue

This is the patch I am currently testing.

Yes, the patch in comment 7 fixes the problem for me.

parted-3.0-10.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/parted-3.0-10.fc17

Package parted-3.0-10.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing parted-3.0-10.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9172/parted-3.0-10.fc17
then log in and leave karma (feedback).

parted-3.0-10.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.