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.
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
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
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.
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?:
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 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: 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!
btw: the turris 4.0 beta1 is no longer available, otherwise i would have tried that as well…
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