U-Boot supports two redundant copies of its environment as an optional feature. This is typically configured in board-specific include/configs/foo-board-name.h files. It seems that users are free to choose where to put these copies, and there's no standard for this as far as I can tell. Buildroot currently does not attempt to keep the real U-Boot's config and uboot-tools' config in sync. In fact, there's no effort to keep their versions synced, and probably for a good reason (one might not want to update the bootloader, for example). Buildroot also attempts to patch out a dependency on a "config.h" for uboot-tools (package/uboot-tools/0001-drop-configh-from-tools.patch). Apparently, the idea is to rely on a properly configured /etc/fw_env.config for env offsets, etc. This is a problem because fw_putenv does not know that a redundant environment is in use, and it only writes one copy. I checked with strace; fw_printenv reads both copies, but then it only stores the primary one: open("/etc/fw_env.config", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=70, ...}) = 0 read(4, "/dev/mmcblk0 0xf0000 0x10000 0x2"..., 4096) = 70 close(4) = 0 open("/dev/mmcblk0", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(179, 0), ...}) = 0 close(4) = 0 open("/dev/mmcblk0", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(179, 0), ...}) = 0 close(4) = 0 open("/dev/mmcblk0", O_RDONLY) = 4 lseek(4, 983040, SEEK_SET) = 983040 read(4, "\32\224!\324\"BOOT_A_LEFT=3\0BOOT_B_LEFT=2"..., 65536) = 65536 <---- this is the primary copy close(4) = 0 brk(0x69000) = 0x69000 open("/dev/mmcblk0", O_RDONLY) = 4 lseek(4, 917504, SEEK_SET) = 917504 read(4, "\226\37\326:#BOOT_A_LEFT=3\0BOOT_ORDER=B "..., 65536) = 65536 <---- secondary environment close(4) = 0 open("/dev/mmcblk0", O_RDWR) = 4 open("/dev/mmcblk0", O_RDWR) = 5 lseek(5, 983040, SEEK_SET) = 983040 write(5, "Sgm[$BOOT_A_LEFT=3\0BOOT_ORDER=B "..., 65536) = 65536 <---- this is the primary's address close(5) = 0 close(4) = 0 brk(0x49000) = 0x49000 flock(3, LOCK_UN) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++
Hmm, this might actually be an upstream issue. I'm looking into the code now, and it seems that it does notice that I have two environments (it's basically counting the relevant lines in the config file). Just one of them is being updated, though, which might or might not be a result of some recent changes. Note that I'm using 2017.07 for the tools and 2017.09 for the actual bootloader.
(In reply to Jan Kundrát from comment #1) Since it is not a buildroot issue, let's close the bug as invalid.