[SOLVED] Hugo's Snap stopped working

support
22

That error looks like a glibc error, and Google returns some hits about this problem in other snaps. I don’t know much about the snap system (I’m just compiling my own on macOS) but, snaps update automatically apparently (when a command is re-run or a daemon is restarted etc), and it seems it’s pretty complicated, coming with its own file system.

People who are using snap should also pitch in and figure out how to troubleshoot it and maintain it, going forward. That a snap exists isn’t magic: someone had to do something to make it available. Echoing @bep’s sentiment, it’s not like people are “getting rich” working on this project.

1 Like
23

According to https://www.ubuntuupdates.org there was a snapcraft package update in Xenial on the 23rd of March. You can view the details here: https://www.ubuntuupdates.org/package/core/xenial/universe/proposed/snapcraft

Also if the problem is still unresolved maybe you should ask the person who pushed the update. He’s listed in the link I provided.

1 Like
24

@RickCogley It’s admirable that you champion the free software movement. However, you’ve summed up the major problem of that movement with your last line. You get what you pay for in this world, and if you didn’t pay anything, you shouldn’t expect anything…

25

Okay, I have made a post over on the snap forum, you can find it here, hopefully they know a bit more about it, since it probably was, as @alexandros said, the update on the snapcraft package.

26

There is an immediate fix, you can download the binary from the release page. As far as I have seen, that seems to still work perfectly.

As for @bep not providing a timescale, how should he? First of all it seems to be a problem with snap, not hugo (indicated by the binary still working). Secondly this is open source software, it will be fixed once it’s fixed.

27

Reddit and proprietary software forums are better places for you to vent your frustration with FOSS.

This forum is not a place for flame wars.

28

I think the snap just needs to be recreated with updated libc. see my earlier message. Who is the maintainer of the hugo snap package?

Also, that snapcraft update is in proposed which is a channel that normally is disabled. I don’t think a change in snapcraft would change a snap. as far as I understand snaps they include all needed files and snapcraft “only” creates a snap, but is not required to run it.

I think that change might hold the fix for the issue though. Updating snapcraft and recreating the snap package should do the job.

I happen to have no experience with it or would have tried so myself.

30
2 Likes
31

You are correct. It wasn’t the package in the proposed channel. Apologies.

But now I know what caused the Hugo Snap to stop working. CC @bep @anthonyfok

I fired up my Xubuntu VM that I hadn’t touched since Thursday.
The Hugo snap was functional.
Then I checked for updates. And here is the list of the updates that were installed:

 initramfs-tools/xenial-updates,xenial-updates 0.122ubuntu8.11 all [upgradable from: 0.122ubuntu8.10]
initramfs-tools-bin/xenial-updates 0.122ubuntu8.11 amd64 [upgradable from: 0.122ubuntu8.10]
initramfs-tools-core/xenial-updates,xenial-updates 0.122ubuntu8.11 all [upgradable from: 0.122ubuntu8.10]
libvorbis0a/xenial-updates,xenial-security 1.3.5-3ubuntu0.2 amd64 [upgradable from: 1.3.5-3ubuntu0.1]
libvorbisenc2/xenial-updates,xenial-security 1.3.5-3ubuntu0.2 amd64 [upgradable from: 1.3.5-3ubuntu0.1]
libvorbisfile3/xenial-updates,xenial-security 1.3.5-3ubuntu0.2 amd64 [upgradable from: 1.3.5-3ubuntu0.1]

Once the updates were installed lo and behold the message I got while trying to run hugo server

/snap/hugo/1455/bin/hugo: relocation error: /snap/hugo/1455/lib/x86_64-linux-gnu/libpthread.so.0: symbol __mmap, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

Now the packages for libvorbis refer to an audio format so we can safely assume that these are not culprit.

But initramfs-tools as per its page on Launchpad:

This package builds a bootable initramfs for Linux kernel packages. The initramfs is loaded along with the kernel and is responsible for mounting the root filesystem and starting the main init system.

Each snap has its own file system and something in this update from Ubuntu upstream caused the Hugo snap to fail.

32

Have you really bothered reading this thread?

It doesn’t look like it.

Also this is not some professional support forum. We are all Hugo users ourselves and people here are trying to help each other.

Your comments are counter productive. I could ignore you -as we usually do- but please do show a modicum of respect rather than coming here and pointing fingers.

1 Like
33

I, too, ran into this exact problem. The host system is fully-updated Ubuntu 16.04.4.

34

I got the same error on my somewhat outdated ubuntu 17.04, and I “solved” it by reverting to a earlier hugo:
sudo snap revert hugo

It seems that this snap works(snap info hugo):
2018-03-07 19:18:07

but this snap doesn’t:
2018-03-24 13:01:28

Both are 0.37.1 so it doesn’t seem it is related to hugo unless a update was made without increasing the version.

This is also reproducible. Doing “sudo snap refresh hugo” to get the latest 0.37.1 build causes the issue again. Not sure if this info is helpful or if its only happening on my machine.

2 Likes
35

Worked for me too, Ubuntu 16.04.4 LTS 32-bit. Thanks.

36

Thanks. Didn’t know about snap revert

So if someone doesn’t want to install the binary this is another workaround.

EDIT

It was an update from Ubuntu upstream, see my previous post.

37

I have a confession to make. It was I who changed the something https://launchpad.net/~gohugoio/+snap/hugo, by using Ubuntu Artful (17.10) instead of Xenial (16.04) for building the hugo snap, which I thought was the solution to fix the build problem of the 0.38-DEV series at https://launchpad.net/~gohugoio/+snap/hugo-dev. As it turns out, I was very wrong, of course.

The good news is: The problem you see in Hugo snap revision 1455 (amd64) has now been fixed! Please do a snap refresh which would fetch revision 1462 for amd64, and that is built with Xenial and has no “relocation error” do to GLIBC version mismatch.

My sincere apologies! For slightly more technical details, please check the my “closing” comment at https://github.com/gohugoio/hugo/issues/4534.

8 Likes
38

No worries @anthonyfok

I just want to thank you for all the hard (and free) work you do maintaining the Hugo snap.

Bugs happen. Software development is hard.

I am closing this thread since the Hugo snap is working again, there is no point discussing this further.

6 Likes