Hi Christian, thanks again for your attention. > * You could enhance the new "arch" field of the grub plugin by not > defaulting to amd64, but to the native host architecture. You can > get this using > subprocess.check_call(['dpkg', '--print-architecture'])
Thank you. I thought it would break backward compatibility of vmdb2, specifically, if vmdb2 is run on some host architecture not being amd64, the above code will behave differently from vmdb2 0.19... > * Instead of the generic Exception, you could raise > NotImplementedException when an unsupported architecture is > encountered Thanks again. I did not know that. I will use it in a similar context... By the way, I think I identified what are required for vmdb2 to build a bootable ppc64el qemu autopkg testbed. I think I succeeded to build a ppc64el testbed as written at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926945#64 >From that experience, the requirements for ppc64el partitioning look as >follows: (1) Create 1st GPT partition of size about 8 MB and set PReP flag to it by parted -- /dev/loop0 mklabel gpt mkpart ESP fat32 0% 9MiB set 1 prep on (2) Fill the first GPT partition by zero, e.g. dd if=/dev/zero of=/dev/loop0p1 (3) apt-get --install-recommends install grub-ieee1275; apt-get purge os-prober (4) chroot grub-mkconfig -o /boot/grub/grub.cfg (5) chroot grub-install --target=powerpc-ieee1275 --no-nvram --no-floppy \ --modules="part_msdos part_gpt" --grub-mkdevicemap=/boot/grub/device.map \ /dev/loop0p1 The strange point is that we have to give /dev/loop0p1 to grub-install. For other architectures, /dev/loop0 is fine. The above (5) is already observed 1.5 years ago at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926945#5 Incorporating the above changes to the current vmdb2 seems to require significant design change. So I refrain from suggesting a patch to vmdb2. Such a significant design decision should be done by the upstream author, IMHO. Best regards, Ryutaroh
