Rob's questions

Booting my very capable PC has become a fingers-on-chalkboard-grating slow nightmare because of snap. It's gone from 5-10 seconds to login screen after GRUB to now 30-45 seconds, sometimes up to a minute or more.

This is absurd.

I'd prefer to not remove every single snap on my machine, but I'm prepared to do that. How do I defeat snap mounts on boot and regain my sanity, without having to scorch the earth?

Specifically looking for an answer to this: how do I modify individual snaps so that they do not mount during boot?

$ systemd-analyze blame
          8.812s plymouth-quit-wait.service
          6.256s NetworkManager-wait-online.service
          5.042s bolt.service
          3.008s snap-spotify-42.mount
          2.994s snap-gnome\x2dlogs-93.mount
          2.917s snap-discord-115.mount
          2.525s snap-chromium-1399.mount
          2.515s snap-gnome\x2dlogs-100.mount
          2.416s snap-gtk2\x2dcommon\x2dthemes-13.mount
          2.392s snap-gnome\x2dcharacters-550.mount
          2.224s snap-gnome\x2d3\x2d34\x2d1804-36.mount
          2.214s snap-gtk\x2dcommon\x2dthemes-1513.mount
          2.174s snap-gnome\x2d3\x2d28\x2d1804-145.mount
          2.170s snap-gnome\x2dcalculator-748.mount
          2.149s snap-postman-128.mount
          1.953s snap-storage\x2dexplorer-17.mount
          1.946s snap-core18-1885.mount
          1.749s systemd-fsck@dev-disk-by\x2duuid-db865690\x2db43f\x2d485b\x2d8bab\x2d808735a403a8.service
          1.725s unifi-video.service
          1.632s dev-loop3.device
          1.632s dev-loop2.device
          1.575s dev-loop5.device
          1.557s dev-loop6.device
          1.555s dev-loop7.device
          1.464s dev-loop9.device
          1.452s dev-loop8.device
          1.441s snap-gnome\x2dcharacters-570.mount
          1.426s snap-core-10185.mount
          1.409s snap-spotify-43.mount
          1.400s snap-libreoffice-196.mount
          1.384s snap-gtk2\x2dcommon\x2dthemes-9.mount
          1.380s snap-gnome\x2d3\x2d34\x2d1804-60.mount
          1.370s snap-postman-129.mount
          1.214s dev-loop10.device
          1.135s dev-loop11.device
          1.132s dev-loop1.device
          1.089s dev-loop21.device
          1.072s snap-vlc-1620.mount
          1.070s dev-loop19.device
          1.054s dev-loop18.device
          1.041s dev-loop20.device
           981ms dev-loop12.device
           975ms dev-loop14.device
           968ms systemd-logind.service
           944ms dev-loop4.device
           903ms dev-loop13.device
           902ms dev-loop17.device
           901ms dev-loop16.device
           881ms dev-loop22.device
           834ms snap-core18-1932.mount
           809ms snap-chromium-1411.mount
           681ms nvidia-persistenced.service
           678ms snap-gnome\x2d3\x2d28\x2d1804-128.mount
           669ms dev-loop15.device

I have a USB webcam on /dev/video0 that I'm trying to access before a user logs in (to be precise, I have an Azure IoT Edge container running on an Ubuntu 18.04 instance that needs to run in headless mode, and the box needs to be able to be power cycled without someone having to physically log in every time).

If I first physically log in on the box, the ACLs are set properly for /dev/video0, and my container (which runs under myuser) can happily access /dev/video0:

myuser@myuser-UBUNTU:~$ sudo getfacl /dev/video0
getfacl: Removing leading '/' from absolute path names
# file: dev/video0
# owner: root
# group: video
user::rw-
user:myuser:rw-
group::rw-
mask::rw-
other::---

But if I do not physically log in on the box (e.g. right after a reboot), my user's account (myuser) never gets ACL access to /dev/video0 (instead, the gdm user gets it).

myuser@myuser-UBUNTU:~$ sudo getfacl /dev/video0
getfacl: Removing leading '/' from absolute path names
# file: dev/video0
# owner: root
# group: video
user::rw-
user:gdm:rw-
group::rw-
mask::rw-
other::---

I'm 99% sure this is an ACL problem, because when I ssh into the box (before physically logging in), and manually add myuser to the ACL list for /dev/video0, my container can again happily access /dev/video0.

My question: how can I ensure that on startup, when /dev/video0 is mounted, that this automatically happens:

sudo setfacl -m u:myuser:rw /dev/video0

Adding myuser to the video group does not work (ACLs seem broken on Ubuntu in this respect):

sudo usermod -a -G video myuser

I've tried every variation I can possibly think of RE: groups, with no impact. It seems like I really need to automatically add myuser to the ACL for /dev/video0 when Ubuntu starts, but I am unsure how to do that. Any ideas?

I’m having a lot of trouble getting Management Studio Express 2008 to recognize my local instance of SQL Server 2008 (SQLEXPRESS).

Background: I’ve installed SQL Server 2008 x64 a few times today; I have verified each time that I have installed the database engine.

The current situation: when I start SQL Server 2008, I cannot connect to SQLEXPRESS; in fact, Management Studio doesn’t seem to recognize any valid instances, as shown in the following screenshot:

If I look at SQL Server Configuration Manager, this is my current setup:

My best guess is that my problem is because neither SQL Server Agent (SQLEXPRESS) or SQL Server Browser are running – however, I am unable to stat them. I can’t change the Log On setting either; I’m stumped as to how to get this working.

Does anyone have any suggestions? I feel like I’m just missing something small here.