Bug 829960 - parted on ppc64 exits with error and no error message when writing GPT (but in fact writes it anyway)
parted on ppc64 exits with error and no error message when writing GPT (but i...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard W.M. Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-07 17:41 EDT by Richard W.M. Jones
Modified: 2012-06-26 17:36 EDT (History)
1 user (show)

See Also:
Fixed In Version: parted-3.0-10.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-26 17:36:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gpt patch to fix endianness issue (1.09 KB, patch)
2012-06-08 08:22 EDT, Richard W.M. Jones
no flags Details | Diff

  None (edit)
Description Richard W.M. Jones 2012-06-07 17:41:35 EDT
Description of problem:

Note this bug occurs on ppc64 only (not on x86-64).

><rescue> dd if=/dev/zero of=/dev/vda bs=1024 count=1000
1000+0 records in
1000+0 records out
1024000 bytes (1.0 MB) copied, 0.236037 s, 4.3 MB/s
><rescue> parted -s -- /dev/vda mklabel gpt
><rescue> echo $?
1
><rescue> ls /dev/vda*
/dev/vda
><rescue> parted -s -- /dev/vda mkpart p1 128s -128s
Warning: The resulting partition is not properly aligned for best performance.
><rescue> echo $?
1
><rescue> ls /dev/vda*
/dev/vda
><rescue> blockdev --rereadpt /dev/vda
[  536.917790]  vda: vda1
><rescue> ls /dev/vda*
/dev/vda  /dev/vda1

Notice:

(1) Each command returns an error, but no error message.
(2) Changes are made to the disk despite (1).
(3) Kernel is not told to re-read the partition table.
(4) When we manually tell the kernel about the changes, it
    is able to re-read the partition table.

Not shown above: I straced the program, and it doesn't
ever call BLKRRPART.

Version-Release number of selected component (if applicable):

parted-3.0-9.fc17.ppc64

How reproducible:

100% although only on /dev/vda.  It works fine on a regular file.

Steps to Reproduce:
1. See above.
Comment 1 Brian Lane 2012-06-07 18:29:32 EDT
What does the output look like if you don't pass -s?
Comment 2 Richard W.M. Jones 2012-06-08 06:18:37 EDT
><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 ...
Comment 3 Richard W.M. Jones 2012-06-08 06:56:34 EDT
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?
Comment 4 Richard W.M. Jones 2012-06-08 07:17:46 EDT
Actually the stack trace does make sense.  It's falling off the
end of 'main' (return !status;).
Comment 5 Richard W.M. Jones 2012-06-08 07:39:04 EDT
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.
Comment 6 Richard W.M. Jones 2012-06-08 07:52:22 EDT
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)
Comment 7 Richard W.M. Jones 2012-06-08 08:22:09 EDT
Created attachment 590418 [details]
gpt patch to fix endianness issue

This is the patch I am currently testing.
Comment 8 Richard W.M. Jones 2012-06-08 08:37:01 EDT
Yes, the patch in comment 7 fixes the problem for me.
Comment 9 Fedora Update System 2012-06-08 18:44:49 EDT
parted-3.0-10.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/parted-3.0-10.fc17
Comment 10 Fedora Update System 2012-06-09 21:27:34 EDT
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).
Comment 11 Fedora Update System 2012-06-26 17:36:50 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.