snap and the amount loop back devices and duplicate snaps
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
New
|
Undecided
|
Unassigned |
Bug Description
in the recent times my harddrive went into read only mode and the cluprit was always a checksum error in one of the snap cache directories.
today i investigated more about this issue and I was shocked to find that every snap application is some what chrooted using a bind with a local loop
```
\oop5 7:5 0 62M 1 loop /snap/core20/1611
loop7 7:7 0 70.4M 1 loop /snap/core22/188
loop8 7:8 0 70.4M 1 loop /snap/core22/275
loop9 7:9 0 6.3M 1 loop /snap/curl/1046
loop10 7:10 0 6.3M 1 loop /snap/curl/1093
loop11 7:11 0 118.4M 1 loop /snap/docker/1779
loop12 7:12 0 178.4M 1 loop /snap/firefox/1877
loop13 7:13 0 237.3M 1 loop /snap/firefox/1883
loop14 7:14 0 164.8M 1 loop /snap/gnome-
loop15 7:15 0 219M 1 loop /snap/gnome-
loop16 7:16 0 346.3M 1 loop /snap/gnome-
loop17 7:17 0 346.3M 1 loop /snap/gnome-
loop18 7:18 0 137M 1 loop /snap/golangci-
loop19 7:19 0 440.6M 1 loop /snap/gradle/134
loop20 7:20 0 91.7M 1 loop /snap/gtk-
loop21 7:21 0 37.1M 1 loop /snap/hunspell-
loop22 7:22 0 57.2M 1 loop /snap/kops/18
loop23 7:23 0 10.9M 1 loop /snap/kubectl/2591
loop24 7:24 0 6.9M 1 loop /snap/kubectx/17
loop25 7:25 0 10.9M 1 loop /snap/kubectl/2624
loop26 7:26 0 87.4M 1 loop /snap/moon-
loop27 7:27 0 81.3M 1 loop /snap/gtk-
loop28 7:28 0 187.6M 1 loop /snap/postman/183
loop29 7:29 0 188.3M 1 loop /snap/postman/184
loop30 7:30 0 112.4M 1 loop /snap/slack/65
loop31 7:31 0 112.4M 1 loop /snap/slack/66
loop32 7:32 0 45.9M 1 loop /snap/snap-
loop33 7:33 0 45.9M 1 loop /snap/snap-
loop34 7:34 0 48M 1 loop /snap/snapd/16778
loop35 7:35 0 48M 1 loop /snap/snapd/17029
loop36 7:36 0 20.5M 1 loop /snap/terraform/395
loop37 7:37 0 20.5M 1 loop /snap/terraform/400
loop38 7:38 0 123.8M 1 loop /snap/tusk/29
loop39 7:39 0 4.6M 1 loop /snap/yq/1805
```
and there is duplicates too, what is the reasoning behind this behaviour, I am quite sure the concurrent writes being made by snap on cache files at somepoint ends up with a invalid checksuym causing a panic in the file system.
can you please explain your rational behind this (if its sandboxing is it worth the amount of block device thaat it keeps allocating? why arent the old versions being removed.
We trust the ubuntu apt system and it works, but i guess you thought it's slow and created a new system wuth less timeline to publish, but since you probably don;t go through recogorse testing you decided to sandbox the apps, causing different kind of issues for a high demand user.
Can you please give the user the option to decide when installking that they can be installed in the natural way other apps are installed,
I am going to go uninstall all these snaps and install them manually, because i don't want to suffer from another disk issue with what so ever bug in your snap application framework.
call it a bug or feature, i am the one at fault for not reading up more about how snap works, all
it just so happend as i was writing this bug report, all i did in the machine was trying to uninstall docker that was installed with snap
[ 3434.095271] EXT4-fs error (device sda2): ext4_lookup:1808: inode #1448099: comm tar: iget: checksum invalid
[ 3434.095276] Aborting journal on device sda2-8.
[ 3434.096720] EXT4-fs error (device sda2): ext4_journal_
[ 3434.096736] EXT4-fs error (device sda2): ext4_journal_
[ 3434.133216] EXT4-fs (sda2): Remounting filesystem read-only
[ 3902.863233] kauditd_printk_skb: 10 callbacks suppressed
here we go another waste of time for a reboot
and here we go, always problems in the snap .cache
Pass 2: Checking directory structure snap/slack/ common/ .cache/ gio-modules/ libgiognomeprox y.so (inode #6295303) is invalid. snap/slack/ common/ .cache/ gio-modules/ libgiognutls. so (inode #6295304) is invalid. snap/slack/ common/ .cache/ immodules/ im-cyrillic- translit. so (inode #6295320) is invalid.
Symlink /home/nayana/
Symlink /home/nayana/
Symlink /home/nayana/