Suppose I boot my device in an unusual mode, such as from a USB Mass storage device, via network, or maybe a removable SD card. It’s not the normal boot medium. Perhaps, there is something wrong with the rootfs(es) in the normal boot medium and they do not boot…
If I try to do a standalone manual mender update, with mender -install, mender kindly informs me the device is not running from any configured root filesystem. Which is quite true. But it then refuses to install the update. I assume, because it can not determine what rootfs it should be installed to.
Is there a way to force the install anyway? I could tell mender which rootfs it should install to. Or it could figure out what rootfs the bootloader will boot from next, and install it there. The rootfs which is not in use and the rootfs which will be used on the next boot are not exactly the same thing.
Sorry, there is no such mechanism currently. Mender expects that the
rootfs is configured and that the bootloader is also configured for this
pair of partitions.
Further, it sounds to me that you would be best to do a “re-provision” of the device in this case e.g using the “.uefiimg” file in this case to re-write the “correct” storage medium to get a working device.
While I could re-flash the entire eMMC chip, this takes 42 minutes, and would reset the persistent data partition too. I don’t really need to do that. All I need is what Mender would do: to flash a single rootfs partition. That only takes a couple minutes.
So I’m left with transferring a compressed ext4 image manually and flashing it by hand. When there is a perfectly good automatic system that already does exactly this.
This also means Mender isn’t used during development. Using stuff when developing a product is a good way to get the bugs worked out.
During development, I just scp’d the mender file onto the device and ran mender -install from an ssh session
If you want to cut the time for a full image flash from mass storage mode, I use bmaptools as my yocto build is configured to produce a bmap file along with the corresponding sdimg. For me flashing this way is faster than doing a mender install.
Yes, that’s exactly what I’d like to do. Except I didn’t boot from the normal rootfs, as the normal boot rootfs partitions are not in a functional state. And maybe I want to boot over NFS because it’s a heck of a lot faster to update than the eMMC.
When mender -install is run, it fails, because the system is not currently running on one of the eMMC partitions. There’s no reason Mender can’t update one of those partitions, it just won’t do it.
I believe mender -install does a lot more than writing to the rootfs partition, I believe it is also using fw_utils to manipulate the uboot environment of an active running system in preparation for a reboot and subsequent commit, so being able to do this offline with mender -install I would hazard a guess is probably outside of the initial design spec. However I could be wrong and the team is always happy to receive pull requests.
It does do that. Though in my case, I’m using Barebox, so it uses bareboxenv to accomplish the same thing. But this will work perfectly well when the currently running root file systems is not one of the two Mender knows about.
The bootloader env isn’t in the rootfs, so it doesn’t matter. The code in Mender that changes the env doesn’t know what rootfs is running. It’s not one of the variables that gets passed to the BootEnvReadWriter interface. And all the code in dual_rootfs_device only cares about what rootfs is being install into. What rootfs is currently running is only used to determine what rootfs to install into (the install target being the rootfs that isn’t running).
So I don’t see any reason it wouldn’t be possible to allow mender -install xxx.mender -target rootfsPartB to work easily.
Given, that you have done a lot of good investigation so far, and identified that it should be possible, maybe the next stage is to have a go at making the necessary changes to make it work and supply a pull request?
