# Force install an update to a specific partition? **URL:** \ **Category:** General Discussions\ **Created:** [March 3, 2020, 3:37am UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593 "2020-03-03T03:37:40Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![tpiepho](https://avatars.discourse-cdn.com/v4/letter/t/e9a140/32.png) [@tpiepho](https://hub.mender.io/u/tpiepho)\ **Post date:** [March 3, 2020, 3:37am UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/1 "2020-03-03T03:37:40Z")
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. ---
**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\ **Post date:** [March 3, 2020, 6:58am UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/2 "2020-03-03T06:58:16Z")
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. ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [March 3, 2020, 9:45am UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/3 "2020-03-03T09:45:44Z")
> [@tpiepho](#): > > 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… 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. ---
**Author:** ![tpiepho](https://avatars.discourse-cdn.com/v4/letter/t/e9a140/32.png) [@tpiepho](https://hub.mender.io/u/tpiepho)\ **Post date:** [March 3, 2020, 5:27pm UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/4 "2020-03-03T17:27:17Z")
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. ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [March 3, 2020, 7:17pm UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/5 "2020-03-03T19:17:23Z")
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. ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [March 3, 2020, 7:50pm UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/6 "2020-03-03T19:50:56Z")
> [@dellgreen](#): > > During development, I just scp’d the mender file onto the device and ran mender -install from an ssh session Yes, this. Even better, one can run `mender -install http://` and on the host just run `python -m http.server` wherever my `.mender` file is. ---
**Author:** ![tpiepho](https://avatars.discourse-cdn.com/v4/letter/t/e9a140/32.png) [@tpiepho](https://hub.mender.io/u/tpiepho)\ **Post date:** [March 3, 2020, 9:37pm UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/7 "2020-03-03T21:37:17Z")
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. ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [March 3, 2020, 10:30pm UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/8 "2020-03-03T22:30:53Z")
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. 🙂 ---
**Author:** ![tpiepho](https://avatars.discourse-cdn.com/v4/letter/t/e9a140/32.png) [@tpiepho](https://hub.mender.io/u/tpiepho)\ **Post date:** [March 3, 2020, 11:09pm UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/9 "2020-03-03T23:09:12Z")
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. ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [March 4, 2020, 6:38am UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/10 "2020-03-04T06:38:41Z")
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? ---
**Author:** ![shainert.israel](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/shainert.israel/32/438_2.png) [@shainert.israel](https://hub.mender.io/u/shainert.israel)\ **Post date:** [March 12, 2020, 11:49am UTC](https://hub.mender.io/t/force-install-an-update-to-a-specific-partition/1593/11 "2020-03-12T11:49:13Z")
Note that you will need to mark this “update” as special without rollback (no other (original) partition is ready).