We would like to inform you that we released Turris OS 4.0 - beta2. It is released for Turris MOX and Turris Omnia.
Changelog for this release:
New implementation of dev-detect which does not depend on Pakon (experimental)
Fixed default encryption method for passwd from package shadow. Reset your
system user’s passwords (including root) if you set them by passwd.
LXC fixes for systemd based hosts
Foris: packages lists UI reworked
Foris: improved “no link” message in WAN tab
Netmetr: fixed initial setup
Nextcloud: dropped duplicate Referrer-Policy and updated to 16.0.1
Commit hash replaced with router name in banner
Suricata updated to version 4.0.7
kmod-usb2 is now part of base installation
libxslt: CVE-2019-11068
prosody: CVE-2018-10847
python-urllib3: CVE-2019-9740, CVE-2019-11324
When you were using our previous Beta1 version, you should be updated to this version automatically within a few hours.
If someone wants to give it try on Turris Omnia router, which is running Turris OS 3.11.4 or any other operating system, then we have prepared some short notes about how to do it.
From scratch, you just need to plug USB flash drive and put there rootfs, which you can download it here and by using the re-flash method, which is described in our documentation. If you want to have a backup, we suggest you create a snapshot using our tool - schnapps.
Thanks for the new Version!
Update installed without Problems.
Buuuuttt: I have problems to start “old” lxc-containers from Turris OS 3:
lxc-start gives me the output in the logfile:
start - start.c:start:2028 - Exec format error - Failed to exec “/sbin/init”
a second container:
start - start.c:start:2028 - Permission denied - Failed to exec “/sbin/init”
(the first-container i make a permission-change to 777 before, to test the Things…)
Could you help me? (which informations are needed? should i open a new thread?)
You could set up first a new guest container to test/see if lxc works in general, which would be expected, or fails too.
For the old container specifics run from cli lxc-start containername -F -l debug, or if you want to save the console output lxc-start containername -F -l debug -o /path/to/log/file
maybe another (known) limitation …
I’ve installed the fresh beta2 and noticed that you’ve updated lxc to 3.x which is cool. Unfortunately there is no longer the lxc-related ubus interface available - which makes the luci interface pretty useless. Is it planned to re-add ubus support in a later beta?
Just to avoid any misunderstanding, despite the different file mask both container are failing to start with the same Permission denied - Failed to exec “/sbin/init.?
And to clarify to which path this been applied
assuming /path/to/container?
If am not mistaken exec “/sbin/init” refers to the root of the guest and not the host. And former gets supposedly temporarily mounted to /usr/lib/lxc/rootfs/
It is used to temporary mount the rootfs of lxc in a private mount namespace only visible by the processes running in the container.
Not sure if that might be the underlying cause, assuming that that uid (root 0) is all the same at your node directories that are involved in the lxc running?
@BeCube, sorry bro for the late reply in my other topic, was kind of busy at work and all.
Last night when i read about Beta2 being released i updated it, however LXC was out and not visible in the lxc in luci. Just now i started to look what was wrong with it.
As there was no lxc container visible in luci i turned to the terminal and i saw that there was a problem the container not being visible. I suspected that it was because of the config being one based on version 2. I created another new container and decided to compare the new config file that is being created by lxc 3.x with the old config file.
#Template used to create this container: /usr/share/lxc/templates/lxc-download #Parameters passed to the template: --dist ubuntu --release bionic --arch armhf --server images.linuxcontainers.org --no-validate #For additional config options, please look at lxc.container.conf(5)
#Uncomment the following line to support nesting containers: #lxc.include = /usr/share/lxc/config/nesting.conf
#(Be aware this has security implications)
root@K-Router:/mnt/LXC/test# cat config #Template used to create this container: /usr/share/lxc/templates/lxc-download #Parameters passed to the template: #For additional config options, please look at lxc.container.conf(5)
#Uncomment the following line to support nesting containers: #lxc.include = /usr/share/lxc/config/nesting.conf
#(Be aware this has security implications)
#Some workarounds #Template to generate fixed MAC address
#Distribution configuration
lxc.arch = armv7l
#Container specific configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.hook.start-host = /usr/share/lxc/hooks/systemd-workaround
lxc.rootfs.path = dir:/mnt/LXC/test/rootfs
lxc.uts.name = test
#Container specific configuration
root@K-Router:/mnt/LXC/K-Router-LXC# cat config #Template used to create this container: /usr/share/lxc/templates/lxc-download #Parameters passed to the template: --dist ubuntu --release bionic --arch armhf --server images.linuxcontainers.org --no-validate #For additional config options, please look at lxc.container.conf(5)
#Uncomment the following line to support nesting containers: #lxc.include = /usr/share/lxc/config/nesting.conf
#(Be aware this has security implications)
So far the whole systemd issue seems like it being solved as the systemd services have started at boot of the lxc. Big thanks to the TOS team for fixing this issue by updating to lxc 3.0.3, it bothered me alot as i had to rely on init.d however not all apps had a init.d script.
appears to be absent from the default conf and subsequent container conf, unless I missed it somewhere. Not sure whether it would make a difference though but perhaps worth a try
As you stated that you can start containers in b1 and b2, then most probably it is something in the config just like @anon50890781 said. In my topic “LXC containers - how to restore them?” there i also pointed at the config being the root cause of not working.
For the “Test” container, I primitively set all permissions from the /srv/lxc/Test/ directory to 777 to see if the container will be started.
I did not change the second container.
The difference between the two containers are the error message:
“Permission Denied” to “Exec Format Error”
Sorry, i do not understand you
When i remember correctly, i created both containers from the WebFrontend.
I check the config and Change it to the new OS4b2-format, no difference.
I Play around with you three hints (lxc.arch+lxc.include + lxc.mount.entry) and hints from [Big_boss].
My actual config is (i played with the additional lines, which i commented out & activate - but no important difference):
What if you used the config of the test container for your actual container, ONLY changed a few settings, for example, the name (uts), rootfs. With the rootfs, also NOT changing the dir to btfrs. just ONLY the names where the directory is.
(to big_boss too)