Description of problem: I'm trying to set up dual boot on a system and Fedora 19 insists on reformatting my /boot partition. The checkbox for Reformat is enabled and it's grayed-out so I cannot uncheck the box. How do I preserve /boot so it doesn't erase the kernel from my other Linux install? Version-Release number of selected component (if applicable): Fedora 19 Alpha RC1 anaconda 19.16-1 How reproducible: every time Steps to Reproduce: 1. boot Fedora 19 Alpha RC1 installation DVD 2. go to Manual Partitioning 3. try to set up /boot/efi and /boot on /dev/sda1 and /dev/sda2 Actual results: anaconda checkbox for Reformat is enabled and grayed out Expected results: I can uncheck the box and preserve /boot from my other Linux install Additional info:
In fact, Anaconda in F19 Alpha doesn't show me any of my existing partitions! The left side of the partition screen is blank, and Anaconda says all of my disk space is free and available. Why doesn't it detect my existing RHEL install?
Created attachment 734378 [details] screenshot showing Reformat permanently checked
Created attachment 734379 [details] anaconda.log
Created attachment 734380 [details] storage.log
Here's a manual dump of my current partitions from the ALT-F2 terminal. My RHEL install is on /dev/sda. The /dev/sdb disk is completely blank. [anaconda root@localhost tmp]# parted /dev/sda print Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. OK/Cancel? ok Model: ATA WDC WD10EALX-759 (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 211MB 210MB fat16 EFI System Partition boot 2 211MB 735MB 524MB xfs 3 735MB 1000GB 999GB lvm [anaconda root@localhost tmp]# parted /dev/sdb print Error: /dev/sdb: unrecognised disk label Model: ATA WDC WD10EALX-759 (scsi) Disk /dev/sdb: 1000GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: [anaconda root@localhost tmp]# pvscan PV /dev/sda3 VG rhel_gecko lvm2 [930.82 GiB / 0 free] Total: 1 [930.82 GiB] / in use: 1 [930.82 GiB] / in no VG: 0 [0 ] [anaconda root@localhost tmp]# vgscan Reading all physical volumes. This may take a while... Found volume group "rhel_gecko" using metadata type lvm2 [anaconda root@localhost tmp]# lvscan inactive '/dev/rhel_gecko/swap' [7.78 GiB] inherit inactive '/dev/rhel_gecko/home' [873.04 GiB] inherit inactive '/dev/rhel_gecko/root' [50.00 GiB] inherit
(In reply to comment #5) > [anaconda root@localhost tmp]# parted /dev/sda print > Error: The backup GPT table is corrupt, but the primary appears OK, so that > will be used. I wonder if this is related to bug 950145 ? In that bug, pvcreate fails because of the above problem with the backup GPT.
Parted rejected your disklabel on sda. If parted says the disk isn't partitioned we aren't going to show any partitions on it.
This is weird: I used gdisk to fix the backup GPT, then used parted to print the partitions and confirmed that the "Error: The backup GPT table is corrupt" message is gone. [anaconda root@dhcp-176-117 ~]# gdisk /dev/sda GPT fdisk (gdisk) version 0.8.6 Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header. Partition table scan: MBR: protective BSD: not present APM: not present GPT: damaged **************************************************************************** Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended. **************************************************************************** Command (? for help): r Recovery/transformation command (? for help): d Recovery/transformation 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) to /dev/sda. The operation has completed successfully. [anaconda root@dhcp-176-117 ~]# parted -s /dev/sda print Model: ATA WDC WD10EALX-759 (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 211MB 210MB fat16 EFI System Partition boot 2 211MB 735MB 524MB xfs 3 735MB 1000GB 999GB lvm Then I rebooted and started F19 Anaconda again, and it tells me that my backup GPT is corrupt again!
Created attachment 734382 [details] screenshot after fixing backup GPT with gdisk and rescanning disks Ok, I tried fixing the backup GPT again with gdisk, but this time I didn't reboot. Instead, I told Anaconda to rescan the disks (the little circle with an arrow button on the manual partition screen) and now it found my existing RHEL install! Attached is a fresh screenshot of the manual partitioning screen.
Created attachment 734383 [details] storage.log after fixing backup GPT with gdisk This is the storage.log after I fixed the backup GPT with gdisk, then told Anaconda to re-scan the storage.
F19 finished installing, and the backup GPT is corrupt again after rebooting into the full OS. [root@gecko ~]# parted -s /dev/sda print Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. Model: ATA WDC WD10EALX-759 (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 211MB 210MB fat16 EFI System Partition boot 2 211MB 735MB 524MB xfs 3 735MB 1000GB 999GB lvm [root@gecko ~]# parted -s /dev/sdb print Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. Model: ATA WDC WD10EALX-759 (scsi) Disk /dev/sdb: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 262GB 262GB My partitions are: /dev/sda1 /boot/efi /dev/sda2 /boot /dev/sda3 LVM for RHEL /dev/sdb1 btrfs for F19
I'm attaching a copy of the main and backup GPT labels from both of my disks. dd if=/dev/sda of=/tmp/sda-main-gpt.bin bs=512 count=34 dd if=/dev/sda of=/tmp/sda-backup-gpt.bin bs=512 count=34 skip=$(( $(cat /sys/block/sda/size) - 34 )) dd if=/dev/sdb of=/tmp/sdb-main-gpt.bin bs=512 count=34 dd if=/dev/sdb of=/tmp/sdb-backup-gpt.bin bs=512 count=34 skip=$(( $(cat /sys/block/sdb/size) - 34 ))
Created attachment 734429 [details] sda main GPT
Created attachment 734430 [details] sda backup GPT
Created attachment 734431 [details] sdb main GPT
Created attachment 734432 [details] sdb backup GPT
I compared the main and backup GPTs from sda and I do see some small differences in the GPT header. The partition tables are identical, though. We need to strip the MBR block from the main GPT, i.e., take blocks 2-34 dd if=sda-main-gpt.bin of=sda-main-gpt-nombr.bin \ bs=512 count=33 skip=1 Then take the last block of the backup, the EFI header, and move it to the beginning of the backup by appending the partition table. Also, skip the first block because it's actually a data-block (not part of the backup GPT); i.e. 34 blocks for the main GPT but only 33 blocks for the backup GPT. I grabbed one block too many. dd if=sda-backup-gpt.bin of=sda-backup-gpt-rearranged.bin \ bs=512 count=1 skip=33 dd if=sda-backup-gpt.bin of=sda-backup-gpt-rearranged.bin \ oflag=append conv=notrunc \ bs=512 count=32 skip=1 Finaly hex-dump and diff the results: xxd sda-main-gpt-nombr.bin > sda-main-gpt-nombr.hex xxd sda-backup-gpt-rearranged.bin > sda-backup-gpt-rearranged.hex diff -u sda-main-gpt-nombr.hex sda-backup-gpt-rearranged.hex --- sda-main-gpt-nombr.hex 2013-04-12 08:45:58.915695052 -0500 +++ sda-backup-gpt-rearranged.hex 2013-04-12 08:45:58.931695313 -0500 @@ -1,9 +1,9 @@ 0000000: 4546 4920 5041 5254 0000 0100 5c00 0000 EFI PART....\... -0000010: b43b 64f2 0000 0000 0100 0000 0000 0000 .;d............. -0000020: af6d 7074 0000 0000 2200 0000 0000 0000 .mpt...."....... +0000010: 1e49 6b02 0000 0000 af6d 7074 0000 0000 .Ik......mpt.... +0000020: 0100 0000 0000 0000 2200 0000 0000 0000 ........"....... 0000030: 8e6d 7074 0000 0000 8442 0067 c7e1 ed48 .mpt.....B.g...H -0000040: 9680 afb5 3e95 faa8 0200 0000 0000 0000 ....>........... -0000050: 8000 0000 8000 0000 1e49 6b02 0000 0000 .........Ik..... +0000040: 9680 afb5 3e95 faa8 8f6d 7074 0000 0000 ....>....mpt.... +0000050: 8000 0000 8000 0000 0000 0000 0000 0000 ................ 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
And similar results for my sdb disk: --- sdb-main-gpt-nombr.hex 2013-04-12 08:55:07.480633271 -0500 +++ sdb-backup-gpt-rearranged.hex 2013-04-12 08:55:07.489633418 -0500 @@ -1,9 +1,9 @@ 0000000: 4546 4920 5041 5254 0000 0100 5c00 0000 EFI PART....\... -0000010: a227 e2bc 0000 0000 0100 0000 0000 0000 .'.............. -0000020: af6d 7074 0000 0000 2200 0000 0000 0000 .mpt...."....... +0000010: f1fa 1176 0000 0000 af6d 7074 0000 0000 ...v.....mpt.... +0000020: 0100 0000 0000 0000 2200 0000 0000 0000 ........"....... 0000030: 8e6d 7074 0000 0000 a97d 8497 f59c 8141 .mpt.....}.....A -0000040: 81be e44d e1a0 06f2 0200 0000 0000 0000 ...M............ -0000050: 8000 0000 8000 0000 f1fa 1176 0000 0000 ...........v.... +0000040: 81be e44d e1a0 06f2 8f6d 7074 0000 0000 ...M.....mpt.... +0000050: 8000 0000 8000 0000 0000 0000 0000 0000 ................ 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
Created attachment 734812 [details] utility to print GPT header I wrote a small utility to dump the GPT header in a somewhat human readable format, see attached. Running it against the modified GPT dumps (no MBR in main, rearranged sections in backup): $ ./gpt-header-dump sda-main-gpt-nombr.bin Signature: 0x20494645 (EFI PART) Revision: 0x10000 Header size: 92 bytes Header CRC32: 0xF2643BB4 This header LBA: 0x1 Alt. header LBA: 0x74706DAF 1st Usable LBA: 0x22 Last usable LBA: 0x74706D8E Part. Entries LBA: 0x2 Num Part. Entries: 128 Size of Part. entry: 128 Part. Entry CRC32: 0x26B491E $ ./gpt-header-dump sda-backup-gpt-rearranged.bin Signature: 0x20494645 (EFI PART) Revision: 0x10000 Header size: 92 bytes Header CRC32: 0x26B491E This header LBA: 0x74706DAF Alt. header LBA: 0x1 1st Usable LBA: 0x22 Last usable LBA: 0x74706D8E Part. Entries LBA: 0x74706D8F Num Part. Entries: 128 Size of Part. entry: 128 Part. Entry CRC32: 0x0 Everything seems to check out except for the "Part. Entry CRC32" for the backup GPT. Why is it 0?
Created attachment 734814 [details] utility to print GPT header Oops, attaching the real gpt-header-dump.c file this time (not the Makefile)
Created attachment 734832 [details] utility to print GPT header Argh, I forgot a field, the Disk GUID. Trying one last time... $ ./gpt-header-dump sda-main-gpt-nombr.bin Signature: 0x20494645 (EFI PART) Revision: 0x10000 Header size: 92 bytes Header CRC32: 0xF2643BB4 This header LBA: 0x1 Alt. header LBA: 0x74706DAF 1st Usable LBA: 0x22 Last usable LBA: 0x74706D8E Disk GUID: 84420067-c7e1-ed48-9680-afb53e95faa8 Part. Entries LBA: 0x2 Num Part. Entries: 128 Size of Part. entry: 128 Part. Entry CRC32: 0x26B491E $ ./gpt-header-dump sda-backup-gpt-rearranged.bin Signature: 0x20494645 (EFI PART) Revision: 0x10000 Header size: 92 bytes Header CRC32: 0x26B491E This header LBA: 0x74706DAF Alt. header LBA: 0x1 1st Usable LBA: 0x22 Last usable LBA: 0x74706D8E Disk GUID: 84420067-c7e1-ed48-9680-afb53e95faa8 Part. Entries LBA: 0x74706D8F Num Part. Entries: 128 Size of Part. entry: 128 Part. Entry CRC32: 0x0 Again, everything looks ok except for the partition entry crc32 on the backup.
It looks like I have to do some byte-swapping for different endian-ness in the fields, e.g., the first, second, and third fields of the Disk GUID are byte-swapped from what gdisk reports: gdisk: 67004284-E1C7-48ED-9680-AFB53E95FAA8 gpt-header-dump: 84420067-c7e1-ed48-9680-afb53e95faa8 But the point is, the fields are consistent between the main and backup, with the exception of the partition entry crc32 in the backup.
@Jeff Bastian Are you using the RAID or AHCI mode for the disk controller? I experienced a backup gpt corruption on every boot in the past which was solved by switching back to AHCI. In this case the corruption does happen with anaconda or by its own?
Reartes, that fixed it! Thank you! My system was set to RAID in the UEFI settings. I switched it to AHCI and now the backup GPT is no longer corrupt after each reboot. (I then switched it back to RAID and it was corrupt again.) This is very interesting. The corruption was happening on every reboot so it was independent of anaconda.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.