Im trying to install CE version CoreELEC-Amlogic-ng.arm-19.5-Matrix_nightly_20221103-Generic.img to eMMC. I tries using the ce tool first of all and that didnt work. I then tried the way ive done it before. Here are the results.
CoreELEC:~ # blkid
/dev/mmcblk1p1: SEC_TYPE=“msdos” LABEL_FATBOOT=“COREELEC” LABEL=“COREELEC” UUID= “0311-3304” BLOCK_SIZE=“512” TYPE=“vfat” PARTUUID=“56690862-01”
/dev/mmcblk1p2: LABEL=“STORAGE” UUID=“1277c2b4-b108-4d31-8a26-e3e6e67e4c24” BLOC K_SIZE=“1024” TYPE=“ext4” PARTUUID=“56690862-02”
/dev/param: UUID=“29e0beec-0842-4e9a-82cb-98f024ac4564” BLOCK_SIZE=“4096” TYPE=" ext4"
/dev/tee: UUID=“0e5cc07f-9303-46db-a546-840a812fac70” BLOCK_SIZE=“4096” TYPE=“ex t4”
/dev/metadata: UUID=“62f5b496-7c8e-45ef-8b59-db1da0fff8f8” BLOCK_SIZE=“4096” TYP E=“ext4”
/dev/factory: SEC_TYPE=“msdos” LABEL_FATBOOT=“KEYBOX PART” LABEL=“KEYBOX PART” U UID=“D0A6-62DE” BLOCK_SIZE=“512” TYPE=“vfat”
/dev/loop0: TYPE=“squashfs”
CoreELEC:~ # ^C
CoreELEC:~ # e2label /dev/mmcblk1p2 “”
CoreELEC:~ # e2label /dev/data “STORAGE”
e2label: No such file or directory while trying to open /dev/data
Couldn’t find valid filesystem superblock.
We’re currently working on ceemmc and we can expect some results in the short term. @7Ji , I think your work is very admirable and it’s a shame your actions aren’t on the same level.
You see this post above is exactly the point of your attitude.
Your PR was closed because you just didn’t understand that such tool can’t be replaced over night. Ceemmc tool was/is used by number of different devices and it work. Sure not on newer devices because other things has higher priorities.
And what is your point of ceemmc being only in binary form? It is the choice of the author. Not sure why you bring this up.
So, please calm down because cooperative work is not possible with such tone of yours.
I get that i cant use the cemmc tool, but what your saying is that there is also no current way of installing to emmc without jumping through hoops.
As in i can’t just:
What I am saying is that installing CoreELEC to eMMC on SoC S905X4 via our recommended and supported method (ceemmc) is currently unavailable. Nothing more, nothing less.
EPT report: 29 partitions in the table:
===================================================================================
ID| name | offset|( human)| size|( human)| masks
-----------------------------------------------------------------------------------
...
28: userdata bcc00000 ( 2.95G) 68b000000 ( 26.17G) 4
===================================================================================
But your method still wouldn’t work even if you replace data with userdata, because the ext4 fs on the last partition (userdata) is created on a newer kernel and can’t be safely read by CE’s kernel (at least in -ng image, I didn’t test -ne image). So you’ll probably also need to create an ext4 fs on that partition in CE with mke2fs manually.
At least that is not the case for HK1, the Amlogic 4.9 kernel fails to mount it becauses of the features introduced in later kernel, not because of encrytion. No luks, no lvm, no any device mapper, just a plain ext4 fs. And ext4 does not support fs-level encryption anyway, it can only do file-level encryption.
$ dd if=x4_emmc.img of=x4_userdata.img bs=1M skip=3020
$ file x4_userdata.img
x4_userdata.img: Linux rev 1.0 ext4 filesystem data, UUID=1390e8bf-4138-4a38-b0eb-ad6c1373f7c2 (needs journal recovery) (extents) (large files) (huge files)
$ sudo losetup -f x4_userdata.img
$ sudo mount -o ro /dev/loop2 /mnt
$ ls /mnt
adb app-asec app-staging dalvik-cache incremental mediadrm nfc preloads rollback-observer system_ce user_de
anr app-ephemeral backup data local misc ota property server_configurable_flags system_de vendor
apex app-lib bootchart drm lost+found misc_ce ota_package resource-cache ss tombstones vendor_ce
app app-private cache gsi media misc_de per_boot rollback system user vendor_de
$ tune2fs -l x4_userdata.img
tune2fs 1.46.5 (30-Dec-2021)
Filesystem volume name: <none>
Last mounted on: /data
Filesystem UUID: 1390e8bf-4138-4a38-b0eb-ad6c1373f7c2
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype extent casefold sparse_super large_file huge_file uninit_bg dir_nlink extra_isize verity
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1715280
Block count: 6860796
Reserved block count: 8192
Free blocks: 6172187
Free inodes: 1695598
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8168
Inode blocks per group: 1021
Filesystem created: Thu Jul 28 20:24:41 2022
Last mount time: Thu Jan 1 08:00:06 1970
Last write time: Thu Jan 1 08:00:06 1970
Mount count: 11
Maximum mount count: -1
Last checked: Tue Aug 16 18:37:21 2022
Check interval: 0 (<none>)
Lifetime writes: 7483 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 1065 (group unknown)
First inode: 11
Inode size: 512
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 46591f2e-2b39-4373-b81c-2201980896f4
Journal backup: inode blocks
Character encoding: utf8-12.1
Sorry for all dramas and other possible impact in the community caused by my childish move these days. I’ve removed all previous mentions and possible misleading infos posted here and on Github, and am willing to remove other controversial infos if I forgot them.
I’m absolutely sorry for them and would do best of what I can (mostly experience in my work on ampart) to help inproving ceemmc and other aspects on CoreELEC, to hopefully make up for the damage I’ve caused
