Is /dev/pts/ptmx necessary for running snaps?

I’m trying to get snaps running on a Moxa UC-8112-LX board (https://www.moxa.com/product/UC-8100.htm). Not a full Ubuntu Core installation - just snaps. I’ve got close after making some modifications to the stock Debian “firmware” supplied by Moxa, such as upgrading to Debian 9 and adding a SquashFS kernel module.

I can install snaps, but they all (including core) fail, with the following appearing to be the root cause:

cannot stat /dev/pts/ptmx: No such file or directory

Indeed there is no such device under /dev/pts/; there is only /dev/ptmx. I’ve tracked this down to the fact that the Moxa kernel is compiled without the CONFIG_DEVPTS_MULTIPLE_INSTANCES option. That’s not something I can fix with modules, and so far I’m having an unexpectedly hard time installing a new kernel on the device.

So I figured I’d ask - is the above-mentioned kernel option (and /dev/pts/ptmx) absolutely necessary in order to be able to run snaps? Or can I work around this error in some way, without replacing the kernel?

(for the record, simple workarounds like trying to add a symlink to /dev/ptmx under /dev/pts/fail with “Operation not permitted”)

Yes, it is required to provide isolation between snaps so they can’t sniff or otherwise interfere with each other. See https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L113

If you don’t care about strict mode snaps, it is theoretically possible if your system is detected with partial confinement that snapd could skip this setup. @zyga-snapd has currently been working in this area (though @zyga-snapd, this would require snap-confine to understand this), but we would need @mvo/@niemeyer to comment on if snapd should implement this.

i strongly assume this is not the only missing kernel option … also, their kernel seems to be 3.2 based … that might be missing particular bits … but as start i’d go with

https://www.moxa.com/support/download.aspx?type=support&id=7975

and make sure all snap and systemd related config options are set with your own uImage

Thanks both for your support and clarifications!

Just to clarify and provide some more context on the situation I’m trying to work through: the latest stock kernel for that Moxa is actually 4.1; I was also able to get the source for that through their support staff (for some reason it’s not published online). Unfortunately any kernel I’ve compiled myself - even just the stock config - fails to boot with “bad header checksum”. And it’s pretty much impossible to diagnose what u-boot is doing there, as it seems that the u-boot config is hardcoded, with no u-boot prompt available. Anyway, that’s a separate story. I’ve again reached out to Moxa support to try to understand what I’m missing.

In the meantime I wanted to explore whether any workarounds are available within snapd. Indeed, I am not looking for confinement between snaps on this system. We’re primarily interested in using snappy as a mechanism for deploying a software package we want to run on the Moxas, and automatically pushing remote updates. But it sounds like such a workaround-within-snapd would at the very least involve codebase patches and recompilation of snapd, rather than e.g. a config option somewhere. Or am I missing a trick?

That is accurate, yes.

Thanks for confirming! I’ll try and get this fixed “the right way” before resorting to that.

I was also told by Moxa support that there’ll be a new Debian-9-based firmware out in June, so I’m holding out some hope that the kernel that comes with it will have CONFIG_DEVPTS_MULTIPLE_INSTANCES=y set. From what I’ve seen it’s not exactly a controversial option to include…

1 Like

Just wanted to follow up and say that I got this working in the end, by getting the custom kernel to run on the Moxa. It looks like CONFIG_DEVPTS_MULTIPLE_INSTANCES=y was indeed the only missing ingredient from the Moxa stock kernel, so now that that’s sorted, snaps appear to be running without a hitch.

For the benefit of the very-few-if-any people who may be in the same boat as me, I’ve written up a guide to running snaps on a Moxa UC-8100 board here https://gist.github.com/svet-b/ebe60ca25a34c493bfa304fe8c595785. The main thing that was catching me out was that the stock u-boot was locked down and would actually throw a checksum error for any customer kernel.

1 Like