Hi Vagrant, On Wed, 10 Apr 2019 15:22:18 -0700 Vagrant Cascadian wrote: > > On 2019-04-10, Vagrant Cascadian wrote: > > * gnu/packages/bootloaders (u-boot): Update to 2019.04. > ... > > (u-boot-am335x-evm): New variable. > > (u-boot-am335x-boneblack): Deprecate variable. > > The am335x-boneblack configuration was dropped from upstream. > > The am335x-evm image is considerably larger than the am335x-boneblack > images, which leads to issues when installing at a device offset, as it > will overwrite the first partition unless the first partition starts > significantly later than most tools (parted, cfdisk) default of sector > 2048 (beagleboard.org images start the first partition at sector 8192). > > The embedded-os-installation code should probably check to make sure > they aren't trampling the first partition if installing to the raw > device offset. That would make the parted bindings a hard dependency, probably even build-side. But I think that would still be better than the alternative: destroying user filesystems. > Alternately, it's possible to copy the u-boot.img onto the first FAT > partition of the microSD/eMMC, which will be loaded instead of the > offset. But that takes some rethinking of how to install the bootloader > (which would be good to not diverge from upstream for other platforms, > such as u-boot-novena). Yeah, I think sooner or later it's going to come to this. Might as well bite the bullet now. > In light of all that, I'm not sure what a proper way forward is... Yeah, sounds like a bad situation with no nice solution that allows updating of existing installations. In that case, keeping existing installations on the old version would be preferrable to breaking them.