[00:51] <sub526> While building ubuntu-xenial kernel it failed for me with "debian/rules.d/4-checks.mk: recipe for target 'module-check-generic' failed", how to solve this error?
[01:07] <sub526> Again just retried building the kernel by executing "fakeroot debian/rules binary-headers binary-generic binary-perarch" but this time got different error "mv: cannot move '/home/sa/ubuntu-xenial/debian/linux-modules-4.4.0-154-generic/lib/modules/4.4.0-154-generic/kernel' to '/home/sa/ubuntu-xenial/debian/linux-modules-extra-4.4.0-154-generic/lib/m
[01:07] <sub526> odules/4.4.0-154-generic/kernel/kernel': Directory not empty
[01:07] <sub526> debian/rules.d/2-binary-arch.mk:123: recipe for target 'install-generic' failed
[01:09] <sub526> Any help is appreciated.
[10:28] <jibel> hi, I just reported https://forum.snapcraft.io/t/cannot-launch-snaps-on-eoan-and-kernel-5-2/12341 which is apparently caused by kernel 5.2. Could someone help to bisect this?
[11:04] <mvo> jibel: thanks for digging into the 5.2 squashfs mount issue! I wonder if its just snaps or any squashfs (or loop mount) that is broken? you could create a squashfs file with mksquashfs and try to mount it to double check (if you are on this already anyway, if not I can install 5.2 and see what happens)
[11:11] <jibel> mvo, mounting a squashfs works fine. I tried with the squashfs of an iso
[11:12] <jibel> mvo, I added a comment to the report. I seems that it tried to mount loop devices on already mounted loop devices
[11:12] <jibel> in my case it attempts to mount vscode on loop21 but freemind is already mounted on it.
[11:13] <jibel> so some snap squashfses are successfully mounted
[11:15] <Chipaca> jibel: mvo: I suspect it's the attempt at doing all the mounts together at boot that trips it up
[11:15] <ogra> are you sure it is kernel and not systemd's way to do the mounts ?
[11:15] <Chipaca> ogra: rebooting into 5.0 makes the issue go away
[11:16] <ogra> yeah, sure ... not saying it isnt triggered by the kernel ... 
[11:16] <Chipaca> jibel: i.e. to repro without snapd, you'll need to do a lot of parallel mounts :-)
[11:16] <ogra> but if manual mounting gives you properly numbered loop devices it smells more like systemd is messing it up
[11:16] <Chipaca> a lot == 10? maybe more
[11:17] <Chipaca> ogra: when doing a single mount there is no race between assigning a loop device and using it for the mount
[11:17] <ogra> (using mount /dev/loop$(rand()) ;) ... )
[11:18] <Chipaca> I'll stop for lunch, and then look at repro'ing this without snaps, in a vm
[11:18] <Chipaca> jibel: is there a live image with 5.2 already?
[11:18] <mvo> Chipaca, jibel aha, yes - a race a boot - that makes sense
[11:19] <Chipaca> answering my question, yesterday's pending is 5.2, good enough for me
[11:19] <Chipaca> (downloaded it because of a different issue :)
[11:19] <jibel> Chipaca, http://cdimage.ubuntu.com/daily-live/pending/
[11:19] <Chipaca> jibel: poncho!
[11:19] <Chipaca> wait how does that work on the internet
[11:19]  * Chipaca gives up and goes for lunch
[11:34] <Laney> it'd be good to add an autopkgtest which would have caught this
[11:34] <Laney> new kernels do trigger snapd's tests
[11:34] <Laney> Chipaca: mvo: 
[11:34] <Laney> dunno if you want to put that on your backlog or something
[11:36] <Chipaca> Laney: tbh if this is a race, autopkgtest might be the worst place to hope to catch it
[11:36] <Laney> worst?
[11:37] <Chipaca> Laney: autopkgtest seems to run on a powerpc nubus mac emulating a 386sx running dosbox for the amd64 build, or something :-)
[11:37] <Chipaca> i mean it's quite slow
[11:37] <Chipaca> so timing issues there are different
[11:37] <Laney> sounds like a good place to make race conditions happen to me
[11:37] <Laney> it's the place where new kernels automatically trigger tests of your stuff
[11:38] <Laney> and you get to block kernels from getting into the hands of users
[11:42] <Chipaca> Laney: can autopkgtest be rebooted from a test?
[11:42] <Laney> yes
[11:42] <Chipaca> that is, can a test say "and now reboot plz"
[11:42] <Chipaca> and then it carries on?
[11:42] <Laney> you set a "marker" and then when it carries on you can check that variable
[11:43] <Laney> https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst <- "Reboot during a test"
[11:44] <Chipaca> this might be doable then
[11:44] <Chipaca> need to figure out how to repro it first :)
[11:44] <Laney> nod
[13:12] <Chipaca> so, i need to have at least 42 snaps to reproduce the issue
[13:13] <Chipaca> and then i get a broken mount where the assignment of the loopback device went bad
[14:19] <Chipaca> jibel: #1836914
[14:19] <Chipaca> mvo: ^
[14:19] <jibel> bug 1836914
[14:20] <jibel> Chipaca, thank you
[14:22] <Chipaca> made a note about it affecting 5.2 arch also
[14:22] <Chipaca> now to figure out which upstream kernel to try :-)
[14:23] <mvo> Chipaca: thank you!
[14:26] <Chipaca> huh, the amd64 builds are failing
[14:26] <LocutusOfBorg> hello guys... http://autopkgtest.ubuntu.com/packages/d/ddcci-driver-linux/eoan/s390x this is failing only on s390x, and of course it looks like because of the new kernel
[14:27] <LocutusOfBorg> unfortunately this is an error that happens only on that architecture... how can I dump the make.log file without having an s390x machine=
[14:27] <LocutusOfBorg> ?
[14:27] <LocutusOfBorg> (it is regressed in release FWIW)
[14:30] <LocutusOfBorg> we should really dump the log when dkms fails