I2C in LXC container not accessible after upgrade to 5.0

Hello,

after upgrade to 5.0 I lost access to i2c bus in my container.

Relevant part of container configuration:

lxc.cgroup.devices.allow = c 89:* rwm
lxc.group.devices.allow = c 89:* rwm
lxc.mount.entry = /dev/i2c-7 dev/i2c-7 none bind,rw,optional,create=file 0 0

in container:

root@container:~# i2cdetect -y 7
Error: Could not open file `/dev/i2c-7': Operation not permitted
root@container:~# ls -l /dev/i2c-7 
crw------- 1 root root 89, 7 Jun  7 18:16 /dev/i2c-7

on host:

root@turris:~# ls -l /dev/i2c-7 
crw-rw-rw-    1 root     root       89,   7 Jun  7 18:16 /dev/i2c-7
root@turris:~# i2cdetect -y 7
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- -- 
20: -- -- -- 23 -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: 40 -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: UU -- -- -- -- -- 76 -- 

All was working before update. Update is not reversible.

Please, how to fix this. It is critical for me.

You can rollback update via schnapps.

No, problem is that I made full factory reset because of some other error. I don’t have a way back.

“3 LEDs: Rollback to factory reset” removes all schnapps images?

OK, I made 4 leds…

Four leds removes all schnapps images?

Anyway, you can use same method for installing TOS 3.

Yes, four leds removes all snapshots. This formats whole /dev/mmcblk0. Reverting to TOS 3 does not fix this problem. Btw. Solved for me, I made omnia-medkit-latest.tar.gz from backup and reflashed Omnia again. But, this is not solution. I must stay forever on version 3.X?

So, please, how to fix non-working /dev/i2c-7 export to lxc container?

I have another experience.

I am not fully understand. Solve TOS 3 image your problem or not?

It’s depend on your preferences.

@viktor: if you buy a new car, where you cannot open doors, you want to fix this. Solution is not use old car, where doors are working.

And no, this is not about my preferences. What about a new user, which buy Omnia with TOS 5 pre-installed - you will offer him downgrade to TOS 3? This is not only problem with old lxc container migrated to new host OS version.

I answerd to you, because you wrote sentence above.

TOS is open source builded on also OSS OpenWrt. It’s about software, not hardware (which is also among other things open source).

TOS 5 is not pre-installed yet.

I will offer them best solution to resolve their issue.

Viktor, you are missing point of my message. There is (maybe) bug in TOS 5. Reverting to TOS 3 is TEMPORARY workaround, but not solving problem. Solution is something like “this is a new version of LXC, try this to solve issue” or “Hmmm… this is working for me, you are doing something wrong, but I don’t know what” or “Hmmm… Hmmm… this is not working for me too, it looks like a bug”.

Car was example and one BASIC REASON of buying Turris Omnia are updates. Software is a part of this contract. And “If you need functionality, don’t upgrade” is the worst solution. If you don’t understand this, please do not answer.

Btw. TOS 5 is not preinstalled today, but tomorrow maybe yes.

“I will offer them best solution to resolve their issue.” - this is not the best solution. Trust me. Try to offer this to customer and they will never buy your product again. I am working on tech support. Yes, you can offer rollback to prev/older version, but with request to engineering to fix this issue. No matter if your software is opensource.

Is it possible to rule out that the issue, if the issue is present only inside the LXC container or it is present also within Turris OS? Did you upgrade from Turris OS 4.0 or 3.x? This is important to know.

OT: I think I need to make it a little bit clear. @viktor is not part of our team. “Forum is a platform for our users to discuss among themselves and help each other even with unsupported scenarios” as it is stated in our official documentation.

TOS 3 is stable and maintenanced. I am still using it on my routers in production environment.

It’s not workaround and it’s solving your problem. Or TOS 5 contain some other necessary functionality for you?

I don’t think so.

Reason for buying is not same as the part of contract.

This is speculation. Turris 2020 has already been released.

I’m not selling anything, I just walked by. I was the only one who offer a functional solution.

I don’t envy you.

Really no matter if your software is open source? No one is obliged to solve your problem!

Has anyone claimed the opposite?

Hi @Pepe, thank you for your answer.

First thing, I know that Viktor is not part of your team, but what he is doing is a “bear service”…

Second thing, my problem. Upgrade was made from version 3.11.17. Upgrade was performed by reflashing from flash drive to system linked from https://docs.turris.cz/hw/omnia/rescue_modes/ (I had corrupted FS on eMMC by my fault).

I recovered configuration from backup (I had exported snapshot), fixed some differences caused by new version of LXC and container started. Everything was working, except export /dev/i2c-* into container. As this is essential part, I tried to create archive for reflash from snapshot and it worked, so I have back version 3.11.17 now. This is story in short.

Some points: no error visible in logs (from starting container or system), dmesg etc. Same behavior with old container and new, freshly created. I didn’t think about the version, I left it for automatic updating and I thought I had the immediately previous version 5.0.

Is there a way to upgrade from 3.X to 4.X? I mean another way then reflash? To test if device export works in container in TOS4… (I don’t want to / I cannot spend too much time by testing this).

So you ask a question in the forum, someone does answer you and is it wrong?

This is not supported, because support for Turris OS 4.0 was terminated on the same date when we released Turris OS 5.0. Your question is rather if the LXC version is the same. Yes, it is. About kernel configuration, it was reworked&changed during these two versions as well.

1 Like

Do you recommend another forum user to report me?

i can use this in my arch container and it works:

lxc.cgroup.devices.allow = c 89:* rw
lxc.mount.entry = /dev/i2c-7 dev/i2c-7 none bind,optional,create=file 0 0

I do not have a solution in hand directly but I want to point out that Turris OS 3.x provided LXC 1 while Turris OS 5.0 provides LXC 3. There are differences in configuration. Same configuration won’t work one to one. Migration of LXC is concerned only with minimal functionality and that is network. Mount points or any other advanced configuration has to be migrated manually. Try to google for solution for LXC 3 instead of 1, that could help you.

1 Like