Auto-mounting and docker not working after latest update

Help and Support Vero 4K / Vero 4K +
1

I am using Vero4k+ and I just updated to the latest release (2020.10-1) this morning and I’m now having 2 issues:

  1. My WdElements 12TB external hard drive does not mount automatically anymore, here is what I have in fstab:
    UUID=96b7efb3-4ab3-45ea-9b2f-eecbd458138b /mnt/elements ext4 nofail,x-systemd.device-timeout=5,noatime 0 0

I checked and the fstab UUID matches the device UUID, here is output of blkid:
/dev/sda1: LABEL="elements" UUID="96b7efb3-4ab3-45ea-9b2f-eecbd458138b" TYPE="ext4" PARTLABEL="Elements" PARTUUID="c5934aef-8628-476d-853d-3132dfddf9bc"

It doesn’t mount it even if I reboot the system, I have to manually mount it with sudo mount /dev/sda1 /mnt/elements/ -t ext4

  1. I was running docker with a few containers and it seems like the docker daemon stopped working after this update, when I docker ps I get this error:
    Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

After checking sudo service --status-all it seems like docker isn’t running, so I tried to reset it with systemctl but it didn’t work and didn’t give me any useful info, so I checked what sudo dockerd --debug outputs:

https://paste.osmc.tv/zifufobore.vala

Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables: Operation not supported.
 (exit status 1)

Not sure what changed that this isn’t working anymore… did anyone else face any issues like that? I’m a bit stuck here.

I do have the automatic MY_OSMC backup from before the update… can I just restore that and use the previous version?

2

Hi,

Not sure if this will fix the docker problem or not, but it seems to loading iptables-legacy rules; where as buster loads nfttables by default. Please try this:

sudo update-alternatives --config iptables

When prompted (Press to keep the current choice[*], or type selection number) enter 1.

As for fstab mount:

To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.

Depending on the used skin you have to set the settings-level to standard or higher, in summary:

  • enable debug logging at settings->system->logging

  • reboot the OSMC device twice(!)

  • reproduce the issue

  • upload the log set (all configs and logs!) either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A

  • publish the provided URL from the log set upload, here

Thanks for your understanding. We hope that we can help you get up and running again shortly.

OSMC skin screenshot:

image
image957×540 224 KB

Thanks Tom.

3

Hey Tom,

Thanks for the answer.

I’ve tried your docker solution with update-alternatives and it worked. However, all of my containers changed the status to dead and I had to recreate them. Now I get this error anytime I try to run any containers again:

docker: Error response from daemon: unable to find "net_prio" in controller set: unknown.

I googled about it a bit and it seems like people are recommending to rebuild the kernel:

To fix it on my system I just needed to rebuild my kernel with CONFIG_CGROUP_NET_PRIO enabled

Did something like this change in the new october release?

Regarding the fstab issue, I will post the logs later on, when I get the time to prepare everything… I can manage with manual mount atm, but docker sucks a bit.

5

Here are the logs after I enabled debug logging: https://paste.osmc.tv/udubozufoy

Regarding auto mounting issue, I found this error in the logs:

Nov 16 18:31:46 osmc udisks-glue[281]: Failed to automount /dev/sda1: Error mounting: mount exited with exit code 1: helper failed with:
Nov 16 18:31:46 osmc udisks-glue[281]: mount: /mnt/elements: operation permitted for root only.

It seems like some permission changed with the newest update? No idea. I have fixed the fstab issue by changing the /etc/fstab entry and adding the user option:

UUID=96b7efb3-4ab3-45ea-9b2f-eecbd458138b /mnt/elements ext4 nofail,x-systemd.device-timeout=5,noatime,user 0 0

I rebooted the device and it correctly mounted it.

I am still having docker issues though, I will go through the logs again and check if there’s something useful.

6

Should be:

UUID=96b7efb3-4ab3-45ea-9b2f-eecbd458138b /mnt/elements ext4 nofail,x-systemd,device-timeout=5,noatime,user 0 0
7

Hey @bmillham, not sure what’s the difference between your and my solution, but I’ve already fixed the fstab issue.

8

It’s difficult to see how that would have fixed the issue, since root is already mounting the disk. I think a more likely source of the problem is your use of x-systemd.device-timeout. I’ve seen this produce the same error in Buster (Debian and RaspiOS) and would recommend that you change it to x-systemd.automount,noauto.

As to the kernel cgroups issue, it looks like Sam omitted it from the 3.14 kernel (and also from the Pi2/3 kernel).

Edit: fixed typo - nauto should be noauto. D’oh! Cheers @ooZee.

1 Like
10

OK, I now actually see what @bmillham was trying to say. So I tried both of your solutions:

  • first I tried to change x-systemd.device-timeout=5 to x-systemd,device-timeout=5 and it stopped mounting again,
  • then I also tried your solution @dillthedog and I added x-systemd.automount,nauto and it also didn’t work…

I’ve reverted the change as it seems like my solution is the only one that works, tbh I can’t be bothered with this issue anymore…

Regarding cgroups issue, it seems like some people had luck by downgrading systemd to <240 version, it seems like the current version is 241. Would that be possible? Am I basically stuck without docker on the latest october release? Kind of sucks, I will probably be forced to downgrade :frowning:

11

I can’t say for sure that downgrading systemd is/isn’t possible, but I wouldn’t recommend it.

Why do you think it’s caused by systemd – and not by docker?

12

I am just guessing - I have also checked my docker-ce and containerd.io installation and it seems like I have the latest version for debian, so I guess this problem has not been fixed by docker yet.

I have found a lot of similar issues with systemd where people report success on <240 versions:

15

It’s been pointed out that I made a typo in my post above. It should read x-systemd.automount, noauto (not nauto). I’ve amended the original post.

If you’re feeling sufficiently amenable, you might want to give it a try. No guarantees, but it usually works.

20

This should be solved in the next 4.9 kernel which is due very shortly

See:

21

Awesome, thanks @sam_nazarko! Will be on the lookout for this update.

28

Hey @sam_nazarko has this been updated yet? I can’t find any info regarding updates - can I follow a specific website with new version info? :slight_smile:

29

Docker works on the 4.9 kernel which is still in a testing state.
Test builds can be found on the forums

Cheers

Sam