diskimage-builder

Bug #1674402
Comment #6

Comment 6 for bug 1674402

Revision history for this message

Ian Wienand (iwienand) wrote on 2017-03-22:

Ok, so what seems to be at the root of this is that "grub-install" for ieee-1275 is trying to find a companion prep partition (type 0x41) to the root partition which it will copy the openfirmware binaries into

So after adding the extra prep partition for PPC in https://review.openstack.org/447739 the bootloader does correctly make this on loop0p1 and we have the root device at /dev/loop0p2. however, when we "grub-install /dev/loop0p2" here, we get the weird error about

/usr/sbin/grub-install: error: the chosen partition is not a PReP partition

I *think* this is all tied up around [1] where it does a bunch of path matching. However, I think that when finding device-mapper, grub takes a different probe path. This probably explains why in [2] the ppc hard-coded itself to run kpartx and then overrides the devices to the /dev/mapper equivalents (note the original change gives no clues in the changelog about why it does this, and no comments are left at all).

So by running kpartx during partitioning to make /dev/mapper/loop* entries, and then hard-coding the PPC build to use /dev/mapper/loop0p2, "grub-install" was happy and Mikhail tested and made a bootable image.

This leaves the question of what to do ...

@Andreas -- in [3] why do we have the kpartx call conditionally after the udev/partprobe call? Would we be better off using /dev/mapper/* throughout the code, instead of /dev/loop*?

A hack that I think I will try might be to symlink /dev/mapper/loop* entries back to /dev/loop* entries just in the PPC build around the call to "grub-install". I'm hoping this might fool it into finding the right partitions using it's /dev/mapper support. I think this would be a rather massive hack, and probably limit the partitioning magic that can happen on PPC ... but it might be enough for now to at least get us back to where we were.

[1] https://github.com/coreos/grub/blob/grub-2.02-beta2/grub-core/osdep/linux/ofpath.c#L517
[2] https://git.openstack.org/cgit/openstack/diskimage-builder/tree/elements/vm/block-device.d/10-partition?h=1.28.0#n45
[3] https://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/block_device/level1/partitioning.py#n197

So after adding the extra prep partition for PPC in https://review.openstack.org/447739 the bootloader does correctly make this on loop0p1 and we have the root device at /dev/loop0p2.  however, when we "grub-install /dev/loop0p2" here, we get the weird error about

/usr/sbin/grub-install: error: the chosen partition is not a PReP partition

I *think* this is all tied up around [1] where it does a bunch of path matching.  However, I think that when finding device-mapper, grub takes a different probe path.  This probably explains why in [2] the ppc hard-coded itself to run kpartx and then overrides the devices to the /dev/mapper equivalents (note the original change gives no clues in the changelog about why it does this, and no comments are left at all).

This leaves the question of what to do ...

@Andreas -- in [3] why do we have the kpartx call conditionally after the udev/partprobe call?  Would we be better off using /dev/mapper/* throughout the code, instead of /dev/loop*?

A hack that I think I will try might be to symlink /dev/mapper/loop* entries back to /dev/loop* entries just in the PPC build around the call to "grub-install".  I'm hoping this might fool it into finding the right partitions using it's /dev/mapper support.  I think this would be a rather massive hack, and probably limit the partitioning magic that can happen on PPC ... but it might be enough for now to at least get us back to where we were.