#3406 PR merged: ppc64le: Fix compatibility with PowerNV on RHEL 8+

Labels: enhancement, special hardware or VM

lzaoral opened issue at 2025-02-24 14:01:

Pull Request Details:

  • Type: Bug Fix / Enhancement

  • Impact: Normal

  • Reference to related issue (URL): Unfortunately, the RHEL Jira ticket cannot be made public.

  • How was this pull request tested? ppc64le RHEL 8 on baremetal Power 9 machine

  • Description of the changes in this pull request:

Modern PowerNV systems with the OPAL firmware do not require the presence of the PPC PReP boot partition [1,2]. Therefore, the installation of GRUB2 should be made optional on these machines if such partition does not exist. As long as the GRUB2 configuration is created successfully, Petitboot will be able to load it and boot the restored system.

This PR makes sure that PowerNV machines will fallback on GRUB2 if no PPC PReP boot partitions were found and also skips GRUB2 installation in such case.

[1] https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html-single/automatically_installing_rhel/index#raid_kickstart-commands-for-handling-storage
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1970432#c2

jsmeix commented at 2025-02-24 15:40:

@lzaoral
could you provide the text of your

commit messages for additional details and links

from your current
https://github.com/rear/rear/pull/3406/commits/4c2f4ad42493b3fbd4257bc81236071d5551397e
(will your commit and its commit message
be still available after it was merged
e.g. possibly with "squash and merge"?)
in a way that it is more easily still accessible also

when years later your code has somewhat bitrotted and
others intend to update and enhance your code properly

cf.
https://github.com/rear/rear/wiki/Coding-Style#code-must-be-easy-to-understand-answer-the-why

lzaoral commented at 2025-02-26 15:29:

@lzaoral could you provide the text of your

commit messages for additional details and links

from your current 4c2f4ad (will your commit and its commit message be still available after it was merged e.g. possibly with "squash and merge"?)

Done. By default, the resulting squashed commit should contain all respective commit messages, thus, no piece of information should be lost. On the other hand, I'd argue that squash-merge is a rather inconvenient practice, especially when you want to revert something later.

jsmeix commented at 2025-03-07 12:27:

From what I read in the initial description
this issue is not actually a bug in ReaR
but an enhancement because it improves ReaR.

pcahyna commented at 2025-03-07 20:20:

Modern PowerNV systems with the OPAL firmware do not require the presence of the PPC PReP boot partition [1,2].

Please add the references to the description

pcahyna commented at 2025-03-10 13:35:

@jsmeix

(will your commit and its commit message
be still available after it was merged
e.g. possibly with "squash and merge"?)

Please do not use "squash and merge" unless really necessary, that is if the intermediate steps are wrong and you want to discard such history. Contributors often split their contributions into several commits for valid reasons and they would be disappointed to see this work discarded by a final squash.

jsmeix commented at 2025-03-10 13:42:

@pcahyna
I think I remember that some time ago
you had recommended "squash and merge" to me?

When "squash and merge" is used the merge commit message
must tell the whole story sufficiently.

The advantage - as far as I understood - is to have
in the master branch simple and straightforward commits
without possibly many unneeded "noise" commits that
were done during development?

pcahyna commented at 2025-03-10 14:20:

@jsmeix

I think I remember that some time ago
you had recommended "squash and merge" to me?

Unfortunately I don't remember the context in which I made that suggestion, but I don't think I suggested it as a general method that should be always used, rather as a solution for a particular scenario.

The advantage - as far as I understood - is to have
in the master branch simple and straightforward commits
without possibly many unneeded "noise" commits that
were done during development?

Yes, but only when the commits are indeed "unneeded noise". Sometimes (and in my case, it is nearly always) I intend the commits to be in the final history and tailor them appropriately. Also, I often tell to people to at least split "by the way" changes (like style/formatting/spelling changes and cleanups) that they make when changing something else into separate commits (if they don't want to open multiple PRs for this, which I understand), as unrelated changes do not belong in one commit. This effort would be lost if one squashed the stuff together at the end.

I think it is safe to use "squash and merge" on your own PRs when you know that you (as the author) don't want the intermediate steps, but not on other contributors' PRs unless requested.

pcahyna commented at 2025-03-24 13:38:

I would like to merge the PR today unless there are further suggestions for improvements.

[Export of Github issue for rear/rear.]