`cd /sys` lands in real instead of simulated /sys

[xnox]

so, ubiquity does check for existance of /sys/firmware/efi/efivars

that doesn't work when ubiquity is running under umockdev.

i.e.

$ sudo umockdev-run bash
$ ls /sys/firmware/efi/efivars
ls: cannot open directory '/sys/firmware/efi/efivars': No such file or directory
$ cd /sys/firmware/efi/efivars
$ ls
....
lots of files
....

I guess that direntry emulation is expensive, but it would be nice if umockdev did emulate /sys/firmware/efi/efivars if the host system has it.

As behaviour is different in ubuntu-drivers when on efi and when on non-efi.

[martinpitt]

Hey @xnox, how are you?

$ sudo umockdev-run bash

No need for sudo BTW -- umockdev is primarily meant for running unit tests without root privileges. That said, it should of course work as root as well.

$ ls /sys/firmware/efi/efivars
ls: cannot open directory '/sys/firmware/efi/efivars': No such file or directory

That's expected -- you didn't put anything into the testbed, so /sys is empty by default:

$ umockdev-run -- ls -l /sys
total 0

You can certainly mkdir -p $UMOCKDEV_DIR/sys/firmware/efi/efivars to fill your simulated testbed. Normally that's done by umockdev-run's --device option, but you can muck around with /sys, /dev, and /proc as you like.

$ cd /sys/firmware/efi/efivars

that is the unexpected thing here -- this changes into the real /sys, not the faked one in $UMOCKDEV_DIR. Curious that apparently nobody ever noticed that until now. I guess umockdev needs to intercept chdir(). I devote this issue to that.

[martinpitt]

Fixed in master, thanks for the report! There is still one remaining corner case which doesn't work: cd /; ls sys, i.e. relative paths into the emulated directories. I'm looking at that now.

[xnox]

When enabled, the preload library diverts access to /proc and /dev to the corresponding directories in $UMOCKDEV_DIR, aka. umockdev_testbed_get_root(). However, if a path does not exist there, it falls through the real /proc and /dev. Thus you can easily replace files like /proc/cpuinfo or add new ones without losing standard files such as /dev/null or /proc/pid/*.

Ermhf =) that's a step in the wrong direction for me =)))))))) but maybe this can be solved.

My bug report is that I did not polulate /sys/firmware/efi/efivars and fallthrough to it, is not implemented correctly.

I expect for ls /sys/firmware/efi/efivars to return lots of files under umockdev-run, and instead it does not.

I want the hosts /sys/firmware/efi/efivars to be transparent in the testbed environment. And yet it is not there. I do not want to repopulate or fake all of the Efivars. There is lots of them.

Note that none of the files in /sys/firmware/efi/efivars are ever provided by the sysfs. Instead that's efivars mountpoint of the UEFI firmware variables of the host. In my case I boot my host with UEFI secureboot and want the umockdev environment to continue operate correctly with believe that UEFI secureboot is on.

[xnox]

Maybe that needs to be reverted, and instead in https://github.com/tseliot/ubuntu-drivers-common/blob/master/share/fake-devices-wrapper i should add things to bind-mount efivars.

[xnox]

I've now opened https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1906320 hopefully, with my now improved understanding of umockdev testbed, it is the right approach.

I.e. the /usr/share/ubuntu-drivers-common/fake-devices-wrapper should bindmount and/or populate efivars.

[martinpitt]

I expect for ls /sys/firmware/efi/efivars to return lots of files under umockdev-run, and instead it does not.

Right, that's by design -- the whole raison d'être of umockdev is to simulate an user-defined /sys, so that tests don't have to rely on hardware.

You can try something like this:

mkdir -p $UMOCKDEV_DIR/sys/firmware/efi
cp -r /sys/firmware/efi/efivars $UMOCKDEV_DIR/sys/firmware/efi

but beware that this is breaking tests in the sense that you make the test dependent on the hardware it's running on. So I rather suggest making tarballs of a bunch of real systems with the properties that you want, and unpack these in your test cases.