So after you calm down you become rude again? You can clearly see how much troubles such features bring.
I’m actually thinking how to make this work in more general way but with such attitude I’m putting this on hold again. Why even bother …
I’m really sorry for my attitude. I was digging through s905x4 day and night and constantly flipping through CE and EE forums/discord to give support advice on stock CE/EE and my fork HE and saw the Unsupported SW section and misunderstood it was a big no from your side (I’m not a native English speaker and have never speaken to foreigners before these months, so my words in English might seem offending when I didn’t mean to). I just slept 3 hours last night so I was not thinking straight. After Portisch’s explanation I understood it’s for better warning for users
The trouble was actually not there if you are planning to use the firmware just as-is. But it was really my fault that I didn’t include an alter-way to first boot to CE so the layout will be 2-partitions instead of 3-partitions created by EE.
In more general way it could be done, and I have idea on how to achive it. But that needs some heavy modification of the bootup process, and many tests to ensure it does not break backward-compatibility
Then explain it and share ideas. Who knows what will future bring.
I was looking into this in the past to have dual boot of 2 CE systems. Like A/B for easier testing. The question is how many partitions would be used? 2, 3 or 4? With 4 it should be pretty easy to do.
The system partition can be shared, subfolders can be used to store kernel, squashfs image and dtb for alternative system when contents of the root folder can stay the same as how it is. A env var prefix can be set during startup according to other contents(other env var, file in system partition, or with user input got from gpio, etc) or by some easy userspace tools
Fatload supports loading contents from subfolders so this will work. By default prefix is or is set to empty and will load contents in the root folder. When selected other OS, kernel, system, dtb will be loaded from subfolser
Storage partition can be shared or dedicated, a dedicated condig file in system partition can be created for this. Read during init to update DISK to other contents other than default LABEL=STORAGE, the config file can have similar format like systemd-boot configs yet it only have to record disk= like root= for systemd-boot
So minimum at 2 and maximum at the partition table format(mbr/gpt)/u-boot can handle
Just as a side note, this is mentioned in the category description:
and also the home of community guided developments that can be PR’d to CoreELEC GitHub for official support
Wow, so this is a new category just added several hours ago? Thank you for your side-note.
So project-wise this will be achieved with multiple parts:
- A dedicated config file format should be defined, it can be json, xml, yaml, but simple key=value config is enough.
- Bootup script cfgload should be updated to support optional subfolder prefix. It always falls back to no-prefix boot directly from root folder for compatibility
- A helper tool/script that translate one of the above config file will be invoked by busybox/init. Its functionality is not included in busybox/init directly so merging upstream LibreELEC changes won’t become more tedious
- A section should be added in busybox/init that invokes the above helper to update certain bootup arguments. This is done during init, before sysroot mounted.
- A userspace tool with optional GUI should be added for managing multi-boot and switch between OSs. For implementation in kodi some easy python code is enough.
- A multi-platform converter that can convert any LibreELEC format update tarboll onto a valid subfolder onto the drive.
Yes, it’s new. As we’re adding new soc’s to the list and new devices are being supported we have to finally (not without a bit of sadness) move the EOL devices, CE based on Leia and other unsupported features to an own place. I think it will better highlight people efforts and will bring more support from the community.
In fact two days ago Amlogic-old device was brought back at EmuELEC. So with some effort I believe the community can also bring it back to CE.
This sounds very complicated which means lot of testing which means don’t expect anything like this to be included soon.
I think I will try to do something much easier without much overhead.
Will not happen. Not because it is not doable (I already have everything set) but because it is too much work to handle.
I didn’t expect you to include this, considering you are busy bringing support to s905x4 and a311d2 these days. I was planning to do all of these by myself. It’s doable in my sight even I can’t guarantee it’s achieved at anytime soon.
It’s not “just to be added or doable”, it need to be maintain and kept alive.
We already have to take alive 2 CE-branches, 2 Kodi branches, 1 kernel and 1 media-modules.
This will be increase again with 5.4 kernel to 3 Kodi branches (as Matrix will not be on 5.4), 2 kernel and 2 media-modules. So if the old kernel or Kodi Leia is coming back on new devices you can just multiply all by 2. It’s just not doable because of missing manpower. And all branches aren’t compatible, so each commit need to be checked and if needed adapted and tested again…
I didn’t say bringing back Amlogic-old is doable. I meant a generic multi-boot environment with my planned project structure for CE and all Amlogic CE-forks is doable. And I meant doable for me, not for Team CE. I’m doing all these for personal challenge and expect no help or manpower from any other.
About Amlogic-old, I meant community can try to bring it back (3.14 kernel + old media modules + Matrix) not that should be brought back by Team CE and kept alive. I helped fixing problems bringing Amlogic-old back in EE so I can see the possibility.
it’s doable for sure,
just as hint:
-> 3.14 | -> 4.9 | -> 5.4
GXXB -> GXL -> GXM -> G12B -> G12A -> SM1 -> SC2 -> S4 -> T7...
SC2 is almost done, since S4 it’s maybe only 5.4 kernel.
You see it does not make really sense to work on 5 generation old SoC when you just can buy a “cheap” new generation SoC. This will never pay off.
Yeah, just got a SC2 box for only 200CNY for myself for future-proof and it is way faster than my GXBB and GXL boxes. I’m happy with it and will use it as my main media box. But there’s always some “enthusiast” wanting to squeeze the last 1% performance and willing to pay tens of even hundres of hours to do so 
.
My tinkering with CE and EE actually starts with me digging through my old storage and happened to find a Xiaomi Mibox MDZ-16-AA (gxbb) that worths nothing yet I put almost a week to reverse-engineer all kinds of Xiaomi’s proprietary stuff and that ended up with a USB Bunring Tool flashable image for CE9.2.8+EE4.3 with full Xiaomi support and that is the base of the current generic Amlogic-ng HybridELEC.
I trying with your suggestions too, with gparted live, or my windiskmanager, deleted the full eeroms, than in the next install just resized and shrinked eeroms. With all method at the end, the results good until the first reboot. Than the emuelec not mount anymore my second usb drive with gameroms … Coreelec works good.
You can replace the aml_autoscript in the freshly burnt HybridELEC image with the following one, for first boot it will always boot into CoreELEC, thus the fs-resize will be done by CoreELEC, and thus the partition layout is 2 partition only: 2G system + a storage partition that fills the remaining space
The force-ee-first script and force-ce-first will be included in the next full image release of HybridELEC.
It was my fault that I didn’t include these scripts that can force you boot into any of the OS you like, and by doing so I force you to have a 3 partition EE-style layout.
aml_autoscript_ce_first (1.5 KB)
With this, you can just: flash the image, place the dtbs, replace the autoscript, and boot staright up to CE and have a 2 partition layout instead of the 3 partition one created by EE
As long as there’s EEROMS partition on the same drive EE is booting, it won’t mount that from other drives. You shrinked EEROMS instead of deleting it, so EEROMS is still there, and it will be mounted from the SAME drive instead of your second usb.
Sorry, not work. I made new install, CE installed first. Next install EE.
EE not mount my Second USB drive, not even if force mount.
Another usb installation, Single normal 4.5 EE, boot fine, and mount the external usb roms.There is EEROMS partition as well.
Is your EEROMS a fat32 fs? If not you need to copy ee_fstype fron the old installation under EMUELEC partition to HYBRIDELEC partitoon. The init process in EE will mount EEROMS with corresponding fs type recorded in this file. And maybe you’ve modified it yet forgot to migrate it?