592 replies to this topic

[Abu Baniaz]

Also, if somebody was to use the partioning tool by the PKT (I think) where the internal flash memory is partitioned like the other receivers with hardware multiboot, would that also work with this implementation of multiboot? Obviously leaves the bootloader as an issue.

[Mr.Yoshi!]

The easiest way is to flash bp image neutrino with the file for multiboot and then by ofgwrite into the other partitions, so you have all 4! back to 1 it goes again! but I have no vu that knows best bpanther! neutrino has that with uuid but not with vu !

p.s. from time to time a box branding is very useful in a few images!

pkt is no longer freely accessible, unfortunately, which I find cheeky as with egami! I could ask for a donation for my pictures, but I won't do that because it's inhuman! Best wishes kittybua Yoshi

https://forum.mbreme...opic.php?t=2903

[Huevos]

If I understand the E2 PR correctly, the images are stored in directories of that "base" image, in the only partition the VU+ emmc has, together with STARTUP information in the root of that partition.

 

Because it is a full image, it makes all that visible and accessable for end-users, which is imho a massive downside of this solution. An "it should not be used" warning doesn't stop any end user.

 

Ideally, we should make a minimal bootable image (as a sort-of recovery image), which only gives the option to either boot a slot, or flash a slot), and install that as the base image.

That is Ev0's opinion. Using the base image does not cause any problems. It is an everyday image. I personally use it without multiboot activated. Creating a short image is just over complicating a very simple solution. So I'll say again, there is no prerequisite not to use the base image.

Edited by Huevos, 26 March 2023 - 10:11.

[Matrix10]

I also use the so-called recovery image

I see no reason not to use it

except that I would have to install everything again in case of a fatal crash.

But that doesn't happen to me often, maybe once or twice a year. 

[Huevos]

 

except that I would have to install everything again in case of a fatal crash.. 

 

Just make a decent backup. Then it is just a case of flash and restore.

[littlesat]

Still the if box x then do y is on the wrong location in the code. The only location were it can be allowed is SystemInfo.py…. There the canmultiboot system key should get the correct values and then nothing needs to be changed elsewhere…. Tell me when I miss something
It is indeed an easy patch/merge request but it should be discussed to get it in the right structural way. Just it works is not enough. It should be done eight in the best structural way.
That there is no recovery image is due to vu+ did not create it….
Multiboot is for me easy as I can experience and test stuff and go easily back to something that is stable…

Edited by littlesat, 26 March 2023 - 14:02.

[neo]

The patch as it stands should not be merged imho, as I agree the "canMultiboot" and also the list of devices should go into SystemInfo.

 

And I understand people here use the base image, I would do too. But we all have the skills. OpenPLi is mainly an end-user image, and those users don't. So we have to take that into account.

 

Issues I see is that the entire multi boot structure is open for access to end-users (a cifs mount to "root" would do it) and possibly abuse, and a "no more space on device" is a serious risk even with 3 slots, and when it happens, all slots are "dead".

[Huevos]

Can you please explain what you are all talking about? "canMultiboot" is there in Multiboot.py after the patch exactly as before.

 

This thread is crazy. First it starts with every reason why multiboot is not needed when OpenPLi already has multiboot and then it progresses into a fault finding mission into the patch. If you guys don't like the patch, write a better one. I'm sure in the time it has taken to fill 6 pages of this thread someone could have already rewritten the patch how they want it. And if you don't like the feature just don't bother with it and let users that want it migrate to other images that do have it (after all Vu+ users have been waiting more than 10 years for this).

Edited by Huevos, 26 March 2023 - 15:29.

[littlesat]

I did again look at the code and actually a new feature is added to it for multiboot the kexec method.

it has a different ‘bootlist’ and these are in the patch globals. I prefer to do in the code a simple check in kexec, give the list the partitions and at else the older original values and avoid these lists are globals. Just put them lower in the code. This is the stuff that hocked me. Inwas thinking these were listen in the systeminfo can multiboot… my mistake.

 

 

actually the location where it is done is the good location.

And do not call it kexec vu+ Receiver in the remarks…. Just when you make a remark call it kexec method and remark at the standard e.g. recovery image method.
This method might also be possible for other hardware that does not support the ‘recovery image’ method….

 

and there is somewhere a tab instead of a space in an if uuid line.

 

I hope somewhere tomorrow I can highlight what I exactly mean.

Edited by littlesat, 26 March 2023 - 15:23.

[littlesat]

if fileHas("/proc/cmdline", "kexec=1"):
    bootlist = …bootlist for kexec stuff…
else:
    bootlist = …bootlist for recovery image stuff…

so do not use globals…. And then the list is also close to where it is used which makes it more readable

sorry I did not list the partitions as on an iPhone it is difficult to edit

Edited by littlesat, 26 March 2023 - 15:27.

[Dimitrij]

https://github.com/O...sKexecMultiboot

[littlesat]

Dimitrij this is excellent!!! But in about just remove vu+ maybe later this kind of multiboot can also be used for more hardware.

[littlesat]

Merged and small adjustments to it were made...

Now we need to wait for the update of the bsp....

[Taapat]

Please fix import order: https://github.com/O...902#step:10:119
getMultibootStartupDevice method is imported before hasKexec is set.

Edited by Taapat, 27 March 2023 - 12:55.

[littlesat]

Thanks for the report, reverted (for now).

Please fix import order: https://github.com/O...902#step:10:119

getMultibootStartupDevice method is imported before hasKexec is set.

Edited by littlesat, 27 March 2023 - 13:04.

[Huevos]

Why did someone fiddle around with the patch and then not test?

[Dimitrij]

Why did someone fiddle around with the patch and then not test?

Anything happens.

[littlesat]

Anything happens.

 

Maybe because I was not near a box....  and prefer not to forget to perform the finetuning.... It was indeed true the last patch with SystemInfo became untested...

Edited by littlesat, 27 March 2023 - 15:38.

[Guest-*0823016*]

I'm sorry to say but you're talking about nothing... the multibot... USELESS thing.

krime mobile

[Huevos]

I'm sorry to say but you're talking about nothing... the multibot... USELESS thing.

krime mobile

Please explain.