The bottom line question is, would it be useful to have an fsck_gpt run by systemd at either startup or shutdown time? This wasn't needed for MBR, so it seems kinda silly to suggest it, but there are some cases of one or the other GPT being stepped on in a way that probably never happened to MBR for the obvious reason that if it did, the computer would be busted. A recent bug came up in QA that made me go down a bit of a rabbit hole, corrupting one or the other GPT to see how different things behave, starting with the various partition tools. This is a summary: parted does the right thing, identifies which GPT is corrupt and says it's using the other one, and fixes the problem on the next write to disk. gdisk does the right thing also. fdisk sees a disk with corrupt primary GPT as being an MBR disk, RHBZ 1022217, fix now available although I haven't tested it yet. anaconda sees such a disk as totally blank, RHBZ 1020974 is in progress. grub2 only uses the primary GPT table, it doesn't check to see if it's valid, RHBZ 1022743. So a bit flip probably won't cause a computer to not boot. It'd have to be something that alters just the start LBA of /boot or / (or both), or stomps on the whole table data. In either case the result is an unbootable system. It's an open question if a bootloader should be able to determine the validity of the primary GPT since that means it needs CRC32 code. And then whether it should know to use the backup GPT. I've raised this on grub-devel@. And just now, I found the kernel nose dives if the primary GPT table is altered by even one byte. kernel.org bug 63591. Anyway, as rare as this is, it might be nice if the system can self-heal from such problems, because it's pretty much guaranteed the user will never know about it until the other GPT is toast. And the UEFI spec amusingly requires the user be asked for confirmation before restoring a primary GPT, which is probably not in either the kernel nor systemd's job description. So that's why I ask if it makes sense to have an fsck for GPT disks. Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
