grub2 attempts to parse LVM2 metadata in grub-core/disk/lvm.c but the parser is incomplete and isn't robust enough to detect all the failure cases, and indeed, looks as if it could produce incorrect mapping tables for certain metadata! This code needs to be updated in conjunction with the lvm2 package, so that: (1) The lvm2 metadata parser in grub2 accepts the same metadata as lvm2. (In particular, whitespace handling and field order handling currently differ from lvm2. This could lead to avoidable failures or incorrect mapping tables.) (2) lvm2 writes a field to the metadata to say 'I know that this LV would be parsed correctly by grub2 (version X and later, perhaps)' and grub2 only uses the LV if this condition is true.
/* Only first (original) is ok with in progress pvmove. */ That comment appears incorrect: a pvmove can consist of multiple steps and the metadata specifies whether you take the first or the second at each point, and using the wrong one will give you corruption if anything got written to it during the move.
Supporting that this needs to be fixed. Another consequence of the incompatibility is that running grub2-mkconfig in a system with lvm2 volumes may give scarey error: unknown LVM metadata header. messages. They seem to be harmless (if /boot is on a standard partition), but they are sure to worry users.
Which grub2 version do these comments apply to? Do you see the problem in the latest f17 packages that are based on grub 2.0beta2?
All versions I have seen. If you wish to use grub2 with lvm2 then you must restrict yourself to that subset of lvm2 functionality which it can handle adequately. As far as I am aware grub2 has not yet documented that subset. Each time the lvm2 package is updated you should re-test that your configuration still works as the grub2 code seems to rely incorrectly upon some lvm2 internals that might change.
So this is not so much a bug in the grub2 package but more of a place-holder for an upstream development project or a feature request? Is that something you @RH plan/hope to do? Or is it something that really should be filed upstream together with some test cases that demonstrate specific problems?
It's a problem with the package insofar as people might assume it's safe to use it in circumstances where it isn't. (E.g. Do not let the system be rebooted automatically with grub2 for any reason while a pvmove is in progress: you must boot read-only and perform recovery manually.) In its current form, it is unsupportable except in some limited (though admittedly common) cases. More than one person has tried to engage with upstream on this issue in the last few years and given up through lack of interest: carrying patches in Fedora that rewrite this code to work correctly might be more fruitful in the short term. But by all means have another go at trying to get some interest from upstream...
Could you post information as to how you created a volume GRUB couldn't support? I've run tests on 2.00~beta6 with LVM and all of them succeeded. LVM version: 2.02.95(2) (2012-03-06) Library version: 1.02.74 (2012-03-06) (tests were run on Debian)
I gave one example above - perform a multi-step pvmove, where you're writing to all the segments of the volumes being moved during the move, and turn the machine's power off any time after the first step has completed but some of the other steps haven't.
I haven't tested multi-step pvmove but the simple interrupted pvmove worked (but you may get outdated filesystem). pvmove and snapshots are the main unsupported features.
I am seeing what I think may be the same problem in 1:2.0-0.37.beta6.fc17. I.e. I see GRUB loading. Welcome to GRUB! then two occurrences of: error: unknown LVM metadata header. (however the system boots OK).
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
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.