This is unexpected. Were there any failed refreshes maybe? Can you check the output of snap changes ? If there is a recent change that has status other than Done, please attach the output of snap change <id> for it.
It seems no changes with a status other than done, am posting anyway just in case I misunderstood?
$ snap changes ID Status Spawn Ready Summary 4 Done yesterday at 16:56 EDT yesterday at 16:57 EDT Install "core" snap 5 Done yesterday at 19:19 EDT yesterday at 19:19 EDT Remove snaps "gnome-3-28-1804", "gtk-common-themes" 6 Done yesterday at 19:19 EDT yesterday at 19:19 EDT Install snaps "gnome-3-28-1804", "gtk-common-themes"
Yeah, there don’t appear to be any changes that triggered that or maybe they were already garbage collected. Can inspect the journal between Jun 09 11:00 and 12:00 and attach it? The command should be sudo journalctl --since '2021-06-09 11:00' --until '2021-06-09 12:00'
ok, that gives me:
$ sudo journalctl --since ‘2021-06-09 11:00’ --until ‘2021-06-09 12:00’
– Logs begin at Wed 2021-06-09 11:24:40 EDT, end at Fri 2021-06-11 09:36:23 EDT. –
Jun 09 11:24:40 localhost kernel: Linux version 5.4.98-1.fc25.qubes.x86_64 (user@build-fedora4) (gcc version 6.4.1 20
Jun 09 11:24:40 localhost kernel: Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH rd.p
Jun 09 11:24:40 localhost kernel: x86/fpu: Supporting XSAVE feature 0x001: ‘x87 floating point registers’
Jun 09 11:24:40 localhost kernel: x86/fpu: Supporting XSAVE feature 0x002: ‘SSE registers’
Jun 09 11:24:40 localhost kernel: x86/fpu: Supporting XSAVE feature 0x004: ‘AVX registers’
Jun 09 11:24:40 localhost kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Jun 09 11:24:40 localhost kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using ‘standard’ f
Jun 09 11:24:40 localhost kernel: BIOS-provided physical RAM map:
Jun 09 11:24:40 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
Jun 09 11:24:40 localhost kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fefff] reserved
Jun 09 11:24:40 localhost kernel: BIOS-e820: [mem 0x00000000000ff000-0x00000000000fffff] ACPI data
Jun 09 11:24:40 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000003e8003ff] usable
Jun 09 11:24:40 localhost kernel: BIOS-e820: [mem 0x00000000fc000000-0x00000000fc007fff] ACPI data
Jun 09 11:24:40 localhost kernel: x86/PAT: PAT support disabled.
Jun 09 11:24:40 localhost kernel: NX (Execute Disable) protection: active
Jun 09 11:24:40 localhost kernel: DMI not present or invalid.
Jun 09 11:24:40 localhost kernel: Hypervisor detected: Xen HVM
Jun 09 11:24:40 localhost kernel: Xen version 4.8.
Jun 09 11:24:40 localhost kernel: HVMOP_pagetable_dying not supported
Jun 09 11:24:40 localhost kernel: tsc: Fast TSC calibration failed
Jun 09 11:24:40 localhost kernel: tsc: Detected 3192.610 MHz processor
Jun 09 11:24:40 localhost kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Jun 09 11:24:40 localhost kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Jun 09 11:24:40 localhost kernel: last_pfn = 0x3e800 max_arch_pfn = 0x400000000
Jun 09 11:24:40 localhost kernel: MTRR default type: uncachable
Jun 09 11:24:40 localhost kernel: MTRR fixed ranges disabled:
Jun 09 11:24:40 localhost kernel: 00000-FFFFF uncachable
Jun 09 11:24:40 localhost kernel: MTRR variable ranges disabled:
Jun 09 11:24:40 localhost kernel: 0 disabled
Jun 09 11:24:40 localhost kernel: 1 disabled
Jun 09 11:24:40 localhost kernel: 2 disabled
Jun 09 11:24:40 localhost kernel: 3 disabled
Jun 09 11:24:40 localhost kernel: 4 disabled
Jun 09 11:24:40 localhost kernel: 5 disabled
Jun 09 11:24:40 localhost kernel: 6 disabled
Jun 09 11:24:40 localhost kernel: 7 disabled
Jun 09 11:24:40 localhost kernel: Disabled
Jun 09 11:24:40 localhost kernel: CPU MTRRs all blank - virtualized system.
Jun 09 11:24:40 localhost kernel: x86/PAT: Configuration [0-7]: WB WT UC- UC WB WT UC- UC
Jun 09 11:24:40 localhost kernel: Using GB pages for direct mapping
Jun 09 11:24:40 localhost kernel: RAMDISK: [mem 0x03a01000-0x049bbfff]
Jun 09 11:24:40 localhost kernel: ACPI: Early table checksum verification disabled
Jun 09 11:24:40 localhost kernel: ACPI: RSDP 0x00000000000FFFC0 000024 (v02 Xen )
Jun 09 11:24:40 localhost kernel: ACPI: XSDT 0x00000000FC007F70 000034 (v01 Xen HVM 00000000 HVML 00000000)
Jun 09 11:24:40 localhost kernel: ACPI: FACP 0x00000000FC007D70 00010C (v05 Xen HVM 00000000 HVML 00000000)
Jun 09 11:24:40 localhost kernel: ACPI: DSDT 0x00000000FC001050 006C9B (v05 Xen HVM 00000000 INTL 20160831)
Jun 09 11:24:40 localhost kernel: ACPI: FACS 0x00000000FC001010 000040
Jun 09 11:24:40 localhost kernel: ACPI: FACS 0x00000000FC001010 000040
Ok, let’s sum up. The core18 snap is unmounted, there’s no log that indicates that snapd did that, because of this running snap applications that use core18 as base will not work. I suggest you try to identify why the snap mount was stopped. AFAICT the unit is enabled so rebooting should bring it up again, or you can just start it manually.
Maybe there’s something else at the os level that I’m not aware of. The version info indicates that you’re on debian, but you seem to be running a kernel from qubes? So maybe it’s not debian after all.
It is indeed sounding like a qubes issue. I posted a similar post on the qubes mailing list and got this response:
Snaps now go across the file system, so are no longer the user-specific install they seemed to be.
I don’t think there is a simple fix - you cant use bind-dirs for the
devices under /dev, and I’m guessing the /tmp directory is created per
boot.
I am still learning Qubes but it was pointed out to me that when I turn off a “VM” (in this case debain) the only thing that is retained is snapd and what was installed in ~/ everything else is “wiped clean”. It hadnt occured to me this would be the problem - some snaps seem to be working (vidcutter continues to work). So is it that some snaps install stuff in places other than ~/ and some snaps only install to ~/ ?
funny, i wonder what makes them think snaps had ever been a “user specific install”, while a few people asked for this as a feature they surely have never been …
Not sure, I honestly hadnt considered that - the main attraction of snaps for me was that quite a few apps that you cant find for linux in the repos are available as snaps. That and some who are more clever than me put together snaps with wine (like for foobar2000) that work much better than I was able to get the app to work with wine.
Regardless, its a pity i cant install authy but the foobar2000 and vidcutter snaps seem to be working quite well, all the help has really been appreciated!