[00:51] 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] 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] odules/4.4.0-154-generic/kernel/kernel': Directory not empty [01:07] debian/rules.d/2-binary-arch.mk:123: recipe for target 'install-generic' failed [01:09] Any help is appreciated. === cpaelzer__ is now known as cpaelzer [10:28] 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] 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] mvo, mounting a squashfs works fine. I tried with the squashfs of an iso [11:12] mvo, I added a comment to the report. I seems that it tried to mount loop devices on already mounted loop devices [11:12] in my case it attempts to mount vscode on loop21 but freemind is already mounted on it. [11:13] so some snap squashfses are successfully mounted [11:15] jibel: mvo: I suspect it's the attempt at doing all the mounts together at boot that trips it up [11:15] are you sure it is kernel and not systemd's way to do the mounts ? [11:15] ogra: rebooting into 5.0 makes the issue go away [11:16] yeah, sure ... not saying it isnt triggered by the kernel ... [11:16] jibel: i.e. to repro without snapd, you'll need to do a lot of parallel mounts :-) [11:16] but if manual mounting gives you properly numbered loop devices it smells more like systemd is messing it up [11:16] a lot == 10? maybe more [11:17] ogra: when doing a single mount there is no race between assigning a loop device and using it for the mount [11:17] (using mount /dev/loop$(rand()) ;) ... ) [11:18] I'll stop for lunch, and then look at repro'ing this without snaps, in a vm [11:18] jibel: is there a live image with 5.2 already? [11:18] Chipaca, jibel aha, yes - a race a boot - that makes sense [11:19] answering my question, yesterday's pending is 5.2, good enough for me [11:19] (downloaded it because of a different issue :) [11:19] Chipaca, http://cdimage.ubuntu.com/daily-live/pending/ [11:19] jibel: poncho! [11:19] wait how does that work on the internet [11:19] * Chipaca gives up and goes for lunch [11:34] it'd be good to add an autopkgtest which would have caught this [11:34] new kernels do trigger snapd's tests [11:34] Chipaca: mvo: [11:34] dunno if you want to put that on your backlog or something [11:36] Laney: tbh if this is a race, autopkgtest might be the worst place to hope to catch it [11:36] worst? [11:37] Laney: autopkgtest seems to run on a powerpc nubus mac emulating a 386sx running dosbox for the amd64 build, or something :-) [11:37] i mean it's quite slow [11:37] so timing issues there are different [11:37] sounds like a good place to make race conditions happen to me [11:37] it's the place where new kernels automatically trigger tests of your stuff [11:38] and you get to block kernels from getting into the hands of users [11:42] Laney: can autopkgtest be rebooted from a test? [11:42] yes [11:42] that is, can a test say "and now reboot plz" [11:42] and then it carries on? [11:42] you set a "marker" and then when it carries on you can check that variable [11:43] https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst <- "Reboot during a test" [11:44] this might be doable then [11:44] need to figure out how to repro it first :) [11:44] nod === JanC is now known as Guest31310 [13:12] so, i need to have at least 42 snaps to reproduce the issue [13:13] and then i get a broken mount where the assignment of the loopback device went bad === JanC_ is now known as JanC [14:19] jibel: #1836914 [14:19] mvo: ^ [14:19] bug 1836914 [14:19] bug 1836914 in linux (Ubuntu) "Doing multiple squashfs ((and other loop?) mounts in parallel breaks" [Undecided,New] https://launchpad.net/bugs/1836914 [14:20] Chipaca, thank you [14:22] made a note about it affecting 5.2 arch also [14:22] now to figure out which upstream kernel to try :-) [14:23] Chipaca: thank you! [14:26] huh, the amd64 builds are failing [14:26] 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] 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] ? [14:27] (it is regressed in release FWIW) [14:30] we should really dump the log when dkms fails