bumping this thread waiting for reply.
Ok, so it looks like you are correctly defining your systems-files plug correctly now, which is good.
However, I am wondering if you actually need this system-files plug at all:
-
readaccess to/run/systemd/resolve/stub-resolv.confis already provided when pluggingnetwork -
/etc/hostsand/etc/hosts.confis not normally required by snaps - can you please show any errors which occur when running your snap for this file? - Finally if you plug the
gsettingsinterface your snap should gain the access for/home/darts/.config/dconf/user.
So in summary: since your snap already plugs network you can remove the /run/systemd/resolve/stub-resolve.conf - and if you plug gsettings you can remove /home/darts/.config/dconf/user - and I suspect /etc/hosts should not actually be required either so please can you provide more info regarding that.
Hello @alexmurray and @emitorino,
I changed my snap configuration to suggested. The snap application is not crashing anymore and I was able to run the application on beta channel.
When I tested I am not able to register any kind of input using serial port. When I check the logs this is the permission denied i am getting. Can you please assist me what could i be missing? Thanks in advanced!
Hi @alexmurray
I enabled hotplugs using command $ sudo snap set system experimental.hotplug=true
I still get the same error Permission denied, cannot open /dev/ttyS0
Do I need to do additional configuration like adding slots to the .yaml?
does your app have serial-port defined in plugs: and did you use snap connect ... to connect your app to the hotpluggable slot as described in the hotplug doc ?
(also, is your user in the “dialout” group ? snap interfaces do not change permissions so if your user can not write to the interface outside of the snap env, it wont be able to do that inside either)
Hello @ogra
Thanks for jumping in!
- I enabled hot plugs and reboot.
- serial-port is listed in plugs (Im pasting an image of my .yaml configuration).
- My user is in the dialout group (I previously did this in order to make it work on devmode).
- I ran
snap interface serial-portand no slots are listed, see image (I assume the slot listed here is the one I would need tosnap connect ...). - By the way the device im connecting is NOT via USB.
oh, then hotplug wont help i fear, it currently only works for usb-serial devices i think…
Hello,
Im still having this issue when running the app in beta in strict confinement gives me a permission denied to the serial port im trying to connect to.
If running in edge channel in --devmode the serial port works good. Any thoughts what could i be missing or why i keep getting serial port permission denied?
In devmode, the snap sandbox is effectively disabled so this gives the snap access to the system. In general, the snap system expects a serial port slot to be provided by an appropriate gadget snap - and these are only applicable on Ubuntu Core systems. For classic Ubuntu / other distros there is no standard way for an application level snap to be provided access to a non-hotplugged serial port - whilst you could perhaps use system-files to specify access to the device node on the file-system, the snap would still likely not be able to access it since the device node would not be present in the snap’s device-cgroup.
So since you are not using a hotpluggable serial port, your use-case sounds more like a kiosk-type device on known hardware - in which case I think using Ubuntu Core would be more appropriate and hence then a custom gadget snap which can declare the serial-port slot for this device node would be the best approach.
Hi all, I work with @dguerrero5. All of these suggestions have been great.
couple of questions:
- Is there a reason why we can’t be granted classic permissions for our snap? This app isn’t for public consumption. It runs on"off the shelf" desktop motherboards and a custom i/o board from the year one that we didn’t build or know much about.
- Anyone have contractor hours available to help sort this out?
Regarding classic confinement, there is the Process for reviewing classic confinement snaps which will give you some idea of what that looks like - basically to be granted this, a snap must both require it in order to function (ie it is not possible to get it working under strict confinement at all) and the snap must fit within one of the existing supported categories for classic confinement. However, I think unforunately this snap may not meet the second criteria since I don’t think requiring access to a particular hardware device is not a supported category.
Also if your snap is in the public store, whilst it may not be intended for use by others, they could still install it.
As I suggested above, I really do feel like this sounds like a great use case for Ubuntu Core rather than classic Ubuntu (or some other Linux) since then you can prepare a custom image for the device which contains your own custom gadget snap which in-turn defines an appropriate serial-port slot to provide access to /dev/ttyS0 for your snap. See Building a gadget snap | Ubuntu which mentions the 64-bit PC Gadget Snap which sounds like it would be a good basis to work from in your case.
Beyond that, perhaps @ogra may be able to provide further advice if needed 
Thanks @alexmurray! Totally get public can install it, but it doesn’t do anything without registration in our system. This snap is being installed in old ‘arcade’ cabinets with antiquated monitors, etc most of which are unknown to us. While it certainly fits the ‘kiosk’ concept, the hardware involved is largely unknown. Having a full linux install is important so that he owner/operators of these cabinets can troubleshoot their issues.
As for the gadget snap idea, my concern is that it’s a suggestion, not declarative as to what we should be doing. Maybe it’s just how I’m reading it? My fear is the engineering cost/time to explore the suggestion only to be back where we are now if it doesn’t get the result we need. Make sense? We are letting electron-builder do a lot of the heavy lifting for us…
I’d be interested in what @ogra thinks as well. Happy to book either of you for consulting hours as this is a little out of our wheelhouse.
@TeamRBDG out of interest, could you please provide the output of the following on one of these machines? Thanks (I am wondering whether we may be able to revive https://github.com/snapcore/snapd/pull/7261 which could then allow snapd to support PCI-based serial-ports for hotplug - and so this should be enough to indicate whether in your case you are using such a device and then if this could support your use-case).
udevadm info /dev/ttyS0
Here I attach an image of the output.
@alexmurray See @dguerrero5 post above. I’ve also ordered the adaptor you recommended to at least say we tried that route.
Hmm since I don’t see something like:
E: ID_BUS=pci
Then I don’t think the PR I linked to above would help in this case (although since it looks like you are using VirtualBox I assume this is a virtual serial port). Can you provide more details on what your hardware setup is?
Also if you manage to have success using a USB-Serial adapter please let us know too. Thanks.
its actually not running in virtualbox, @dguerrero5 pulled that from his dev machine not from the actual device. below is from the cabinet:
