This seems true, but...
After some tests I found that uboot version 2013.01.01 still can sometimes brick a device.
I can't say wether it's this concrete version or all of them including 2017, but power-cycling the device when bootloader saves environment variables leads to corruption of uboot.env file.
After that you see:
FAT: Misaligned buffer address (3fed6738)
Invalid FAT entry
*** Warning - bad CRC, using default environment
Default environment doesn't have snappy_boot variable and as a result will not boot UbuntuCore at all, neither kernel nor initrd.
Standard UbuntuCore snappy_boot saves environment every time it boots, not only when something gets updated. So that the probability of that fail is very high. I had some tests when I tried to catch the moment of writing environment to FAT and trigger the power off. And I can say that it's not difficult to achieve, I get this in 5th trial.
Moreover the first time I had this situation was a casual work with device when I turned it on, changed my mind, turned it off in 1.5 second and I got precisely in that moment of saving uboot.env.
After that disaster I put my SD card in a card-reader and:
denis@denis-m1:~$ sudo fsck.fat /dev/sdc1
[sudo] password for denis:
fsck.fat 3.0.28 (2015-05-16)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
Contains a free cluster (49455). Assuming EOF.
File size is 131072 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.
Perform changes ? (y/n) y
/dev/sdc1: 91 files, 26551/258078 clusters
Well, the result is sad, uboot.env is lost and so the ability to boot.
Is it inevitable behavior or I just miss something?
P.S. And BTW, I don't see how "RUDUNDANT" works here in the case of FAT write to uboot.env. For example when you use SPI-NOR flash or NAND flash with CONFIG_SYS_REDUNDAND_ENVIRONMENT, you also have CONFIG_ENV_OFFSET_REDUND. And there are 2 copies present. And I suppose it can revert back to healthy environment every time something happens. I never saw it in action but at least this is present in uboot sources. In env_fat.c OFFSET is not used.
// --------------- cut--------------------------------------
read1_fail = readenv(CONFIG_ENV_OFFSET, (u_char *) tmp_env1);
read2_fail = readenv(CONFIG_ENV_OFFSET_REDUND, (u_char *) tmp_env2);
if (read1_fail && read2_fail)
puts("*** Error - No Valid Environment Area found\n");
else if (read1_fail || read2_fail)
puts("*** Warning - some problems detected "
"reading environment; recovered successfully\n");
Then it checks crc32 and handles env_valid flags.