# Force Mender to boot form the passive partition

**URL:** <https://hub.mender.io/t/force-mender-to-boot-form-the-passive-partition/6797>\
**Category:** General Discussions\
**Created:** [May 6, 2024, 6:28pm UTC](https://hub.mender.io/t/force-mender-to-boot-form-the-passive-partition/6797 "2024-05-06T18:28:34Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![zivkapl](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/zivkapl/32/2061_2.png) [@zivkapl](https://hub.mender.io/u/zivkapl)\
**Post date:** [May 6, 2024, 6:28pm UTC](https://hub.mender.io/t/force-mender-to-boot-form-the-passive-partition/6797/1 "2024-05-06T18:28:34Z")

</div>

Hi all,  
Can I force the mender-client (maybe by setting some vars) to rollback to the passive partition?

Ill use an example:  
Lets assume I have a device running my app and have mender roots module installed.  
One day, I sent an upgrade and the everything goes well.  
Deice current state is:  
Active Partition - new app  
Passive partition - old app  
One day I discover a critical bug or vulnerability on my app’s new version - can I use mender-client to roll back immediately to the previous stable state?

Thanks

---

<div class="post-metadata">

**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\
**Post date:** [May 6, 2024, 7:20pm UTC](https://hub.mender.io/t/force-mender-to-boot-form-the-passive-partition/6797/2 "2024-05-06T19:20:13Z")

</div>

Hi @zivkapl,

You can write a custom Update Module (or use the `script` one) which manually switches, as shown in the integration documentation: [Integration checklist | Mender documentation](https://docs.mender.io/client-installation/integration-checklist#confirm-os-switch-using-bootloader-variables)

Please note though that this will have all kinds of unexpected effects, both on your applications persistent state as well as the reported versions in Mender, so I’d always try to avoid it.

The correct way in such a case is basically always to redeploy the old, previous version through a new deployment.

Greets,  
Josef
