Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installation error: Unsupported image boot_bundle.img.caibx for slot type boot-mbr-switch #804

Open
timemaster5 opened this issue Nov 6, 2021 · 5 comments
Labels
question RFE Request for Enhancement
Milestone

Comments

@timemaster5
Copy link

Hi, I am facing this issue after turning on a boot-mbr-switch for a bootloader partition.
For a rootfs, I've been using rauc+casync successfully.
I was kind of expecting not to chunk the boot images.

Any thoughts on how I could fix this?

I am on the latest rauc 1.5.1

@ejoerns
Copy link
Member

ejoerns commented Nov 9, 2021

@timemaster5 Unfortunately, there is no easy way to fix this, yet.

As you already pointed out correctly, not chunking selected slots at all is the generic solution.

We had a discussion about this in the #irc/matrix chat some weeks ago. I just dug it out again to sum up the findings:

  • We need a switch to deactivate conversion to caidx/caibx for some images
  • Switch should be either
    • in the manifest as convert-casync=false, or
    • in the command line call as argument --no-converty-casync="bootloader ..."

Another point to solve that came up with this is how to proceed with the rauc convert command in general.
Up to now this is meant only for casync bundle conversion. But it might be required to also cover other conversion purposes in the future. Thus one suggestion was to have a command line option to select the actual conversion and have casync as the default for backwards compatibility with external tools etc.

Final note on the conversation from @jluebbe was:

@ejoerns maybe we should first figure out how we want to control the various conversion options with rauc convert in the future

So this is the current state of our discussion.

@timemaster5 Feel free to share your opinion or demands on this :)

@ejoerns ejoerns added question RFE Request for Enhancement labels Nov 9, 2021
@timemaster5
Copy link
Author

Hi @ejoerns , thank you very much for you reply.

I went through the code and found out that there is really no matching pair of any kind of .caibx format for the boot-mbr-switch.

I found some discussion though in the issues here, but can't remember the name. Someone there was suggesting that it shouldn't be that hard to implement .caibx with vfat for mbr-boot-switch too, but there wasn't probably a high demand.

So then I was naturally looking for some --exclude option in rauc convert, without success :) But it was definitely the place I was checking to resolve my problem. What you suggest is basically this, so I am 100% for it.

My workaround was however to add the image as a file instead of a slot. I don't know exactly what does it mean translated to the command line arguments for rauc convert as I use meta-rauc with Yocto build system. But I guess if someone needs, it should be possible to get the clues from this bundle bbclass.

The orginal configuration code in my bundle recipe was

RAUC_SLOT_bootloader[file] = "boot_bundle.img"
RAUC_SLOT_bootloader[type] = "image"

and I have replaced it with:

RAUC_BUNDLE_EXTRA_FILES += "boot_bundle.img"

And in the post-install hook I do:

rauc write-slot bootloader.0 ${RAUC_BUNDLE_MOUNT_POINT}/boot_bundle.img

Interesting on this is that when I check the bundle with rauc info, I see one image and 0 files. Which is strange, and maybe some bug. A hook script is also not being shown in the files section, but it is at least mentioned in the image details section of the output. But that's fine with me as long as my bootloader image file is in the bundle:)

This approach is applicable only on small images as it defeats the point of having casync in place, but I guess for the boot-mbr-switch the images are gonna be pretty small, so we are good here.

@ejoerns
Copy link
Member

ejoerns commented Nov 10, 2021

Hi @ejoerns , thank you very much for you reply.

I went through the code and found out that there is really no matching pair of any kind of .caibx format for the boot-mbr-switch.

Exactly.

I found some discussion though in the issues here, but can't remember the name. Someone there was suggesting that it shouldn't be that hard to implement .caibx with vfat for mbr-boot-switch too, but there wasn't probably a high demand.

Yes, witth adding a switch for caibx in the handler functions and calling casync_extract() instead of copy_raw_image() it should be possible.

So then I was naturally looking for some --exclude option in rauc convert, without success :) But it was definitely the place I was checking to resolve my problem. What you suggest is basically this, so I am 100% for it.

My workaround was however to add the image as a file instead of a slot. I don't know exactly what does it mean translated to the command line arguments for rauc convert as I use meta-rauc with Yocto build system. But I guess if someone needs, it should be possible to get the clues from this bundle bbclass.

You did add it as a loose artifact in the bundle. This is just like placing any random file there that RAUC itself does not really know about. It is just packed into the bundle (squashfs) and accessible for hooks from there.

The orginal configuration code in my bundle recipe was

RAUC_SLOT_bootloader[file] = "boot_bundle.img"
RAUC_SLOT_bootloader[type] = "image"

and I have replaced it with:

RAUC_BUNDLE_EXTRA_FILES += "boot_bundle.img"

And in the post-install hook I do:

rauc write-slot bootloader.0 ${RAUC_BUNDLE_MOUNT_POINT}/boot_bundle.img

Interesting on this is that when I check the bundle with rauc info, I see one image and 0 files. Which is strange, and maybe some bug. A hook script is also not being shown in the files section, but it is at least mentioned in the image details section of the output. But that's fine with me as long as my bootloader image file is in the bundle:)

The 'files' you see in rauc info is not to be confused with what you thought you've seen. This is completely unrelated.
As noted above, the 'file' you add with RAUC_BUNDLE_EXTRA_FILES is just some random content to be added to the bundle while the files info you see in rauc info is a remnant from an old non-bundle network mode in rauc. This is already removed in master.

I actually onder which image you see if you did not defined one and would say that your post-install hook should actually be an install hook instead.

This approach is applicable only on small images as it defeats the point of having casync in place, but I guess for the boot-mbr-switch the images are gonna be pretty small, so we are good here.

@timemaster5
Copy link
Author

Hi @ejoerns, thank you for the explanation, it is simpler than I thought.

To clarify my bit. I have pasted above only the part related to the boot-mbr-switch.

Besides that I have a rootfs slot defined of ext4 image. So this is what gives me a bundle converted to chunks, and what triggers post-install hook during the update process.

What is a bit strange to me though is the fact that rauc write-slot works a little bit different for the A/B deployments than for the boot-mbr-switch. For boot-mbr-switch it switches to the other (previously hidden) partition, whereas for an image update it only copies files to the partition and the actual switch has to be done manually. But I am glad at this moment it is like that :)

@ejoerns
Copy link
Member

ejoerns commented Nov 11, 2021

What is a bit strange to me though is the fact that rauc write-slot works a little bit different for the A/B deployments than for the boot-mbr-switch. For boot-mbr-switch it switches to the other (previously hidden) partition, whereas for an image update it only copies files to the partition and the actual switch has to be done manually. But I am glad at this moment it is like that :)

The reason for this that the boot-mbr-switch is not part of the A/B scheme. It only serves as a method to atomically write a (single) slot. Think of it like an atomic file writing operation.

@jluebbe jluebbe added this to the Unplanned milestone Apr 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question RFE Request for Enhancement
Projects
None yet
Development

No branches or pull requests

3 participants