snap try broken in containers after deb update to 2.48
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Fix Committed
|
High
|
Paweł Stołowski |
Bug Description
In a focal container, after the deb upgrade from to 2.48+20.04 (from 2.45.1+20.04.2), `snap try` no longer works.
The same tree works fine with `snap try` outside of the container
Downgrading the deb to the previous version fixed the issue
journalct output shows:
Dec 16 16:02:20 maas sudo[2191]: ack : TTY=pts/1 ; PWD=/home/
Dec 16 16:02:20 maas sudo[2191]: pam_unix(
Dec 16 16:02:21 maas systemd[1]: Reloading.
Dec 16 16:02:21 maas systemd[1]: /lib/systemd/
Dec 16 16:02:21 maas systemd[1]: systemd-
Dec 16 16:02:21 maas systemd[1]: systemd-
Dec 16 16:02:21 maas systemd[1]: systemd-
Dec 16 16:02:21 maas systemd[1]: systemd-
Dec 16 16:02:21 maas systemd[1]: Reloading.
Dec 16 16:02:22 maas systemd[1]: /lib/systemd/
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: Mounting Mount unit for maas, revision x2...
-- Subject: A start job for unit snap-maas-x2.mount has begun execution
-- Defined-By: systemd
-- Support: http://
--
-- A start job for unit snap-maas-x2.mount has begun execution.
--
-- The job identifier is 691.
Dec 16 16:02:22 maas mount[2289]: This doesn't look like a squashfs image.
Dec 16 16:02:22 maas systemd[1]: snap-maas-x2.mount: Mount process exited, code=exited, status=
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: http://
--
-- An n/a= process belonging to unit snap-maas-x2.mount has exited.
--
-- The process' exit code is 'exited' and its exit status is 255.
Dec 16 16:02:22 maas systemd[1]: snap-maas-x2.mount: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: http://
--
-- The unit snap-maas-x2.mount has entered the 'failed' state with result 'exit-code'.
Dec 16 16:02:22 maas systemd[1]: Failed to mount Mount unit for maas, revision x2.
-- Subject: A start job for unit snap-maas-x2.mount has failed
-- Defined-By: systemd
-- Support: http://
--
-- A start job for unit snap-maas-x2.mount has finished with a failure.
--
-- The job identifier is 691 and the job result is failed.
Dec 16 16:02:22 maas systemd[1]: snapd.service: Got notification message from PID 2286, but reception only permitted for main PID 315
Dec 16 16:02:22 maas systemd[1]: Reloading.
Dec 16 16:02:22 maas systemd[1]: /lib/systemd/
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: Reloading.
Dec 16 16:02:22 maas systemd[1]: /lib/systemd/
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas systemd[1]: systemd-
Dec 16 16:02:22 maas snapd[315]: taskrunner.go:271: [change 1244 "Mount snap \"maas\" (unset)" task] failed: [start snap-maas-x2.mount] failed with exit status 1: Job failed. See "journalctl -xe" for details.
Dec 16 16:02:22 maas snapd[315]: handlers.go:496: Reported install problem for "maas" as already-reported
Dec 16 16:02:22 maas sudo[2191]: pam_unix(
Changed in snapd: | |
assignee: | nobody → Paweł Stołowski (stolowski) |
Changed in snapd: | |
status: | Triaged → Confirmed |
Changed in snapd: | |
status: | In Progress → Fix Committed |
My theory but we need to add tests to prove it and debug this properly is that the issue relates to the change we made to the snapd-generator to make preseeded images work inside containers. I think we are emitting squashfs options even for dir bind mounts, and that I suppose would confuse/break things.