11:49 p.m.
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
3:33 a.m.
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
So that's why I ask if it makes sense to have an fsck for GPT
disks.
Sounds sensible. The "fsck" would just check the checksums of primary
& secondary tables, and if an error in either (but not both) is
detected it would restore from the other one? Does such an "fsck"
tool exist already or would you just run gdisk (doesn't appear
to be automatic)?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
9:59 a.m.
On 10/24/2013 01:33 AM, Richard W.M. Jones wrote:
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
> So that's why I ask if it makes sense to have an fsck for GPT disks.
Sounds sensible. The "fsck" would just check the checksums of primary
& secondary tables, and if an error in either (but not both) is
detected it would restore from the other one?
Such a tool also should diagnose both overlap and unclaimed space,
and provide some means for repair of these conditions.
For example in the case of "minor" overlap: repair might be "minimum
wins",
"maximum wins", or arbitrary edit of extent fields.
The tool also should diagnose "protective MBR" situations and
understand common values for partition type entries (both GPT and MBR).
It should provide the ability to overwrite any existing checksum
with the calculated correct checksum. The tool also should be able
to erase both GPT tables (overwrite all bytes to 0x00.)
12:51 p.m.
On Thu, Oct 24, 2013 at 4:59 PM, John Reiser <jreiser(a)bitwagon.com> wrote:
On 10/24/2013 01:33 AM, Richard W.M. Jones wrote:
> On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
>> So that's why I ask if it makes sense to have an fsck for GPT disks.
>
> Sounds sensible. The "fsck" would just check the checksums of primary
> & secondary tables, and if an error in either (but not both) is
> detected it would restore from the other one?
Such a tool also should diagnose both overlap and unclaimed space,
and provide some means for repair of these conditions.
For example in the case of "minor" overlap: repair might be "minimum
wins",
"maximum wins", or arbitrary edit of extent fields.
The tool also should diagnose "protective MBR" situations and
understand common values for partition type entries (both GPT and MBR).
It should provide the ability to overwrite any existing checksum
with the calculated correct checksum. The tool also should be able
to erase both GPT tables (overwrite all bytes to 0x00.)
Please let's not mix the two concepts of "tools" quoted above.
If the proposal is to run something by default on every bootup, it
must be overwhelmingly safe, not apply heuristics that may break the
system even more.
Mirek
2:04 p.m.
On Oct 24, 2013, at 11:51 AM, Miloslav Trmač <mitr(a)volny.cz> wrote:
Please let's not mix the two concepts of "tools" quoted above.
If the proposal is to run something by default on every bootup, it
must be overwhelmingly safe, not apply heuristics that may break the
system even more.
Right. If anything, a heuristic more sophisticated than checksum pass-fail, might indicate
when NOT to do something in an unattended use context.
For instance if a valid GPT contains overlaps, yet the invalid one contains entries that
do not, and that invalid entry happens to be the primary GPT which is obviously working or
it wouldn't be booting the system to get to the fsck… well that'd be pretty
adorable in that I don't anticipate such a possibility. But a particularly smart tool
should probably just sound a klaxon somehow but otherwise alter nothing on disk; or
possibly it halts boot at this point to really get the attention of the user.
Chris Murphy
1:41 p.m.
On Oct 24, 2013, at 8:59 AM, John Reiser <jreiser(a)bitwagon.com> wrote:
Such a tool also should diagnose both overlap and unclaimed space,
and provide some means for repair of these conditions.
For example in the case of "minor" overlap: repair might be "minimum
wins",
"maximum wins", or arbitrary edit of extent fields.
The tool also should diagnose "protective MBR" situations and
understand common values for partition type entries (both GPT and MBR).
It should provide the ability to overwrite any existing checksum
with the calculated correct checksum. The tool also should be able
to erase both GPT tables (overwrite all bytes to 0x00.)
For now the scope is unattended operation at startup or shutdown. I think all of the above
suggestions need a user to be directly involved.
Chris Murphy
1:41 p.m.
On Oct 24, 2013, at 2:33 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
> So that's why I ask if it makes sense to have an fsck for GPT disks.
Sounds sensible. The "fsck" would just check the checksums of primary
& secondary tables, and if an error in either (but not both) is
detected it would restore from the other one?
Yes. I think the exception to fixing would be if the MBR is clearly not a protective MBR,
i.e. it does not at all have an 0xEE entry. In that case, I'd say leave the stale GPT
info alone as the disk is MBR not GPT.
There are some challenges interpreting hybrid MBRs correctly, because there's no
standard here. So if the MBR contains an 0xEE entry and at least one additional entry, we
could safely fix an invalid GPT with information from the valid GPT so long as the entries
in the MBR and the valid GPT agree. If they don't, all bets are off and we probably
shouldn't touch anything.
Does such an "fsck"
tool exist already or would you just run gdisk (doesn't appear
to be automatic)?
Does not exist as far as I know. Much of this code is in parted, including recognizing
stale GPTs (a formerly GPT disk that's repartitioned MBR; which does not wipe out the
old GPT information).
Chris Murphy
10:40 a.m.
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
The bottom line question is, would it be useful to have an fsck_gpt
run by systemd at either startup or shutdown time?
I have a system that corrupts the backup GPT on every reboot: the CRC32
in the backup GPT is always 0. I run parted or gdisk to fix it, verify
that everything is good (even by dd'ing the backup GPT and manually
inspecting it), then reboot and bam, it's corrupt again (i.e., set to
0). I don't know if it's an OS bug, a firmware bug, or something with
the actual disk.
This was causing some headaches for me with anaconda:
https://bugzilla.redhat.com/show_bug.cgi?id=950145
https://bugzilla.redhat.com/show_bug.cgi?id=951244 <-- especially this
So fsck_gpt would indeed be useful. (Although it would probably force
me to switch from UEFI back to legacy BIOS emulation and back to MBR
partitioning on this one system.)
Jeff
1:46 p.m.
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian <jbastian(a)redhat.com> wrote:
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
> The bottom line question is, would it be useful to have an fsck_gpt
> run by systemd at either startup or shutdown time?
I have a system that corrupts the backup GPT on every reboot.
Certain RAID implementations write metadata at the end of the disk and step on the backup
GPT in this manner. But that was on computers with BIOS firmware that weren't GPT
aware. UEFI firmware obviously should be GPT aware so it'd be quite a bungling if its
firmware RAID were writing metadata where the backup GPT goes. But it's worth seeing
if the firmware is up to date.
You could also use dd and hexdump to read in ~100 of the last sectors of the disk, and see
if the metadata written to that area is identifiable.
Chris Murphy
4:09 p.m.
On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian
<jbastian(a)redhat.com> wrote:
> I have a system that corrupts the backup GPT on every reboot.
Certain RAID implementations write metadata at the end of the disk and
step on the backup GPT in this manner. But that was on computers with
BIOS firmware that weren't GPT aware. UEFI firmware obviously should
be GPT aware so it'd be quite a bungling if its firmware RAID were
writing metadata where the backup GPT goes. But it's worth seeing if
the firmware is up to date.
Reartes Guillermo mentioned the same thing with RAID in BZ 951244, so I
checked my system UEFI settings and indeed it was configured for RAID.
I switched it to AHCI and that solved the problem! No more backup GPT
corruption!
I switched it back to RAID just to be sure and the backup GPT was
corrupt again.
I guess I'll leave it in AHCI since I wasn't using the hardware RAID
anyway.
Thank you!
Jeff
10:58 p.m.
On Nov 4, 2013, at 3:09 PM, Jeffrey Bastian <jbastian(a)redhat.com> wrote:
On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
> On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian <jbastian(a)redhat.com> wrote:
>> I have a system that corrupts the backup GPT on every reboot.
>
> Certain RAID implementations write metadata at the end of the disk and
> step on the backup GPT in this manner. But that was on computers with
> BIOS firmware that weren't GPT aware. UEFI firmware obviously should
> be GPT aware so it'd be quite a bungling if its firmware RAID were
> writing metadata where the backup GPT goes. But it's worth seeing if
> the firmware is up to date.
Reartes Guillermo mentioned the same thing with RAID in BZ 951244, so I
checked my system UEFI settings and indeed it was configured for RAID.
I switched it to AHCI and that solved the problem! No more backup GPT
corruption!
I switched it back to RAID just to be sure and the backup GPT was
corrupt again.
I guess I'll leave it in AHCI since I wasn't using the hardware RAID
anyway.
What ought to happen, with the feature enabled, is the combined devices appear as a
logical device that's then partitioned. This puts the GPT in the proper location for
the logical device. It so happens the primary GPT in the logical device is the same
location as for the physical devices, so if the logical device breaks, the physical
devices have a primary GPT that's intact. The backup GPT for the logical device is in
the correct location for only the logical device, it will be too far "in" on the
physical device which has the IMSM RAID metadata at the end of the physical device
instead.
Chris Murphy
3823
days inactive
3835
days old
10 comments
5 participants
participants (5)
-
Chris Murphy -
Jeffrey Bastian -
John Reiser -
Miloslav Trmač -
Richard W.M. Jones