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.
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.