New: uboot-tools' fw_setenv does not update the redundant environment

https://bugs.busybox.net/show_bug.cgi?id=10426

Bug ID: 10426
Summary: uboot-tools' fw_setenv does not update the redundant
environment
Product: buildroot
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: jan.kundrat at cesnet.cz
CC: buildroot at uclibc.org
Target Milestone: ---

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 +++

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10426

Ricardo Martincoski <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at buildroot.uclibc |ricardo.martincoski at datacom
|.org |.ind.br

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10426

--- Comment #1 from Jan Kundr?t <[email protected]> ---
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.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10426

Ricardo Martincoski <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Ricardo Martincoski <[email protected]> --- (In reply to Jan Kundr?t from comment #1)

Since it is not a buildroot issue, let's close the bug as invalid.

You are receiving this mail because:
You are on the CC list for the bug.