8 replies to this topic

[Qu@rk]

VUDUO4K with multiboot, 8.3

 

I performed an software update today and the updater forced an upgrade to 9.0 without notification.

Everything was lost, settings, plugins, multiboot etc. That really sucks!

 

Beford the update I have created an backupsuite backup. I assume the restore of an multiboot image to single boot fails.

So I had to flash 9.0, initialize multiboot, create a backup image from the backupsuite backup (create zip file, rename it and put it in hdd/images) and flash the 8.3 backup to slot 1.

That worked so far.

 

But as soon as I connect via SMB to the box from my Windows PC the box freezes and loses network connection.

I have to hard power off the box using the power switch.

 

I am fighting for 4 hours now to get the box running with 8.3 again.

 

What can I do to restore my 8.3 backup correctly?

Edited by Qu@rk, 30 June 2024 - 15:04.

[Qu@rk]

I tried to enable multiboot again and restored my today's backup of 8.3 but it did not work not matter what I tried.

 

I tried another approach:

 

I "injected" a kernel image (bin) of an old (6 months) backupsuite single-boot-backup into my today's multiboot backup and flashed it.

That have seemed to work. But it's a dirty solution, I guess.

 

Why does the software updater of 8.3 force an upgrade to 9.0 by installing/updating packages?

That will never work.

Edited by Qu@rk, 30 June 2024 - 16:31.

[WanWizard]

There is nothing in an OpenPLi image that updates across major releases, so a software update "forcing" an update from 8.3 to 9.0 is impossible. Major image version have different package feeds.

 

There is a generic issue, in ALL images, when you update an image that has a kernel update, and you're using kexec multiboot. This is being discussed by all image makers at the moment.

 

A workaround to fix this is in our wiki: https://wiki.openpli...er_an_update.3F

 

Simply searching for this issue would have saved you hours...

[Qu@rk]

Well, I found the Wiki  before but it did not work or help because my installation was already messed up by the updater (and new kernel image) and I could not boot any more to recover anything, only the 9.0 boot image was showing so I assumed an upgrade had happened.

 

After I returned to "single-boot" and injected the old kernel image into the backup everything worked again, also SMB.

 

A moment ago, because of your post, I performed another software update.

Of course you are right, the kernel image have been upgraded but the setup has stayed with 8.3.

Now everything works again with the new kernel in single-boot.

[WanWizard]

It doesn't look like it can be easily fixed, in that it can be adressed for images that are still being build ( I've proposed an updated postinst for the kernel package here: https://github.com/o...core/issues/877 ) but it can not be adressed for images already built.

 

Probably the best way would be to have something in the slot 0 image that could detect a boot with an incorrect kernel, and then forces a flash of the kexec kernel and reboot. That would address this issue at least as long as the slot 0 image still boots...

 

An alternative could be a repair image, which only contains the kexec kernel and no rootfs, which you can flash via USB.

[Qu@rk]

Thanks for the update.

I will stay with "single-boot" for the time being.

 

The recovery USB image without rootfs sounds intriguing.

It seems to be the most independent way.

But which kernel would it contain?

Different images use different kernels. You can have several images installed, all with a very different kernel.

 

So, a solution integrated into future images would therefore be safer.

 

That's a complicated topic and would require a lot of testing, I guess.

 

 

 

[WanWizard]

When you activate / install multiboot, a custom kernel is installed in flash. It boots, and then uses a linux kexec call to boot the secondary kernel for the selected slot.

 

So it is the custom kexec kernel, which is independent of any image used, and the same for all image makers.

 

And this is also the cause of the problem: the image build isn't aware of this custom kernel, so when the kernel-image package is (re)installed, it will overwrite the kernel in flash with the image kernel.

[Qu@rk]

That's a great explanation. Now I understand this mechanism much better.

You should put this into the Wiki. It would make this much clearer.

What a clever solution. That explains why the multi-boot procedure takes more time, it has to boot two kernels.

 

The USB recovery image would have to move the falsely flashed kernel to the right place in the slot and flash back the kexec kernel, right? Otherwise a kernel update within a slot would never work.

 

Or the slot image software updater would try to update/flash it again and again (maybe not, because the package manager thinks that the correct kernel had been installed). But how does the USB recovery image know which slot was active? Or would it always be the last active slot?

[WanWizard]

It is a workaround for the fact there is no source of the bootloader, which is where other multiboot capable boxes make the decision which kernel to load.

 

There are multiple actions to be taken:

• update the build recipe so that a kernel-image package is produced with a postinst that is multiboot aware ( I've posted a proposal in the OE-A issue ), for any image that is still being built.
  this will address the issue for all future software updates, images that are not build anymore will never have a kernel update in their feeds.
   
• provide an end-user friendly solution for when things go wrong, which for me is
  • an automatic mechanism in slot 0, which gets installed when you activate multiboot, and which can restore the kexec kernel if needed
  • a manual mechanism using USB that can restore the kexec kernel, with a custom "recovery" zip that can be downloaded by users.

It is not really needed to move the flashed kernel to its correct position, apart from the occasional Edision, no box has ever had a kernel update. Also, the first bullet will fix this problem.

 

There are two possible scenario's in which a new kernel image is built:

• a bitbake PR server is used and bitbake decides to bump the PR based on changes to the BSP
  this is what caused this particular issue for us, we had to change downloads as the VU+ code repository is down, which triggered a kernel rebuild
   
• no PR server is used (like OE-A), but the PR is bumped manually to force a rebuild
  which they didn't do for the download location change, but could happen for example when a kernel patch is added