592 replies to this topic

[littlesat]

I recommend not to spend time on it…

The basic thing as it is now it is fully transparant. Except now for the slot 0 with kexec. We should avoid exceptions and as it is now flashing slot 0 is not done. And in addition it is a full image. I see vix did something to the setup wizard to make the image in slot 0 less in size and let you install multiboot which is basically a good idea, but I prefer to have a simple recovery image with only the required stuff like most other system do have -or- do something which is transparent, stealthy so it does not have a special recovery slot from the user point of view.

Edited by littlesat, 14 June 2023 - 18:13.

[Dimitrij]

So, I conclude.

There will be no flashing slot 0 in openPli.

Edited by Dimitrij, 15 June 2023 - 05:20.

[littlesat]

My meaning is that this is the best for now. Better wait for a structured method where it can be done in a stealthy matter so for the user it behaves as a real slot (and we do not care what technically is made below it) -or- be patience and wait that there is a kind of real recovery slot that do not need flashing at all. Then for now having on slot 0 a kind of dummy image that performs like a kind of recovery image is for the time being the best we have. I prefer better to spend only time on something that is really good.

 

For having it in a stealthy way teams need to work together. It seems this does not work. So I prefer simply to wait...... 

 

Actually the work-a-round that Vix did with removing packages from the slot 0 may be also a good work-a-round. So when you initiate kexec that (you have the option) the current image in slot 0 is stripped and behaves as a recovery image. But I also think we should then also remove e.g. python and use a kind of binary. This takes a lot time so this might be also a good approach with the things we currently have. E.g. have the enigma2 binary, with just a few simple screens that arrange flashing/selecting a slot and all think that are not needed removed. But then maybe it is also better to get a kind of recovery image that do all for you at once.

 

What I consider is just call the slot 0 simply as a recovery slot (remove the zero).... (the same we do for the other multiboot systems)

 

There is much to discuss here to get things aligned. But it seems not everyone is 'on the boat'.

[Dimitrij]

 

Actually the work-a-round that Vix did with removing packages from the slot 0 may be also a good work-a-round

Who told you that this is a recovery slot only?

For example, I use it as the main slot with periodic software updates.

And the rest of the slots are like test ones with other images.

So why did you decide for everyone that we cannot flash it online? What is the reason for this decision?

Do you think that users are stupid enough to make decisions for them and deprive them of this opportunity?

A few lines of my code and this multiboot can not be touched at all, since everything works.

[littlesat]

Actually you are now getting to the real painpoint...

 

Slot 0 is a recovery slot and is also used as a backup mechanism when you insert a USB stick with a specific file on it on the USB. It contains also the directories that contain the other 'slots'. So it needs special handling and when you 'break' it you can lost all the other slots. I did not decide anything, I just mentioned the fact. So that is also why it is not recommendable to flash it online. And yes when it is an option, we are aware of it, but users will make the mistake as they do not know, lost slots or event think they brick their box (unless they can restore it with flashing via USB).

 

I recommend to put it on hold and sleep on it for a moment as I prefer a 'real' solution. Actually what VIX is trying to do, making it a real kind of recovery 'image' is the best option we have. From the first time the idea came up my feeling was I miss a recovery image, but it may take some time to get it done somehow.

 

A few line of codes can indeed arrange you can flash slot 0, but the code is full of exceptions we should try to avoid. And when the slot 0 is a real recovery thing instead of a full image with enigma2 functionality is what I think we should prefer. As longer I think about it making slot 0 a kind of normal slot for the user is for me more and more not a good approach. It always somehow 'breaks' the recovery 'mind of thing'.

Edited by littlesat, 15 June 2023 - 11:23.

[Persian Prince]

Actually you are now getting to the real painpoint...
 
Slot 0 is a recovery slot and is also used as a backup mechanism when you insert a USB stick with a specific file on it on the USB. It contains also the directories that contain the other 'slots'. So it needs special handling and when you 'break' it you can lost all the other slots. I did not decide anything, I just mentioned the fact. So that is also why it is not recommendable to flash it online. And yes when it is an option, we are aware of it, but users will make the mistake as they do not know, lost slots or event think they brick their box (unless they can restore it with flashing via USB).
 
I recommend to put it on hold and sleep on it for a moment as I prefer a 'real' solution. Actually what VIX is trying to do, making it a real kind of recovery 'image' is the best option we have. From the first time the idea came up my feeling was I miss a recovery image, but it may take some time to get it done somehow.
 
A few line of codes can indeed arrange you can flash slot 0, but the code is full of exceptions we should try to avoid. And when the slot 0 is a real recovery thing instead of a full image with enigma2 functionality is what I think we should prefer. As longer I think about it making slot 0 a kind of normal slot for the user is for me more and more not a good approach. It always somehow 'breaks' the recovery 'mind of thing'.

Just to let you know we have cmd images for all devices on https://images.openvision.dedyn.io for more than 2 years.

