Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hi Christian, Thank you for accepting MR. >>> I'll try to get some tests done over the weekend. Ryutaroh, given your >>> experience, if you get a chance to look at ARM side of this, too, I'd be >>> immensely grateful :-) >> I will see its behavior on building an arm image by the start of the next >> week. I tested vmdb2 0.21 with autopkgtest-build-qemu 5.15 + https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=973038;filename=simpler-patch.txt;msg=45 debci setup -b qemu -a arm64 -s sid failed at apt-get install linux-image-arm64. My impression is that Linux 5.10.? is still unreliable. On the other hand, debci setup -b qemu -a arm64 -s bullseye finished with no problem. I saw no problem in the built image. Best regards, Ryutaroh
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hi Ryutaroh, On 07.01.21 02:02, Ryutaroh Matsumoto wrote: > I have sent an MR regarding > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975024 Good catch, thanks! I slightly modified debian/changelog to follow convention. (In particular, I think the Closes: #xx syntax requires the : to be recognized by the parser. But I'm not entirely sure, this may have changed...) > I have looked at > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=vmdb2;dist=unstable > but there seems no other bug that can be easily fixed by packaging... Indeed. I was thinking: 1. let's get up to date with the upstream repository first 2. then start applying fixes (and send them back upstream) 3. Hopefully have a 0.22 before the bullseye freeze :-) >> I'll try to get some tests done over the weekend. Ryutaroh, given your >> experience, if you get a chance to look at ARM side of this, too, I'd be >> immensely grateful :-) > > I will see its behavior on building an arm image by the start of the next > week. Great, thank you! Best, Christian
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hi Christian, Thank you very much for your work!. > The updated packaging is in my fork on Salsa: > https://salsa.debian.org/ckk/vmdb2 I have sent an MR regarding https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975024 I have looked at https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=vmdb2;dist=unstable but there seems no other bug that can be easily fixed by packaging... > I'll try to get some tests done over the weekend. Ryutaroh, given your > experience, if you get a chance to look at ARM side of this, too, I'd be > immensely grateful :-) I will see its behavior on building an arm image by the start of the next week. Best regards, Ryutaroh
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hi Ryutaroh, Gunnar, On 01.01.21 05:27, Ryutaroh Matsumoto wrote: > I wonder if you have available time to package vmdb 0.21 for Debian Bullsyeye > before its deadline. I went ahead and took a stab at updating the package. There were some minor tweaks to the build process, but the first result looks fine. I did a simple test of basic functionality (create a simple image) and it booted fine. I did not yet test any advanced features; most importantly, I did not yet test the features for the newly supported architectures. The updated packaging is in my fork on Salsa: https://salsa.debian.org/ckk/vmdb2 Gunnar, if you're satisfied with this, let me know and I'll file an MR (or merge myself, if you prefer). I uploaded a source package and amd64 binary package to my own personal repo: https://apt.kvr.at/debian/pool/main/v/vmdb2/ I'll try to get some tests done over the weekend. Ryutaroh, given your experience, if you get a chance to look at ARM side of this, too, I'd be immensely grateful :-) Best, Christian
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
On 01.01.21 05:27, Ryutaroh Matsumoto wrote: > vmdb 0.21 appeared in the upstream: > http://git.liw.fi/vmdb2/log/?showmsg=1 > > I wonder if you have available time to package vmdb 0.21 for Debian Bullsyeye > before its deadline. Gunnar, I'm happy to do this if your schedule doesn't permit it. Just let me know :-) Happy New Year, all! Christian
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
> As I said in debian-private (which, of course, is not read by > everybody), I am in a [VAC] period. I am having quite limited > available time, and this will continue at least until the beginning of > 2021. So, please, if you have an upload to make - NMU the package at > will! Hi Gunnar, CC: Christian vmdb 0.21 appeared in the upstream: http://git.liw.fi/vmdb2/log/?showmsg=1 I wonder if you have available time to package vmdb 0.21 for Debian Bullsyeye before its deadline. Best regards, Ryutaroh
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
On 12/11/20 12:33 AM, Ryutaroh Matsumoto wrote: >> The conclusion being that the proposed changes should be first included >> into upstream directly. > > According to > http://git.liw.fi/vmdb2/log/?showmsg=1 > arm64 support is being developed at the upstream. > armhf, armel, or ppc64el doesn't seem so. > > I am willing to submit a merge request like salsa.debian.org, > but http://git.liw.fi does not seem to accept MR. In this case, the MR is communicated by email :-) My suggestion would be to clone the repository somewhere (eg: Salsa), implement, and once the implementation is complete, contact Lars for review and merge. Please let me know/if where I can help with any of these steps. Best, Christian
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
> The conclusion being that the proposed changes should be first included > into upstream directly. According to http://git.liw.fi/vmdb2/log/?showmsg=1 arm64 support is being developed at the upstream. armhf, armel, or ppc64el doesn't seem so. I am willing to submit a merge request like salsa.debian.org, but http://git.liw.fi does not seem to accept MR. best regards, Ryutaroh
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
I forgot to say: On 12/10/20 10:45 AM, Christian Kastner wrote: > In any case, I guess the most reasonable course of action would be only > do "new upstream versions", that is, only changes coming from upstream. The conclusion being that the proposed changes should be first included into upstream directly.
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hi all, On 12/10/20 2:12 AM, Ryutaroh Matsumoto wrote: > In short, I am not qualified to do NMU, a detailed excuse follows. > > I have no right or expertise to NMU... > As your email is publicly appearing to BTS, > I CC'ed my reply to Christian. > > I know he is also very busy now, but he has experience of packaging > and maintaining Debian packages, so he seems much more qualified than me... I'm happy to do or sponsor an NMU if the need arises, although if Gunnar plans to be back in January, I don't think there's an urgency at the moment. In any case, I guess the most reasonable course of action would be only do "new upstream versions", that is, only changes coming from upstream. > For me, maybe the first required task is to learn proper packaging of > a Debian package, then I have to submit application to obtain the privilege > to upload an NMU'ed package... > It can possibly/probably be done in my year-end holidays, > but I am unsure if I can meet the Debian freeze deadline... Getting to know Debian packaging is great if you also want to contribute to other areas in Debian (in which case, feel free to ping me if you need a sponsor!). However, if you'd rather like to focus on the vmdb2 and autopkgtest themselves, rather than the packaging, I'm happy to build and host packages for you :-) Best, Christian
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hi everyone interested in vmdb2! Short comments: David's approach for vmdb2 multi-arch supports re-uses the architecture specified for qemu-debootstrap for that of "grub: uefi". My approach requires a user to specify the architecture twice for qemu-debootstrap and "grub: uefi". So, David's approach seems cleaner than mine. In his approach, the architecture of grub defaults to the host architecuture, which also seems more reasonable than mine, but it could break backward compatibility that vmdb2 0.19 and earlier always assumes amd64 architecture for "grub: uefi" even on non-amd64 hosts. It could cause a minor regression from 0.19. Best regards, Ryutaroh
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hi Gunnar, CC: Christian, Thank you for your message. Since I am in To: field of your email, I assume your last email is somewhat directed to me. In short, I am not qualified to do NMU, a detailed excuse follows. I have no right or expertise to NMU... As your email is publicly appearing to BTS, I CC'ed my reply to Christian. I know he is also very busy now, but he has experience of packaging and maintaining Debian packages, so he seems much more qualified than me... For me, maybe the first required task is to learn proper packaging of a Debian package, then I have to submit application to obtain the privilege to upload an NMU'ed package... It can possibly/probably be done in my year-end holidays, but I am unsure if I can meet the Debian freeze deadline... Best regards, Ryutaroh
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hello world, As you have guessed by now, I have been unable to follow on this bug report. As the Debian vmdb2 maintainer, I am ashamed of not even answering... :-( Anyway, I'm happy to see that Lars, upstream author, is part of the discussion, and there are other DDs involved. As I said in debian-private (which, of course, is not read by everybody), I am in a [VAC] period. I am having quite limited available time, and this will continue at least until the beginning of 2021. So, please, if you have an upload to make - NMU the package at will! Thanks, signature.asc Description: PGP signature
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hi Lars, David, On 12/9/20 8:39 AM, Lars Wirzenius wrote: > On Tue, Dec 08, 2020 at 05:12:57PM +, David Edmondson wrote: >> I figured that out today (need to specify a 64 bit CPU) and provided an >> updated set of patches. > > I'll just note that David updated his patches and that I've merged > them now. that's good to hear! This bug was cloned to #975303 for ppc64 and ppc64el support, and Ryutaroh has posted an exact solution for how to get a bootable system there, too [1]. And he got autopkgtest to work with armel and armhf, with images he built using his own tooling. So there's a path for those architectures, too. With David now having added support for multiple architectures, I guess step-by-step extension could be considered? With all of the above, vmdb2 would be able to create images for all official architectures except for mips* and s390x. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975303#54 Best, Christian
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
On Tue, Dec 08, 2020 at 05:12:57PM +, David Edmondson wrote: > I figured that out today (need to specify a 64 bit CPU) and provided an > updated set of patches. I'll just note that David updated his patches and that I've merged them now. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
On Friday, 2020-12-04 at 08:39:55 +02, Lars Wirzenius wrote:
> As it happens, David Edmonson (dme), added to cc, has been working on
> adding arm64 support for the grub plugin. Part of his changes is that the
> grub plugin will know the target archietecure, and choose the right grub
> .deb package to install based on that.
>
> Unfortunatly, the tests for his changes don't pass yet.
I figured that out today (need to specify a 64 bit CPU) and provided an
updated set of patches.
> David, do you have any commnent on this?
Gunnar's suggestion is much what is implemented in the patches - vmdb2
maintains a notion of "the VM architecture" that defaults to that of the
host. The qemu-debootstrap set updates that to the architecture
specified there and the grub plugin references it to determine which set
of grub packages to install.
The changes only support amd64 and arm64, but should be trivially
extended for other UEFI based platforms that use grub by updating the
dictionary in the plugin:
variants = {
"amd64": ("grub-efi-amd64", "x86_64-efi"),
"arm64": ("grub-efi-arm64", "arm64-efi"),
}
Non-UEFI platforms would need a similar patch to this, to add a map of
architecture to non-UEFI grub variant. I don't have any of those to
test, so it would make sense for someone more familiar with those
platforms to do it.
> On Sat, 2020-11-07 at 23:42 -0600, Gunnar Wolf wrote:
>> Hello Lars,
>>
>> I am writing to you regarding the bug report I am Cc:ing here. Please
>> help me correctly answer to this! The submitter says, in the initial
>> mail:
>>
>> > I am trying to let autopkgtest-build-qemu work on arm64.
>> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038
>> > for relevant report.
>> > The original autopkgtest-build-qemu uses "grub: bios" for vmdb2,
>> > which let vmdb2 install grub-pc on arm64, and fail.
>> >
>> > So I try "grub: uefi" for vmdb2.
>> > Then vmdb2 tries to install grub-efi-amd64,
>> > and again fails.
>> > There is no way to let vmdb2 to create a bootable image on arm64.
>> > vmdb2 seems completely unusable on arm64 (and armhf, armel, etc.)
>> > So I set severity grave.
>>
>> He sent a workaround that does not fix the issue, but lets him build
>> for his target system:
>>
>> --- usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py-orig
>> 2020-10-31 12:47:04.796899268 +0900
>> +++ usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py
>> 2020-10-31 12:50:00.322817935 +0900
>> @@ -112,8 +112,8 @@
>> raise Exception('"efi" or "efi-part" required in UEFI GRUB
>> installation')
>>
>> vmdb.progress("Installing GRUB for UEFI")
>> -grub_package = "grub-efi-amd64"
>> -grub_target = "x86_64-efi"
>> +grub_package = "grub-efi-arm64"
>> +grub_target = "arm64-efi"
>> self.install_grub(values, settings, state, grub_package,
>> grub_target)
>>
>> def install_bios(self, values, settings, state):
>>
>> *If* there is any information to plugins as to which architecture is
>> being built, the fix is basically trivial... But I could not find
>> anything on that regard. Can you suggest anything?
>>
>> Thanks a lot!
dme.
--
Do not leave the building.
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
As it happens, David Edmonson (dme), added to cc, has been working on
adding arm64 support for the grub plugin. Part of his changes is that the
grub plugin will know the target archietecure, and choose the right grub
.deb package to install based on that.
Unfortunatly, the tests for his changes don't pass yet.
David, do you have any commnent on this?
On Sat, 2020-11-07 at 23:42 -0600, Gunnar Wolf wrote:
> Hello Lars,
>
> I am writing to you regarding the bug report I am Cc:ing here. Please
> help me correctly answer to this! The submitter says, in the initial
> mail:
>
> > I am trying to let autopkgtest-build-qemu work on arm64.
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038
> > for relevant report.
> > The original autopkgtest-build-qemu uses "grub: bios" for vmdb2,
> > which let vmdb2 install grub-pc on arm64, and fail.
> >
> > So I try "grub: uefi" for vmdb2.
> > Then vmdb2 tries to install grub-efi-amd64,
> > and again fails.
> > There is no way to let vmdb2 to create a bootable image on arm64.
> > vmdb2 seems completely unusable on arm64 (and armhf, armel, etc.)
> > So I set severity grave.
>
> He sent a workaround that does not fix the issue, but lets him build
> for his target system:
>
> --- usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py-orig
> 2020-10-31 12:47:04.796899268 +0900
> +++ usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py
> 2020-10-31 12:50:00.322817935 +0900
> @@ -112,8 +112,8 @@
> raise Exception('"efi" or "efi-part" required in UEFI GRUB
> installation')
>
> vmdb.progress("Installing GRUB for UEFI")
> -grub_package = "grub-efi-amd64"
> -grub_target = "x86_64-efi"
> +grub_package = "grub-efi-arm64"
> +grub_target = "arm64-efi"
> self.install_grub(values, settings, state, grub_package,
> grub_target)
>
> def install_bios(self, values, settings, state):
>
> *If* there is any information to plugins as to which architecture is
> being built, the fix is basically trivial... But I could not find
> anything on that regard. Can you suggest anything?
>
> Thanks a lot!
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
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
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hi Ryutaroh, On 11/18/20 5:45 AM, Ryutaroh Matsumoto wrote: > I made the attached patch against the latest upstream git source > as attached. I also add "patch" tag to this bts. > As far as I tested, the patch seems working well. > I also added bind-mount of /proc and /dev/pts as recent version of > grub seems to use them. It's great to see progress with vmdb2 getting support for more architectures, thank you for looking into this! I haven't tested this version yet, but looking at the patch, I'd like to two (minor) observations: * 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']) * Instead of the generic Exception, you could raise NotImplementedException when an unsupported architecture is encountered By the way, it would be really nice to eventually have example commands for creating images in the documentation somewhere. Perhaps Lars is open to extending README.md, or the manual, with some examples for other architectures? Best, Christian
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Control: tags -1 + patch
Hi Gunnar, in response to your message,
From: Gunnar Wolf
Subject: Re: Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on
arm64 and does not work on arm64
Date: Sat, 7 Nov 2020 23:33:01 -0600
> As you said here, the workaround is not a fix, as it would make vmdb2
> produce images unable to boot on amd64 - So I'm removing the "patch"
> tag. I am also adding the tags "confirmed" and "upstream", as the
> comments in the file in question mention:
I made the attached patch against the latest upstream git source
as attached. I also add "patch" tag to this bts.
As far as I tested, the patch seems working well.
I also added bind-mount of /proc and /dev/pts as recent version of
grub seems to use them.
uefi-arm64.vmdb is a test file corresponding to the original uefi.vmdb.
Ryutaroh
--- vmdb-git-20201118/vmdb2/vmdb/plugins/grub_plugin.py-orig2020-11-18
09:34:51.093900848 +0900
+++ vmdb-git-20201118/vmdb2/vmdb/plugins/grub_plugin.py 2020-11-18
12:41:30.056459254 +0900
@@ -93,6 +93,7 @@
"image-dev": "",
"quiet": False,
"timeout": 0,
+"arch": "amd64",
}
def run(self, values, settings, state):
@@ -111,9 +112,23 @@
if efi is None and efi_part is None:
raise Exception('"efi" or "efi-part" required in UEFI GRUB
installation')
+arch = values["arch"]
+if arch == "amd64":
+grub_package = "grub-efi-amd64"
+grub_target = "x86_64-efi"
+elif arch == "i386" or arch == "x32":
+grub_package = "grub-efi-ia32"
+grub_target = "i386-efi"
+elif arch == "arm64":
+grub_package = "grub-efi-arm64"
+grub_target = "arm64-efi"
+elif arch == "armhf" or arch == "armel":
+grub_package = "grub-efi-arm"
+grub_target = "arm-efi"
+else:
+raise Exception('Currently unsupported architecture for Grub
UEFI.')
+
vmdb.progress("Installing GRUB for UEFI")
-grub_package = "grub-efi-amd64"
-grub_target = "x86_64-efi"
self.install_grub(values, settings, state, grub_package, grub_target)
def install_bios(self, values, settings, state):
@@ -144,7 +159,7 @@
quiet = values["quiet"]
-self.bind_mount_many(chroot, ["/dev", "/sys"], state)
+self.bind_mount_many(chroot, ["/dev", "/sys", "/proc", "/dev/pts"],
state)
if efi_dev:
self.mount(chroot, efi_dev, "/boot/efi", state)
self.install_package(chroot, grub_package)
--- vmdb-git-20201118/vmdb2/vmdb/plugins/grub.mdwn-orig 2020-11-18
13:32:55.989389129 +0900
+++ vmdb-git-20201118/vmdb2/vmdb/plugins/grub.mdwn 2020-11-18
13:36:27.762255325 +0900
@@ -30,6 +30,9 @@
* `timeout` OPTIONAL; set the grub menu timeout, in seconds.
Defaults to 0 seconds.
+* `arch` OPTIONAL; set the target architecture of grub-efi.
+ Defaults to amd64. Currently, amd64, i386, x32, arm64, armhf and armel are
supported.
+
Example (in the .vmdb file):
- grub: bios
@@ -41,6 +44,7 @@
tag: root
efi: efi
console: serial
+ arch: i386
Install to a real hard disk (named with the `--image` option):
@@ -48,3 +52,4 @@
tag: root
efi: efi
image-dev: "{{ image }}"
+ arch: arm64
--- /dev/null 2020-11-18 12:39:50.085968484 +0900
+++ vmdb-git-20201118/vmdb2/uefi-arm64.vmdb 2020-11-18 13:00:06.591549633
+0900
@@ -0,0 +1,62 @@
+# This is a sample VMDB2 input file that specifies a simple system for
+# a PC that boots with UEFI.
+
+steps:
+ - mkimg: "{{ output }}"
+size: 4G
+
+ - mklabel: gpt
+device: "{{ output }}"
+
+ - mkpart: primary
+device: "{{ output }}"
+start: 0%
+end: 1G
+tag: efi
+fs-type: 'fat32'
+
+ - mkpart: primary
+device: "{{ output }}"
+start: 1G
+end: 100%
+tag: /
+fs-type: 'ext4'
+
+ - kpartx: "{{ output }}"
+
+ - mkfs: vfat
+partition: efi
+
+ - mkfs: ext4
+partition: /
+
+ - mount: /
+
+
+ - unpack-rootfs: /
+
+ - qemu-debootstrap: bullseye
+mirror: http://deb.debian.org/debian
+arch: arm64
+target: /
+unless: rootfs_unpacked
+
+ - apt: install
+packages:
+ - linux-image-arm64
+fs-tag: /
+unless: rootfs_unpacked
+
+ - cache-rootfs: /
+unless: rootfs_unpacked
+
+ - chroot: /
+shell: |
+ echo uefi-vmdb2 > /etc/hostname
+
+ - fstab: /
+
+ - grub: uefi
+tag: /
+efi: efi
+arch: arm64
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
I've sent some patches to liw for vmdb2 to improve building a UEFI based arm64 image which can be seen here: https://git.sledj.net/dme/vmdb2/src/branch/devel/arm64 These should address the general problem of vmdb2 being able to build an arm64 image when grub is used, as long as UEFI is chosen (there is no BIOS support for arm64). This should result in a usable image, but it may still be necessary to make some changes to autotest to ensure that: - a UEFI image is built on arm64 rather than attempting BIOS, - qemu is configured to use UEFI firmware when the resulting image is used. dme. -- So tap at my window, maybe I might let you in.
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Hello Lars,
I am writing to you regarding the bug report I am Cc:ing here. Please
help me correctly answer to this! The submitter says, in the initial
mail:
> I am trying to let autopkgtest-build-qemu work on arm64.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038
> for relevant report.
> The original autopkgtest-build-qemu uses "grub: bios" for vmdb2,
> which let vmdb2 install grub-pc on arm64, and fail.
>
> So I try "grub: uefi" for vmdb2.
> Then vmdb2 tries to install grub-efi-amd64,
> and again fails.
> There is no way to let vmdb2 to create a bootable image on arm64.
> vmdb2 seems completely unusable on arm64 (and armhf, armel, etc.)
> So I set severity grave.
He sent a workaround that does not fix the issue, but lets him build
for his target system:
--- usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py-orig
2020-10-31 12:47:04.796899268 +0900
+++ usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py
2020-10-31 12:50:00.322817935 +0900
@@ -112,8 +112,8 @@
raise Exception('"efi" or "efi-part" required in UEFI GRUB
installation')
vmdb.progress("Installing GRUB for UEFI")
-grub_package = "grub-efi-amd64"
-grub_target = "x86_64-efi"
+grub_package = "grub-efi-arm64"
+grub_target = "arm64-efi"
self.install_grub(values, settings, state, grub_package,
grub_target)
def install_bios(self, values, settings, state):
*If* there is any information to plugins as to which architecture is
being built, the fix is basically trivial... But I could not find
anything on that regard. Can you suggest anything?
Thanks a lot!
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
tags 973467 - patch
tags 973467 + confirmed upstream
severity 973467 important
thanks
Hello Ryutaroh,
As you said here, the workaround is not a fix, as it would make vmdb2
produce images unable to boot on amd64 - So I'm removing the "patch"
tag. I am also adding the tags "confirmed" and "upstream", as the
comments in the file in question mention:
# Note that this is currently rather strongly assuming that UEFI and
# the amd64 (a.k.a. x86_64) architecture are being used. These should
# probably not be hardcoded. Patch welcome.
I will be taking this issue with upstream author, I think the patch is
somewhat trivial, but given I lack any hardware to test it, I will not
commit a fix without his approval.
Finally, I am downgrading the severity to "important", as I judge this
bug to be "a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone"¹. It
does not completely render vmdb2 useless, not even for the arm64
architecture (for which I use it on a daily basis!) - Just for arm64
machines that boot via UEFI.
¹ https://www.debian.org/Bugs/Developer#severities
Greetings,
Ryutaroh Matsumoto dijo [Sat, Oct 31, 2020 at 02:32:27PM +0900]:
> Control: tags -1 + patch
>
> The following workaround (NOT A FIX AT ALL) let vmdb2 work for my arm64...
>
> --- usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py-orig
> 2020-10-31 12:47:04.796899268 +0900
> +++ usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py 2020-10-31
> 12:50:00.322817935 +0900
> @@ -112,8 +112,8 @@
> raise Exception('"efi" or "efi-part" required in UEFI GRUB
> installation')
>
> vmdb.progress("Installing GRUB for UEFI")
> -grub_package = "grub-efi-amd64"
> -grub_target = "x86_64-efi"
> +grub_package = "grub-efi-arm64"
> +grub_target = "arm64-efi"
> self.install_grub(values, settings, state, grub_package, grub_target)
>
> def install_bios(self, values, settings, state):
>
--
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Control: tags -1 + patch
The following workaround (NOT A FIX AT ALL) let vmdb2 work for my arm64...
--- usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py-orig
2020-10-31 12:47:04.796899268 +0900
+++ usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py 2020-10-31
12:50:00.322817935 +0900
@@ -112,8 +112,8 @@
raise Exception('"efi" or "efi-part" required in UEFI GRUB
installation')
vmdb.progress("Installing GRUB for UEFI")
-grub_package = "grub-efi-amd64"
-grub_target = "x86_64-efi"
+grub_package = "grub-efi-arm64"
+grub_target = "arm64-efi"
self.install_grub(values, settings, state, grub_package, grub_target)
def install_bios(self, values, settings, state):
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
Package: vmdb2 Version: 0.19-1 Severity: grave Justification: renders package unusable Control: block 973038 by -1 Dear Maintainer, I am trying to let autopkgtest-build-qemu work on arm64. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038 for relevant report. The original autopkgtest-build-qemu uses "grub: bios" for vmdb2, which let vmdb2 install grub-pc on arm64, and fail. So I try "grub: uefi" for vmdb2. Then vmdb2 tries to install grub-efi-amd64, and again fails. There is no way to let vmdb2 to create a bootable image on arm64. vmdb2 seems completely unusable on arm64 (and armhf, armel, etc.) So I set severity grave. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: arm64 (aarch64) Kernel: Linux 5.9.0-1-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vmdb2 depends on: ii cmdtest 0.32.14.gcdfe14e-1 ii debootstrap 1.0.123 ii kpartx 0.8.4-4 ii parted 3.3-4 ii python3 3.8.2-3 ii python3-cliapp 1.20180812.1-4 ii python3-jinja2 2.11.2-1 ii python3-yaml5.3.1-3 ii qemu-utils 1:5.1+dfsg-4+b1 Versions of packages vmdb2 recommends: pn ansible vmdb2 suggests no packages. -- no debconf information
