Related
During my time hacking on android I've discovered some nice easter eggs deep in the android platform. One such easter egg is the mounting of ext4 images directly in the init.rc script. This is a feature I have never seen used by any oems and only by one custom rom [ EDIT: and by letama in his Sony Xperia Boot Manager ]! looking at the git logs this functionality has been present since September 2010 [ commit 49b8124a1759cb8b27e0c21a1a5a54b8a81bdb19 ]. What this effectively gives us is the ability to overlay a pseudo partition layout over the top over the existing layout, thus avoiding any "Danger" of accidental bricking the device by reformatting the SDCard. This is very similar to the way archos mount the stock file system and a variation/extension on the existing methods we use for the SDE Roms.
Although the explanation assumes the use of the SD models it should be fairly straightforward to apply the the HDD models.
THE METHOD:
PART 1 - Prepare a recovery ext4 image file
1. Build CWM6 from the CM10 source.
2. Modify The Recovery's init.rc file to look something similar to this
Code:
on early-init
start ueventd
on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
mkdir /boot
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mount /tmp /tmp tmpfs
mkdir /partitions 0771 system system
mount ext4 /dev/block/mmcblk0p4 /partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount ext4 [email protected]/partitions/CAC /cache nosuid nodev
mount ext4 [email protected]/partitions/DATA /data nosuid nodev
mount ext4 [email protected]/partitions/SYS /system
mount ext4 [email protected]/partitions/SDCARD /sdcard nosuid nodev
mount ext4 [email protected]/partitions/BOOT /boot
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
# Always start adbd on userdebug and eng builds
# In recovery, always run adbd as root.
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
#write /sys/class/android_usb/android0/enable 1
write /sys/class/android_usb/android0/iManufacturer $ro.product.manufacturer
write /sys/class/android_usb/android0/iProduct $ro.product.model
write /sys/class/android_usb/android0/iSerial A101S_REC
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
3. Modify the etc/recovery.fstab to look like this
Code:
# mount point fstype device
/cache ext4 /dev/block/loop1
/data ext4 /dev/block/loop2
/system ext4 /dev/block/loop3
/sdcard ext4 /dev/block/loop4
4. Creating an empty ext4 image file name REC and mount it on your pc. [ 5MB should do it ]
5. Copy the contents of the built recovery/root directory to the root of your mounted image.
6. chmod init.rc , default.prop and ueventd.rc to 644 ( rw-r-r- )
7. umount the ext4 image and push it to the root of you data partition
That's stage 1 complete. Part 2 Will Follow Shortly.....
Part 2 - Make a dual boot initramfs.cpio.lzo
1. Change the name of the /data directory to /bootdata by modifying the etc/mountpoints file in the initramfs.cpio.lzo. This stops CWM getting confused when trying to un/mount the data partition
Code:
mount_name mount_dev mount_point mount_fs mount_opts volume_name error_code custom_opt
rawfs /dev/mmcblk0p1 /mnt/rawfs rawfs none 150
system /dev/mmcblk0p2 /mnt/system ext4 rw,noatime,noexec system 152
bootdata /dev/mmcblk0p4 /bootdata ext4 rw,noatime,noexec bootdata 154 crypt_compat
storage /dev/mmcblk1p1 /mnt/storage ext4 rw,noatime #storage_name# 155
storage_A80S /bootdata/media /mnt/storage bind bootdata none 155
storage_A101S /bootdata/media /mnt/storage bind bootdata none 155
storage_A101XS /bootdata/media /mnt/storage bind bootdata none 155
storage_LUDO /bootdata/media /mnt/storage bind bootdata none 155
storage_A80H /dev/hdd1 /mnt/storage ext4 rw,noatime #storage_name# 155
storage_A101H /dev/hdd1 /mnt/storage ext4 rw,noatime #storage_name# 155
usbhost_ehci /dev/storage_ehci1 /mnt/usbhost_ehci vfat rw,noatime,utf8,shortname=mixed none 156
usbhost_otg /dev/storage_otg1 /mnt/usbhost_otg vfat rw,noatime,utf8,shortname=mixed none 156
rfsext4 /dev/loop0 /new-root ext4 rw,noatime none 157
rfsext3 /dev/loop0 /new-root ext3 rw,noatime none 157
rootfs /dev/loop0 /new-root squashfs ro,cts_compat none 157
ramdisk /tmp/ramdisk /ramdisk vfat loop,rw,utf8,shortname=mixed #ramdisk_name# 158 ramdisk,ramdisk_size=256
2. Using sirduke989 dmenu initramfs you can modify the init script in the initramfs to mount /bootdata instead of /data and also add /bootdata/REC and /bootdata/BOOT to the list
of known locations , I see this a temporary measure as there are a number of other ways to enable dual ( Triple?!? ) booting
3. Flash the modified initramfs and your choice of kernel using either the recovery menu or kd_flasher, I used the 3.0.21 kernel extracted from the 4.0.24 aos file.
You should now be able to boot into CWM Recovery!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Clearly I'm a developer not a photographer!!
Part 3 - Create rest of the "partition" images.
You should have a /partitions directory in you device root, This is what is normally mounted as your /data ( /dev/block/mmcblk0p4) and contains normal android user data e.g installed app settings databases etc. This is where I've created the reset of my Partitions which are just more ext4 images files. I did this using "dd if=/dev/zero ...." and "mke2fs -text4 ...." on the device through adb whilst booted into CWM. This saved time in pushing large empty ext4 files from my pc.
I called my image CAC ( cache ) DATA ( data ) SYS ( system ) SDCARD ( sdcard ) BOOT ( boot ) you can obviously call them what you like and place them anywhere as long as you match up the image names with those in init.rc and make sure the loop numbers are correct in the etc/recovery.fstab everything should be fine.
You can play around with the files sizes, I have an 8gb my current file sizes at the moment are
BOOT = 25MB
CAC = 500MB
DATA = 3GB
SYS = 500MB
SDCARD = 2GB
The sdcard mount point is probably worth pointing at an external sd if you have one available. I have a 32GB Class 10 that I'll probably set up.
After you've setup your psuedo partitions you should then be able to reboot into recovery, if you've done things correctly you mount output should contain the following
Code:
/dev/block/mmcblk0p4 on /partitions type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop1 on /cache type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop2 on /data type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop3 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop4 on /sdcard type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop5 on /boot type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
Everything seems to function correctly, I have successful done a backup and restore of my system partition. I have also applied CWM-SuperSU.zip through install zip from sdcard. Mounting and Remounting works although I'm not sure if Mount USB Storage works yet, I didn't on linux and I've not tested on windows and finally wiping and formating was also successful.
Part 4 - Notes on setting up rom images.
Now you may of already realized normal archos images don't come as separate the /boot and /system images so work is require to split them up.
Also if you want to split the /system from the reset of a archos image your boot partition will need to be about 50MB as archos have they /bin /lib /usr directories which contains binary files that use /lib/libuClibc-*.so as it's libc which brings there root filesystem in at around 38MB.
There is a very strong case for ditching these binaries especially when using AOSP/CM based roms. My intial tests show this is possible.
Just like the recovery init.rc Similar changes have to be made to the roms init.rc
Moving Forward:
of course, there's a lot to do but I wanted to at least get this initial information out there for people to consider. I'm currently booting a Linaro 4.1.1 rom using the split partitions. I have also been working on better booting methods which is why I haven't given any details re the initramfs init script but It's fairly straight forward to adjust and adapt. I'll write up more details soon!
More Research!
As I mentioned, I've been further looking into different booting methods and I think I'm approaching what could be a workable solution that will make the Gen9 more like standard android devices
Here's some more of my findings
1. It turns out that we can dump the existing initramfs.cpio.lzo and we can use a standard android ramdisk layout as the android init will load instead of the init script that is currently being used, this also removes the need for switch root and other nonsense that archos have in there. There was one gotcha when had me stumped for about ten minutes, I needed to add "write /sys/class/leds/lcd-backlight/brightness 75" to the init.rc to turn the screen on.
2. It's possible to stop android either using adb shell stop or stopping each service zygote etc, and start CWM while android is booted. It's probably also feasible the manage booting between recovery and android using the persist properties system which should make switching between the 2 fairly easy to control without much tweaking to any binaries. Looking at other devices, namely samsung, they seem to do something similar with recovery being in the same boot.img as the standard files, they simply load a recovery.rc instead of the main init.rc, this might mean that we have to patch CWM to load the correct init.rc I've not looked at the code properly yet but It's not going to be an issue anyway as all the code is fully available, You've gotta love open source.
3. By mounting /dev/block/mmcblk0p1 to /mnt/rawfs we are still able to use abcbox, reboot_into writes to the params file in the partition to control boot switching, so we can maintain booting into sde while leaving the stock android partition in place. I was unable to get any immediate joy from kd_flasher, that maybe because we currently have the ramdisk we want to overwrite mounted as the rootfs. Again I can't imagine it being too difficult to jig this, It can probably be worked out by looking at the current recovery ramdisk scripts should kd_flasher style functionality be required at any point.
4. Most of the binaries that rely on uClibc can be recompiled against bionic without any issue, usb_modeswitch for example. If there are any closed source ones, then the dynamic linker ld-uclibc or whatever is called, ultimately symlinks back to uClibc and we can just grab the one file and place it in the /lib directory. I tested /usr/bin/lsdvd in this way and It seemed to work fine.
I've got all this going on while still leaving a stock android fully intact, which is a great fallback Just in case.... Keeping these modifications at a safe level is one of the primary goals to enable much wider use
I'll put together some examples within the next couple of days to demostrate what I'm talking about here.
I've got a Linaro 4.1.1 ( JRO03R ) which has working powervr drivers with a 3.0.21 kernel, although that's about all that's working on it at the minute.
It's more a proof of concept than anything else, The kernel would need recompiling to add tracefs functionality which is required by jellybean but using the same magic should leave the powervr drivers functioning still, If anyone's interested I can stick that up, I've foolishly deleted ( misplaced/can't remember ) the device files I used to build this.... Too many android source trees and not using git properly leads to school boy errors.
I'm currently working on an omapzoom 4.1.2 tree using the blaze_tablet device as a base, I think this may yield the best results for the archos.
I suppose one other thing to do is the fix up a stock rom to use these methods and give it CWM, that should be pretty simple to do. Although ICS is ooold and I'm really not a fan of some of archos' methods e.g booting 4 different devices off one firmware. Although to their credit they do demostrate just what possible with deviating android from it's normal standard structures.
Hopefully this has whetted your appetites, I'm pretty excited about what's possible here as I feel it brings these archos devices in line with most others.
Me Again!
Just a cheeky little update, I been trying the figure out the best approach to handle switching between android and recovery mode. In effect I kind of wanted to create a Stage 4 bootloader! because you can never have too many bootloaders LOL I certainly wanted to do a "proper" job on it and try to avoid changes to the android platform code.
While to doing research into this I found this patch to the linux kernel which the android team submitted for review, Reading the mailing list thread I don't think it's been accepted yet! It's true what they say about the Kernel Mailing List, You need to bring your A game and be sure of what your doing..
Anyways the patch add a boot-control-block driver to kernel which check for a boot flag, which is exactly what I need to make booting into alternative configuration nice and simple. I suppose it wouldn't be too difficult to chuck in support for the fastboot protocol on one of those configurations. So a CWM Shouldn't be too far off now!!!
As a little treat I've attached a recovery based ram disk if anyone what's to play, just flash it with you favourite kernel on to your sde partition. Then You can boot into recovery and set your self up a pseudo partition image layout through adb. You won't be able to be into android, obviously until you put your old initramfs back.......
This is totally unsupported.
Click to expand...
Click to collapse
I'm just chucking up for those who want to get a feel for to do so. If your uncomfortable playing around in this area then stand well back, It's not prime time yet!!!!
However Feel free to ask questions of a technical bent but If you can't get it to boot then tough luck I'm afraid for now! :laugh:
You shouldn't be able to do any damage with this be I wouldn't go selecting wipe/format etc until you've got some partition images sorted.
I've add abcbox to sbin and symlink reboot_into. It does not seem to fully reboot but It will set the boot flag which you then follow with a call to reboot, That will reboot back into CWM (sde).
Onward
EDIT: Here's the Init.rc and etc/recovery.fstab that It attempts to use.
Code:
on early-init
start ueventd
on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
mkdir /boot
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mkdir /mnt
mkdir /mnt/rawfs
mount /tmp /tmp tmpfs
mkdir /partitions 0771 system system
mount ext4 /dev/block/mmcblk0p4 /partitions
mount rawfs /dev/block/mmcblk0p1 /mnt/rawfs
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount ext4 [email protected]/partitions/CAC /cache nosuid nodev
mount ext4 [email protected]/partitions/DATA /data nosuid nodev
mount ext4 [email protected]/partitions/SYS /system
mount ext4 [email protected]/partitions/SDCARD /sdcard nosuid nodev
mount ext4 [email protected]/partitions/BOOT /boot
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
# Always start adbd on userdebug and eng builds
# In recovery, always run adbd as root.
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
#write /sys/class/android_usb/android0/enable 1
write /sys/class/android_usb/android0/iManufacturer $ro.product.manufacturer
write /sys/class/android_usb/android0/iProduct $ro.product.model
write /sys/class/android_usb/android0/iSerial A101S_REC
write /sys/class/leds/lcd-backlight/brightness 75
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
Recovery.fstab
Code:
# mount point fstype device
/cache ext4 /dev/block/loop0
/data ext4 /dev/block/loop1
/system ext4 /dev/block/loop2
/sdcard ext4 /dev/block/loop3
Any words about hdd versions?
DragosP2010 said:
Any words about hdd versions?
Click to expand...
Click to collapse
I all depends how you want the structure it, What it would change is the mount point of the paritions directory. After that. everything is loop mounted and sitting on top of the existing structure.
Code:
mount ext4 /dev/block/mmcblk0p4 /partitions
Great stuff!!!!
Hey trevd,
that's fantastic... i will definitely try this CWM in a few days with my custom kernel and bootloader (mountpoint will need some tweaks as well ).
I'm very busy these days, so i gess i'll leave some longer statements to the recent developments in a few days.
Just in short... it's very pleasant to see all these open developments popping up and i really, really appreciate this kind of hacking!
Keep on your great work... you rock!!
Cheers,
scholbert
Hi Trevd,
Nice job!
I've been using the same kind of trick on my Xperia S boot manager project, recovery on loops and mount [email protected] in inits. You may want to take a look at what I did there (see my sig), it may have some use for your project.
Basically, what I do is storing multiple kernels+cpios on the regular kernel partition. I use one (trimmed down to maximize space) to handle the boot logic and cwm, and I have enough space to handle two "regular" kernels. I handle kernel switch just before they load with a small assembly loader. It works very nicely on Xperia, and it's very nice to be able to dual boot with isolated cwms. I can't remember maximum size on a g9 kernel rawfs file, but I think you could have at least enough space to have two kernels to isolate recovery.
Hey letama,
nice to read you :highfive:
letama said:
I've been using the same kind of trick on my Xperia S boot manager project, recovery on loops and mount [email protected] in inits. You may want to take a look at what I did there (see my sig), it may have some use for your project.
Click to expand...
Click to collapse
Cool stuff again...
letama said:
Basically, what I do is storing multiple kernels+cpios on the regular kernel partition. I use one (trimmed down to maximize space) to handle the boot logic and cwm, and I have enough space to handle two "regular" kernels. I handle kernel switch just before they load with a small assembly loader. It works very nicely on Xperia, and it's very nice to be able to dual boot with isolated cwms. I can't remember maximum size on a g9 kernel rawfs file, but I think you could have at least enough space to have two kernels to isolate recovery.
Click to expand...
Click to collapse
AFAIK, we got around ~30MBytes in the raws partition on our tablets so would be possible to put some more kernel+cpios here easily.
Anyway, made some experiments with my latest u-boot port for the tablet this weekend.
I was able to bring up my A80S completely from MicroSD and boot into CWM by using uImage and uInitramfs (based on trevd's CWM image).
There's also some lowlevel multiboot implemented now by using the volume keys... but i know that i use a very special setup, so this is more a proof of concept and not a suitable environment for the average user
Cheers,
scholbert
Thanks Letama + Scholbert
I'll look at all this stuff this week....As a aside, I've played around with mmcblk0p3 and given myself an mmcblk0p5 / 6 of 4MB each. I found parted to be pretty useful (read:safe) for this..... I'm dubious about playing around with the rawfs too much at this point, mainly because I don't understand it fully, yet!.
Have you guy seen this https://github.com/swetland/omap4boot ( I think it's along the line of what Scholbert been working with/on )
Like I've mentioned to ultimate goal is a solution that is "safe" for the average user and also leaves the rest of the tablet in-tact, it maybe a lofty goal but worth a shot. :good:
Thanks for the input guys!
scholbert said:
AFAIK, we got around ~30MBytes in the raws partition on our tablets so would be possible to put some more kernel+cpios here easily.
Click to expand...
Click to collapse
30 for init kernel ? That's plenty indeed! Cool!
Anyway, made some experiments with my latest u-boot port for the tablet this weekend.
I was able to bring up my A80S completely from MicroSD and boot into CWM by using uImage and uInitramfs (based on trevd's CWM image).
There's also some lowlevel multiboot implemented now by using the volume keys... but i know that i use a very special setup, so this is more a proof of concept and not a suitable environment for the average user
Click to expand...
Click to collapse
Nice job! Too bad that Archos doesn't do this on their board with a small internal switch. Would be cool for people like me with big fingers and poor soldering skills
trevd said:
I'll look at all this stuff this week....As a aside, I've played around with mmcblk0p3 and given myself an mmcblk0p5 / 6 of 4MB each. I found parted to be pretty useful (read:safe) for this..... I'm dubious about playing around with the rawfs too much at this point, mainly because I don't understand it fully, yet!.
Click to expand...
Click to collapse
Hummm... You're going to end with a full re-partitioning scheme with system and data if you continue this way . Just be careful when you recreate partitions to let the empty space at the beginning of the disk untouched, instant brick ahead if you go there...
Just in case, here is what I did with my repartition script (do you have it ?): delete p3, delete p4, re-create p3 (careful with start point, leave the hole! it should start just after p2) as extended partition, big enough to hold the new partitions, recreate p4 (same thing about the hole, it should start after p3) with what remains and then you can create p5,p6,p7 with the size you want inside p3.
Last advice: rawfs, don't touch it .
Anyway, the good thing with what I did on Xperia S is that you don't mess with rawfs and re-partition, it's just like flashing a very big SDE kernel from recovery with unmodfified sde firmware, that's all. If I find some time, I'll take a look to see if we can do the same thing here.
letama said:
Just in case, here is what I did with my repartition script (do you have it ?): delete p3, delete p4, re-create p3 (careful with start point, leave the hole! it should start just after p2) as extended partition, big enough to hold the new partitions, recreate p4 (same thing about the hole, it should start after p3) with what remains and then you can create p5,p6,p7 with the size you want inside p3.
Click to expand...
Click to collapse
Hi
Yes I have read your previous threads on the subject which provided alot of the inspiration for the work currently at hand, It is also why I am being ultra careful around the partitions
I think maybe I'm just being too clever trying too pull everything back a step into the intramfs when we can just do the old switch root method method.... It's a little messy on the inside but it will get the job done!
Well, I don't like much the switch root too, it's not a very "Android way" of doing things and make some apps not very happy with it, but yes, it will get the job done, one root for recovery, one root for firmware. And Archos stock would be difficult without switch root, they did put far too much stuff outside of system.
letama said:
Well, I don't like much the switch root too, it's not a very "Android way" of doing things and make some apps not very happy with it, but yes, it will get the job done, one root for recovery, one root for firmware. And Archos stock would be difficult without switch root, they did put far too much stuff outside of system.
Click to expand...
Click to collapse
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
trevd said:
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
Click to expand...
Click to collapse
Well, it's required. It's used inside Android, it handles audio, wifi, codecs, smb...
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
Click to expand...
Click to collapse
In rawfs or initramfs ? I wouldn't add any file in rawfs, it would be difficult to do and I don't know how would behave the bootloader if it sees new files there. Initramfs you're free to do whatever you want until you reach maximum size of kernel+initramfs.
trevd said:
Have you guy seen this https://github.com/swetland/omap4boot ( I think it's along the line of what Scholbert been working with/on )
Click to expand...
Click to collapse
Well kind of... while i try to stick with the MicroSD our fellow vincencb follows the omap4boot path.
He already made a port of barebox bootloader to work with this tool and pushed it to the repos.
This way you may put anything you like on the tablet's RAM by using MicroUSB for communication and file transfer.
My way is more to get a full featured u-boot and put it into a state, where it might replace stock loader.
Last step is to put it in internal eMMC... so this is also research and development for now.
trevd said:
Like I've mentioned to ultimate goal is a solution that is "safe" for the average user and also leaves the rest of the tablet in-tact, it maybe a lofty goal but worth a shot. :good:
Click to expand...
Click to collapse
Yepp that sounds like a reasonable approach.
letama said:
30 for init kernel ? That's plenty indeed! Cool!
Click to expand...
Click to collapse
To be even more precisely, there are 32512*1K blocks for the rawfs partition.
On my device there's ~12MB left...
letama said:
Nice job! Too bad that Archos doesn't do this on their board with a small internal switch. Would be cool for people like me with big fingers and poor soldering skills
Click to expand...
Click to collapse
Yeah, a real switch would be nice indeed... there's some unused testpoints giving us additional GPIO
Need to solder though...
trevd said:
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
Click to expand...
Click to collapse
Some stuff outside of system is quite useful and gives us something like a minimal linux ecosystem.
Very useful at console level... some tools seem to be used by the Android system as well.
trevd said:
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
Click to expand...
Click to collapse
Mmmh, letama maybe right with being very careful with this part of internal storage. If it get's corrupt you'll risk a brick (could be restored though by using external boot mechanism).
Anyway the best would be to mount it RW and use the kernel driver to access it... the unknown part is still the bootcode.
There's some kind of allocation table at the beginning of rawfs partition. It is yet unknown how bootcode behaves with an additional entry
Anyway, this is a real nice project and i would really appreciate to see it pushing forward.
Take your time trevd, and again thanks a lot for contribution!!
Have a nice day,
scholbert
Not to put this down in any way, but wouldn't TWRP be better for the G9? It has a full touch tablet UI, which is better than CWM's
Sent from my Galaxy Nexus using Tapatalk 2
Quinny899 said:
Not to put this down in any way, but wouldn't TWRP be better for the G9? It has a full touch tablet UI, which is better than CWM's
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Hi Quinny
There's nothing to stop us using whatever recovery we like.... they all work the same way ( I think ) , i.e the code is compiled into a recovery binary. Unfortunately my touch screen stopped working long ago so I wouldn't really benefit
scholbert said:
To be even more precisely, there are 32512*1K blocks for the rawfs partition.
On my device there's ~12MB left...
Click to expand...
Click to collapse
Ah, yes, but there is space reserved for each file there, what I have to figure is how much is reserved for custom file (sde kernel). I don't want to have to shift the files located after custom to make room for sde kernel , it would defeat the "no-fuss/no-risk" of the method.
Anyway the best would be to mount it RW and use the kernel driver to access it... the unknown part is still the bootcode.
There's some kind of allocation table at the beginning of rawfs partition. It is yet unknown how bootcode behaves with an additional entry
Click to expand...
Click to collapse
Definitely. Re-partitioning is much safer if space is needed.
trevd said:
.... they all work the same way ( I think ) , i.e the code is compiled into a recovery binary.
Click to expand...
Click to collapse
This is a good keyword: The recovery binary itself!
Most tools inside the recovery are simply linked to busybox, which itself is a link to recovery executable.
In other words, we have some code responsable for the menu and framebuffer stuff and we have busybox.
The strings command gave me version 1.2.0. Now my question...
How to configure this part of code?
I'd like to enhance the busybox part.
Could you please provide a little to howto for a compiler run?
Will i need all that Android stuff installed...
I you have any clue, please point me in the right direction.
Lazy,
scholbert
scholbert said:
How to configure this part of code?
I'd like to enhance the busybox part.
Could you please provide a little to howto for a compiler run?
Will i need all that Android stuff installed...
Click to expand...
Click to collapse
Yes, you need full android repo. Android Build system is messy and tightly coupled, busybox is compiled with bionic (android libc), recovery is built on top of it with few android libraries links. Isolating all this "mess" would be difficult. Except disk space required, there is no big deal in getting full android repo.
I'd suggest to take a look at this, you should do the "Prepare the Build Environment" section.
I don't know how trevd built his recovery, but what I did is create a gen9 device to get proper configuration for recovery (frame buffer config, ...). You can get mine if you want, it's a little outdated (latest cwm doesn't need a specific gfx anymore, the custom one I used has been moved to upstream for instance), but it should give you a base.
To do that, you have to create an "archos" directory in cm9/device directory, then from inside it do:
Code:
git clone git://gitorious.org/archos-ics/device-g9.git gen9
Then, you need to setup the build env once. From cm9 root, you have to do that:
Code:
. build/envsetup.sh
(it setups android build environment)
then
Code:
lunch
then choose full_gen9-eng.
(it selects device target for build)
You should have something like that:
Code:
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=4.0.4
TARGET_PRODUCT=full_gen9
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=IMM76L
============================================
from this point, you can compile:
make -j4 recoveryimage (change j4 with the number of parallel build you want depending on your cpu).
whole recovery fs should be in out/target/product/gen9/recovery/root, with recovery command in sbin
Last, how do you want to extend it? If you want to add custom commands, take a look at cwm bootable/recovery/extendedcommands.c, it may be easier to add stuff there than in busybox.
What's the best way to mount a network directory. I've used sshfs before but it was lacking support in the kernel usually it seems(sshfsandroid). What's the best way this can be done mounting from a Linux machine. I'm so big on the idea of exposing a workgroup publicly like a windows share seems to do. Any suggestions. Ideally it would be nice to mount a directory from a single command in init.d if that could work.
CifsManager is great for mounting Samba/CIFS shares, both from Linux and Windows servers.
However I've tried with the stock rom rooted but had no luck.
May someone help us?
I bought a tab S2 about a month ago to replace my HP touchpad i've had/been using since the firesale about 4 yrs ago. At the time of purchase, I discovered really quickly that lack of custom roms on the S2 at that time was to much of an issue, and I returned it.
I am however seeing an alpha of CyanogenMod for the tab S2 that's looking pretty close to usable. Given that the tab is also on sale this week, i'm very much inclined to repurchase it, however, question: Does cifs/smb mounting remote filesystems work with the tab s2 rom that was posted?
You can do that on the stock S2 with many different apps in the Play Store. ie. ES File Explorer, Solid Explorer, AndSMB
nrage23 said:
You can do that on the stock S2 with many different apps in the Play Store. ie. ES File Explorer, Solid Explorer, AndSMB
Click to expand...
Click to collapse
Correct me please if i'm wrong, but those applications just allow me to browse remote filesystems from the application itself. They don't smb mount them. It's the cifs.ko file i'm missing (which i'm assuming is included with cm12?)
The cifs.ko file would have to be done via a kernel module based on what I seen from other devices. I do not know if it is included in CM kernels or not.
Did you or anyone get cifs working?
I understand it may be possible to compile a cifs.ko and insmod it.
I don't know how possible that is but whilst I'm googling how to compile I thought I'd see if anyone had done it.
Cheers, Guy
I got CIFS mount working on my 710 by installing Neked_Nook_MM-710-V1 and my fork of @engine95 mm kernel which has the cifs module enabled.
Hi thanks for the reply
I don't suppose you have any tips or suggested posts/ guides I could use to recreate your setup?
I guess I could figure out how to get neked nook flashed based on the guides but the fork of the engine95 Kernel that includes cifs..? I can see a post about the permissive kernel by engine95..
Is your device fully functional and stable now?
Thanks a lot,
Guy
Neked nook is very stable. My tab s2 has not crashed so far with that rom, and my custom kernel. I have attached my boot image. This is a fork of engine95 kernel with just cifs module added. This kernel only works on MM.
Extract boot.zip and flash boot.img via twrp(boot image) or fastboot.
You can use the attached cifs manager to mount your smb/cifs drives on android as a directory.
I am only able to mount it to /mnt/drive. I could not get it to mount to /sdcard.
Awesome thanks
I use cifsmanager on a Chuwi hi12 that i've rooted, it already has the cifs modules and permissive kernel so I am able to mount the shares almost wherever I like - and I use cifsmanager to poke 1TB of satellite images into the map folder of my mapping app on the SD card. But I don't know if cifs was in the kernel (chuwi is on lollipop) already or part of the rooting process, would love to recreate the setup on my samsung as its a far superior device.
I'll give it a go this weekend, really appreciate you taking the time to upload the files you used.
Cheers,
Guy
Hi Currowth,
I know life is too short to help each noob, but can I trouble you for another pointer?
I used the full image of Neked Nook MM v1, and the boot image you provided, and the tablet is working great, and if I cat /proc/filesystems I can now see cifs listed....but..
I can't mount any cifs shares - to anywhere, including /mnt/drive. I get the mount failed Mount: I/O error.
(I think my process was along the lines of: ODIN to cf-autoroot (i'd actually done this a while before starting this thread so including in case its relevant, as i dont know if there is an issue with a /system or systemless root?) then I ODIN'd TWRP on, took a full backup with TWRP and then wiped data,cache, system etc and flashed Neked Nook on, booted into NNook, then went back to twrp and put the boot image you provided on.
Any help greatly appreciated.
If it means anything I'm not trying to watch Batman in bed, I'm trying to put together a repeatable solution for me and my overland traveller friends so we can take huge amounts of map and satellite image tiles completely offline when we're driving our landrovers, toyotas etc across deserts where sat navs or road maps are useless.
thanks again,
Guy
*Edited to add i've been googling the crap out of the mount i/o error, tried a patched version of cifsmanager, tried copying the apk to the system/apps folder and changing its permissions before reinstalling.. no joy
Looks like it can be a root issue. This is what i flashed to get root. "BETA-SuperSU-v2.74-2-20160519174328"
try to install busybox also and try again.
If that does not work:
Can you try to run this in adb shell as root?
mount -t cifs -o username="username",password="password" //smbpath/dir mnt/cifs/dir
replace "username,"password", and smbpath/dir
Guy009 said:
Hi Currowth,
I know life is too short to help each noob, but can I trouble you for another pointer?
I used the full image of Neked Nook MM v1, and the boot image you provided, and the tablet is working great, and if I cat /proc/filesystems I can now see cifs listed....but..
I can't mount any cifs shares - to anywhere, including /mnt/drive. I get the mount failed Mount: I/O error.
(I think my process was along the lines of: ODIN to cf-autoroot (i'd actually done this a while before starting this thread so including in case its relevant, as i dont know if there is an issue with a /system or systemless root?) then I ODIN'd TWRP on, took a full backup with TWRP and then wiped data,cache, system etc and flashed Neked Nook on, booted into NNook, then went back to twrp and put the boot image you provided on.
Any help greatly appreciated.
If it means anything I'm not trying to watch Batman in bed, I'm trying to put together a repeatable solution for me and my overland traveller friends so we can take huge amounts of map and satellite image tiles completely offline when we're driving our landrovers, toyotas etc across deserts where sat navs or road maps are useless.
thanks again,
Guy
*Edited to add i've been googling the crap out of the mount i/o error, tried a patched version of cifsmanager, tried copying the apk to the system/apps folder and changing its permissions before reinstalling.. no joy
Click to expand...
Click to collapse
Thanks for coming back Currowth,
Ok my SuperSU from the original cf-autoroot was 2.46. I assumed I needed to remove that so I ran the unroot function and then used twrp to flash the version you linked to, after reboot SuperSu is at 2.74.
Unfortunately i have the same I/O error.
I also ran adb root from my win10 machine and tried the manual mount command as you suggested - it returns I/O error also. Initially it said 'no such file or directory' so I manually created the dir, with the name the same as the share dir, in /mnt/cifs.
command output
255|[email protected]:/ # mount -t cifs -o username=admin,password=admin //10.10.10.254/Public1 /mnt/cifs/Public1
mount: No such file or directory
255|[email protected]:/ # cd /mnt/cifs
[email protected]:/mnt/cifs # mkdir Public1
255|[email protected]:/ # mount -t cifs -o username=admin,password=admin //10.10.10.254/Public1 /mnt/cifs/Public1
mount: I/O error
One other thing, in the NNook image thread, i see it says make sure you 'ODIN M' first. I'm embarrassed to say i don't know what that means!
update in mean time: i started again, based on doing all the flashing whilst rooted with the older supersu. So i've unrooted, rooted with your beta_xx linked above, wiped system, cache, data and dalvik, flashed the Neked Nook full MM V1 ROM, booted into that, then back to twrp to flash the boot.img you linked above, installed busybox, the linked cifsmanager, tried to mount, then updated supersu as recommended in NNook thread, rebooted and tried mount again but no joy, always getting i/o error.
just for further info, the shared folder does work on my chuwi with cifsmanager, so hopefully that is not the issue. Before I re-did the ROM and the boot image, i installed paragon ntfs and was able to successfully mount an NTFS formatted SD card into the /mnt/cifs/public1 directory.
interestingly cifsmanager couldn't create the directories under /mnt, but i was able to create them manually and then get an IO error. I changed permissions on the /mnt/cifs folder and now it can create the directory when attempting to mount but still gets IO error.
i'm beyond my depth, guess it feels like cifsmanager is either not working or not got permission - or something i've done prior to the NN and kernel flashes has caused an issue.
Its starting to feel like a lost cause. You know better than me - if this is the end of the easy flash-type fixes to try, perhaps I should just throw in the towel.
Thanks again for your help Currowth, you're a gent
I just did a clean install to replicate you issue, but was not able to reproduce it. 'ODIN M' means that install a marshmallow rom first via ODIN. If you already came from a marshmallow ROM, you can ignore it.
The steps i took to ensure that i am was able to get cifs were the following:
First i installed "Neked_Nook_MM-710-V1.zip"
Next I installed "BETA-SuperSU-v2.74-2-20160519174328.zip"
Last i installed "boot.img"
I did this all through twrp.
Reboot, dont setup knox if it asks you to.
Try to do a wipe, then reinstall the following and try again.
Guy009 said:
Thanks for coming back Currowth,
Ok my SuperSU from the original cf-autoroot was 2.46. I assumed I needed to remove that so I ran the unroot function and then used twrp to flash the version you linked to, after reboot SuperSu is at 2.74.
Unfortunately i have the same I/O error.
I also ran adb root from my win10 machine and tried the manual mount command as you suggested - it returns I/O error also. Initially it said 'no such file or directory' so I manually created the dir, with the name the same as the share dir, in /mnt/cifs.
command output
255|[email protected]:/ # mount -t cifs -o username=admin,password=admin //10.10.10.254/Public1 /mnt/cifs/Public1
mount: No such file or directory
255|[email protected]:/ # cd /mnt/cifs
[email protected]:/mnt/cifs # mkdir Public1
255|[email protected]:/ # mount -t cifs -o username=admin,password=admin //10.10.10.254/Public1 /mnt/cifs/Public1
mount: I/O error
One other thing, in the NNook image thread, i see it says make sure you 'ODIN M' first. I'm embarrassed to say i don't know what that means!
update in mean time: i started again, based on doing all the flashing whilst rooted with the older supersu. So i've unrooted, rooted with your beta_xx linked above, wiped system, cache, data and dalvik, flashed the Neked Nook full MM V1 ROM, booted into that, then back to twrp to flash the boot.img you linked above, installed busybox, the linked cifsmanager, tried to mount, then updated supersu as recommended in NNook thread, rebooted and tried mount again but no joy, always getting i/o error.
just for further info, the shared folder does work on my chuwi with cifsmanager, so hopefully that is not the issue. Before I re-did the ROM and the boot image, i installed paragon ntfs and was able to successfully mount an NTFS formatted SD card into the /mnt/cifs/public1 directory.
interestingly cifsmanager couldn't create the directories under /mnt, but i was able to create them manually and then get an IO error. I changed permissions on the /mnt/cifs folder and now it can create the directory when attempting to mount but still gets IO error.
i'm beyond my depth, guess it feels like cifsmanager is either not working or not got permission - or something i've done prior to the NN and kernel flashes has caused an issue.
Its starting to feel like a lost cause. You know better than me - if this is the end of the easy flash-type fixes to try, perhaps I should just throw in the towel.
Thanks again for your help Currowth, you're a gent
Click to expand...
Click to collapse
Thanks Currowth I will try and give it a go tomorrow
Just a thought, are you booting into Android after each step, or doing all the flashing in one twrp session then doing first boot once all items are flashed?
I flashed them in one session without rebooting.
Hi Currowth, I've had a breakthrough!
I re did the NNook/root/boot image in the order you advised.
I have been using a patriot node WiFi disk enclosure, that works with cifs manager on my other tablet. Today I was working away from the WiFi disk so I made do with a windows pc to provide a shared folder. After setting cifs manager up I was able to mount the share under /mnt, but not to any other location. I got back to my WiFi disk, and that continued to give an io error!? So windows worked but the patriot didn't. Weird. I'd ruled the patriot out as it works on my 5.1 lollipop tab.
So I continued to mess around... I had stumbled across another app called mount manager by Ryan conrad (I don't have the link but I have the apk) which has more noob-friendly options and found if I used the ntlmv2 option I could mount the patriot into /mnt !
I did try to get it to mount to other locations and although it succeeded in the app, the mounted folder was empty.
As my app - Osmand+ has the option to manually specify it data folders I created a 777 permission folder for it under /mnt, and then mounted the patriot containing my satellite images into the appropriate empty tile folder.
Working solution!!! If a little messy.
Thanks so much for your help, the Samsung s2 is about 400% faster and more practical than the other tablet so really happy
I don't know why android devices are so limited by manufacturers when the OS is capable of so much, but that's a different conversation haha
A follow up on this in case it is useful to others...
Using /mnt was a bad idea. /mnt is mounted / built on a system partition as a mount point for other file systems or devices (how I have explained it to myself). So anything you add here as a folder gets destroyed when you reboot.
So, I installed my osmand app to /data/osmand and then used a root terminal to run "chmod -R 777 /data/osmand/" to set permissions to 777 on that folder and all subfolders.
After doing this I was able to get mount manager to mount my cifs share into an empty subfolder in the apps folder tree.
I initially tried changing permissions on /data in case it was needed for folders further down the tree, but it was not needed - which is just as well because again, /data is mounted at boot with 771 permissions, so changes 777 back to 771 after reboot. To change that would involve unpacking the boot image in order to edit the init.rc file and then repacking. I didn't bother it was not required.
If anyone wants mount manager, Google 'ryan conrad mount manager' and take your chance with the apk sites, can't remember whigh site I used!
This guide is intend to help you with "installing" Ubuntu 14.04 (12.04 also works) on the Amazon Fire TV 2 after @rbox recovery has been setup. Only headless mode is possible, similar to Ubuntu Server, but it still makes a nice little ARMv8 development box. Starting X.org or running systemd based Linux distributions will likely never be possible due to features missing from the Amazon kernel. Creative use of the framebuffer is possible if desired, maybe eventually a terminal emulator could be started. As long as you don't mount and modify mmcblk0pX there should be no possible way to mess up Android or brick the device. It's 100% reversible by just removing the SD card. You accept all responsibility for what you do with this work should something go wrong and the device becomes inoperable. With disclaimers and precursor knowledge out of the way let's get started.
To follow this guide you will need:
A micro SD card (2 GB+ recommended)
A Linux system
To login into Ubuntu you will need either:
A 1.8 V TTY USB serial device connected to the UART
A pair of USB serial devices and a null modem cable
I actually used a pair of Xbee's for testing the ttyUSB0 stuff, so hence a pair of FTDI chips would also work.
Preparing the SD Card
To get started you need to first partition the micro SD card:
Type = MBR
Part 1 = 100 MB, Fat32 (vfat)
Part 2 = Remainder, Ext4
Extract the attached zip file to the root of the first partition (extracted filename must be "ramdisk-recovery.cpio.lzma"). This is an alternative initramfs that simply uses busybox to clean up from the partial Android boot and prepare the filesystem for regular Linux. Extract an Ubuntu core root filesystem archive, ubuntu-core-14.04.4-core-arm64.tar.gz, to the root of the second partition as the root user (to preserve ownership/permissions). Make sure you sync or eject the device when done with this work so the data gets flushed to the SD card.
Now we need to make a few changes to the root filesystem to avoid usability issues and allow logins.
Replace /etc/fstab with the following contents to correct some mount options. This "disables" SELinux which fixes dpkg errors and some other login annoyances.
Code:
/dev/mmcblk1p2 / ext4 defaults,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs ro,relatime 0 0
Replace /etc/init/console.conf with the following contents to allow logins from the UART. Once the root password has been set (root is disabled by default) you can remove "-a root" if desired.
Code:
# console - getty
#
# This service maintains a getty on console from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec /sbin/getty -s -a root console
Create /etc/init/ttyUSB0.conf with the following contents to allow logins from an attached USB serial device. This should help people who don't want to take apart their device to solder wires onto the UART test points. SSH would of course be an alternative but it's not installed by default in Ubuntu core and this guide is about the building blocks not providing pre-made images (yet). Since udev doesn't work due to devtmpfs not being enabled in the kernel you will need to attach the USB serial device before booting for this to work. As before you can remove "-a root" later if desired once the root password is set. Also you should change the baud rate if needed.
Code:
start on (tty-device-added ttyUSB0)
stop on (runlevel [!2345] or tty-device-removed ttyUSB0)
respawn
exec /sbin/getty -L -a root 115200 ttyUSB0 vt102
Preparing the Fire TV
Until the search order for the initramfs file is changed by @rbox you will need to rename the initramfs on the system partition so it will continue to search for one on the SD card or USB stick. You need to connect to the device using adb either over USB or the network to execute the following commands.
Code:
adb$ su
adb# mount -o remount,rw /system
adb# mv /system/recovery/ramdisk-recovery.cpio.lzma /system/recovery/ramdisk-recovery.cpio.lzma.bak
adb# mount -o remount,ro /system
Right now this prevents "su" from working, which should be fixed by @rbox in due time. To get "su" working again you should extract the original recovery initramfs file to a USB stick and boot the device with that USB stick inserted instead of the previously created SD card. Then to restore "su" you can repeat the above steps just swapping the order of the files in the "mv" command.
Booting Ubuntu
After connecting your serial device of choice simply insert the SD card and power on the device. It's that easy! With luck you should get a shell prompt that is already logged in as root. It's a good idea to set the root password before going much further. The device isn't too useful without networking, so you can install more packages. To solve that connect an ethernet cable (since it's simpler) and type "dhclient eth0" to get online. At this point you can install openssh-server using apt-get or do anything else you'd normally do on an Ubuntu VM or headless Ubuntu system. I'm interested in hearing what people plan to do with a more-or-less high-end ARM development system.
Tips and Tricks
NOTE: These changes, unless otherwise noted, are performed while logged into the target Ubuntu system.
Setting the Hostname
You can change the hostname using the following command:
Code:
echo sloane > /etc/hostname
You should also create a simple /etc/hosts file that matches the chosen hostname.
Code:
127.0.0.1 localhost
127.0.1.1 sloane
Enable Ethernet at Boot
Create the file /etc/network/interfaces.d/eth0 with the following contents:
Code:
auto eth0
iface eth0 inet dhcp
Allow Users Network Access
Since we are stuck running an Android kernel you need to create the following group and add users who need network access (such as ping) to this special group.
Code:
groupadd -g 3003 aid_inet
usermod -G aid_inet -a root
usermod -G aid_inet -a <username>
Removing Failed Services
There are a few services that fail to start due to hardware limitations. We should just prevent them from starting in the first place. We have no VT support enabled in the kernel (boo) so we can just remove the ttyX login prompt services. Also the console setup doesn't work since our console is a serial device not a virtual terminal or other "graphical" type terminal emulator.
Code:
rm /etc/init/tty?.conf
echo manual > /etc/init/console-font.override
echo manual > /etc/init/console-setup.override
Fix /dev Hotplug
As stated before udev doesn't work due to missing kernel features. The busybox applet mdev is a simple replacement for most users. After installing the "busybox-static" package run the following command:
Code:
ln -s /bin/busybox /sbin/mdev
Now add the following line to /etc/rc.local before "exit 0".
Code:
echo /sbin/mdev > /proc/sys/kernel/hotplug
Pre-installing SSH
See: http://forum.xda-developers.com/showpost.php?p=65595013&postcount=13 (thanks @segfault1978)
Thanks a lot, that was exactly the thing I was searching for. Since before today the Raspi3 came out, this box is the cheapest ARMv8 development machine available. With your instruction I was able to login via SSH and install all required software for my development environment. No GUI needed for that, I'm doing all remotely via SSH. Again, thank you!
segfault1978 said:
Thanks a lot, that was exactly the thing I was searching for. Since before today the Raspi3 came out, this box is the cheapest ARMv8 development machine available. With your instruction I was able to login via SSH and install all required software for my development environment. No GUI needed for that, I'm doing all remotely via SSH. Again, thank you!
Click to expand...
Click to collapse
Awesome to hear that it worked for you. Just curious if you went the USB serial route or soldered to the UART pins.
There is also the Dragonboard 410c which is a quad core A53 but has a bit more than the raspberry pi. The price is higher though but it has been out probably a year or so. Just FYI. The raspberry pi 3 is a good deal.
zeroepoch said:
Awesome to hear that it worked for you. Just curious if you went the USB serial route or soldered to the UART pins.
Click to expand...
Click to collapse
None of these methods (since I was in my weekend and all cables and adapters reside in my office)
I placed all .deb-files for openssh-server including all requiremens onto the microSD card, and placed a call "dpkg -i /*.deb" with logging options in /etc/rc.local. I also configured network by mounting the sd card, editing /etc/network/interfaces, and last changed /etc/shadow to have a valid root account for login. It took my some try-and-error loops, but finally it worked as expected. Call me crazy, but I succeeded without any hardware.
---------- Post added at 09:09 PM ---------- Previous post was at 09:03 PM ----------
zeroepoch said:
There is also the Dragonboard 410c which is a quad core A53 but has a bit more than the raspberry pi. The price is higher though but it has been out probably a year or so. Just FYI. The raspberry pi 3 is a good deal.
Click to expand...
Click to collapse
Thank you for the hint, I'll have a look for the availability of this board in germany.
I'm facing a memory problem, resulting in a reboot of the device when all RAM is being used. My compile session takes more than 1.x GB of RAM for the quite complex compilation of all required packages. I can reproduce the situation where all memory is consumed and the device instantly reboots when hitting "no memory left" situation. Since "swapon" is not supported by the kernel (really?): is there any way to enable swap functionality, i.e. via a kernel module? How to overcome this situation where more memory is needed?
segfault1978 said:
None of these methods (since I was in my weekend and all cables and adapters reside in my office)
I placed all .deb-files for openssh-server including all requiremens onto the microSD card, and placed a call "dpkg -i /*.deb" with logging options in /etc/rc.local. I also configured network by mounting the sd card, editing /etc/network/interfaces, and last changed /etc/shadow to have a valid root account for login. It took my some try-and-error loops, but finally it worked as expected. Call me crazy, but I succeeded without any hardware.
Click to expand...
Click to collapse
That is pretty crazy, but since you knew the changes required it worked Not everyone I expected to have such experience. I figured someone might even try to do a qemu chroot or debbootstrap to preinstall openssh. Multiple ways to solve the same problem I guess.
segfault1978 said:
I'm facing a memory problem, resulting in a reboot of the device when all RAM is being used. My compile session takes more than 1.x GB of RAM for the quite complex compilation of all required packages. I can reproduce the situation where all memory is consumed and the device instantly reboots when hitting "no memory left" situation. Since "swapon" is not supported by the kernel (really?): is there any way to enable swap functionality, i.e. via a kernel module? How to overcome this situation where more memory is needed?
Click to expand...
Click to collapse
Looking at the default kernel config from the source code drop from Amazon I see:
Code:
# CONFIG_SWAP is not set
Swap can not be compiled as a module. Even if you chose to use a USB stick or something as the swap device It wouldn't work. Given that we can't change the kernel we can't try stuff like zram or zswap either. The only other suggestion I might have is if you're using "-j4" or something while compiling just remove that so it does a single threaded compile. I'm sure you already tried that. Beyond that you could look at using the Linaro AArch64 toolchain and cross compile. Since we're running Ubuntu you shouldn't need to worry about static binaries.
zeroepoch said:
Looking at the default kernel config from the source code drop from Amazon I see:
Code:
# CONFIG_SWAP is not set
Swap can not be compiled as a module. Even if you chose to use a USB stick or something as the swap device It wouldn't work. Given that we can't change the kernel we can't try stuff like zram or zswap either. The only other suggestion I might have is if you're using "-j4" or something while compiling just remove that so it does a single threaded compile. I'm sure you already tried that. Beyond that you could look at using the Linaro AArch64 toolchain and cross compile. Since we're running Ubuntu you shouldn't need to worry about static binaries.
Click to expand...
Click to collapse
Unfortunately, I'm not compiling with parallel processes (I'm compilig Icinga2 for arm64), I'm running
Code:
dpkg-buildpackage -us -uc
within the source package. One single cpp call consumes so much memory (which is crazy in my eyes, never seen such a big compiler process until today), so I'll investigate the option of cross compiling and afterwards creating the deb file outside of the machine.
Code:
cd /root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib/base && /usr/bin/aarch64-linux-gnu-g++ -DI2_BASE_BUILD -Doverride="" -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g -pthread -std=c++11 -Wno-inconsistent-missing-override -fPIC -I/root/icinga2-2.4.3 -I/root/icinga2-2.4.3/lib -I/root/icinga2-2.4.3/obj-aarch64-linux-gnu -I/root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib -I/root/icinga2-2.4.3/third-party/execvpe -I/root/icinga2-2.4.3/third-party/mmatch -I/root/icinga2-2.4.3/third-party/socketpair -o CMakeFiles/base.dir/base_unity.cpp.o -c /root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib/base/base_unity.cpp
I'm a novice in android devices: What would be required to use a custom kernel? A hacked boot loader, which is not available for the AFTV2?
segfault1978 said:
I'm a novice in android devices: What would be required to use a custom kernel? A hacked boot loader, which is not available for the AFTV2?
Click to expand...
Click to collapse
Yep... we need to be able to use fastboot to boot an unsigned kernel and initramfs (boot.img). I tried at one point to overwrite the boot partition with own image and it failed to boot. Since I had the preloader stuff worked out already I was able to restore the original boot image and get it working again.
On a side note, if you don't mind could you post the list of packages needed to install SSH server from rc.local? Others might find that useful. To get around the unset password issue you could have also saved a public key in /root/.ssh/authorized_keys which would also avoid you needing to change /etc/ssh/sshd_config to allow password logins as root.
segfault1978 said:
within the source package. One single cpp call consumes so much memory (which is crazy in my eyes, never seen such a big compiler process until today), so I'll investigate the option of cross compiling and afterwards creating the deb file outside of the machine.
Code:
cd /root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib/base && /usr/bin/aarch64-linux-gnu-g++ -DI2_BASE_BUILD -Doverride="" -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g -pthread -std=c++11 -Wno-inconsistent-missing-override -fPIC -I/root/icinga2-2.4.3 -I/root/icinga2-2.4.3/lib -I/root/icinga2-2.4.3/obj-aarch64-linux-gnu -I/root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib -I/root/icinga2-2.4.3/third-party/execvpe -I/root/icinga2-2.4.3/third-party/mmatch -I/root/icinga2-2.4.3/third-party/socketpair -o CMakeFiles/base.dir/base_unity.cpp.o -c /root/icinga2-2.4.3/obj-aarch64-linux-gnu/lib/base/base_unity.cpp
Click to expand...
Click to collapse
I see you are not using -pipe which is good, but a quick search suggested something that might not be simple since this package has it's own build system but changing from -O2 to -O1 might help.
I noticed that Debian has the package available for the same version and already built for arm64.
https://packages.debian.org/sid/icinga2
Maybe you already tried that. You could try going back to jessie which is probably an older version but I think most jessie packages work with Ubuntu 14.04.
zeroepoch said:
Yep... we need to be able to use fastboot to boot an unsigned kernel and initramfs (boot.img). I tried at one point to overwrite the boot partition with own image and it failed to boot. Since I had the preloader stuff worked out already I was able to restore the original boot image and get it working again.
On a side note, if you don't mind could you post the list of packages needed to install SSH server from rc.local? Others might find that useful. To get around the unset password issue you could have also saved a public key in /root/.ssh/authorized_keys which would also avoid you needing to change /etc/ssh/sshd_config to allow password logins as root.
Click to expand...
Click to collapse
This is the list of packages I manually downloaded for ARM64 (unfortunately I used Debian packages which worked first, but leads to a hell situation afterwards when dealing with other dependencies; be sure to use Ubuntu packages in order to avoid problems afterwards):
Code:
busybox_1.22.0
libedit2_3.1
libgssapi-krb5
libk5crypto3
libkeyutils1
libkrb5
libkrb5support0
libwrap0
openssh-client
openssh-server
openssh-sftp-server
This is the piece of calls in /etc/rc.local, right before the exit:
Code:
dpkg --force-all -i /*.deb > /install.log 2>/install.err
echo $? >> /install.log
echo "installation finished" >> /install.log
It took about 1-2 minutes before SSH started to work automatically, you can mount the SD card afterwards in another system in order to check the written logfiles.
Here are some notes for getting wireless working. In addition to the normal OS steps (installing wpasupplicant or wireless-tools and editing /etc/network/interfaces or using wicd) you will need some firmware files from /system (/dev/mmcblk0p13).
Code:
mount -o ro /dev/mmcblk0p13 /mnt
cp -r /mnt/etc/firmware/ /lib/
cp -r /mnt/etc/Wireless /etc/
umount /mnt
segfault1978 said:
None of these methods (since I was in my weekend and all cables and adapters reside in my office)
I placed all .deb-files for openssh-server including all requiremens onto the microSD card, and placed a call "dpkg -i /*.deb" with logging options in /etc/rc.local. I also configured network by mounting the sd card, editing /etc/network/interfaces, and last changed /etc/shadow to have a valid root account for login. It took my some try-and-error loops, but finally it worked as expected. Call me crazy, but I succeeded without any hardware.
Thank you for the the fire tv guide.
Click to expand...
Click to collapse
So, what's the verdict on this? I want to use my firetv 2 as an emby server. Is it worth it trying to get Ubuntu to run?
Sent from my Mi A1 using Tapatalk
mrchrister said:
So, what's the verdict on this? I want to use my firetv 2 as an emby server. Is it worth it trying to get Ubuntu to run?
Click to expand...
Click to collapse
If it has arm64 packages and headless you can give it a try. If you don't like it you can just revert the ramdisk and go back to Android.
Ok sweet, thanks for the reply
Sent from my Mi A1 using Tapatalk
Just curious if anyone's tried running Plex server on this?
I've been looking for a better solution without shelling out $500+ for a dedicated NAS. AFTV is tiny so I could hardwire it and hide it away.
Thanks
I got the same idea. Right now the firetv is still being used as a media streamer but I'm thinking of doing this soon
Hey!
I found this thread with fully compile-able code for android on most hardware platforms, I see it uses system level modifications to do its business, and would love to see it rolled into a magisk module. I regularly use external hard drives on my Pixel 2 XL for a plethora of reasons and really need legit exFat and NTFS support as I use flash kernel and I cant merge the code myself (my only machine couldn't handle the compiling). Anyway, If possible, making a ZIP that is universal and has the binaries for arm, arm64, and all x86 variants would be pretty great!
GitHub: https://github.com/Lurker00/Android-fs
XDA: https://forum.xda-developers.com/android/development/exfat-ntfs-fuse-drivers-easy-build-t3126413
I am not magisk-ninja so anyone who can help make this happen OR educate me in the process of doing so (and who can compile the above Git files for arm64 and send them to me) would be very much appreciated! I am willing to learn to help the community!
Over and out
thomasamas said:
Hey!
I found this thread with fully compile-able code for android on most hardware platforms, I see it uses system level modifications to do its business, and would love to see it rolled into a magisk module. I regularly use external hard drives on my Pixel 2 XL for a plethora of reasons and really need legit exFat and NTFS support as I use flash kernel and I cant merge the code myself (my only machine couldn't handle the compiling). Anyway, If possible, making a ZIP that is universal and has the binaries for arm, arm64, and all x86 variants would be pretty great!
GitHub: https://github.com/Lurker00/Android-fs
XDA: https://forum.xda-developers.com/android/development/exfat-ntfs-fuse-drivers-easy-build-t3126413
I am not magisk-ninja so anyone who can help make this happen OR educate me in the process of doing so (and who can compile the above Git files for arm64 and send them to me) would be very much appreciated! I am willing to learn to help the community!
Over and out
Click to expand...
Click to collapse
Hi. I just started working on this yesterday.
It seems like the perfect method to install additional filesystem support.
I am currently able to manually mount exfat or ntfs sdcard images on my phone (LG Aristo 2, Android 7).
However, a great deal has changed in how filesystem support is added to an existing kernel. Lurker00's code is for Android 4.4.2.
If you want to work together on it, I would be more than happy to do so. I will try to get together what I have so far in a post later today.
FYI, this is a TWRP installable .zip that has Lurker00's compiled binaries for arm64-v8a, armeabi-v7a, x86 and x86_64.
It also installs init.d scripts that supposedly support auto mounting of exFat and NTFS partitions. That part is not working for me, as I think it is setup for Android 5 and before. However the mount binaries work for manually mounting exFat or NTFS partitions.
Just install the .zip from TWRP.
https://forum.xda-developers.com/attachment.php?attachmentid=4600419&stc=1&d=1537390717
Hey! I just saw this, I can try my best but I was assuming it wouldn't be an android thing but rather a Linux/android kernel thing. Is there a way we can Abstract the mounting from android, solely into the kernel, basically leaving Android unaware that the introduced file system is not "officially supported"? I'm assuming FUSE can do this.
Edit: spelling.
tecknight said:
Hi. I just started working on this yesterday.
It seems like the perfect method to install additional filesystem support.
I am currently able to manually mount exfat or ntfs sdcard images on my phone (LG Aristo 2, Android 7).
However, a great deal has changed in how filesystem support is added to an existing kernel. Lurker00's code is for Android 4.4.2.
If you want to work together on it, I would be more than happy to do so. I will try to get together what I have so far in a post later today.
FYI, this is a TWRP installable .zip that has Lurker00's compiled binaries for arm64-v8a, armeabi-v7a, x86 and x86_64.
It also installs init.d scripts that supposedly support auto mounting of exFat and NTFS partitions. That part is not working for me, as I think it is setup for Android 5 and before. However the mount binaries work for manually mounting exFat or NTFS partitions.
Just install the .zip from TWRP.
https://forum.xda-developers.com/attachment.php?attachmentid=4600419&stc=1&d=1537390717
Click to expand...
Click to collapse
How exactly do you manually mount them? (your method)
Edit: also! I was thinking maybe this could become a kernel patch that I could alert kernel devs to? (see my above comment)
And... Thanks for all the hard work to get this going. Tell me how I can help!
thomasamas said:
How exactly do you manually mount them? (your method)
Edit: also! I was thinking maybe this could become a kernel patch that I could alert kernel devs to? (see my above comment)
And... Thanks for all the hard work to get this going. Tell me how I can help!
Click to expand...
Click to collapse
I installed the .zip file that I posted earlier using TWRP.
This installs these binaries to /system/xbin:
mount.exfat
mkfs.exfat
fsck.exfat
dumpexfat
exfatfsck
exfatlabel
mkexfatfs
mount.exfat-fuse
ntfs-3g
ntfsfix
probe
I then inserted an exFat formatted SDCard into my phone and Android told me the device was corrupt.
That is due to the fact that Android no longer uses probe to determine the filesystem of a device, it now uses a program called blkid.
I would like to figure out how to add a new supported filesystem type to blkid
In any event, I mounted my exFat sdcard by launching a shell from adb, running su to get root and then I created a folder named exfatsd in the /mnt folder. I then ran this command:
mount.exfat /dev/block/mmcblk1 /mnt/exfatsd
The mount succeeded and I was able to browse the sdcard from /mnt/exfatsd
When I typed mount to enumerate the mounts, this is the entry I saw for my sdcard:
/dev/block/mmcblk1 on /mnt/exfatsd type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
By the way, even as i was browsing the exfat sdcard, Android still had a notification up telling me that my sdcard was corrupt
Is there any legit documentation on blkid?
I haven't found any, but I haven't given up on this project either. I have been busy on a couple of other things lately, but I still would like to see this work.
Making progress on this on my LG cv1 ROMs
I just wanted to let you know that I now have exFAT and NTFS support working on my phone, even though the kernel does not have support for either filesystem..
I am mounting the Micro SD using a script that runs under Magisk from the:
post.fs.data.d folder
This folder contains scripts that are to run immediately after the /data filesystem is mounted.
My script is checking the Micro SD device using the blkid command.
The blkid command will indicate the type of filesystem residing on the device, even if the kernel won't mount it.
So I use the results from the blkid command to issue mount commands myself using the binaries created by lurker00.
Here is the script I am using, it is really quite short:
Code:
#!/system/bin/sh
#
# mount NTFS / exFAT
# 06/07/2019 by TecKnight
# This script checks the inserted Micro SD--
# If Micro SD is formatted exFAT or NTFS, it mounts it
sdcard_device=`blkid /dev/block/mmcblk1`
sdcard_part1=`blkid /dev/block/mmcblk1p1`
# Uncomment next 2 lines to troubleshoot
# echo $sdcard_device > /cache/sdcard_device.txt
# echo $sdcard_part1 > /cache/sdcard_part1.txt
# output from blkid command looks like this:
# /dev/block/mmcblk1p1: LABEL="e" UUID="CEDC-3F3A" TYPE="exfat"
# create mount point
mkdir /mnt/media_rw/extsd
# mount approriate filesystem if it resides on device directly
case "$sdcard_device" in
*exfat*) mount.exfat /dev/block/mmcblk1 /mnt/media_rw/extsd ;;
*ntfs*) ntfs-3g /dev/block/mmcblk1 /mnt/media_rw/extsd ;;
esac
# mount approriate filesystem if it resides on first partition of device
case "$sdcard_part1" in
*exfat*) mount.exfat /dev/block/mmcblk1p1 /mnt/media_rw/extsd ;;
*ntfs*) ntfs-3g /dev/block/mmcblk1p1 /mnt/media_rw/extsd ;;
esac
FYI: The reason I am checking /dev/block/mmcblk1 (the actual SD card itself) and dev/block/mmcblk1p1 (the first partition on the sdcard) is that depending on where the sdcard is formatted exFAT or NTFS, it could be on the disk itself or within a parrition. This way, I will catch it either way and mount it correctly.
I was thinking of creating a subroutine to cycle through the block devices to determine the sdcard device.
This would make it compatible with practically every device.
Then I could turn the whole thing into a Magisk module.
There are still 2 minor issues that I am having:
1. The phone still displays a notification about the sdcard being corrupt. You just have to clear the notification and it never reappears.
2. The mounted card is not identified as an external SD by android.
However, the exFAT or NTFS filesystem is mounted at /mnt/media_rw/extsd and is browseable and the filesystem is readable and writable.
Tell me what you think.
TWRP installable .zip to install NTFS/exFAT suport
OK, this is a installable .ZIP that will copy the binaries to /system/xbin and copy the mounting script to:
/data/adb/post-fs-data.d.
This should enable NTFS/exFAT support to most phones.
Requirements:
1. You must have Magisk installed
2. Your Micro SD''s device address must be:
/dev/block/mmcblk1. This is the case on most devices running Android 6 or higher.
If your Micro SD's device address is different, you can fix it by modifying:
/data/adb/post-fs-data.d/mount_ntfs_exfat.sh
replacing /dev/block/mmcblk1 with the device address of your external Micro SD.
Download the installer here:
https://forum.xda-developers.com/attachment.php?attachmentid=4773292&stc=1&d=1559992139
tecknight said:
OK, this is a installable .ZIP that will copy the binaries to /system/xbin and copy the mounting script to:
/data/adb/post-fs-data.d.
This should enable NTFS/exFAT support to most phones.
Requirements:
1. You must have Magisk installed
2. Your Micro SD''s device address must be:
/dev/block/mmcblk1. This is the case on most devices running Android 6 or higher.
If your Micro SD's device address is different, you can fix it by modifying:
/data/adb/post-fs-data.d/mount_ntfs_exfat.sh
replacing /dev/block/mmcblk1 with the device address of your external Micro SD.
Download the installer here:
https://forum.xda-developers.com/attachment.php?attachmentid=4773292&stc=1&d=1559992139
Click to expand...
Click to collapse
Hi,
I know this post isn't new, but I tried installing this zip file and it tells me that my bootloader in't unlocked even though I'm pretty sure it's unlocked,
any way around this?
rachelld said:
Hi,
I know this post isn't new, but I tried installing this zip file and it tells me that my bootloader in't unlocked even though I'm pretty sure it's unlocked,
any way around this?
Click to expand...
Click to collapse
Same here. Maybe the template is to old? Also could use this module.
aCIDsLAM said:
Same here. Maybe the template is to old? Also could use this module.
Click to expand...
Click to collapse
Try this one:
https://www.androidfilehost.com/?fid=4349826312261782012I removed the check for
ro.boot.bl_unlock_complete = true
---------- Post added at 11:08 PM ---------- Previous post was at 11:06 PM ----------
rachelld said:
Hi,
I know this post isn't new, but I tried installing this zip file and it tells me that my bootloader in't unlocked even though I'm pretty sure it's unlocked,
any way around this?
Click to expand...
Click to collapse
Try this one:
https://www.androidfilehost.com/?fid...26312261782012
I removed the check for
ro.boot.bl_unlock_complete = true
I could flash it, using TWRP. In Magisk itself, it told me me, its no magisk module. Anyway. Thanks!
@thomasamas
@tecknight
Is this thread dead ?
Has these drivers been tested on Android 11 ?
I have a custom ROM and would like to use my SDCard with NTFS/exFAT but the ROM only supports FAT32.
KineSight said:
@thomasamas
@tecknight
Is this thread dead ?
Has these drivers been tested on Android 11 ?
I have a custom ROM and would like to use my SDCard with NTFS/exFAT but the ROM only supports FAT32.
Click to expand...
Click to collapse
+1
tecknight said:
TWRP installable .zip to install NTFS/exFAT suport
OK, this is a installable .ZIP that will copy the binaries to /system/xbin and copy the mounting script to:
/data/adb/post-fs-data.d.
This should enable NTFS/exFAT support to most phones.
Requirements:
1. You must have Magisk installed
2. Your Micro SD''s device address must be:
/dev/block/mmcblk1. This is the case on most devices running Android 6 or higher.
If your Micro SD's device address is different, you can fix it by modifying:
/data/adb/post-fs-data.d/mount_ntfs_exfat.sh
replacing /dev/block/mmcblk1 with the device address of your external Micro SD.
Download the installer here:
https://forum.xda-developers.com/attachment.php?attachmentid=4773292&stc=1&d=1559992139
Click to expand...
Click to collapse
Actually, this still works! Have tested this on A11 OctaviOS GSI. You still need to have Magisk installed, but you don't necessarily have to install this as a Magisk module.
Don't flash the .zip file from TWRP, it doesn't do anything (at least not for me). Just unzip everything in the .zip file into a folder. Then, take the files inside the xbin folder and put it into /system/xbin (as per instructions). Make sure those files have execute permissions. I just set the xbin folder with full execute permissions and apply to all child files in the folder, by using Root Explorer.
Next, do the same thing by taking the script and chuck that into /data/adb/post-fs-data.d. Again, give this script full execute permissions.
Reboot phone and voila, it should work! You should also see that the script is loaded and running in Magisk logs.
Oh and the reason why Magisk is required is because Magisk creates that "post-fs-data.d" folder after it is installed. If you put scripts into /data/adb/service.d or /data/adb/post-fs-data.d, they will automatically get executed by Magisk and run with superuser rights.
chaoscreater said:
Actually, this still works! Have tested this on A11 OctaviOS GSI. You still need to have Magisk installed, but you don't necessarily have to install this as a Magisk module.
Don't flash the .zip file from TWRP, it doesn't do anything (at least not for me). Just unzip everything in the .zip file into a folder. Then, take the files inside the xbin folder and put it into /system/xbin (as per instructions). Make sure those files have execute permissions. I just set the xbin folder with full execute permissions and apply to all child files in the folder, by using Root Explorer.
Next, do the same thing by taking the script and chuck that into /data/adb/post-fs-data.d. Again, give this script full execute permissions.
Reboot phone and voila, it should work! You should also see that the script is loaded and running in Magisk logs.
Oh and the reason why Magisk is required is because Magisk creates that "post-fs-data.d" folder after it is installed. If you put scripts into /data/adb/service.d or /data/adb/post-fs-data.d, they will automatically get executed by Magisk and run with superuser rights.
Click to expand...
Click to collapse
Hello, I did everything as you said and it worked normally, but now SELinux is turned off. This is normal?
i have same issue. But i cant find xbin folder
my device is Samsung M51 on custom os
I converted this twrp zip into a magisk module https://github.com/phhusson/treble_experimentations/files/8948418/ntfs-exfat-support.zip
Hi.
I'm using Ancient OS A13 and I can't access my SD Card.It asks for format and after formatting it still asks for format.
it still works on my pc and twrp recovery. Unfortunately, this fix isn't working. Also, there is not any xbin folder in system.
What should I Do?