| 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? | 00:51 |
|---|---|---|
| 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:07 |
| sub526 | Any help is appreciated. | 01:09 |
| === cpaelzer__ is now known as cpaelzer | ||
| 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? | 10:28 |
| 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:04 |
| jibel | mvo, mounting a squashfs works fine. I tried with the squashfs of an iso | 11:11 |
| 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:12 |
| jibel | so some snap squashfses are successfully mounted | 11:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 | |
| 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:34 |
| Chipaca | Laney: tbh if this is a race, autopkgtest might be the worst place to hope to catch it | 11:36 |
| Laney | worst? | 11:36 |
| 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:37 |
| Laney | and you get to block kernels from getting into the hands of users | 11:38 |
| 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:42 |
| Laney | https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst <- "Reboot during a test" | 11:43 |
| Chipaca | this might be doable then | 11:44 |
| Chipaca | need to figure out how to repro it first :) | 11:44 |
| Laney | nod | 11:44 |
| === JanC is now known as Guest31310 | ||
| Chipaca | so, i need to have at least 42 snaps to reproduce the issue | 13:12 |
| Chipaca | and then i get a broken mount where the assignment of the loopback device went bad | 13:13 |
| === JanC_ is now known as JanC | ||
| Chipaca | jibel: #1836914 | 14:19 |
| Chipaca | mvo: ^ | 14:19 |
| jibel | bug 1836914 | 14:19 |
| ubot5 | bug 1836914 in linux (Ubuntu) "Doing multiple squashfs ((and other loop?) mounts in parallel breaks" [Undecided,New] https://launchpad.net/bugs/1836914 | 14:19 |
| jibel | Chipaca, thank you | 14:20 |
| Chipaca | made a note about it affecting 5.2 arch also | 14:22 |
| Chipaca | now to figure out which upstream kernel to try :-) | 14:22 |
| mvo | Chipaca: thank you! | 14:23 |
| 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:26 |
| 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:27 |
| LocutusOfBorg | we should really dump the log when dkms fails | 14:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!