Doubt related to the OTA update Mechanism for Debian Operating System
I am working on the OTA update for an embedded system project. You can assume my hardware like Raspberry Pi / Beaglebone and the operating system is a Debian 9.
This OTA update mechanism will be A + B Redundancy update. Where there will be 3 total partitions available. Partition A will have a Debian Operating system and Partition B will have a separate Debian operating system. Partition C will be a persistent partition where I'll be storing all my Configuration which I don't want to change or get affected by an OTA update. There will be one Active and another inactive partition.
I'm planning to have 2 Types of the update mechanism. One will be a File Level update and another is an OS level update.
File-level Update:
Now at first Instance let's consider Partition A is an active Partition and Partition B is an inactive partition. Partition C will always be a Persistent partition for configuration and will never be affected by an OTA update. A file level update will be deployed by the server and the hardware will be continuously polling for the update. ( Every 24 hrs possibly ) Once the update is downloaded from the network it will be copied to the inactive partition ( Partition B ) and all the files will be placed in proper directories according to the package configuration and requirement.
Now Once the OTA update is done the Boot Priority of the hardware will change ( Here Partition B will become Active Partition ) So that once the user reboots the hardware it will be rebooted into an updated Partition ( In this instance Which will be Partition B ).
OS-level Update:
For OS-Level update, I'll be sending a new version of the operating system as an update to the user. In this update, the Same mechanism will be followed like the File level only a minor difference will be that here the inactive partition will be flashed with the new image of the operating system. Here also U-boot bootloader can help in configuring the Boot Priority Same as above.
I am using a Rauc Framework for the OTA update mechanism at the client side. I hope the above explanation gave a clear idea about the mechanism. I have a doubt related to the above mechanism as I am a newbie:
Question:
According to my understanding, the above mechanism will provide a fail-safe update ( Offcourse I need to add some more validations for that purpose ) but I have a doubt related to the mechanism. Is this the right way to provide the OTA Update for Embedded Device? Or is there any other mechanism which is more feasible and scalable than the above one?
I would like to have feedback on the above implementation and where I might have gone wrong?
Thanks
debian raspberry-pi upgrade software-updates beagleboneblack
New contributor
add a comment |
I am working on the OTA update for an embedded system project. You can assume my hardware like Raspberry Pi / Beaglebone and the operating system is a Debian 9.
This OTA update mechanism will be A + B Redundancy update. Where there will be 3 total partitions available. Partition A will have a Debian Operating system and Partition B will have a separate Debian operating system. Partition C will be a persistent partition where I'll be storing all my Configuration which I don't want to change or get affected by an OTA update. There will be one Active and another inactive partition.
I'm planning to have 2 Types of the update mechanism. One will be a File Level update and another is an OS level update.
File-level Update:
Now at first Instance let's consider Partition A is an active Partition and Partition B is an inactive partition. Partition C will always be a Persistent partition for configuration and will never be affected by an OTA update. A file level update will be deployed by the server and the hardware will be continuously polling for the update. ( Every 24 hrs possibly ) Once the update is downloaded from the network it will be copied to the inactive partition ( Partition B ) and all the files will be placed in proper directories according to the package configuration and requirement.
Now Once the OTA update is done the Boot Priority of the hardware will change ( Here Partition B will become Active Partition ) So that once the user reboots the hardware it will be rebooted into an updated Partition ( In this instance Which will be Partition B ).
OS-level Update:
For OS-Level update, I'll be sending a new version of the operating system as an update to the user. In this update, the Same mechanism will be followed like the File level only a minor difference will be that here the inactive partition will be flashed with the new image of the operating system. Here also U-boot bootloader can help in configuring the Boot Priority Same as above.
I am using a Rauc Framework for the OTA update mechanism at the client side. I hope the above explanation gave a clear idea about the mechanism. I have a doubt related to the above mechanism as I am a newbie:
Question:
According to my understanding, the above mechanism will provide a fail-safe update ( Offcourse I need to add some more validations for that purpose ) but I have a doubt related to the mechanism. Is this the right way to provide the OTA Update for Embedded Device? Or is there any other mechanism which is more feasible and scalable than the above one?
I would like to have feedback on the above implementation and where I might have gone wrong?
Thanks
debian raspberry-pi upgrade software-updates beagleboneblack
New contributor
add a comment |
I am working on the OTA update for an embedded system project. You can assume my hardware like Raspberry Pi / Beaglebone and the operating system is a Debian 9.
This OTA update mechanism will be A + B Redundancy update. Where there will be 3 total partitions available. Partition A will have a Debian Operating system and Partition B will have a separate Debian operating system. Partition C will be a persistent partition where I'll be storing all my Configuration which I don't want to change or get affected by an OTA update. There will be one Active and another inactive partition.
I'm planning to have 2 Types of the update mechanism. One will be a File Level update and another is an OS level update.
File-level Update:
Now at first Instance let's consider Partition A is an active Partition and Partition B is an inactive partition. Partition C will always be a Persistent partition for configuration and will never be affected by an OTA update. A file level update will be deployed by the server and the hardware will be continuously polling for the update. ( Every 24 hrs possibly ) Once the update is downloaded from the network it will be copied to the inactive partition ( Partition B ) and all the files will be placed in proper directories according to the package configuration and requirement.
Now Once the OTA update is done the Boot Priority of the hardware will change ( Here Partition B will become Active Partition ) So that once the user reboots the hardware it will be rebooted into an updated Partition ( In this instance Which will be Partition B ).
OS-level Update:
For OS-Level update, I'll be sending a new version of the operating system as an update to the user. In this update, the Same mechanism will be followed like the File level only a minor difference will be that here the inactive partition will be flashed with the new image of the operating system. Here also U-boot bootloader can help in configuring the Boot Priority Same as above.
I am using a Rauc Framework for the OTA update mechanism at the client side. I hope the above explanation gave a clear idea about the mechanism. I have a doubt related to the above mechanism as I am a newbie:
Question:
According to my understanding, the above mechanism will provide a fail-safe update ( Offcourse I need to add some more validations for that purpose ) but I have a doubt related to the mechanism. Is this the right way to provide the OTA Update for Embedded Device? Or is there any other mechanism which is more feasible and scalable than the above one?
I would like to have feedback on the above implementation and where I might have gone wrong?
Thanks
debian raspberry-pi upgrade software-updates beagleboneblack
New contributor
I am working on the OTA update for an embedded system project. You can assume my hardware like Raspberry Pi / Beaglebone and the operating system is a Debian 9.
This OTA update mechanism will be A + B Redundancy update. Where there will be 3 total partitions available. Partition A will have a Debian Operating system and Partition B will have a separate Debian operating system. Partition C will be a persistent partition where I'll be storing all my Configuration which I don't want to change or get affected by an OTA update. There will be one Active and another inactive partition.
I'm planning to have 2 Types of the update mechanism. One will be a File Level update and another is an OS level update.
File-level Update:
Now at first Instance let's consider Partition A is an active Partition and Partition B is an inactive partition. Partition C will always be a Persistent partition for configuration and will never be affected by an OTA update. A file level update will be deployed by the server and the hardware will be continuously polling for the update. ( Every 24 hrs possibly ) Once the update is downloaded from the network it will be copied to the inactive partition ( Partition B ) and all the files will be placed in proper directories according to the package configuration and requirement.
Now Once the OTA update is done the Boot Priority of the hardware will change ( Here Partition B will become Active Partition ) So that once the user reboots the hardware it will be rebooted into an updated Partition ( In this instance Which will be Partition B ).
OS-level Update:
For OS-Level update, I'll be sending a new version of the operating system as an update to the user. In this update, the Same mechanism will be followed like the File level only a minor difference will be that here the inactive partition will be flashed with the new image of the operating system. Here also U-boot bootloader can help in configuring the Boot Priority Same as above.
I am using a Rauc Framework for the OTA update mechanism at the client side. I hope the above explanation gave a clear idea about the mechanism. I have a doubt related to the above mechanism as I am a newbie:
Question:
According to my understanding, the above mechanism will provide a fail-safe update ( Offcourse I need to add some more validations for that purpose ) but I have a doubt related to the mechanism. Is this the right way to provide the OTA Update for Embedded Device? Or is there any other mechanism which is more feasible and scalable than the above one?
I would like to have feedback on the above implementation and where I might have gone wrong?
Thanks
debian raspberry-pi upgrade software-updates beagleboneblack
debian raspberry-pi upgrade software-updates beagleboneblack
New contributor
New contributor
New contributor
asked 7 mins ago
Sharvin ShahSharvin Shah
1
1
New contributor
New contributor
add a comment |
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sharvin Shah is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501518%2fdoubt-related-to-the-ota-update-mechanism-for-debian-operating-system%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sharvin Shah is a new contributor. Be nice, and check out our Code of Conduct.
Sharvin Shah is a new contributor. Be nice, and check out our Code of Conduct.
Sharvin Shah is a new contributor. Be nice, and check out our Code of Conduct.
Sharvin Shah is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501518%2fdoubt-related-to-the-ota-update-mechanism-for-debian-operating-system%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown