@György-Farkas It's no immediate problem, but something not entirely clean either.
The environment here means the u-boot environment variables (configuration of the bootloader and the linux boot process), which are stored in a flash partition
u-boot-env of their own:
root@xyz:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 00fb0000 00010000 "firmware"
mtd4: 001393d6 00010000 "kernel"
mtd5: 00e76c2a 00010000 "rootfs"
mtd6: 00a00000 00010000 "rootfs_data"
There is a utility called
fw_printenv which is supposed to display the environment, and
fw_setenv to change these variables. These tools need
/etc/fw_env.config to be present. For some strange reason, this file sometimes does not exist on a fresh Omega2. You can create one manually with
echo "/dev/mtd1 0x0 0x1000 0x10000" >/etc/fw_env.config
fw_printenv works, but shows the same CRC error message you see in dmesg, because the data it tries to access is not valid.
However, when you start your Omega into u-boot command line (connect console, hold button and then switch on power and quickly press
1), you can see what really is in the uboot environment:
U-Boot 1.1.3 (Oct 18 2016 - 17:30:55)
Omega2 # printenv
From here, the uboot-env is writable, like:
setenv myvarname myvalue
When you now boot the Omega again normally, and then use
fw_printenv, there's no CRC error any more, and you see the same info as from the uboot command line.
Conclusion: something is wrong in the way the u-boot env is initialized on the Omega2, such that no correct CRC value is written.
To track down this entirely, we'll have to wait until Onion also publishes their modified u-boot - soon, I hope, now that they finally published their LEDE tree)!