So what you are saying is that it works now without any errors?
Sorry, my englishā¦.
No, The OS4b2 container runs with the old config (+Change of the two lines), the OS3 container does not runs with the new config (+Chage of the two lines).
=> Nothing changed 
Just do exactly what i say.
Put the old config to config.old
cp config config.old
Browse to the directory of the test container and copy this config to the config of your actual container.
So in your actual container there should be a config and a config.old file.
In the new config file, change ONLY the uts name, KEEP the dir: and do not copy the whole line. Also change the rootfs. Afterwards, try to start the container if it still does not work, then the problem is NOT with the config, but within your rootfs or something.
Yes, i have done this with both containers:
The OS4b2 created works
The OS3 created do not work.
I Change only the ālxc.rootfs.pathā and the ālxc.uts.nameā lines.
The OS3-Container throws out the same error-message as before
can you change this
lxc.rootfs.path = btrfs:/srv/lxc/CosmicTest2/rootfs
to this
lxc.rootfs.path = dir:/srv/lxc/CosmicTest2/rootfs
the same, for both old containers (Exec Format Error & Permission error)
I then suspect that the problem does not lie with LXC, but with something else.
thanks for your efforts
BTW, guys, i am just scrolling down to see what changes did come after the previous version of LXC.
You can lxc-attach, lxc-start, lxc-stop etc. WITHOUT the -n. For example just lxc-attach < name of the container >
If you also like to take a look at the changes so far.
https://linuxcontainers.org/lxc/news/
hi there
how stable is this beta-version?
i donāt need everything to work perfectly, however basic internet access (and thus sfp, dhcp & wan-lan routing) has to work. other than that iām mostly using default configuration (no wlan) with the addition of openvpn & lxc-containers on a btrfs formatted msata ssd. (I do have installed the following packages as well though i donāt really use them: Data Collection, LuCI extensions, Pakon, NAS, Netmetr, Extensions of network protocols, Cloud Backups.)
is it possible to upgrade without flashing?
iām fine if i have to reconfigure everything & recreate the lxc containers, no migration needed. however i want to retain at least the current snapshot so in case of an error i can rollback/revert to the current configuration (3.11.4), wheras AFAIK flashing wipes the eMMC.
thanks
[Edit]
just found a note in Turris OS 4.0 alpha3 is out!, that with
$ schnapps create pre-4.0 backup
$ schnapps export 167 /mnt/backup
i can create a usb-stick of the last snapshot.
so is this the suggested way?:
does for me since beta 1. I am only using a DSl modem in the SFP port thus cannot comment on fiber use. There is a note in the Alpha release about extra step required to utilize the SFP port.
That should work for creating new containers but may have some issue with containers created with lxc 1.x / 2.x in TOS3.x - see the above in the thread.
migration from 3.x to 4.x is being worked on but will need some to complete
Thus at this stage migration via medkit is recommended, as outline in the initial post.
always good practice to retain a snapshot of a last good known installation on drive other than an internal drive of the device, i.e. after the export download it to some client for safekeeping for potential disaster recovery.
Thanks.
Took the plunge and tried it. However i think the image is broken.
after flashing TOS4b2, my turris omnia was stuck in some sort of reboot loop. The leds would show the āknight riderā-animation about every 15secs, at which point i lost ethernet only to get it back a few seconds later (with the normal mode leds lighting up), with a 192.168.1.x IP and 192.168.1.1 as gateway. so i think dhcp startup was successful. however i never managed to connect via http to the foris or lucl GUI. probably the webserver never started. Neither the DNS-Resolver, nslookup got a dns however dns resolution always failed.
since the omnia has no screen and the GUI isnāt there i canāt see the system log so i donāt know why itās stuck in a reboot loopā¦ or would it be possible to ssh into it? whats the default password?
at least the rollback re-flash from the backup i created an hour ago worked flawlessly. At least now i have the confidence that works as intended! 
Sounds a reasonable assumption. If Foris fails then as casualty train lighttpd fails as well and LuCI is inaccessible thus.
the log would be required to debug. I never managed in such case to login via sshd as setting a passwd did not work, though according to upstream documentation it should but that behaviour might be patched/altered by TOS.
Only way to get to the logs then is via UART console
OK Quick query, Iām currently running Beta 1, I expected the device to upgrade to beta 2, but as yet that hasnāt happened. Is the fact this hasnāt happened a bug or working as advertised?
as per the turris documentation, to login via ssh the root password has to be set using the foris webgui.
however i managed to get the log using the UART console and opened an issue with it attached: Turris 4.0 beta1/2/4 on Omnia = kernel panic/reboot loop (#35) Ā· Issues Ā· Turris / Turris OS / Turris Build Ā· GitLab
sadly, i have no more time for this, holidayās overā¦ i hope the turris guys can fix it for beta3! 
btw: the turris 4.0 beta1 is no longer available, otherwise i would have tried that as wellā¦
1 Like
Have you checked your update setting in foris?
It works on my MOX
Iāve switched to this beta from Turris OS 3.11.4 and everything is working fine, except for the missing kmod-ipt-nathelper-rtsp package. Was it removed on purpose? I need it for my ISP IPTV. Iāve tried to replace it by igmpproxy but without success.
I do not know if this is relevant to you but I had to edit the file /etc/config/network in order to get igmpproxy to work. It started to work after I added option igmp_snooping '1' in the lan section.
1 Like