No enigma2
No GUI
No python (optional)
Less than half in size
OSCam pre-installed
Network only and command line

[babsy98]

in openATV the slot "R" image we call it root image like a normal image, why make it unusable, the user can make a full backup and FlashOnline,
with Flashonline root image will be reset and guest images in emmc will be deleted, but users know that with us. Image on USB slots are not lost by this.

we use this now for several weeks and no problems

[littlesat]

The image still needs a gui and users will know and make it flashable then also name it as a normal slot when I need a box without gui then maybe consider to get a rpi instead. It does not need oscam
It should not be unusable it should follow the function that it should do and then also you can have the option in that gui to backup all….

Edited by littlesat, 15 June 2023 - 18:59.

[rantanplan]

https://github.com/o...d6f2f9248d33ea9

for weeks?
https://github.com/O.../commits/master
https://github.com/B...mits/Python3.11

 

and everyone claims that everything has been going perfectly for months.
and everyone here is complaining about here some critical thoughts.

It's all a little strange.

[Ev0]

https://github.com/o...d6f2f9248d33ea9

for weeks?
https://github.com/O.../commits/master
https://github.com/B...mits/Python3.11

 

and everyone claims that everything has been going perfectly for months.
and everyone here is complaining about here some critical thoughts.

It's all a little strange.

Maybe some teams like to update things, make them better, change the way things work to make them easier to use, rather than do nothing and just talk about it for months.

[dpeddi]

https://github.com/o...d6f2f9248d33ea9

for weeks?
https://github.com/O.../commits/master
https://github.com/B...mits/Python3.11

 

and everyone claims that everything has been going perfectly for months.
and everyone here is complaining about here some critical thoughts.

It's all a little strange.

You complaint about the UI. The UI os pure phylosophy.

 

During these months have been added some functionality on enigma2.

 

..But the multiboot selector and the kexec multiboot kernel had no changes since february.

[rantanplan]

@Ev0

"Maybe"

But it is also possible that (as can also be seen from the commits), not everything works perfectly and errors are fixed.
Such commits are often called 'fix'.

So why is everyone pretending everything is perfect and making stress here all the time?

We can all read and see what happens.
It's a process that obviously keeps creating a few new problems.

This is not a judgement, just looking at your own git.
Why isn't this communicated factually?
Why is everything brought up so aggressively?

Every current fix from yesterday or the day before yesterday remains to be seen whether everything is really in order.

But your statement always comes
'Everything is great here... there have never been any problems...'

is that honest?

[Huevos]

@Ev0

"Maybe"

But it is also possible that (as can also be seen from the commits), not everything works perfectly and errors are fixed.
Such commits are often called 'fix'.

So why is everyone pretending everything is perfect and making stress here all the time?

We can all read and see what happens.
It's a process that obviously keeps creating a few new problems.

This is not a judgement, just looking at your own git.
Why isn't this communicated factually?
Why is everything brought up so aggressively?

Every current fix from yesterday or the day before yesterday remains to be seen whether everything is really in order.

But your statement always comes
'Everything is great here... there have never been any problems...'

is that honest?

So now we're not allowed to post to our repos? Everything is perfect and development should stop?

Instead of watching repos for minor tweaks you should reading the forums and seeing what real users have to say.

[babsy98]

the base has been working for weeks, then there were user requests that were implemented step by step, even there mistakes happen sometimes, which are then fixed.
The current user reports show that we are on the right track.

[littlesat]

It looks like every team is now creating their own work-a-rounds as it is simply not perfect as is, instead of define a real good solution.
The base is indeed perfect! Therefor I merged it. Therefor I also did not merge the latest merge request which is not an easy decision.

Edited by littlesat, 16 June 2023 - 06:32.

[babsy98]

you can also discuss everything to death, where openbh started with it, no one was interested in it, sometimes something has to emerge and mature, just sketch everything on the drawing board and then expect a solution to come out, honestly that would never have happened, I personally think it's ok as it is currently, but you can also improve everything later.

[twol]

When OpenViX/Openbh introduced multiboot for the Vu+4k boxes in February, we worked as a team (of 4 people) both in developing the code and suggesting changes...... which I think was the key element in this implementation.

So the initial implementation has evolved - not through fixing bugs but through a desire to make the solution as user practical as possible.
We responded also to suggestions/comments from outside the team (even Rantanplan), so that after USB flashing (or flashing Recovery) most initialisation is done in the Wizard setup, where a user can choose to keep the Vu+ standard image (note Rantanplan !) or choose the multiboot solution.

If multiboot is chosen and there is no slot 1 image, then that is created, images in slots 1 -> 3 (eMMC slots) are restored (if users have chosen the backup option before flashing) and the wizard reboots to slot 1.
Before exiting the wizard the Recovery image is stripped (reduced in size and functionality) and setup so that on re entry to the Recovery image an Image manager screen is shown so users can delete, download and flash images just like you would for example on the Zgemma Recovery image.

