Turris OS 4.0 beta2 is out!

i changed this two lines:
lxc.rootfs.path = btrfs:/srv/lxc/CosmicTest2/rootfs
lxc.uts.name = CosmicTest2

The Cosmic-Container starts + lxc-attach is possible

Addtional, Maybe it’s interesting:

root@Fritz:/srv/lxc# ls -lisa /srv/lxc/Asterisk/rootfs/sbin/init
 374164    192 -r--------    1 root     root        194844 Jul 18  2014 /srv/lxc/Asterisk/rootfs/sbin/init
root@Fritz:/srv/lxc# ls -lisa /srv/lxc/CosmicTest2/rootfs/sbin/init
  17345      4 lrwxrwxrwx    1 root     root            20 Apr  4 13:29 /srv/lxc/CosmicTest2/rootfs/sbin/init -> /lib/systemd/systemd

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 :frowning:

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.

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.


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?:

  1. create a backup usb flash drive from current eMMC (as described above)
  2. re-flash 4.0b2 using another usb flash drive
  3. be happy or if it doesn’t work re-flash using the backup flash drive

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.


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 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! :slight_smile:

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: https://gitlab.labs.nic.cz/turris/turris-build/issues/35

sadly, i have no more time for this, holiday’s over… i hope the turris guys can fix it for beta3! :crossed_fingers:

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