| Message ID | 20190129175403.18017-10-philmd@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | OpenBSD: Enable qtesting | expand |
On Tue, 29 Jan 2019 at 17:57, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > Various iotests scripts (run via 'make check-block') use bash > specific extentions. OpenBSD comes with the Korn shell as default. > Install bash to be able to run those tests. > > Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > --- > tests/vm/openbsd | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tests/vm/openbsd b/tests/vm/openbsd > index 6263c8956b..e9c2a3f2c8 100755 > --- a/tests/vm/openbsd > +++ b/tests/vm/openbsd > @@ -45,6 +45,8 @@ class OpenBSDVM(basevm.BaseVM): > self.wait_ssh() > sys.stderr.write("Disabling W^X on the build partition...\n") > self.ssh_root_check("sed -E -i 's_(/tmp\ ffs)\ ([^\ ]*)_\\1 \\2,wxallowed_' /etc/fstab") > + sys.stderr.write("Installing bash...\n") > + self.ssh_root_check("PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64 pkg_add bash") > self.ssh_root("shutdown -p now") > self.wait() > Wouldn't it make more sense to just update the image to include the necessary package, the same way we do with all QEMU's other build dependencies ? thanks -- PMM
Hi Peter, On 2/5/19 2:20 PM, Peter Maydell wrote: > On Tue, 29 Jan 2019 at 17:57, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: >> >> Various iotests scripts (run via 'make check-block') use bash >> specific extentions. OpenBSD comes with the Korn shell as default. >> Install bash to be able to run those tests. >> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> --- >> tests/vm/openbsd | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/tests/vm/openbsd b/tests/vm/openbsd >> index 6263c8956b..e9c2a3f2c8 100755 >> --- a/tests/vm/openbsd >> +++ b/tests/vm/openbsd >> @@ -45,6 +45,8 @@ class OpenBSDVM(basevm.BaseVM): >> self.wait_ssh() >> sys.stderr.write("Disabling W^X on the build partition...\n") >> self.ssh_root_check("sed -E -i 's_(/tmp\ ffs)\ ([^\ ]*)_\\1 \\2,wxallowed_' /etc/fstab") >> + sys.stderr.write("Installing bash...\n") >> + self.ssh_root_check("PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64 pkg_add bash") >> self.ssh_root("shutdown -p now") >> self.wait() >> > > Wouldn't it make more sense to just update the image to include > the necessary package, the same way we do with all QEMU's > other build dependencies ? Instead of updating the image, Daniel asked if we could upgrade this image to a more recent release (to remove SDL1), but IIRC the outcome was there is no manpower for that. Meanwhile, this kludge seems the simplest way. BTW This command is run once at image creation.
If someone could point me in the right direction as to how the image is created I could look at coming up with something newer. I would prefer that over some of the workarounds I've seen to date. On 2/5/2019 8:42 AM, Philippe Mathieu-Daudé wrote: > Hi Peter, > > On 2/5/19 2:20 PM, Peter Maydell wrote: >> On Tue, 29 Jan 2019 at 17:57, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: >>> Various iotests scripts (run via 'make check-block') use bash >>> specific extentions. OpenBSD comes with the Korn shell as default. >>> Install bash to be able to run those tests. >>> >>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >>> --- >>> tests/vm/openbsd | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/tests/vm/openbsd b/tests/vm/openbsd >>> index 6263c8956b..e9c2a3f2c8 100755 >>> --- a/tests/vm/openbsd >>> +++ b/tests/vm/openbsd >>> @@ -45,6 +45,8 @@ class OpenBSDVM(basevm.BaseVM): >>> self.wait_ssh() >>> sys.stderr.write("Disabling W^X on the build partition...\n") >>> self.ssh_root_check("sed -E -i 's_(/tmp\ ffs)\ ([^\ ]*)_\\1 \\2,wxallowed_' /etc/fstab") >>> + sys.stderr.write("Installing bash...\n") >>> + self.ssh_root_check("PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64 pkg_add bash") >>> self.ssh_root("shutdown -p now") >>> self.wait() >>> >> Wouldn't it make more sense to just update the image to include >> the necessary package, the same way we do with all QEMU's >> other build dependencies ? > Instead of updating the image, Daniel asked if we could upgrade this > image to a more recent release (to remove SDL1), but IIRC the outcome > was there is no manpower for that. Meanwhile, this kludge seems the > simplest way. > BTW This command is run once at image creation.
Hi Brad, On 2/5/19 2:57 PM, Brad Smith wrote: > If someone could point me in the right direction as to how the image is > created > I could look at coming up with something newer. I would prefer that over > some > of the workarounds I've seen to date. I'm not an OpenBSD user, so I'm more than happy if you can help the upstream community to test QEMU codebase on this OS. Testing helps us to avoid code rot. What we currently use to run tests is the 'tests/vm/openbsd' script. The script itself doesn't document how it was built, but looking at the commit of his introduction fdfaa33291eb we have: The image is prepared following instructions as in: https://wiki.qemu.org/Hosts/BSD Regards, Phil. > On 2/5/2019 8:42 AM, Philippe Mathieu-Daudé wrote: >> Hi Peter, >> >> On 2/5/19 2:20 PM, Peter Maydell wrote: >>> On Tue, 29 Jan 2019 at 17:57, Philippe Mathieu-Daudé >>> <philmd@redhat.com> wrote: >>>> Various iotests scripts (run via 'make check-block') use bash >>>> specific extentions. OpenBSD comes with the Korn shell as default. >>>> Install bash to be able to run those tests. >>>> >>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >>>> --- >>>> tests/vm/openbsd | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/tests/vm/openbsd b/tests/vm/openbsd >>>> index 6263c8956b..e9c2a3f2c8 100755 >>>> --- a/tests/vm/openbsd >>>> +++ b/tests/vm/openbsd >>>> @@ -45,6 +45,8 @@ class OpenBSDVM(basevm.BaseVM): >>>> self.wait_ssh() >>>> sys.stderr.write("Disabling W^X on the build partition...\n") >>>> self.ssh_root_check("sed -E -i 's_(/tmp\ ffs)\ ([^\ >>>> ]*)_\\1 \\2,wxallowed_' /etc/fstab") >>>> + sys.stderr.write("Installing bash...\n") >>>> + >>>> self.ssh_root_check("PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64 >>>> pkg_add bash") >>>> self.ssh_root("shutdown -p now") >>>> self.wait() >>>> >>> Wouldn't it make more sense to just update the image to include >>> the necessary package, the same way we do with all QEMU's >>> other build dependencies ? >> Instead of updating the image, Daniel asked if we could upgrade this >> image to a more recent release (to remove SDL1), but IIRC the outcome >> was there is no manpower for that. Meanwhile, this kludge seems the >> simplest way. >> BTW This command is run once at image creation.
Philippe Mathieu-Daudé <philmd@redhat.com> writes: > Various iotests scripts (run via 'make check-block') use bash > specific extentions. OpenBSD comes with the Korn shell as default. > Install bash to be able to run those tests. Hmmm given we use plain POSIX shell for configure portability is there a reason the check-block test scripts use bash? I guess it doesn't get picked up as check-block isn't run normally. > > Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > --- > tests/vm/openbsd | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tests/vm/openbsd b/tests/vm/openbsd > index 6263c8956b..e9c2a3f2c8 100755 > --- a/tests/vm/openbsd > +++ b/tests/vm/openbsd > @@ -45,6 +45,8 @@ class OpenBSDVM(basevm.BaseVM): > self.wait_ssh() > sys.stderr.write("Disabling W^X on the build partition...\n") > self.ssh_root_check("sed -E -i 's_(/tmp\ ffs)\ ([^\ ]*)_\\1 \\2,wxallowed_' /etc/fstab") > + sys.stderr.write("Installing bash...\n") > + self.ssh_root_check("PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64 pkg_add bash") > self.ssh_root("shutdown -p now") > self.wait() -- Alex Bennée
On Tue, Feb 05, 2019 at 04:09:24PM +0000, Alex Bennée wrote: > > Philippe Mathieu-Daudé <philmd@redhat.com> writes: > > > Various iotests scripts (run via 'make check-block') use bash > > specific extentions. OpenBSD comes with the Korn shell as default. > > Install bash to be able to run those tests. > > Hmmm given we use plain POSIX shell for configure portability is there a > reason the check-block test scripts use bash? I guess it doesn't get > picked up as check-block isn't run normally. configure requests any POSIX shell (#!/bin/sh) & aim for portability. The block iotests though made an explicit choice not to care for POSIX shell portability and so explicitly request bash (#!/bin/bash). The block iotests are not something we expect every user of QEMU to run, so it is valid to have a more specific requirement for executing them, than is required by configure for general purpose build + unit tests. Regards, Daniel
On 2/5/2019 9:23 AM, Philippe Mathieu-Daudé wrote: > Hi Brad, > > On 2/5/19 2:57 PM, Brad Smith wrote: >> If someone could point me in the right direction as to how the image is >> created >> I could look at coming up with something newer. I would prefer that over >> some >> of the workarounds I've seen to date. > I'm not an OpenBSD user, so I'm more than happy if you can help the > upstream community to test QEMU codebase on this OS. Testing helps us to > avoid code rot. > > What we currently use to run tests is the 'tests/vm/openbsd' script. > The script itself doesn't document how it was built, but looking at the > commit of his introduction fdfaa33291eb we have: > > The image is prepared following instructions as in: > > https://wiki.qemu.org/Hosts/BSD Ok, well that brings me to my next question. How do I get access to the Wiki to update the instructions?
On Tue, Feb 05, 2019 at 03:23:53PM +0100, Philippe Mathieu-Daudé wrote: > Hi Brad, > > On 2/5/19 2:57 PM, Brad Smith wrote: > > If someone could point me in the right direction as to how the image is > > created > > I could look at coming up with something newer. I would prefer that over > > some > > of the workarounds I've seen to date. > > I'm not an OpenBSD user, so I'm more than happy if you can help the > upstream community to test QEMU codebase on this OS. Testing helps us to > avoid code rot. > > What we currently use to run tests is the 'tests/vm/openbsd' script. > The script itself doesn't document how it was built, but looking at the > commit of his introduction fdfaa33291eb we have: There also is a patch floating around to auto-install openbsd: https://patchwork.kernel.org/patch/10749459/ Not fully sure why this wasn't merged yet. One problem is that this patch depends on a new slirp feature (added in the 3.1 devel cycle, needed to serve install.conf via http). Which blocked merge during the 3.1 cycle, because depending on unreleased qemu for test builds isn't a good idea. But 3.1 is released, so maybe we can merge that for 4.0 now? The openbsd installer trying to fetch install.conf not only via http but also via tftp would also simplify things, maybe implementing that is an option for the next openbsd release? cheers, Gerd
On Tue, Feb 05, 2019 at 05:24:02PM -0500, Brad Smith wrote: > On 2/5/2019 9:23 AM, Philippe Mathieu-Daudé wrote: > > > Hi Brad, > > > > On 2/5/19 2:57 PM, Brad Smith wrote: > > > If someone could point me in the right direction as to how the image is > > > created > > > I could look at coming up with something newer. I would prefer that over > > > some > > > of the workarounds I've seen to date. > > I'm not an OpenBSD user, so I'm more than happy if you can help the > > upstream community to test QEMU codebase on this OS. Testing helps us to > > avoid code rot. > > > > What we currently use to run tests is the 'tests/vm/openbsd' script. > > The script itself doesn't document how it was built, but looking at the > > commit of his introduction fdfaa33291eb we have: > > > > The image is prepared following instructions as in: > > > > https://wiki.qemu.org/Hosts/BSD > > Ok, well that brings me to my next question. How do I get access to the Wiki > to update the instructions? I'll create you an account and send you details offlist. Regards, Daniel
On Wed, 6 Feb 2019 at 07:29, Gerd Hoffmann <kraxel@redhat.com> wrote: > There also is a patch floating around to auto-install openbsd: > https://patchwork.kernel.org/patch/10749459/ > > Not fully sure why this wasn't merged yet. One problem is that this > patch depends on a new slirp feature (added in the 3.1 devel cycle, > needed to serve install.conf via http). Which blocked merge during the > 3.1 cycle, because depending on unreleased qemu for test builds isn't a > good idea. But 3.1 is released, so maybe we can merge that for 4.0 now? The feature isn't in the installed QEMU for the Ubuntu box I run the BSD VM tests on, which is what the blocker is -- I don't want to have to keep around and maintain a non-system QEMU to run the VMs that are doing the tests here. It would be preferable to remove the dependency on the bleeding-edge slirp feature. thanks -- PMM
On 2/5/2019 8:57 AM, Brad Smith wrote: > If someone could point me in the right direction as to how the image > is created > I could look at coming up with something newer. I would prefer that > over some > of the workarounds I've seen to date. I started creating the image and then wondered what do I set the root password to? The instructions also talk about an SSH key but I don't know how that would work when this image is used for the VM test framework. I updated the instructions on the Wiki to make use of VirtIO for both the NIC and disk controller.
Brad Smith <brad@comstyle.com> writes: > On 2/5/2019 8:57 AM, Brad Smith wrote: > >> If someone could point me in the right direction as to how the image >> is created >> I could look at coming up with something newer. I would prefer that >> over some >> of the workarounds I've seen to date. > > I started creating the image and then wondered what do I set the root > password > to? The instructions also talk about an SSH key but I don't know how > that would > work when this image is used for the VM test framework. See tests/keys - basically we have a hard-wired testing key. > I updated the instructions on the Wiki to make use of VirtIO for both > the NIC and disk controller. Can the OpenBSD kernel use virtio-net-pci and virtio-scsi-pci? It's not super important for build testing but they are the most capable variants of virtio. The virtio-pci gives nice discover-able hotplug and I believe you need virtio-scsi-pci if you want to use funky options like discard for thin provisioning. -- Alex Bennée
On 2/6/2019 3:25 PM, Alex Bennée wrote: > Brad Smith <brad@comstyle.com> writes: > >> On 2/5/2019 8:57 AM, Brad Smith wrote: >> >>> If someone could point me in the right direction as to how the image >>> is created >>> I could look at coming up with something newer. I would prefer that >>> over some >>> of the workarounds I've seen to date. >> I started creating the image and then wondered what do I set the root >> password >> to? The instructions also talk about an SSH key but I don't know how >> that would >> work when this image is used for the VM test framework. > See tests/keys - basically we have a hard-wired testing key. So the root password doesn't matter? >> I updated the instructions on the Wiki to make use of VirtIO for both >> the NIC and disk controller. > Can the OpenBSD kernel use virtio-net-pci and virtio-scsi-pci? > > It's not super important for build testing but they are the most capable > variants of virtio. The virtio-pci gives nice discover-able hotplug and > I believe you need virtio-scsi-pci if you want to use funky options like > discard for thin provisioning. Yes to both.
Brad Smith <brad@comstyle.com> writes: > On 2/6/2019 3:25 PM, Alex Bennée wrote: > >> Brad Smith <brad@comstyle.com> writes: >> >>> On 2/5/2019 8:57 AM, Brad Smith wrote: >>> >>>> If someone could point me in the right direction as to how the image >>>> is created >>>> I could look at coming up with something newer. I would prefer that >>>> over some >>>> of the workarounds I've seen to date. >>> I started creating the image and then wondered what do I set the root >>> password >>> to? The instructions also talk about an SSH key but I don't know how >>> that would >>> work when this image is used for the VM test framework. >> See tests/keys - basically we have a hard-wired testing key. > So the root password doesn't matter? I don't think so. See "Adding new guests" in docs/devel/testing.rst The Ubuntu and CentOS build_image methods are a bit more elaborate in that they build a cloud-image iso which contains a bunch of metadata for the image to apply on boot-up. The OpenBSD build_image just downloads the data and uncompresses it. The defaults in BaseIMG are: GUEST_USER = "qemu" GUEST_PASS = "qemupass" ROOT_PASS = "qemupass" >>> I updated the instructions on the Wiki to make use of VirtIO for both >>> the NIC and disk controller. >> Can the OpenBSD kernel use virtio-net-pci and virtio-scsi-pci? >> >> It's not super important for build testing but they are the most capable >> variants of virtio. The virtio-pci gives nice discover-able hotplug and >> I believe you need virtio-scsi-pci if you want to use funky options like >> discard for thin provisioning. > > Yes to both. Cool. -- Alex Bennée
diff --git a/tests/vm/openbsd b/tests/vm/openbsd index 6263c8956b..e9c2a3f2c8 100755 --- a/tests/vm/openbsd +++ b/tests/vm/openbsd @@ -45,6 +45,8 @@ class OpenBSDVM(basevm.BaseVM): self.wait_ssh() sys.stderr.write("Disabling W^X on the build partition...\n") self.ssh_root_check("sed -E -i 's_(/tmp\ ffs)\ ([^\ ]*)_\\1 \\2,wxallowed_' /etc/fstab") + sys.stderr.write("Installing bash...\n") + self.ssh_root_check("PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64 pkg_add bash") self.ssh_root("shutdown -p now") self.wait()
Various iotests scripts (run via 'make check-block') use bash specific extentions. OpenBSD comes with the Korn shell as default. Install bash to be able to run those tests. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> --- tests/vm/openbsd | 2 ++ 1 file changed, 2 insertions(+)