Rantanplan points out that there have issues
- well the OpenViX/Openbh main code has been stable since March, with the subsequent code move to the Wizard in the last few weeks(hence the noted changes).
- OpenATV have different requirements (use of BoxInfo and flashImage) so implementation of the multiboot code has taken longer, but they only started  implementation in mid April on ATV Captains return. 

Edited by twol, 16 June 2023 - 10:50.

[littlesat]

Before exiting the wizard the Recovery image is stripped (reduced in size and functionality) and setup so that on re entry to the Recovery image an Image manager screen is shown so users can delete, download and flash images just like you would for example on the Zgemma Recovery image.

 

I see you tricks are done via the Wizard and also tricks with the main menu of the box in case it is slot 0 and kexec is possible. Once kexec is activated it also removes some packages from the image in slot 0 trying to make the slot smaller....

Sounds like at you try to try to strip a current image to some kind of recovery image.

Why not directly create a 'stripped' recovery image instead?

Edited by littlesat, 16 June 2023 - 14:43.

[Abu Baniaz]

@Littlesat

How much space will we gain by having a dedicated recovery/"do not use" image?  Is it worth the effort creating such an image? Are the politics of permitted distros going to be ironed out? 

 

With regards to the primary/recovery image, some people say it is fine to use it in a kexec multiboot setup. The OBH team recommended not to use it, so that we have a failsafe (because there is no manufacturer provided recovery image). Surely everybody should buy into this? Flash it, forget about it unless you need it.

 

openpli develop vuduo4k
vuduo4k login: root
Last login: Fri Jun 16 16:39:22 BST 2023 on pts/0
root@vuduo4k:~# blkid
/dev/mmcblk0p4: UUID="6a1b2510-caa1-4394-a4c4-1a309c690fb5" BLOCK_SIZE="1024" TYPE="ext2" PARTLABEL="bp30" PARTUUID="b10645ff-02d1-4eaf-9e64-61bc03c1b951"
/dev/mmcblk0p5: UUID="50396705-5164-4cda-8821-842467901903" BLOCK_SIZE="1024" TYPE="ext2" PARTLABEL="bp31" PARTUUID="686caece-4b47-4c03-89b9-aae4aa7d3472"
/dev/mmcblk0p9: UUID="9ed520d2-66bb-460a-9fe3-6c1d38754dfb" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="rootfs" PARTUUID="084c4b4c-bfa2-47f5-b87c-0cf7edee47ad"
 
/dev/mmcblk0p1: PARTLABEL="nvram" PARTUUID="9ed99a2d-f5da-43d2-b567-99ea9b330a64"
/dev/mmcblk0p2: PARTLABEL="macadr" PARTUUID="c6e4ca6c-5cb0-4aa8-b307-a30f80a634ff"
/dev/mmcblk0p3: PARTLABEL="devtree" PARTUUID="edab0e5c-aee7-477c-bb91-cc0080ee6be4"
/dev/mmcblk0p6: PARTLABEL="kernel" PARTUUID="14ac548e-91b1-487a-8a34-6beb3ab1c3a1"
/dev/mmcblk0p7: PARTLABEL="initrd" PARTUUID="3210ecd8-45a2-4fc7-be28-e610de11c622"
/dev/mmcblk0p8: PARTLABEL="splash" PARTUUID="b1f8c57e-0ad7-43d5-899c-4f808a77bc2c"
root@vuduo4k:~#
root@vuduo4k:~# df -Th
Filesystem           Type            Size      Used Available Use% Mounted on
/dev/root            ext4            3.5G    243.9M      3.1G   7% /
devtmpfs             devtmpfs      269.1M      4.0K    269.1M   0% /dev
tmpfs                tmpfs          64.0K         0     64.0K   0% /media
tmpfs                tmpfs         277.2M    284.0K    277.0M   0% /run
tmpfs                tmpfs         277.2M    688.0K    276.6M   0% /var/volatile
 
root@vuduo4k:~#

 

The slots are directories on the internal flash. So even if we got to 50MB. Is the 200MB gained from the ~3.5GB of any significant benefit? Or are we asking for another directory/slot?

[Huevos]

 

I didn't say that was the sole reason. We inspected the PLi image and know where the size differences are.

 

 

 your statement that an image will be 30mb larger because of a python update to 3.11 is not correct.

 

 

Just the python 3.11 folder is 47 MB and that is without the including enigma differences. Try it yourself if you doubt.

root@dual:/usr/lib# du -sk *|sort -n |tail -n 10
3100    libsmbd-base-samba4.so
3356    libpython3.11.so.1.0
3376    libavfilter.so.9.3.100
3776    libndr-standard.so.0.0.1
5820    gstreamer-1.0
5828    locale
8812    libHA.AUDIO.FFMPEG_WMAPRO.decode.so
10188   libavcodec.so.60.3.100
24304   enigma2
47560   python3.11
root@dual:/usr/lib#