Morning, I’m just trying a simple install, any install fails in the same way and I see no errors in journalctl or much from strace output. I notice in other posts that a service known as status snap-core-.mount usually appears but I have no such service. Used an out the box install of snapd
$ sudo systemctl status snap-core-8935.mount
Unit snap-core-8935.mount could not be found.
$ snap install hello-world
error: cannot perform the following tasks:
- Mount snap “core” (8935) (exit status 1)
$ snap version
snap 2.43.3-1.fc33
snapd 2.43.3-1.fc33
series 16
fedora 33
kernel 5.7.0-0.rc0.git2.1.fc33.x86_64
$ systemctl status snap*
● snapd.service - Snappy daemon
Loaded: loaded (/usr/lib/systemd/system/snapd.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2020-04-16 08:21:20 BST; 1min 27s ago
TriggeredBy: ● snapd.socket
Main PID: 77806 (snapd)
Tasks: 11 (limit: 9277)
Memory: 131.6M
CPU: 6.349s
CGroup: /system.slice/snapd.service
└─77806 /usr/libexec/snapd/snapd
Apr 16 08:21:20 chuwi systemd[1]: Starting Snappy daemon…
Apr 16 08:21:20 chuwi snapd[77806]: AppArmor status: apparmor not enabled
Apr 16 08:21:20 chuwi snapd[77806]: daemon.go:346: started snapd/2.43.3-1.fc33 (series 16; classic; devmode) fedora/33 (amd64) linux/5.7.0-0.rc0.git2.1.fc33.x.
Apr 16 08:21:20 chuwi snapd[77806]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Apr 16 08:21:20 chuwi systemd[1]: Started Snappy daemon.
Apr 16 08:21:24 chuwi snapd[77806]: api.go:986: Installing snap “hello-world” revision unset
Apr 16 08:21:31 chuwi snapd[77806]: handlers.go:496: Reported install problem for “core” as already-reported
● snapd.socket - Socket activation for snappy daemon
Loaded: loaded (/usr/lib/systemd/system/snapd.socket; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-04-12 13:33:06 BST; 3 days ago
Triggers: ● snapd.service
Listen: /run/snapd.socket (Stream)
/run/snapd-snap.socket (Stream)
Tasks: 0 (limit: 9277)
Memory: 0B
CPU: 3ms
CGroup: /system.slice/snapd.socket
Apr 12 13:33:06 chuwi systemd[1]: Starting Socket activation for snappy daemon.
Apr 12 13:33:06 chuwi systemd[1]: Listening on Socket activation for snappy daemon.
[pid 78812] futex(0x55e6d7b79108, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished …>
[pid 78857] write(2, “error: cannot perform the follow”…, 86 <unfinished …>
error: cannot perform the following tasks:
- Mount snap “core” (8935) (exit status 1)
[pid 78847] <… futex resumed>) = 0
[pid 78815] futex(0xc00005cbc8, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished …>
[pid 78813] nanosleep({tv_sec=0, tv_nsec=20000}, <unfinished …>
$ strace -fe trace=file /usr/bin/snap install hello-world
.snap/auth.json", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
error: cannot perform the following tasks:
- Mount snap “core” (8935) (exit status 1)
[pid 79208] +++ exited with 1 +++
[pid 79235] +++ exited with 1 +++
[pid 79204] +++ exited with 1 +++
[pid 79203] +++ exited with 1 +++
[pid 79205] +++ exited with 1 +++
[pid 79207] +++ exited with 1 +++
[pid 79242] +++ exited with 1 +++
[pid 79206] +++ exited with 1 +++
+++ exited with 1 +++
Thanks for reporting this. Anything worthy in audit log maybe?
Also, systemctl status probably won’t show the mount, please take a look at the system journal around the time you tried to install the snap.
oh yes I took a look at that too and saw no errors, anything auth related seems fine. No related errors in the journalctl -xe output, only lines such as these. Is their a way I can manually attempt the mount or step through to see at what stage it is failing?
Apr 16 08:21:24 chuwi snapd[77806]: api.go:986: Installing snap “hello-world” revision unset
Apr 16 08:21:31 chuwi snapd[77806]: handlers.go:496: Reported install problem for “core” as already-reported
You can try doing snap download hello-world and then mount the squashfs manually:
$ mount $PWD/hello-world_*.snap /mnt/<someplace>
Does it work?
yes it does, seems odd to me. Thanks for your help so far, Install after still seems to fail as shown:
$ sudo snap download hello-world
Fetching snap “hello-world”
Fetching assertions for “hello-world”
Install the snap with:
snap ack hello-world_29.assert
snap install hello-world_29.snap
$ sudo mount $PWD/*.snap /tmp
tmp]$ ls
bin meta
$ sudo snap download hello-world
Fetching snap “hello-world”
Fetching assertions for “hello-world”
Install the snap with:
snap ack hello-world_29.assert
snap install hello-world_29.snap
chuwi tmp]$ sudo snap ack hello-world_29.assert
chuwi tmp]$ sudo snap install hello-world_29.snap
error: cannot install snap file: exit status 1
Can you try this:
$ systemd-mount \
-o context=system_u:object_r:snappy_snap_t:s0 \
$PWD/hello-world_*.snap /mnt/<someplace>
yeah works also, forgot to specify mount point so run/media was used:
$ sudo systemd-mount \
-o context=system_u:object_r:snappy_snap_t:s0
$PWD/hello-world_*.snap
Started unit run-media-system-hello\x2dworld_29.snap.mount for mount point: /run/media/system/hello-world_29.snap
$ ls -l /run/media/system/hello-world_29.snap/*
/run/media/system/hello-world_29.snap/bin:
total 2
-rwxr-xr-x 1 root root 31 Jul 11 2016 echo
-rwxr-xr-x 1 root root 27 Jul 11 2016 env
-rwxr-xr-x 1 root root 274 Jul 11 2016 evil
-rwxr-xr-x 1 root root 271 Apr 17 2019 sh
/run/media/system/hello-world_29.snap/meta:
total 1
drwxrwxr-x 2 root root 31 Jul 11 2016 gui
-rw-r–r-- 1 root root 598 Apr 17 2019 snap.yaml
$ systemctl status run-media-system-hello\x2dworld_29.snap.mount
● run-media-system-hello\x2dworld_29.snap.mount - /run/media/system/hello-world_29.snap
Loaded: loaded (/run/systemd/transient/run-media-system-hello\x2dworld_29.snap.mount; transient)
Transient: yes
Active: active (mounted) since Thu 2020-04-16 14:40:37 BST; 1min 32s ago
Where: /run/media/system/hello-world_29.snap
What: /dev/loop0
Tasks: 0 (limit: 9277)
Memory: 280.0K
CPU: 21ms
CGroup: /system.slice/run-media-system-hello\x2dworld_29.snap.mount
Apr 16 14:40:37 chuwi systemd[1]: Mounting /run/media/system/hello-world_29.snap…
Apr 16 14:40:37 chuwi systemd[1]: Mounted /run/media/system/hello-world_29.snap.
Just for the record, can you do the following:
$ systemctl edit snapd.service
Then add:
[Unit]
Environment=SNAPD_DEBUG=1
And restart snapd.service, this should enable more information in the logs.
Please collect the output of snap change --last=install, should contain the error log you got.
And lastly, can you try doing systemctl daemon-reexec, does that change anything?
After I do this the service becomes inactive… then works after I give it time to start: I used edit --full in the end.
$ sudo systemctl status snapd.service
● snapd.service - Snappy daemon
Loaded: loaded (/etc/systemd/system/snapd.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/snapd.service.d
└─override.conf
Active: inactive (dead) since Thu 2020-04-16 15:02:54 BST; 3s ago
TriggeredBy: ● snapd.socket
Process: 106599 ExecStart=/usr/libexec/snapd/snapd (code=exited, status=42)
Main PID: 106599 (code=exited, status=42)
CPU: 459ms
Apr 16 15:02:49 chuwi systemd[1]: Starting Snappy daemon…
Apr 16 15:02:49 chuwi snapd[106599]: AppArmor status: apparmor not enabled
Apr 16 15:02:49 chuwi snapd[106599]: daemon.go:346: started snapd/2.43.3-1.fc33 (series 16; classic; devmode) fedora/33 (amd64) linux/5.7.0-0.rc0.git2.1.fc33.x.
Apr 16 15:02:49 chuwi snapd[106599]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Apr 16 15:02:49 chuwi systemd[1]: Started Snappy daemon.
Apr 16 15:02:54 chuwi snapd[106599]: daemon.go:540: gracefully waiting for running hooks
Apr 16 15:02:54 chuwi snapd[106599]: daemon.go:542: done waiting for running hooks
Apr 16 15:02:54 chuwi snapd[106599]: daemon stop requested to wait for socket activation
Apr 16 15:02:54 chuwi systemd[1]: snapd.service: Succeeded.
$ sudo systemctl status snapd.service
● snapd.service - Snappy daemon
Loaded: loaded (/etc/systemd/system/snapd.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/snapd.service.d
└─override.conf
Active: active (running) since Thu 2020-04-16 15:08:10 BST; 2min 1s ago
TriggeredBy: ● snapd.socket
Main PID: 108091 (snapd)
Tasks: 11 (limit: 9277)
Memory: 121.4M
CPU: 6.466s
CGroup: /system.slice/snapd.service
└─108091 /usr/libexec/snapd/snapd
Apr 16 15:08:09 chuwi systemd[1]: Starting Snappy daemon…
Apr 16 15:08:10 chuwi snapd[108091]: AppArmor status: apparmor not enabled
Apr 16 15:08:10 chuwi snapd[108091]: daemon.go:346: started snapd/2.43.3-1.fc33 (series 16; classic; devmode) fedora/33 (amd64) linux/5.7.0-0.rc0.git2.1.fc33.x.
Apr 16 15:08:10 chuwi snapd[108091]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Apr 16 15:08:10 chuwi systemd[1]: Started Snappy daemon.
Apr 16 15:08:10 chuwi snapd[108091]: api.go:986: Installing snap “hello-world” revision unset
Apr 16 15:08:18 chuwi snapd[108091]: handlers.go:496: Reported install problem for “core” as already-reported
With that DEBUG=1 enabled:
$ sudo snap install hello-world
error: cannot perform the following tasks:
- Mount snap “core” (8935) (exit status 1)
$ snap change --last=install
Status Spawn Ready Summary
Done today at 15:08 BST today at 15:08 BST Ensure prerequisites for “hello-world” are available
Hold today at 15:08 BST today at 15:08 BST Download snap “hello-world” (29) from channel “stable”
Hold today at 15:08 BST today at 15:08 BST Fetch and check assertions for snap “hello-world” (29)
Hold today at 15:08 BST today at 15:08 BST Mount snap “hello-world” (29)
Hold today at 15:08 BST today at 15:08 BST Copy snap “hello-world” data
Hold today at 15:08 BST today at 15:08 BST Setup snap “hello-world” (29) security profiles
Hold today at 15:08 BST today at 15:08 BST Make snap “hello-world” (29) available to the system
Hold today at 15:08 BST today at 15:08 BST Automatically connect eligible plugs and slots of snap “hello-world”
Hold today at 15:08 BST today at 15:08 BST Set automatic aliases for snap “hello-world”
Hold today at 15:08 BST today at 15:08 BST Setup snap “hello-world” aliases
Hold today at 15:08 BST today at 15:08 BST Run install hook of “hello-world” snap if present
Hold today at 15:08 BST today at 15:08 BST Start snap “hello-world” (29) services
Hold today at 15:08 BST today at 15:08 BST Run configure hook of “hello-world” snap if present
Hold today at 15:08 BST today at 15:08 BST Run health check of “hello-world” snap
Done today at 15:08 BST today at 15:08 BST Ensure prerequisites for “core” are available
Undone today at 15:08 BST today at 15:08 BST Download snap “core” (8935) from channel “stable”
Done today at 15:08 BST today at 15:08 BST Fetch and check assertions for snap “core” (8935)
Error today at 15:08 BST today at 15:08 BST Mount snap “core” (8935)
Hold today at 15:08 BST today at 15:08 BST Copy snap “core” data
Hold today at 15:08 BST today at 15:08 BST Setup snap “core” (8935) security profiles
Hold today at 15:08 BST today at 15:08 BST Make snap “core” (8935) available to the system
Hold today at 15:08 BST today at 15:08 BST Automatically connect eligible plugs and slots of snap “core”
Hold today at 15:08 BST today at 15:08 BST Set automatic aliases for snap “core”
Hold today at 15:08 BST today at 15:08 BST Setup snap “core” aliases
Hold today at 15:08 BST today at 15:08 BST Run install hook of “core” snap if present
Hold today at 15:08 BST today at 15:08 BST Start snap “core” (8935) services
Hold today at 15:08 BST today at 15:08 BST Run configure hook of “core” snap if present
Hold today at 15:08 BST today at 15:08 BST Run health check of “core” snap
…
Mount snap “core” (8935)
2020-04-16T15:08:17+01:00 ERROR exit status 1
That’s rawhide, right? If so, I’ll check later today/tomorrow when preparing snapd rpm updates.
1 Like
The bad news is that it works for me™. The good news is that it works in general. Can you double check that kernel-modules for your current is installed?
yep this is what I am running, did an update to latest then rebooted and tried again but same error occurs.
kernel-modules-5.7.0-0.rc0.git2.1.fc33.x86_64
kernel-modules-5.7.0-0.rc1.20200414git8632e9b5645b.1.fc33.x86_64
I’m just here wondering what snapd does when it attempts to mount this snap core and fails, yet I can do everything fine manually. And installs still seem to fail even after downloading and ack first.
Snapd generates a mount unit for systemd, calls systemctl daemon-reload, systemctl enable and finally systemctl start to start the unit. Maybe you can try using strace -vf -p <snapd-pid> -s 4096, this will generate lots of logs. You then need to find when systemctl is called, and see whether it logs anything useful.
I see. I’ll try that again tomorrow, at first glance strace -vp output I can’t see anything of use just doing a quick scan.
From other forum posts and when I ran manually I did see the mount unit on systemd. Otherwise on my system the unit does not exist, it is not created by the snapd process automatically as you would expect. Perhaps this has something to do with the version of systemd being used? I am using this:
systemd-debugsource-245.4-2.fc33.x86_64
systemd-devel-245.4-2.fc33.x86_64
systemd-bootchart-233-6.fc32.x86_64
systemd-245.4-2.fc33.x86_64
systemd-udev-245.4-2.fc33.x86_64
systemd-libs-debuginfo-245.4-2.fc33.x86_64
systemd-libs-245.4-2.fc33.x86_64
systemd-debuginfo-245.4-2.fc33.x86_64
Then it must be failing on that initial step of creating that mount unit automatically when install is called somehow as it just doesn’t seem to occur but works fine when I manually do so. I have done various tracing but nothing comes up.
