$ ls -l /snap
total 16
drwxr-xr-x 2 root root 4096 Mar 12 19:27 bin
drwxr-xr-x 3 root root 4096 Mar 12 19:27 core
drwxr-xr-x 3 root root 4096 Mar 12 19:28 gnome-3-26-1604
-r–r--r-- 1 root root 548 Mar 12 19:27 README
I have no idea what’s going on with your system 
snapd always prints a line or two on restart. systemd itself, always logs a restart. In journalctl -u snapd should have at a minimum, one line from systemd saying Starting Snappy daemon..., then one from snapd saying (on Ubuntu, with the right kernel), AppArmor status: apparmor is enabled and all features are available, and then something like started snapd/2.38~pre1 (series 16; classic) ubuntu/16.04 (amd64) linux/4.4.0-142-generic.
But you don’t. Something is broken on your system, and it isn’t (only) snapd.
this is a new install from Ubuntu 19.04 “Disco Dingo” - Alpha amd64 (20190312)
corrado@corrado-p7-dd-0312:~$ inxi -Fx
System:
Host: corrado-p7-dd-0312 Kernel: 5.0.0-7-generic x86_64 bits: 64
compiler: gcc v: 8.3.0 Desktop: Gnome 3.32.0
Distro: Ubuntu 19.04 (Disco Dingo)
Machine:
Type: Desktop Mobo: ASRock model: H110M-G/M.2 serial:
UEFI: American Megatrends v: P1.10 date: 05/11/2017
CPU:
Topology: Dual Core model: Intel Core i3-7100 bits: 64 type: MT MCP
arch: Kaby Lake rev: 9 L2 cache: 3072 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31296
Speed: 801 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 800 2: 800
3: 800 4: 800
Graphics:
Device-1: Intel HD Graphics 630 vendor: ASRock driver: i915 v: kernel
bus ID: 00:02.0
Display: x11 server: X.Org 1.20.4 driver: i915 resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2)
v: 4.5 Mesa 18.3.4 direct render: Yes
Audio:
Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: ASRock
driver: snd_hda_intel v: kernel bus ID: 00:1f.3
Device-2: Logitech QuickCam Pro 9000 type: USB
driver: snd-usb-audio,uvcvideo bus ID: 1-10:4
Sound Server: ALSA v: k5.0.0-7-generic
Network:
Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: 3.2.6-k
port: f040 bus ID: 00:1f.6
IF: enp0s31f6 state: up speed: 100 Mbps duplex: full
mac: 70:85:c2:44:7b:86
Drives:
Local Storage: total: 931.51 GiB used: 5.92 GiB (0.6%)
ID-1: /dev/sda vendor: Toshiba model: DT01ACA100 size: 931.51 GiB
Partition:
ID-1: / size: 31.25 GiB used: 5.91 GiB (18.9%) fs: ext4 dev: /dev/sda7
ID-2: swap-1 size: 8.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda2
Sensors:
System Temperatures: cpu: 40.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 203 Uptime: 51m Memory: 7.50 GiB used: 1.25 GiB (16.6%)
Init: systemd Compilers: gcc: 8.3.0 Shell: bash v: 5.0.2 inxi: 3.0.32
corrado@corrado-p7-dd-0312:~$
right, and I can probably help you with snapd issues, but what I’m saying is something more fundamental is broken, and that makes it next to impossible to debug snapd itself.
Having said this, I’ve made good progress on the snapd seeding issue with will on IRC. Currently hopeful we can figure it out.
1 Like
I have again the same situation on a NEW install on a different partition
corrado@corrado-p6-dd-0312:~$ snap list
Name Version Rev Tracking Publisher Notes
core 16-2.37.2 6405 stable canonical✓ core
gnome-3-26-1604 3.26.0.20190228 82 stable/… canonical✓ -
corrado@corrado-p6-dd-0312:~$ systemctl restart snapd.service
corrado@corrado-p6-dd-0312:~$ journalctl -u snapd > jjj.txt
corrado@corrado-p6-dd-0312:~$ cat jjj.txt
– Logs begin at Wed 2019-03-13 14:42:47 EDT, end at Wed 2019-03-13 15:17:34 EDT. –
– No entries –
corrado@corrado-p6-dd-0312:~$ ls -l /snap
total 16
drwxr-xr-x 2 root root 4096 Mar 13 14:42 bin
drwxr-xr-x 3 root root 4096 Mar 13 14:42 core
drwxr-xr-x 3 root root 4096 Mar 13 14:43 gnome-3-26-1604
-r–r--r-- 1 root root 548 Mar 13 14:42 README
corrado@corrado-p6-dd-0312:~$
you said I have something more broken on my install but to me it seems unlikely to have the same problem in 3 different installations.
Will try installing on my laptop…
I’m not saying it’s exclusive to your install! You’re trying 19.04, which is in development. There’s an issue with snapd seeding, clearly, but there’s more going on. I’m unlikely to be able to help you figure out the one until the other gets resolved.
1 Like
@chipaca it would probably be simpler if you could grab the iso and spin up a VM. Just grab the latest daily pending from http://cdimage.ubuntu.com/daily-live/pending/
I saved the /var/log/installer/syslog from both ISO 20190312 and 20190306 and checked some differences:
in /var/log/installer/syslog from ISO 20190306 the word ‘snap’ occurs 273 times and snaps works fine
in /var/log/installer/syslog from ISO 20190312 the word ‘snap’ occurs 115 times and i have no snaps
both syslog are to big (about 2 MB) to put it to pastebin so I extracted the lines containing the word ‘snap’ and saved to pastebin
https://pastebin.com/43hRNfBq extract from snap-inst-ok - ISO 20190306
https://pastebin.com/pdfdeH19 extract from snap-inst-ko - ISO 20190312
I hope it can be useful
Trying to reproduce this myself. Random notes about it below.
Struggling to actually get the disco install to boot. I guess it needs more than 10GB? Didn’t get any errors though. kvm just sits at a black screen with no progress. Trying again with 20GB.
these two icons with discs and arrows in opposite directions do the same thing:
…
turns out it is booting, just not starting the graphical wotsit. ctrlaltf2 fixed that.
All snaps are installed fine. Can’t test them, not having X, but they’re there in snap list, an journalctl -u snapd lists stuff.
So… how do I actually reproduce this?
-vga qxl got me a graphical wotsit. Something’s broken wrt the default vga support (works fine in the installer).
It’s very racy but I’ve managed to reproduce it once. Then figured out how to have debug logs from the start. Will try to reproduce again, with debug logs…
I haven’t been able to reproduce it yet. But:
When installing, once it prompts you to restart, before clicking restart edit /target/etc/environment and add SNAPD_DEBUG=1.
Then, once booted, grep snapd /var/log/syslog. It seems disco is a lot more aggressive in rotating the journal, but it reaches syslog ok.
I’ll continue trying to reproduce this.
1 Like
That’s likely to be not enough video ram given to the VM.
I am able to reliably reproduce on Virtualbox. 3GB RAM, 40MB Video RAM, 20GB HDD.
Edit: I was able to reproduce it. Today’s ISO is working so far… will keep trying.
1 Like
I’ve done numerous installs with the 20190314 iso as well as tested in the live session and am unable to reproduce it. I was able to reliably reproduce it with yesterday’s image.
We’ll keep testing this.
1 Like
@corradoventu are you still able to reproduce this?
We think we know what’s going on, but would need to do some extra checks to make sure.
If you are able to reproduce this, please run
snap info --verbose /var/lib/snapd/seed/snaps/* | egrep 'name|base'
and share the output.
problem solved with last ISO Ubuntu 19.04 “Disco Dingo” - Alpha amd64 (20190314)
corrado@corrado-p6-dd-0314:~$ snap list
Name Version Rev Tracking Publisher Notes
core 16-2.37.4 6531 stable canonical✓ core
gnome-3-26-1604 3.26.0.20190228 82 stable/… canonical✓ -
gnome-calculator 3.30.1 260 stable/… canonical✓ -
gnome-characters 3.30.0 139 stable/… canonical✓ -
gnome-logs 3.30.0 45 stable/… canonical✓ -
gnome-system-monitor 3.30.0 57 stable/… canonical✓ -
gtk-common-themes 0.1-16-g2287c87 1198 stable/… canonical✓ -
corrado@corrado-p6-dd-0314:~$ cat /var/log/installer/media-info
Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190314)
corrado@corrado-p6-dd-0314:~$OK, unless anybody comes up with evidence to the contrary, I’m going to say that what was happening was this:
Some isos have gone out with snaps that had base: core18, but without seeding core18. This is not supported, and will cause seeding to hang.
Unless somebody can positively point to this happening on an iso that didn’t have these wrongly-seeded snaps, or conversely have it not happen when the core18-based snaps were seeded, that’s all there was to it.
It’s been harder to debug than would’ve been ideal because there has been some confusion around which isos people were testing.
HTH, HAND.
1 Like