I’ve reproduced the same issue in official EE image when EEROMS does not exist on bootup drive, so this is an issue always existing in EE, not introduced by HybridELEC.
It’s just that since official EE will always create a dedicated EEROMS so this was never found (unless you’re using a 4G drive, I made a PR last month to fix fs-resize issue on 4G drives that’ll omit EEROMS partition on them). I’ll open a PR to fix this in upstream EE hopefully before v4.6 come out.
A temporary workaround of this is:
rename your roms partition to EEROMS
move everything in roms folder except the file emuelecroms to root, so you would see nes, n64, etc directly in the EEROMS partition
create a file ee_fstype under HYBRIDELEC and write the fs type of EEROMS in it (judging by your partition name it should be exfat, since fat32 can only have uppercase names, valid options are: ntfs, ext4, exfat, vfat. in which vfat is for fat12, fat16 and fat32)
Rename “Samsung USB” to “EEROMS” (you can rename a drive/partition just like how you renane folders in Windows 10), and put your roms outside of the roms folder
Previously there was only a roms folder in the root of your usb drive, now there should be nes, snes, n64, etc all these folders lying in the root of your usb drive
Now works.
Mount when the usb drive EEROMS formatted to fat32. Hybridelec, not mounted for me when usb rom drive was formatted NTFS.
Original was ntfs. Now mount all two system, but when load the ee after bootup , freeze for 30 sec.
When there was ntfs formatted rom drive, the original EE mounted and not freeze, yet that freeze as well…
Now tryintg format exfat…
The suggested fs for external roms drive is: (ext4>)exfat>fat32>ntfs, you’re not using Linux day-to-day so ext4 is out of the question.
The problem with ntfs is that support of it is not built into the Linux kernel, and a userspace driver (ntfs-3g + fuse) must be loaded for it to be used.
Previously you didn’t use it as EEROMS, but a simple external roms drive, so it was loaded after initial bootup, at that time userspace is already up and running, so loading ntfs support is not that noticeable as EE can do this in background.
But now since we’re using this drive as EEROMS as a workaround, and EEROMS must be mounted during system initial bootup, and all inital bootup work must be done one by one, loading ntfs support will seem to freeze your system
For pendrive there’s really no point of using NTFS, it’s journal FS that’ll write a lot ton more data that you dont need, which will burnout the drive more quickly than you want. If you want big file support, then exfat is enough. It is the default fs most sd card and pen drive come with, and Nintendo Switch use it as the fs for sd card, so you can trust it
Edit: official EE doesn’t seem to freeze because it has an EEROMS partition on the same drive, so EEROMS will be mounted from there, mostly fat32. If you remove it and let it mount a nfts
EEROMS from another drive it will also freeze
Ok, I forget this method, because not work on both system. I have copyed my rooms to my nas, and made nfs mount for all folder. This method work good, with both Hibrid an Original Emuelec. Thank for your support
This Hybrid system sounds great!!
I have been using the EmuELEC addon for like two years with CoreELEC 18 and 19, but this project is nice, you can have both worlds at the same time.
Unfortunatelly I can´t boot your system
It boots up, installs EmuELEC, but when it reboots for the first start it says
[FAILED] Failed to start Generate system-wide /etc/environment file.
If I use the amlautoscript you have uploaded to start CoreELEC first (thats what I want), then EmuELEC installs, and I can even see the first EmuELEC introduction video, but after the video I only have a black screen.
If have some idea how to solve this problem it would be great.
My device is a Sunvell T95m S905X 2gb ram, and I have instaled standalone EmuELEC 4.5 and CoreELEC without problems
That shouldn’t be. Did you hold the reset button before the startup? And the script needs to be replaced after your burn the image, before the first boot. It should 100% boot you into CE for the first boot if the bootup process is correct, but will not work afterwards to avoid breaking the dual-boot (otherwise you’ll be locked in CE, unable to use EE)
Did you use the correct dtb for both system? There should be two dtbs, ce_dtb.img and ee_dtb.img, one for each system, not dtb.img, not inter-changable. The blackscreen could be caused by wrong dtb. Check the wiki about the installation:
Forget it, my fault. I have just downloaded the last EmuELEC 4.5 and it is doing the same, same error at boot, I have been trying different versions and the newer version booting is the 4.3 one with minor audio problems
So first I´m going to check how to install 4.5 in my S905X T95m, because it is supposed to be compatible
Issues fixed as we discussed on EmuELEC forum, but I’ll add some notes here for future readers:
The current kernel used in both Amlogic-ng images from CoreELEC and EmuELEC are 4.9 kernels from Amlogic with modifications done by team CoreELEC
The u-boot on Android TV boxes with Amlogic SoCs is only compatible with close kernels as Amlogic’s kernel image contains their special sauce that needs a newer or equal u-boot to actaully load
Even though both 4.9, the one used in EE 4.3 is actually 4.9.113, from a vendor (Khadas or hardkernel) with their modifications on top of Amlogic’s modifications, also used in several post-19 CE images. This kernel is new but not new enough that the u-boot on some Android 6 boxes like yours could load.
After a certain time (before EE4.4) team CE switched to a much newer kernel (for now it’s 4.9.269) from Amlogic directly, adding support from ground up instead of from vendor kernels, this kernel is newer enough that the u-boot on Android 6 boxes can not load it anymore. It needs the u-boot bundled with >7.1 Android boxes to be loaded
Anyway, as I suggested and both CE and EE wiki wrote, upgrade your Android firmware to >7.1 before using Amlogic-ng images
Edit: if you have any issue regarding the triple boot image, please open an issue on my project page instead of continuing it in this topic. This topic is only for the USB/SD dual-boot image
No, any file that ends with .xz must be decompressed first, either with xz, 7z or any other decompressor you’re familiar with.
That triple boot image is not covered in this topic and I don’t want the topic to be hijacked even it is also available under the project name HybridELEC because I’m lazy to come up with new project names. But I’ll simply describe how it is a triple boot image:
The tiple-boot image provided in HybridELEC’s android-burning branch is in the same format of an Android burning image, it should be flashed with Amlogic’s official USB Bunring Tool to write to the box’s internal memory, and will erase everything on there just like a stock Android image. It is specially prepared to trick Amlogic’s tool and the box to make them think it is an Android image (but actually not). So you will have unmodified Android, unmodified CoreELEC and unmodifed EmuELEC all on eMMC, achieved with one single image.
Again if you want to discuss the triple boot image, open an issue on my project page instead of continuing the discuss here, this topic is for the USB/SD dual-boot image and nothing else!
If you’re on Windows, right click the file and choose decompress with 7z. It could decompress almost all types of file (hey even exe!) with this method.
Then maybe your memory is not enough, I’ve compressed these images with the highest possible compression ratio to save my bandwidth since it’s slow and painful to upload things to Github for me. The expected free RAM needed to decompress it is 3842MiB. I just decompressed that on my Windows10 PC with 7z without problem.
