On Thu, Jul 09, 2020 at 02:33:49PM +0900, AKASHI Takahiro wrote: > Tom, > > On Wed, Jul 08, 2020 at 11:15:26PM -0400, Tom Rini wrote: > > On Thu, Jul 09, 2020 at 09:58:03AM +0900, AKASHI Takahiro wrote: > > > > > Hi Tom, > > > > > > I'd like to make sure of your policy about usage of "sudo" on CI. > > > Do you think that we should always avoid using "sudo" in testing? > > > > > > I remember that you had allowed us to run sudo in (python) > > > test scripts on Travis CI when I requested this (for FAT filesystem?). > > > > So, the best practices at this time are to have the code try and use > > guestmount (or similar tools) when possible and fall back to sudo, as > > Ubuntu breaks guestmount (and similar tools) by default. > > See the commands log (on my ubuntu 19.10) below: > > ===8<=== > << try 1 >> > tmp$ mkdir tmpdir > tmp$ virt-make-fs -t vfat -s +1M --partition=gpt ./tmpdir tmp.img > libguestfs: error: /usr/bin/supermin exited with error status 1. > To see full error messages you may need to enable debugging. > Do: > export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 > and run the command again. For further information, read: > http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs > You can also run 'libguestfs-test-tool' and post the *complete* output > into a bug report or message to the libguestfs mailing list. > > << try 2 >> > tmp$ LIBGUESTFS_DEBUG=1 virt-make-fs -t vfat -s +1M --partition=gpt ./tmpdir > tmp.img > ... > supermin: kernel: kernel_version 5.3.0-62-generic > supermin: kernel: modpath /lib/modules/5.3.0-62-generic > cp: cannot open '/boot/vmlinuz-5.3.0-62-generic' for reading: Permission > denied > supermin: cp -p '/boot/vmlinuz-5.3.0-62-generic' > '/var/tmp/.guestfs-1000/appliance.d.op62psoy/kernel': command failed, see > earlier errors > libguestfs: error: /usr/bin/supermin exited with error status 1, see debug > messages above > ... > > << try 3 >> > tmp$ sudo chmod a+rw /boot/vmlinuz-5.3.0-62-generic > tmp$ LIBGUESTFS_DEBUG=1 virt-make-fs -t vfat -s +1M --partition=gpt ./tmpdir > tmp.img > ... > tmp$ ls -l tmp.img > -rw-r--r-- 1 akashi akashi 1341440 Jul 9 13:50 tmp.img > ===>8=== > > As you can see, virt-make-fs will fail on *standard* ubuntu. > You have to change the permission of the current kernel's binary.
Yes, exactly. This is an intentional behavior in Ubuntu (and not Debian) and why we cannot rely on the various virt tools working. I fixed the current tests over in http://patchwork.ozlabs.org/project/uboot/patch/20200707155309.24770-1-tr...@konsulko.com/ but need to follow up and try what Stephen was saying to clean it up more still. > While I can't make sure, we will have the same issue with guestmount > as it will also create a minimum virtual machine before execution. > > What does it mean? > You must change the permission every time when you re-install the OS > or re-bump the kernel version. Obviously, I can't do that from my own > test script (without sudo). > So if you don't have any way (or workaround) to deal with it, > libguestfs-tools or guestmount cannot be a solution here. Well, just like the test_fs tests, we try guestmount, if it doesn't work we fall back to just sudo'ing what we need to run directly. I think Ubuntu did something very stupid here. I just don't know if moving CI to be Debian based (and I guess Travis is just working-around the issue by default for us, given the fs tests run there today) is good enough as it will leave everyone else's Ubuntu-based setups broken. -- Tom
signature.asc
Description: PGP signature
