Add safe grub embedded space inhibitor #17
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds a new actor checking for whether any of the GRUB devices have the old GRUB Legacy installed. If any of such devices is detected, the upgrade is inhibited. The GRUB Legacy is detected by searching for the string 'GRUB version 0.94' in `file -s` of the device. (cherry picked from commit 8fe2a2d)
The new message informs the useir will happen (they will boot into the old RHEL's kernel) so they understand why they need to run the remediation. jira: https://issues.redhat.com/browse/RHEL-29683 (cherry picked from commit 6d05575)
Check that the first partition starts at least at 1MiB (2048 cylinders), as too small first-partition offsets lead to failures when doing grub2-install. The limit (1MiB) has been chosen as it is a common value set by the disk formatting tools nowadays. jira: https://issues.redhat.com/browse/RHEL-3341 (cherry picked from commit ea6cd79)
This is extension of the previous commit. The original problem that we are trying to resolve is to be sure the embedding area (MBR gap) has expected size. This is irrelevant in case of GPT partition table is used on a device. The fdisk output format is in case of GPT disk label different, which breaks the parsing, resulting in empty list of partitions in related GRUBDevicePartitionLayout msg. For now, let's skip produce of msgs for "GPT devices". As a seatbelt, ignore processing of messages with empty partitions field, expecting that such a device does not contain MBR. We want to prevent false positive inhibitors (and FP blocking errors). We expect that total number of machines with small embedding area is very minor in total numbers, so even if we would miss something (which is not expected now to our best knowledge) it's still good trade-off as the major goal is to reduce number of machines that have problems with the in-place upgrade. The solution can be updated in future if there is a reason for it. (cherry picked from commit 683176d)
newer versions of leapp deprecated get_grub_device and use get_grub_devices instead which support raid, etc our version does not support multiple grub devices, so use legacy functions instead
Thank you for contributing to the Leapp project!Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergable.
Please open ticket in case you experience technical problem with the CI. (RH internal only) Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please consider rerunning the CI by commenting leapp-ci build (might require several comments). If the problem persists, contact leapp-infra. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR cherry-picks changes from upstream that:
Both changes should decrease amount of machines that are "briked" during elevation.