Bug#989145: Please do not use uml fakemachine backend in the DEP-8 test

[Lucas Kanashiro]

Package: debos
Version: 1.0.0+git20201203.e939090-4
Severity: wishlist

Dear maintainer,

The DEP-8 test recently added to src:debos, called build-chroot, makes
use of the user-mode-linux package (the fakemachine backend used).
However, user-mode-linux is not available in Ubuntu as in Debian which
leads to a test failure. I kindly ask to use a different fakemachine
backend allowing the execution of this test also in Ubuntu.

Thanks for considering this request.

Cheers!
Lucas Kanashiro.

[Steve Langasek]

The options for fakemachine backend are uml and kvm. Having this test use
KVM is not any more help for Ubuntu, because our test runners are all VMs
and nested KVM is not a supported configuration.

So switching the test to use KVM instead of UML is of no further value to
Ubuntu.

I'm not sure that the debos package works at all on Ubuntu; attempting to
manually run the autopkgtest with the KVM backend instead of the UML backend
gives me incomprehensible results:

$ sudo sh -x debian/tests/build-chroot
+ : /tmp/debos-1.0.0+git20201203.e939090/debian/tests
+ debos /tmp/debos-1.0.0+git20201203.e939090/debian/tests/example.yaml
open /tmp/fakemachine-959458465/result: no such file or directory
$

Running debos with --show-boot gives me:

[...]
modprobe: can't load module netfs (kernel/fs/netfs/netfs.ko): No such file or directory
mount: mounting usr on /usr failed: No such device
mount: mounting sbin on /sbin failed: No such device
mount: mounting bin on /bin failed: No such device
mount: mounting lib on /lib failed: No such device
/init: exec: line 2[8: / li b/ sy1.202353] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[ 1.203274] CPU: 0 PID: 1 Comm: init Not tainted 5.13.0-17-generic #17-Ubuntu
s[te md /s ys te1md.: 2n04120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
[ 1.205101] Call Trace:
ot f[ou nd
1.205402] show_stack+0x52/0x58
[ 1.205875] dump_stack+0x7d/0x9c
[ 1.206300] panic+0x101/0x2e3
[...]

(the netfs.ko module does exist in the host environment at
/lib/modules/5.13.0-17-generic/kernel/fs/netfs/netfs.ko, so I don't know why
this fails.)

So from what I can see, the package:
- cannot have meaningful autopkgtests on Ubuntu
- currently does not work on Ubuntu unless passing --disable-fakemachine,
and then only as root

We could switch the autopkgtest to use --disable-fakemachine in Ubuntu
(this wouldn't be an appropriate change to make in Debian). Is it better to
do this, or to drop the package from Ubuntu? If it doesn't work in the
default configuration, does it make sense to have this package in Ubuntu?

My current suggestion is:
- ask for an additional autopkgtest in Debian that runs with debos
--disable-fakemachine (instead of replacing the current autopkgtest)
- introduce an Ubuntu delta that drops the autopkgtest which depends on
fakemachine
- optionally, patch debos in Ubuntu to use --disable-fakemachine by default?

Lukas, what do you think?

Andrej, Héctor, do you think it makes sanse to add an additional
--disable-fakemachine autopkgtest to debos? (If not, this bug can just be
closed, and we should handle it all on the Ubuntu side.)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slan...@ubuntu.com vor...@debian.org

[Lucas Kanashiro]

On Wed, 29 Sep 2021 15:21:01 -0700 Steve Langasek
<steve.l...@canonical.com> wrote:
>
> My current suggestion is:
> - ask for an additional autopkgtest in Debian that runs with debos
> --disable-fakemachine (instead of replacing the current autopkgtest)
> - introduce an Ubuntu delta that drops the autopkgtest which depends on
> fakemachine
> - optionally, patch debos in Ubuntu to use --disable-fakemachine by
default?

Since we got no reply so far I patched debos to use
--disable-fakemachine and adjusted the test dependencies and
restrictions in Ubuntu.

Hopefully, we'll sort this out in Debian and then we can drop the delta
added.

--
Lucas Kanashiro

[Christopher Obbard]

Hi Lucas & Steve,

I plan on implementing the following when releasing a new version:

1) modify the build-chroot autopkgtest to use --disable-fakemachine in
the debos call and remove the additional dependencies (e.g. just
running on the host, this will need Restrictions: needs-sudo)

2) add an additional autopkgtest, build-chroot-uml to build a chroot
using the uml backend, but with Restrictions: skip-not-installable so
to not fail if user-mode-linux is not available in downstreams?


Would this be suitable or do you have other suggestions which would
allow downstreams to test debos without downstream patches :-)


Thanks!

Chris

[Lucas Kanashiro]

Hi Chris,

I think you meant "needs-root" restriction here, right?

> 2) add an additional autopkgtest, build-chroot-uml to build a chroot
> using the uml backend, but with Restrictions: skip-not-installable so
> to not fail if user-mode-linux is not available in downstreams?

This is a possible solution, it should work fine.

> Would this be suitable or do you have other suggestions which would
> allow downstreams to test debos without downstream patches :-)

I believe with that we will be able to make is a sync from Debian again
in Ubuntu. Thanks for working on it.

--
Lucas Kanashiro

[Christopher Obbard]

Well, either works for me, but typically a user who is using debos with
--disable-fakemachine will use sudo to elevate privileges rather than
running as the root account. This will make the test better reflect
reality. Does it make sense to use needs-sudo in this case?

[Lucas Kanashiro]

Aha, OK. I thought you got confused with the restriction name but no, I
was not aware of this new restriction, sorry :)

Looking at its description, it seems what you want indeed.

--
Lucas Kanashiro

[Steve Langasek]

On Mon, Oct 24, 2022 at 12:37:36PM +0100, Christopher Obbard wrote:

> > > 1) modify the build-chroot autopkgtest to use --disable-fakemachine in
> > > the debos call and remove the additional dependencies (e.g. just
> > > running on the host, this will need Restrictions: needs-sudo)

> > I think you meant "needs-root" restriction here, right?

> Well, either works for me, but typically a user who is using debos with
> --disable-fakemachine will use sudo to elevate privileges rather than
> running as the root account. This will make the test better reflect
> reality. Does it make sense to use needs-sudo in this case?

I'm not sure if Debian infrastructure implements support for the needs-sudo
restriction to start the tests as non-root. Ubuntu's infrastructure does
not.