Deploying custom RHEL on PowerNV

Users
,
1

Hi all

Here’s a conundrum we’re just facing and we don’t have a good idea were a good place for a fix would be:

Context: We’ve got a maas envrionment and

  • Have several Power-Machines
  • That run in PowerNV (aka Native/Non-virtualized/Non-PowerVM) mode
  • And need RHEL (which means custom image)

It turns out, that, after having all stuff done:

  • a deployment fails because
    • curtin chokes on grub
      • which dies becasue ofpahtname cannot be found.

It works for deploying Ubuntu, tho, and grub does not complain.

What happens?
When curtin sees a RHEL/Centos image, it runs grub2-install as a job near the end of depolyment, but grub has hardcoded for Power (by means of grub-ieee1275) to run ofpathname to find out where to deploy thing to, and first checks availablility of that command. But that fails, as on PowerNV, ofpathname always exits with 1 and complains that it does not want to be run on PowerNV.

We could avoid that by passing --no-nvram since all calls that result in ofpathname are guarded with update_nvram, and curtin can do that, but sadly only for uefi targets

It turns out that grub(2)-install does not need to be run at all since the PowerNV bootloader petitboot does not make use of grubs’ binaries at all but rather re-uses its config, so its perfectly fine not to run grub-install. RHEL’s installer Anaconda does just that: not call grub install

Seeing curtins config options, we could either pass a device directly, or try to pass an empty array or None to indicate to not install grub anywhere, and the code reflects that.
Sadly, this does not work down the line, as the same function lateron (sets the empty install_devices to ["none"])[curthooks.py « commands « curtin - curtin - [no description]], which it cheerfully passes on directly to grub2-install.

I would see several points where this could be fixed:

  1. grub: It actually probably should not try to run that binary ofpathname on PowerNV (or at least check when it fails, why)
  2. curtin (a): allow passing no-nvram to non-UEFI targets
  3. curtin (b): allow passing empty or None install_devices
  4. maas: make some kind of exception for PowerNV (but I have no idea what that would look like)

What would you all suggest?

PS: Why does it work for ubuntu? It seems that the actual grub-install is avoided somewhere due to the post-install script of grub-ieee1275, but that’s just a conjecture
PPS: We actually have a workaround for now: since we need a custom image anyway, we patched it to include a no-op grub2-install …

2

Our use case is quite exotic, I guess…

3

Hi @score ,

I’m glad that you found a solution/workaround. You are right, PowerNV + RHEL is not something we see frequently.

about your suggested fixes:

  1. Curtin runs the image’s grub, so RHEL grub in this case. Fixing this is out of our control, but you can file a bug with RHEL
  2. please report a bug to Curtin
  3. same as above
  4. a Custom Image is the way to modify the install process the way you need. You could do it by either adding a custom /curtin/curtinhooks.py script to the image, or creating a no-op script (like you did)
4

Hi @alexsander-souza

Glad to see no topic is forgotten :slight_smile:

  1. You’re perfectly right. I have no high hopes for RHEL. Maybe I find time to report it upstream
  2. Will try to post a bug for curtin, sure.
  3. idem
  4. How would a curtin hook look? I cannot really picture it.

Thanks for your time!

5

We use a custom curtin hook for Ubuntu images:

https://github.com/canonical/packer-maas/blob/main/ubuntu/scripts/curtin-hooks

When Curtin finds a /curtin/curtin-hooks script in the image, it runs it instead of the built-in procedure. Unfortunately the original hook does a lot of things, so your custom script becomes responsible for doing it also, but generally is just a matter of calling existing Curtin functions to do tasks you need.

1 Like