Install Uruk 0.3 on second internal flash disk of Archos
UPDATE
At the last end of this guide you will find the steps necessary to upgrade to Uruk 0.6 from Uruk 0.3 or 0.4.
Near the end of this guide you will find the steps necessary to upgrade to Uruk 0.4.2 from Uruk 0.3 or to install it for the first time.
Please note.
If you are upgrading from Uruck 0.3 to 0.4.2 and installed google market hack before upgrade, after upgrade the market will be broken. To solve the problem reed the last step of this guide.
I've manage to boot from the second partition of the second internal flash of 8GB (/dev/block/mmcblk1p2) of my Archos 70IT Urukdroid vers 03 prepared by $aur0n on this post.
Thanks $aur0n for your awesome work.
It may work for other archos generation 8 too, except Archos 70 IT 250GB (i think that model doesn't have a second internal flash disk to boot from for SDE, but the owners can do it creating the 2 needed partitions on the HDD).
I've done it because:
- my micro sdcard is slow compared to internal flash
- i can mount correctly micro sdcard and second internal flash disc in Windows and linux by connecting Archos via USB and
- my sdcard is free. I can boot without sdcard in, take off from archos every time i want and upload files from a card reader or connecting the archos 70 via usb.
If you want to try it, be sure on what you are doing (linux knowledge is needed).
Try it on your own risk.
I don't have any responsibility if you brick your device (actually is hard to brick it following the guide, but pay attention please).
So if you are sure, read carefully this post and ask before if something is not clear enough for you.
I will try to answer as soon as possible (I'm actually a bit busy :-()
First of all install SDE, if you haven't already done (you can get information about it and download the SDE firmware from archos web page archos web page
Attention: Doing that You void your warranty...
Here the Archos notes:
Important notices to be acknowledged before downloading and installing the SDE firmware:
Once the SDE firmware is installed on a device, this device will be watermarked and ARCHOS will be able to detect that this firmware has been installed once.
Installing the SDE firmware is considered by ARCHOS as a voiding of the warranty and ARCHOS declines all liability and responsibility for any issues resulting from the installation of this SDE firmware.
ARCHOS strongly advises that only experts in embedded software development should install this firmware.
This firmware is provided "as is" and is not supported by ARCHOS.
Before following the steps required to install Uruk 0.3 some clarifications:
What you need to have:
- Archos 70 IT with terminal and SDE installed.
- Linux machine (nativly, visualized or LiveCD)
- Optionally Windows PC
Storage map of Archos 70 IT:
a) The first internal flash disk is of approximately 500MB (device /dev/block/mmcblk0) which is used by stock archos firmware and not changed by this guide.
Pay great attention playing with it, you may brick forever your Archos.
This flash disk have 4 partition and the block devices, mountpoints, filesystems type and size are as the following:
The first devices is "/dev/block/mmcblk0p1", mountpoint "/mnt/rawfs", type of filesystem "rawfs", size 32MB
The second devices is "/dev/block/mmcblk0p2", mountpoint "/mnt/system", type of filesystem "ext3", size 119MB
The third devices is "/dev/block/mmcblk0p3", mountpoint "/cache", type of filesystem "ext3", size 30MB
The fourth devices is "/dev/block/mmcblk0p4", mountpoint "/data" (mountpoint only by archos firmware), type of filesystem "ext3", size 300MB
b) The second internal flash disk is of approximately 7,5GB (device /dev/block/mmcblk1) which is used by this guide to boot SDE from and to accommodate the /data mountpoint (not any more on the "/dev/block/mmcblk0p4").
By stock archos firmware it has 1 partition (device /dev/block/mmcblk1p1), mountpoint "/mnt/storage", type of filesystem "fat32", size 7,5GB
After Uruk 0.3 installation it will have 3 partitions and the block devices, mountpoints, filesystems type and size will be as the following:
The first devices will be "/dev/block/mmcblk1p1", mountpoint "/mnt/storage", type of filesystem "fat32", size 5,5GB
The second devices will be "/dev/block/mmcblk1p2", mountpoint root "/", type of filesystem "ext4", size 500MB
The third devices will be "/dev/block/mmcblk1p3", mountpoint "/data", type of filesystem "ext4", size 1GB
C) The sdcard on device /dev/block/mmcblk2. On my case it have 1 partition (device /dev/block/mmcblk2p1), mountpoint "/mnt/storage/sdcard", type of filesystem "fat32".
Let's go:
The first step to do is to backup everything from your second internal flash disk (as above, it has 1 partition formated in fat32, 7,5GB capacity), just for backup purpose.
The simplest way is to connect your archos via usb to your linux box and copy directly that directory to a new directory on your linux with the default graphical file explorer of your distribution.
In my case it mounts automatically to /media/A70S (device is /dev/sdb1):
/dev/sdb1 on /media/A70S type vfat (rw,nosuid,nodev,uhelper=hal,uid=1000,utf8,shortname=mixed,flush)
Click to expand...
Click to collapse
If doesn't mount automatically in your case, find it using "dmesg" command on a terminal after connection complete and mount it manually.
Or you can copy it on your Windows PC (connect Archos via usb, drive mount automatically to A70S).
After backup, don't disconnect your Archos from linux. You have to resize the mounted Archos disk form 7,5GB to 5,5GB.
The easiest way is to do it graphically with your distribution partition manager utility.
First umount it by right click->umount, then resize it letting on the right side of the disk 1,5GB free space.
Create other 2 partition on that free space, first of 500MB and the other with the remaining space approx. 960MB.
Then apply the changes on the partition manager and you will have now 3 partition on the second internal flash disk of your Archos.
The first one with 5,5GB and formated on fat32, the second one 500MB not formated and the third partition of 960MB not formated.
On my case the devices are respectively /dev/sdb1, /dev/sdb2 and /dev/sdb3.
The next step is to format the second and third partition with ext4 filesystems without huge option (as from $aur0n post) on a linux terminal as root:
mkfs.ext4 -O ^huge_file /dev/sdb2
mkfs.ext4 -O ^huge_file /dev/sdb3
Click to expand...
Click to collapse
When finished, just remove safely archos from your linux box.
From the archos open a terminal and just type:
ls /dev/block/mmcblk1*
Click to expand...
Click to collapse
The result will be:
/dev/block/mmcblk1 /dev/block/mmcblk1p1 /dev/block/mmcblk1p2 /dev/block/mmcblk1p3
Click to expand...
Click to collapse
The second partition (/dev/block/mmcblk1p2) will be your new rootfs
and the third one (/dev/block/mmcblk1p3) your new application area (/data).
On this step you are going to copy all the staff on /data (device /dev/block/mmcblk0p4 mounted on /data)
to the third partition of the second internal flash (/dev/block/mmcblk1p3).
Mount the third partition first:
mkdir /tmp/data
mount /dev/block/mmcblk1p3 /tmp/data
Click to expand...
Click to collapse
and copy:
cp -rp /data/* /tmp/data
sync
umount /tmp/data
Click to expand...
Click to collapse
If you get any problems on coping (permissions) then the only way to do it correctly is to use "tar" to make a archive of data to a file on the first partition of the second internal flash disk (/dev/block/mmcblk1p1 mounted on /mnt/storage) like:
tar -cfvz /mnt/storage/data_app.tar.gz /data/
Click to expand...
Click to collapse
and then connect archos via usb to your linux computer (your three partition of the internal flash now will mount in automatic, let say /media/A70S, /media/disk1 and /media/disk2 from the devices /dev/sdb1, /dev/sdb2 and /dev/sdb3)
Now you have to extract the previous tar file (data_app.tar.gz) to the /media/disk2 (the third partition of archos internal flash disk mounted supposedly at /media/disk2):
cd /media/disk2
tar -zvxf /media/disk1/data_app.tar.gz
sync
umount /media/disk2
Click to expand...
Click to collapse
The next step, download the Uruk 0.3 version of rootfs (rootfs.tar.gz) from this link, and kernel image (zImage) from from this link on the /tmp directory of your linux box. I want to remember that this files are prepared and postet from $aur0n on this post.
If you are still connected via usb with your archos (if not, connect it),extract the rootfs (rootfs.tar.gz) directly on the mount point of the second flash partition (as above in my case is /dev/sdb2 mounted on /media/disk1) on linux:
cd /media/disk1
tar -zvxf /tmp/rootfs.tar.gz
Click to expand...
Click to collapse
Change the following lines of the init.rc file (mount point of root filesystem):
mount ext3 /dev/block/mmcblk0p4 /data noatime nosuid
# Uncomment this
# mount ext4 /dev/block/mmcblk2p2 /data noatime
with those:
#mount ext3 /dev/block/mmcblk0p4 /data noatime nosuid
# Uncomment this
mount ext4 /dev/block/mmcblk1p3 /data noatime
Change the line on the file/media/disk1/syste/etc/vold.fsatb:
#dev_mount_lun volume_sdcard /mnt/storage/sdcard 3 /devices/platform/usb_mass_storage/lun1 /class/block/mmcblk2p3
with that:
dev_mount_lun volume_sdcard /mnt/storage/sdcard auto /devices/platform/usb_mass_storage/lun1 /class/block/mmcblk2
sync
umount /media/disk1
Click to expand...
Click to collapse
and remove safely archos from the linux box and shutdown Archos.
Download the initramfs.cpio.gz_Uruk_0.3.zip from here (or from the attachment on the end of this post) and unzip it on the /tmp folder of you linux box.
Flash the initramfs.cpio.gz and zImage (remember , you downloaded zImage on the step 4 and placed it already on /tmp) on SDE environment doing:
- While power on your archos, press the "Volume -" button
- Go to "Recovery System",then "Developer Edition Menu"
- Select "Flash kernel and Initramfs".
- Attach your Archos via USB to linux computer. Archos will automatically mount, in my case is A70S_REC mounted on /media/A70S_REC/. Copy the files (initramfs.cpio.gz and zImage) from /tmp folder.
cp initramfs.cpio.gz zImage /media/A70S_REC/
Click to expand...
Click to collapse
Disconnect safely archos, then push "Ok", power and the archos will reboot.
- Press the "Volume -" to boot to the ""Boot Menu" and choose "Developer Edition" or just while booting press both "Volume -" and "Volume +" to boot directly to the "Developer Edition".
You are done.
Enjoy booting from internal flash (SDE edition).
Update: Uruk 0.4.2
There are 2 possibilities:
- You want to upgrade from Uruk 0.3
- Install Uruk 0.4.2 for the first time (You are on stock archos firmware).
Let's begin with the upgrade from Uruk 0.3 to Uruk 0.4.2
First of all download the Uruk 0.4.2 rootfs prepared from $aur0n UrukDroid-0.4.2-rootfs.rar on your linux box.
Download also UrukDroid-0.4.2-kernel.rar from here (or from the attachment on the end of this guide).
It's is $aur0n's one with the modifications to boot and mount /data from second internal flash.
Copy the above 2 files on the folder /tmp/archos of your linux machine. In my case is the 2 downloaded files are
under /home/shklifo/Download folder:
mkdir /tmp/archos
cd /tmp/archos
cp /home/shklifo/Download/UrukDroid-0.4.2-kernel.rar /home/shklifo/Download/UrukDroid-0.4.2-rootfs.rar .
Click to expand...
Click to collapse
Unrar both of them (if you don't have rar utility, just install it), giving the command:
rar x UrukDroid-0.4.2-kernel.rar
rar x UrukDroid-0.4.2-rootfs.rar
Click to expand...
Click to collapse
When the unrar process goes ok you will see the following on terminal (example of UrukDroid-0.4.2-kernel.rar):
[email protected]:/tmp/archos# rar x UrukDroid-0.4.2-kernel.rar
RAR 3.90 beta 2 Copyright (c) 1993-2009 Alexander Roshal 3 Jun 2009
Shareware version Type RAR -? for help
Extracting from UrukDroid-0.4.2-kernel.rar
Extracting zImage OK
Extracting initramfs.cpio.gz OK
All OK
Click to expand...
Click to collapse
After that you will have the following files on /tmp/archos:
[email protected]:/tmp/archos# ls -lrt
totale 245668
-rw-r--r-- 1 root root 0 2011-01-17 12:10 UrukDroid-copy_data.cmd
-rw-r--r-- 1 root root 120854073 2011-01-21 17:34 UrukDroid-rootfs-upgrade.tgz
-rwxr-xr-x 1 root root 2255648 2011-01-21 17:57 zImage
-rw-r--r-- 1 root root 1733826 2011-01-22 10:26 initramfs.cpio.gz
-rw-r--r-- 1 root root 119128315 2011-01-22 10:26 UrukDroid-0.4.2-rootfs.rar
-rw-r--r-- 1 root root 3985013 2011-01-22 10:36 UrukDroid-0.4.2-kernel.rar
Click to expand...
Click to collapse
You are upgrading and you have all the applications on second internal flash disk already, so just remove the UrukDroid-copy_data.cmd, you don't need it:
rm UrukDroid-copy_data.cmd
Click to expand...
Click to collapse
Now you have to copy UrukDroid-rootfs-upgrade.tgz to the rootfs of the archos (second partition of the second internal flash disk mounted on / of type ext4 with 500MB space).
To do that just connect archos via usb to your linux box and all the tree partition of archos second internal flash will be mounted automatically.
To verify where those partition are mounted just type:
mount
Click to expand...
Click to collapse
on a linux terminal and on my case is as following:
[email protected]:/tmp/archos# mount
...
/dev/sdb1 on /media/A70S type vfat (rw,nosuid,nodev,uhelper=hal,uid=1000,utf8,shortname=mixed,flush)
/dev/sdb2 on /media/disk type ext4 (rw,nosuid,nodev,uhelper=hal)
/dev/sdb3 on /media/disk-1 type ext4 (rw,nosuid,nodev,uhelper=hal)
/dev/sdc1 on /media/disk-2 type vfat (rw,nosuid,nodev,uhelper=hal,uid=1000,utf8,shortname=mixed,flush)
Click to expand...
Click to collapse
and "df -m" like:
[email protected]:/tmp/archos# df -m
/dev/sdb1 5622 2897 2725 52% /media/A70S
/dev/sdb2 485 244 216 53% /media/disk
/dev/sdb3 973 268 656 29% /media/disk-1
/dev/sdc1 15266 1157 14110 8% /media/disk-2
Click to expand...
Click to collapse
So in my case the second partition of the second internal archos flash disk of 485MB is:
/dev/sdb2 485 244 216 53% /media/disk
Click to expand...
Click to collapse
mounted on /media/disk
Then just copy the UrukDroid-rootfs-upgrade.tgz file on the second partition of the second internal archos flash disk, like in my case:
cp /tmp/archos/UrukDroid-rootfs-upgrade.tgz /media/disk/
Click to expand...
Click to collapse
Safely disconect archos from the linux box and shutdown completely your archos.
Now you have to flash initramfs (initramfs.cpio.gz) and kernel (zImage) to your archos from "Recovery Menu" (you know already how to do it),
or if you forget it just do the following:
- While power on your archos, press the "Volume -" button
- Go to "Recovery System",then "Developer Edition Menu"
- Select "Flash kernel and Initramfs".
- Attach your Archos via USB to linux computer. Archos will automatically mount, in my case is A70S_REC mounted on /media/A70S_REC/. Copy the files (initramfs.cpio.gz and zImage) from /tmp/archos folder.
cp initramfs.cpio.gz zImage /media/A70S_REC/
Click to expand...
Click to collapse
Disconnect safely archos, then push "Ok", power and the archos will reboot.
- Press the "Volume -" to boot to the ""Boot Menu" and choose "Developer Edition" or just while booting press both "Volume -" and "Volume +" to boot directly to the "Developer Edition".
You will see the UruckDroid 0.4 screen with "Initramfs: Loading ...." than Rootfs: Loading .... and finally you will see the Uruck Desktop.
Enjoy
Install Uruk 0.4.2 for the first time
For those who whant to install Uruk 0.4.2 for the first time (now it's simplier that Uruk 0.3) will do:
a) First backup, create the partitions and filesystems on the second internal flash disk of archos (step 1
and step 2 of the Uruk 0.3).
You don't need anymore step 3 (copy of /data folder), because Uruk 0.4.2 do it automatically.
b) Then following step by step the guide Let begin with the upgrade from Uruk 0.3 to Uruk 0.4.2, except removing UrukDroid-copy_data.cmd file, because you need it to copy automatically /data files.
When you are on the step "copy the UrukDroid-rootfs-upgrade.tgz file on the second partition of the second internal archos flash disk", you need to copy additionaly UrukDroid-copy_data.cmd like:
cp /tmp/archos/UrukDroid-rootfs-upgrade.tgz /media/disk/
cp /tmp/archos/UrukDroid-copy_data.cmd /media/disk/
Click to expand...
Click to collapse
Than follow till the end the guide Let begin with the upgrade from Uruk 0.3 to Uruk 0.4.2.
Enjoy
OPTIONAL: Install google market.
If you have already istalled google market (using gAppsInstaller for example), you have to uninstall it (market/vending) first.
Then download UrukDroid-0.4.2-GoogleMarket.zip and copy it on the root (/) filesystem of archos (see above on the upgrade section an do the same steps of copying UrukDroid-rootfs-upgrade.tgz to archos rootfs).
Reboot archos.
NOTE
If you are upgrading from 0.3 version to 0.4.2 and installed before the google market from kenyu73 like i did, then the market will be broken and doesn't work any more.
To get it back, you have to remove all the google applications from SDE (Uruk 0.4.2) including the kenyu73's installer (gAppsInstaller).
Then install the market as on the previuos step OPTIONAL: Install google market downloading the file UrukDroid-0.4.2-GoogleMarket.zip and following the instructions.
After rebooting archos on SDE, you need to fix it, because you can't access the whole market (missing some "protected applications" like copilot etc).
To fix just do the following steps as kenyu73 explain on his post :
Go to Settings-->Manage Applications-->All-->Market (Clear Cache then 'Force Stop', DO NOT clear data).
Setting-->Manage Applications-->All-->Google Services Framework (Clear data then 'Force Stop').
Reboot.
Click to expand...
Click to collapse
I've done it twice the fix step, and after that no problem anymore. All the google applications (downloaded from the fresh working market) are working correctly as before.
Update: How to upgrade to Uruk 0.6 from Uruk 0.3 or 0.4.2
There are 2 possibilities:
a) The first one is the simplest one.
Just download the $auron Uruk 0.6 UrukDroid_0.6-EasyInstall.rar posted on this post, extract it on your computer and delete the file initramfs.cpio.gz, because we don't need it.
Then download the file initramfs.cpio_Uruk_0.6.gz.rar in attachment on the end of this post and extract it on the same directory of your computer (this is the initramfs that you will flash on SDE prepared from $auron and can be found on the /root/ directory of $auron new rootfs UrukDroid-install.tgz).
Then boot Archos on stock Android and connect it to your linux box via USB. The root filesystem of Archos (/dev/block/mmcblk1p2 on Archos) will be mounted on some directory on linux automatically, just find it or manually mount it (it's the filesystem with 500MB space, to be sure just type "df -h" on a terminal).
With root on a linux terminal go to that directory (in my case was /media/Disk-1) and remove all the files there:
Code:
rm -rf *
Then copy the UrukDroid-install.tgz extracted before from UrukDroid_0.6-EasyInstall.rar on the above directory.
So, you will have only the file UrukDroid-install.tgz on your rootfs directory of Uruk.
Then disconect safely Archos from your linux box and flash initramfs.cpio.gz and zImage files on SDE (you know how to do that ...) and boot to SDE.
That is
Uruk 0.6 will automatically copy everything needed as you will see on the boot time.
You have to do a last thing to be able to mount automatically the sdcard on Uruk 6. Uncomment the sdcard line on the file /system/etc/vold.fsatb like:
Code:
dev_mount_lun volume_sdcard /mnt/storage/sdcard auto /devices/platform/usb_mass_storage/lun1 /class/block/mmcblk2
This is needed on the second method too (the one below).
Who want to install Uruk (version 0.6 in this case) for the first time on internal, must create and format the 2 partitions of the second internal flash disk (like on the beginning of this post described) and follow step by step the above method and at the end copy everything from the data partiotion (last partition of the first internal flash /dev/block/mmcblk0p4) to the third partition of the second flash disk (/dev/block/mmcblk1p3).
b) The second method is more complicated, but works also good.
You just install Uruk 0.6 to a sdcard like on this $auron post, than shutdown Archos, put the microsd card on a card reader connected to a linux PC and with root make a tar archive of the entire rootfs (root filesystem) of Uruk 0.6 (the second partition of the sdcard with 500MB of space on ext4 filesystem) to a tar file that you can put to the first partition of the sdcard (the fat partition of the sdcard).
Eject the sdcard and put on Archos. Turn on Archos and from a terminal on Uruk as root mount the second partition of the flash disk (/dev/block/mmcblk1p2) on a directory and just delete ("rm -rf") everything on there and then extract the tar archive there.
So, you just put everything from rootfs of the sdcard to internal flash, with correct permissions, timestamp, ownership etc.
Now just shudown Archos, take off the sdcard and boot.
This time it will Uruk 0.6 will boot from internal flash
Enjoy it
I wish I could understand more clearly how to do this with a fresh install...
This is what I am looking to do, using it on internal... but this might be a little too complicated for me.
What about 101?
Does this method applicable to Archos 101 model too?
If someone already have been tried it on 101, please reply with details here, if any troubles you have after installation or any changes need to be done.
Also I am curious about does anyone have tried to connect USB thumb drive to the tablet with modified rom and root access? Do we still have any issues with USB drive recognition?
Is this applicable for UrukDroid 4.1 and The Archos IT 35?
well great work but i dont know if i get it to work and Im a little bit confused -
is it writable in windows per media player (mtp) or per explorer or both (with ext-x driver)?
yura-a said:
Does this method applicable to Archos 101 model too?
If someone already have been tried it on 101, please reply with details here, if any troubles you have after installation or any changes need to be done.
Click to expand...
Click to collapse
Why not. The 101 model have the second internal flash (8 or 16GB) as the 70 S model have. To be sure just type mount and df -m on a terminal in Archos device and you will see the flash drive (/dev/block/mmcblk1p1) formated in fat32 and mounted on /mnt/storage.
I only changed the mounting point on the file init, init.rc and /system/etc/vold.fstab from $aur0n files to be able to boot SDE from the second internal flash disk and doesn't change anything else, configuration file of specific model included.
yura-a said:
Also I am curious about does anyone have tried to connect USB thumb drive to the tablet with modified rom and root access? Do we still have any issues with USB drive recognition?
Click to expand...
Click to collapse
I'm still excpecting my host cable from Hong-Kong and can't try that, but i think will not be a problem.
good work
thanks
svennimann said:
Is this applicable for UrukDroid 4.1 and The Archos IT 35?
Click to expand...
Click to collapse
I do not own your device (it is a Archos 32 IT?), but if is that model, it got a 8GB internal flash like archos 70 IT. The firmware is the same for all archos generation 8 devices (with same configuration files change), but i haven't change them (and $aur0n too i think, but he can answer himself).
So just try it, if you have no problem of understanding all the steps on the first post. You can't break anything. And if it will not work (worse case) or have other problems you just have SDE installed (you can remove it if you want) and 2 more partition on the internal flash disk with some files on them.
You can just delete the partitions and risize (increment) the first partition as from stock. In all situation we are able to boot to stock firmware.
I only change the mountpoints as i wrote in the previous posts on the files init, init.rc and vold.fstab from uruk 0.3.
So mine and $auron solution changed only on the boot partition (mine is booting form the second partition of the internal flash disk, him from the second partition of sdcard) and the application data partition (mine on the third partition of the internal the flash, him on the third partition of the sdcard). All the other files are from him (thanks $aur0n).
I've not installed yet the 0.4.1, i got little free time actually and of the market problem (if i install the 0.4.1, i must uninstall the market on stock firmware and will be not able to access it from original/stock firmware).
But if i decide to install it, i will report here.
svennimann said:
well great work but i dont know if i get it to work and Im a little bit confused -
is it writable in windows per media player (mtp) or per explorer or both (with ext-x driver)?
Click to expand...
Click to collapse
Thanks, as i say above you don't loose anything trying to install it, only time
So, if i understand well your question, on my archos i'm able to access the first partition of the flash disk (it's a fat32 as from stock, only risezed in 5,5 GB) on my windows XP PC by usb connection to archos.
The second (boot partition 500MB) and the third (data application area of 1GB) partitions of internal flash disk are ext4 formated (stock ext3) and can't be mount on a windows PC, and for me have any sense mounting them on a PC.
The sdcard is accesible via usb connection (archos to PC) or via card reader. If you format it fat32 is in r/w mode (as i've done), ext3 or ext4 in readonly mode i think (not yet tried), because actually isn't out a driver to be able to write a linux partition on Windows.
From Ubuntu (connecting archos via usb) i can mount all in r/w mode (all the 3 partitions of the internal flash disk and sdcard too).
Later i will post some picture/command output (mount,ls) from Ubuntu.
In attachment a picture of the flash disk (A70S E: ) and sdcard (Disco rimovibile F: ) on my Windows XP macchine.
{
"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"
}
Just a suggestion.. Please be consistent with your instructions, 1 step your instructions are for linux and the next step would be for archos.
It's really hard to follow what needs to be done or how it should be done properly, considering you're messing around with the internal storage there's bigger chance of bricking your device.
I appreciate all your hard work and contributions here, it's just that it's not that user friendly.
GrandStar said:
Just a suggestion.. Please be consistent with your instructions, 1 step your instructions are for linux and the next step would be for archos.
Click to expand...
Click to collapse
Just to be clear, from archos terminal you have to do only 1 thing, copy or tar the "/data" mountpoint/directory, because this is the 4-th partition of the first internal flash disk (/dev/block/mmcblk0p4) and it can't be mounted on linux via usb connection.
All the other steps are from linux (the first step, you can do it from Windows too).
It's really hard to follow what needs to be done or how it should be done properly, considering you're messing around with the internal storage there's bigger chance of bricking your device.
Click to expand...
Click to collapse
There are 2 internal flash disk in Archos, /dev/block/mmcblk0 of 500MB (used by archos architecture and nobody is touching this flash disk, it's dangerous and you may brick your device) and /dev/block/mmcblk1 of 8GB which is used by the this guide to boot SDE from. So, if you are able to understand what you are doing and don't touch the first flash disk, than nothing can happens.
I appreciate all your hard work and contributions here, it's just that it's not that user friendly.
Click to expand...
Click to collapse
With that i'm in line with your thoughs, thanks. I will try to do it more simple and understandable.
I've followed all the instructions exactly. I'm good with linux, so it wasn't very hard, but when I booted into the Developer Edition at the end, I was at the Initial Setup Screen, like it didn't mount the /data partition. Also, I can't get ES to show the file system, so it doesn't seem to be rooted. Any ideas what's going on?
EDIT: You have a typo in the init.rc the change should be to mmcblk1p3, not mmcblk1p2.
EDIT: Another typo: "dev_mount_lun volume_sdcard /mnt/storage/sdcard auto /devices/platform/usb_mass_storage/lun1 /class/block/mmcblk1" should be mmcblk2, not 1.
Now my data is there, and I can mount SD cards, but I still can't connect to a computer with a USB cable.
EDIT: All Fixed. I flashed a new kernel from http://forum.xda-developers.com/showthread.php?t=897877 and now have USB Storage working. I used the zImage from ardatdat's kernel with your initramfs.cpio.gz and the changes I listed above. Everything seems to work perfectly, and it's way faster than it was before. I was using Ardatdat's full kernel and booting from internal memory before. When I rotated the screen it used to take almost 10 seconds to update all the icons on the home screen. Now it takes less than 2-3 seconds to update. Great work on the EXT4 conversion! If you'll permit me, I'm going to write up a guide that incorporates my experience, and of course give you full credit.
Update: Just updated to UrukDroid 0.4.1. Needed a little more customization, but usb storage worked with the default 0.4.1 kernel instead of needing ardatdat's kernel. Currently testing to see which is better. Uruk says it's kernel has usb charging enabled, a very exciting possibility, but I kind of doubt it works on the A101IT.
msticninja said:
EDIT: You have a typo in the init.rc the change should be to mmcblk1p3, not mmcblk1p2.
EDIT: Another typo: "dev_mount_lun volume_sdcard /mnt/storage/sdcard auto /devices/platform/usb_mass_storage/lun1 /class/block/mmcblk1" should be mmcblk2, not 1.
Now my data is there, and I can mount SD cards, but I still can't connect to a computer with a USB cable.
EDIT: All Fixed. I flashed a new kernel from http://forum.xda-developers.com/showthread.php?t=897877 and now have USB Storage working. I used the zImage from ardatdat's kernel with your initramfs.cpio.gz and the changes I listed above. Everything seems to work perfectly, and it's way faster than it was before. I was using Ardatdat's full kernel and booting from internal memory before. When I rotated the screen it used to take almost 10 seconds to update all the icons on the home screen. Now it takes less than 2-3 seconds to update. Great work on the EXT4 conversion! If you'll permit me, I'm going to write up a guide that incorporates my experience, and of course give you full credit.
Update: Just updated to UrukDroid 0.4.1. Needed a little more customization, but usb storage worked with the default 0.4.1 kernel instead of needing ardatdat's kernel. Currently testing to see which is better. Uruk says it's kernel has usb charging enabled, a very exciting possibility, but I kind of doubt it works on the A101IT.
Click to expand...
Click to collapse
Thanks for the corrections (you pay the needed attention), but i just modified the first post radically (easier).
Sure, you can do your own thread with your experience on the installation.
I will install Uruk 0.4.1 too, and update the first post.
WORKING
I had to add a new line into the init.rc file, but afterwards I was able to get Uruk 0.4.1 to boot internal
***mount ext4 /dev/block/mmcblk1p2 / noatime*** - I don't htink you have this in your steps...
After I did this, it works. I also am able to see both the internal and external storage in windows.
I didn't know if you need that line or it was left out of your steps process. All I did to get this to work on an existing 0.4.1 was:
1. Move the data off the internal inside windows to a saved directory on my PC.
2. Partition the 3 partitions like you describe on the internal and formated as you describe...
3. Mount the partitions inside my VMplayer Ubuntu sdb2, sdb3, sdc2, and sdc3 (sdb was the internal formated like you describe and sdc was my 16 0.4.1 SD card fromatted using uruk already)
Su terminal CODE:
$su
***password
#
#cd
#cd /tmp
#mkdir sdb2
#mkdir sdb3
#mkdir sdc2
#mkdir sdc3
#mount /dev/sdb2 /tmp/sdb2
#mount /dev/sdb2 /tmp/sdb3
#mount /dev/sdb2 /tmp/sdc2
#mount /dev/sdb2 /tmp/sdc3
4. Copy through terminal everything from sdc2 --> sdb2 using below code and Copy through terminal everything from sdc3 --> sdb3 using below code
**CODE I used:
#cp -rp /tmp/sdc2/* /tmp/sdb2
#sync
#cp -rp /tmp/sdc3/* /tmp/sdb3
#sync
6. Add in the lines inti init.rc to mount the sdb2, and the sdb3 instead of sdc2 and sdc3
mount ext4 /dev/block/mmcblk1p2 / noatime
mount ext4 /dev/block/mmcblk1p3 /data noatime
7. Add the line into tmp/sdb2/system/etc/vold.fsatb (Which is where I mounted that..)
dev_mount_lun volume_sdcard /mnt/storage/sdcard auto /devices/platform/usb_mass_storage/lun1 /class/block/mmcblk2
**I believe in 0.4.1 it is already like this, so i really made no changes to vold.fsatb....***
Unmounted all 4 I had mounted into /tmp using terminal ubuntu
CODE (I was already inside cd /tmp/sdb2 and i had edited the init.rc and saved it):
#sync
#cd..
#umount /tmp/sdb2
#umount /tmp/sdb3
#umount /tmp/sdc2
#umount /tmp/sdc3
EDIT: after this step, you will need to mount the Archos back into Windows, and copy the files you saved into a folder on your windows PC back into the Internal Fat32 storage. This was why you backed it up in the first place.... You might have to reboot and boot into your stock OS to get the internal to mount back into Windows, i did...
Reboot and go into the developer menu
Reflashed your initramfs and Uruk 0.4.1 Zimage and booted to developers edition...
***Remember this will only work if you have a preexisting 0.4.1 on an SD card where it is formatted with #1 fat32 for dtorage #2 500Mb and #3 1G and it already has been working using $auron's method.
BIG thanks to $aron and shklifo and msticninja... I am very happy using my internal memory to boot with instead of the SD card. i will prob keep the SD card I have and use it whenever I need to boot to SD and just get a different one for Videos and Music.
JW
sublimejosh2000 said:
I had to add a new line into the init.rc file, but afterwards I was able to get Uruk 0.4.1 to boot internal
***mount ext4 /dev/block/mmcblk1p2 / noatime*** - I don't htink you have this in your steps...
After I did this, it works. I also am able to see both the internal and external storage in windows.
I didn't know if you need that line or it was left out of your steps process.
JW
Click to expand...
Click to collapse
I really appreciate your feedback.
But you don't need to add the line:
Code:
mount ext4 /dev/block/mmcblk1p2 / noatime
on the file init.rc, because it is present on the init file included on initramfs.cpio.gz.
If you extract the initramfs.cpio.gz attached on my first post with this command on a shell:
Code:
gunzip initramfs.cpio.gz && cpio -i -d -H newc -F initramfs.cpio --no-absolute-filename
You will find the following line:
Code:
$MOUNT -t ext4 -o noatime,errors=continue /dev/mmcblk1p2 /new-root
To upgrade to $aur0n 0.4.2 now it's really simple.
I'm preparing the new initramfs.cpio.gz. And putting the new rootfs of 0.4.2 on the rootfs of our archos (just to remember it is on the second partition of the second internal disk on device /dev/block/mmcblk1p2 mountet on /) and flashing the new initramfs.cpio.gz and zimage, when booting up on "Developer Edition" it will upgrade automatically.
Is there a reason why we want to be on 0.4.2?
I am not having problems with Market, is there other benifits of this update?
JW
BTW: Thanks for this halp on getting to internal.. I am not sure why we wanted to not do this in the first place.. I guess because some SD cards are faster, mine is working pretty fast and I think the internal is at least class 6
sublimejosh2000 said:
Is there a reason why we want to be on 0.4.2?
I am not having problems with Market, is there other benifits of this update?
JW
BTW: Thanks for this halp on getting to internal.. I am not sure why we wanted to not do this in the first place.. I guess because some SD cards are faster, mine is working pretty fast and I think the internal is at least class 6
Click to expand...
Click to collapse
Just see on the $aur0n post about the new version log change. We will have upgraded module, new wifi, more services like samba sshd etc.
I to havn't any speed problem with internal flash. It is fast enough (with dd copying speed test got till 16 mbit/s write speed) on the internal flash and it is way faster than my sdcard class 4.
0.4.2
Well.. I already reverted back to the origional wifi config file using terminal, and my Market is good to go.
I'm not sure that there are any major differences between 0.4.1 --> 0.4.2
If I am wrong, i think it requires to uninstall all google apps to make that upgrade, which I don't think I need to do.
Am I wrong?
sublimejosh2000 said:
Well.. I already reverted back to the origional wifi config file using terminal, and my Market is good to go.
I'm not sure that there are any major differences between 0.4.1 --> 0.4.2
If I am wrong, i think it requires to uninstall all google apps to make that upgrade, which I don't think I need to do.
Am I wrong?
Click to expand...
Click to collapse
From $auron post on Uruk doesn't seem to be difference between 0.4.1 and 0.4.2, except google applications. With the 0.4.2 you can install the google staff separatly with UrukDroid-0.4.2-GoogleMarket.rar. If you have those apps allready on your 0.4.1 than nothing change, you don't need to upgrade.
Thanks and no problem with your methods.
My 16GB microSD card isn't very good and boot / use of archos 101 is very slow with Uruk0.4.2 installed on external SD.
Now it's fast installed on internal SD...
Maybe this help:
if can't mount ext4 partition on your linux box, you can do:
tune2fs -E test_fs /dev/sdbx (sdb2 for instance)
and then:
mount -t ext4dev /dev/sdbx /mnt/sdcard
trouble with fresh install for 0.4.2 $auron....
I was able to create 3 partition internally (sdb1(vfat), sdb2(ext4), sdb3(ext4))
I was able to move rootfs and cmd script to sdb2
I was able to flash initramfs and zImage
But I'm stuck when rebooting into SDE (the screen is all messed up)
Any suggestion?
I didn't modify init.rc and vold.stab since this is a fresh install
yura-a said:
Does this method applicable to Archos 101 model too?
If someone already have been tried it on 101, please reply with details here, if any troubles you have after installation or any changes need to be done.
Also I am curious about does anyone have tried to connect USB thumb drive to the tablet with modified rom and root access? Do we still have any issues with USB drive recognition?
Click to expand...
Click to collapse
Yes this procedure works the same way on the A101. I have the 16GB version so I made the 1st partition a bit bigger but that was the only deviation.
Related
I have managed to natively boot Urokdroid's OS in my Archos-70 device. This means that I don't need to go to the boot loader menu and select Developer to boot into my SD card which contains my Android OS. Upon power-up or reboot without pressing the volume -, I can have rooted Android OS.
First and foremost I'd like to give credits to where credits are due. I'd like to thank $aur0n for his excellent work on allowing us to boot our Archos device to external SD card. This has paved the way for many enhancements that we have now, and soon to come. I'd also like to give thanks to apr24991 for discovering a way to always boot in Developer mode. This has given me a chance to tweak my OS and allow Urokdroid's kernel to boot natively. And for all those generous people here who have willingly share their knowledge in this forum, I appreciate all your work. Now it's time for me to share what I've learned.
I'm no expert of Linux or Android. This was just based on my experience and there may be better ways to do this. Having said that, I just want to lay out some precautions.
Be prepare to lose data. So as preparation, please back-up your data.
Don't blame me if you brick your device. I would say that instructions here are easy enough for those knowledgeable in linux. However there may be few cases that you don't get the expected results. In any case, you can still restore your original Android OS by going to recovery menu and applying the stock 2.0.71 firmware from Archos.
This works on my A70, and I cannot guarantee that it will also work on A101 and other Gen8 devices. I'm suspecting it will.
After applying this successfully, you will lose the capability to dual boot. Meaning you will only be able to boot in SDE mode with rooted Android. Again you can still restore the stock firmware in the recovery menu.
Pre-requisites
Please download the SDE firmware from here. You can also download the stock 2.0.71 firmware in case you want to recover your original OS.
You should have already installed Urokdroid's kernel & this is properly working on your Archos device. In other words, you are already running Android on external SD card. $aur0n has setup a comprehensive guide here. The guide here is based on 0.3 version of Urokdroid's kernel.
Steps
Warning. On this step, you will lose all data in your device but excluding contents of external SD card. Please backup important data before continuing. Apply SDE into your Archos following phase 1 of apr24991's post here. This method will actually erase your stock Android firmware and only the SDE (AngStrom) will be present. So whenever you power on or reboot,
it will always boot AngStrom.
Now the trick now is to modify the kernel & initramfs of SDE so it will boot into external SD which contains your Android OS.
Insert your external SD card into your device.
Go to recovery menu. Press volume - while powering on.
Chose Developer Menu from the Recovery Menu.
Select flash kernel & initramfs.
Attach the device to your PC via USB. Your device will now appear as mass storage device in your PC. Copy 0.3 zImage from Urokdroid's, and the modified initramfs.cpio.gz, attached in this post (Extact it from the zip file first). This is the same initramfs.cpio.gz as Urokdroid's except I've modified /init to disable the checking of squasfs file in mmcblk0p2.
Safely unmount your device from your PC. Afterwards, select ok in your device. This would apply the copied zImage and initramfs.cpio.gz. And then it will prompt you that it will boot the device. Press power
button to reboot.
If everything is ok, you will now always be booted into Urokdroid's Android OS, rooted, and able to do other things. If you wish to restore stock firmware from Archos, just go to recovery menu and apply the firmware version you want. You may follow phase 2 of apr24991's post
here and just use your desired firmware version (2.0.54 or 2.0.71).
So far my setup is stable.
Optional: If you look at /data.old (mmcblk0p4), there is no longer data there. You have additional 300MB of partition where you can setup swap space.
Why?
You can remove the Android (Original Archos Android - not the SD-One!) in the Developer Menu in the Recovery - so no need to flash a special modified initramfs?!
Or am I missing something?
As I've mentioned, I'm no expert on Linux or Android. I've just laid out what I did. I did a lot of trial and error. If I did not flash a modified initramfs it will always boot AngStrom. What I want is to always boot on rooted Android in SD. The only thing I modified from Uruk's initramfs is to bypass the checking of squash file in /dev/mmcblk0p1. Since we reformat the device, the squash file in /dev/mmcblk0p1 has been erased. The only way to bring it back is either copy from backup or reapply the stock firmware.
I have also managed to boot a rooted Android using the built-in mmcblk0p2, mmcblk0p4 block devices. When I got to AngStrom, I just copied a backup of squash file to mmcblk0p2, and backup of data to mmcblk0p4, and then flash the kernel & initramfs from this thread. My only problem here is I'm limited to 300MB for apps.
There may be more efficient ways to do this, and if you have suggestions that will achieve the same results I'll be happy to include them in this guide.
I think I did it in a different order but it still worked.
1- SDE
2- New kernel
3- Remove "Andriod" from recovery
I liked this way since I knew the new kernel booted before I erased Archos's.
xnatex21 said:
I think I did it in a different order but it still worked.
1- SDE
2- New kernel
3- Remove "Andriod" from recovery
I liked this way since I knew the new kernel booted before I erased Archos's.
Click to expand...
Click to collapse
That works for sure and is the simplest way I know of.
A possible dangerous, scary way?
Thinking out loud here... but
the archos/sde bootloader is mounted by Uruk in /mnt/rawfs (currently the permissions seem to prevent write access)
rawfs contains, among other things, a file called 'custom' (which is a copy of the zImage and initramfs.cpio.gz flashed under developer edition menu and packaged together) and 'avboot', which looks to be the archos kernel/loader.
Does anyone else think it might be possible to rename custom->avboot and avboot->custom to swap both the behavior of the bootmenu and default boot around? Rooted android booting by default, stock android boots when developer edition is selected?
Ok so is there a way now that we can move the sdcard android files over to the system as a re-write-able system?
sent from epic 4g
There isn't enough space where the stock android is atm (mmcblk0)
I have put Uruk onto the internal storage (mmcblk1) because my sdcard is slow and rubbish.
so how big is the file? cant we just edited and delete some junk apps to make it enough?
I think it's possible to use mmcblk0p4 as storage for root fs. It has 300MB of space. The other partitions are too small. I'm not sure if it's possible to consolidate mmblk0 to 1 partition, but i've managed to convert mmcblk0p4 to ext4.
Update:
I consolidated mmcblk0p2, mmcblk0p3 and mmcblk0p4 into 1 ext4 partition. It's about 450MB. I put the rootfs here and use 2GB of internal storage as /data partition.
Code:
# mount
mount
rootfs on / type rootfs (rw)
/dev/mmcblk0p2 on / type ext4 (rw,noatime,barrier=1,nodelalloc,data=ordered)
/dev/mmcblk1p2 on /data type ext4 (rw,noatime,barrier=1,nodelalloc,data=ordered)
tmpfs on /dev type tmpfs (rw,mode=755)
devpts on /dev/pts type devpts (rw,mode=600)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw,devuid=1000,busuid=1000,listuid=1000)
debugfs on /sys/kernel/debug type debugfs (rw)
tmpfs on /mnt/asec type tmpfs (rw,mode=755,gid=1000)
/dev/block/mmcblk0p1 on /mnt/rawfs type rawfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/block/vold/179:9 on /mnt/storage type vfat (rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fma
sk=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,utf8,errors=remount-ro)
/dev/block/vold/179:9 on /mnt/secure/asec type vfat (rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015
,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,utf8,errors=remount-ro)
tmpfs on /mnt/storage/.android_secure type tmpfs (ro,size=0k,mode=000)
/dev/block/mmcblk2p1 on /mnt/storage/sdcard type vfat (rw,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask
=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,utf8,errors=remount-ro)
fusesmb on /mnt/storage/network/smb type fuse (rw,nosuid,nodev,user_id=0,group_id=0,allow_other,max_read=32768)
djmount on /mnt/storage/network/upnp type fuse (ro,nosuid,nodev,user_id=0,group_id=0,allow_other)
# df -h
df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 448M 313M 112M 74% /
/dev/mmcblk0p2 448M 313M 112M 74% /
/dev/mmcblk1p2 2.0G 268M 1.6G 15% /data
tmpfs 120M 12K 120M 1% /dev
tmpfs 120M 0 120M 0% /mnt/asec
/dev/block/mmcblk0p1 32M 13M 20M 40% /mnt/rawfs
tmpfs 120M 4.0K 120M 1% /dev/shm
/dev/block/vold/179:9
4.6G 464M 4.1G 11% /mnt/storage
/dev/block/vold/179:9
4.6G 464M 4.1G 11% /mnt/secure/asec
/dev/block/mmcblk2p1 1.4G 4.0K 1.4G 1% /mnt/storage/sdcard
fusesmb 448M 313M 112M 74% /mnt/storage/network/smb
#
As a newer Archos buyer, I'm very happy about this info. I'd like to get some additional info tho. Firstly, you consolidated mmcblk0p2, mmcblk0p3, and mmcblk0p4 into a 400MB part for the rootfs. Were you unable to consolidate mmcblk0p1 in as well?
Secondly, you allocated 2GB of internal storage for /data, but what do you use this for? Also, this leaves you about 5GB of internal storage (as the internal storage shows approx. 7GB on my stock 101IT)? And, you're able to utilize your entire SD for storage data, as opposed to booting and keeping your OS here?
Thirdly, do you think, if necessary this could be rolled back to stock? Would a flash back to the stock ROM package restore the original partition table? The only reason I ask this, is that I've been considering selling this in a short while, when the verdict comes in on which tablets will get Gingerbread updates. Also, the pontential performance gains on a Viewsonic GTablet with it's Tegra2 based chipset intrigue me (I hadn't heard of this device when I chose my 101IT), and with it's horsepower, I think it might be a surer bet for Gingerbread love. But, if I sell it, I'd like to give my buyer an option to recieve a ROM'd/rooted or stock device depending on preference.
Lastly, as if I haven't asked enough already ;-) , could you provide detail on how one could replicate your processes? I imagine you'd start with installing SDE on your storage card to have root access to the mmcblk0 devices and install the new kernel to the consolidated mmcblk0 partition? Are there any other steps that one would need follow?
If you've read this far, thanks much for your patience and assistance!
As a newer Archos buyer, I'm very happy about this info. I'd like to get some additional info tho. Firstly, you consolidated mmcblk0p2, mmcblk0p3, and mmcblk0p4 into a 400MB part for the rootfs. Were you unable to consolidate mmcblk0p1 in as well?
Click to expand...
Click to collapse
I didn't try to include mmcblk0p1 since the boot process is still accessing this partition. One access i've seen is the flash image at boot up is taken from this partition. There may be more. So to be safe, i've excluded this partition.
Secondly, you allocated 2GB of internal storage for /data, but what do you use this for? Also, this leaves you about 5GB of internal storage (as the internal storage shows approx. 7GB on my stock 101IT)? And, you're able to utilize your entire SD for storage data, as opposed to booting and keeping your OS here?
Click to expand...
Click to collapse
/data is used to be mounted to mmcblk0p4 which has about 300MB of space. I've transferred this to internal storage with 2GB, which allows me for more apps to be installed. In the internal storage, I've allocated 4.5GB as vfat (/sdcard), 2GB as ext4 (/data), and 500MB as swap.
Thirdly, do you think, if necessary this could be rolled back to stock?
Click to expand...
Click to collapse
You can always go to recovery menu, and reformat the device. This will repartition the internal storage, and install a stock firmware. This, however, will erase all your data in the internal storage.
Lastly, as if I haven't asked enough already ;-) , could you provide detail on how one could replicate your processes?
Click to expand...
Click to collapse
I'll back trace my steps later, and post them here.
Here are the steps I did to use mmcblk0p1 as rootfs and a partition in mmcblk1 (internal storage).
I assume you are already on Urukdroid's kernel running on external SD.
Partitioning Internal Storage
1) I first partitioned the internal storage. To partition without destroying existing data, I used GParted from Ubuntu desktop. Connect Archos to PC running Ubuntu via USB. Mount the USB Mass Storage. A70S will appear as one of drive in Ubuntu.
2) Open GParted and select the device for the Archos internal storage. You will see 1 fat32 partition labeled A70S. Unmount the partition. Upon unmounting, you will be able to resize the partition. In my case, I put 2500 free space after the partition.
3) After resizing, I have 2500MB free space. I created 2 primary unformatted partitions, 2GB (/data), and the last one 500 (swap). After this, apply the changes in GParted.
4) Afterwards, from linux command line I formatted the 2 partitions using the following command:
Code:
mkfs.ext4 -O ^huge_file -L data /dev/sdb2
mkswap /dev/sdb3
5) Unmount USB from Archos.
Partitioning System Storage
6) Use adb shell. Unmount /dev/block/mmcblk0p4, /dev/block/mmcblk0p3, /dev/block/mmcblk0p2, /dev/block/mmcblk0p1. Using fdisk, delete partitions 2, 3, 4 from /dev/block/mmcblk0, then create 1 partition utilizing the rest of the disk space. This will give you about 450MB, that you can use as root.
7) format the partition.
Code:
mkfs.ext4 -O ^huge_file -L root /dev/block/mmcblk0p2
Copying files to the created partition
8) I mount /dev/block/mmcblk0p2 to /tmp/root, /dev/block/mmcblk1p2 to /tmp/data
Code:
mkdir /tmp/root
mkdir /tmp/data
mount -t ext4 /dev/block/mmcblk0p2
mount -t ext4 /dev/block/mmcblk1p2
8) I grabbed Urukdroid's 0.4 rootfs.tgz, and extract them mmcblk0p2.
Code:
cd /tmp/root
tar zxvf /sdcard/rootfs.tgz
9) Since 0.4 already contains Gapps, I've uninstalled Gapps first on my archos.
10) I copied the data files
Code:
cp -a /data/* /tmp/data/.
11) I modified /tmp/root/init.rc and comment out mounting /mnt/system, /cache & /data. I've attached my modified init.rc.
12) Unmount /tmp/data, and /tmp/root.
Apply kernerl & modified initramfs
13) I then rebooted to recovery, on Developer Edition Menu, flash new kernel & initramfs. Use zImage, and modified initramfs.cpio.gz which I have attached here. The modification I did in initramfs is use mmcblk0p2 as root and mmcblk1p2 as data, and if it finds /dev/mmcblk1p3 (assuming mkswap has already been applied) use it as swap.
Hope this helps.
Will this work on the 101 too?
Sent from my A101IT using Tapatalk
hexto said:
Will this work on the 101 too?
Click to expand...
Click to collapse
Also curious about this
Thanks for your walkthrough! I greatly appreciate it. I'm testing this on my 101IT now. However, I seem to be boot-looping (Archos Entertainment your way screen flashes on, off, and on repeatedly). However, for the first boot of the Urukdroid kernel, it took a significant amount of time as well. I'm going to give it a few, and if there's no change, I'll retry. I may have made a mistake someplace causing this issue, so I'll see what I can dig up.
nmyron said:
Thanks for your walkthrough! I greatly appreciate it. I'm testing this on my 101IT now. However, I seem to be boot-looping (Archos Entertainment your way screen flashes on, off, and on repeatedly). However, for the first boot of the Urukdroid kernel, it took a significant amount of time as well. I'm going to give it a few, and if there's no change, I'll retry. I may have made a mistake someplace causing this issue, so I'll see what I can dig up.
Click to expand...
Click to collapse
Are you following the guide from the 1st post or from the 13th post? What version of Urukdroid kernel are you using?
I was totally incorrect. When I boot with the dev edition option, I'm booting off the two internal partitions. To be honest, when I made that first post, I had been at work all night, then did this, and just didn't think to check "mount" in the terminal to see the result.
However, it's performing somewhat sluggishly. I'm unsure what's going on there. I'm going to look at some things and see what might be going on. But, the tutorial was spot on.
Is there a way to force it to boot Dev Edition (so it boots this OS) automatically upon logon?
Edit: And, I'm running the Urukdroid 0.4.1 currently, I just downloaded the latest before I began this process
On recovery menu, select Developer Edition, then select delete android's kernel. After this you'll always boot in Developer mode.
________________________________
Sent from my GT-I9000 using Tapatalk
... And you would've thought that I'd have noticed that, being all the in/out of that menu I've done in the last two days...
As far as the sluggishness goes, it seems to be mostly directly after boot. After about 2 minutes, it fades, and performance improves drastically. I'm guessing it ties mostly to swappiness, and the system making initial use/caching data.
You have no idea how much of an amazing help this walkthrough has been. Just a little messing around with the file system, and moving things around, and now it's just cooking along, running an internally booted os with root access... Great work here!
This thread is for discussing features and improvements of this rooting method
For questions and problems read the [HOWTO] thread
Project site online: archos-gen8-sde-rooting
wdl1908 said:
chulri what about creating a 1Gb file on the /mnt/storage and formatting that as ext3 copying all the original /data to it and then mounting that with a loop interface on /data.
Click to expand...
Click to collapse
That's what I tried previously (before the /data thing), but I had no luck and it's a big issue because android tries to unmount /mnt/storage when you connect your archos device to the computer but that's not possible because the lock of the mounted rw-file makes umounting of /mnt/storage impossible and I have to mount the rw-file before /mnt/storage gets mounted, that's another issue which must be resolved.
chulri said:
That's what I tried previously (before the /data thing), but I had no luck and it's a big issue because android tries to unmount /mnt/storage when you connect your archos device to the computer but that's not possible because the lock of the mounted rw-file makes umounting of /mnt/storage impossible and I have to mount the rw-file before /mnt/storage gets mounted, that's another issue which must be resolved.
Click to expand...
Click to collapse
Yeah I came to the same conclusion as you, that what I suggested would bork the usb mount option to the PC.
Another thing I realized is that the official firmware upgrades could probably update files on the data partition. So moving the whole partition is not an option as that would break the upgrade process.
I've been looking at splitting the storage partition in several parts with parted I found an arm binary at http://plugapps.com/arm/ maybe these can be included in the initramfs.
I've also been analyzing my data partition
Code:
# du -s /data/*
112003 app
70503 dalvik-cache
40084 data
4622 test
The test directory is the place where the google market is installed via arctools or gappsinstaller.
So if it's possible to split the storage partition in several part we could move these dirs to it's own partition. This would not be optimal a good solution would be to move the complete data partition over but this needs a bit of thinking how to handle upgrades.
wdl1908 said:
So if it's possible to split the storage partition in several part we could move these dirs to it's own partition. This would not be optimal a good solution would be to move the complete data partition over but this needs a bit of thinking how to handle upgrades.
Click to expand...
Click to collapse
We could shrink the internal storage and append partition(s) after it. I'll give it a try, as long as my usb port is broken I have more time to focus on this here
chulri said:
We could shrink the internal storage and append partition(s) after it. I'll give it a try, as long as my usb port is broken I have more time to focus on this here
Click to expand...
Click to collapse
I've been trying to cross compile e2fsprogs and parted but I can't seem to get it.
Code:
e2fsprogs-1.41.14$ cross ./configure --host=arm-linux-uclibcgnueabi --build=i686-linux
Completes without errors but the make does not complete.
Code:
gen_uuid.c:(.text+0x418): undefined reference to `__aeabi_read_tp'
../../lib/libuuid.a(gen_uuid.o):gen_uuid.c:(.text+0x788): more undefined references to `__aeabi_read_tp' follow
I've tried to use the pre-compiled packages but it seems they don't work or i'm missing something.
fdisk is already included in initramfs thus no need for a parted binary.
edit: but to minimize data loss we need a resize2fs binary to resize the fat/ext3 partition
mkfs.ext3 (for the rw partition) and fsck are included too in the initramfs by archos
chulri said:
fdisk is already included in initramfs thus no need for a parted binary.
edit: but to minimize data loss we need a resize2fs binary to resize the fat/ext3 partition
mkfs.ext3 (for the rw partition) and fsck are included too in the initramfs by archos
Click to expand...
Click to collapse
Yep resize2fs is part of e2fsprogs. I've been working on the packages in the buildroot there seems to be a lot of errors but I finally succeeded in building the e2fsprogs package. but riseze2fs is not included. I need to check the config for that package maybe there is an option missing.
To get the buildroot working properly you need to copy the file
Code:
cp local/g8_arm/g8_arm.config .config
remove the line
Code:
package/apdf/Config.in
from .config.cmd
remove the line
Code:
depends on BR2_EXT_UCLIBC_VERSION_0_9_30_1
from toolchain/uClibc/Config.in
then in the buildroot directory execute
Code:
make menuconfig
enable the e2fsprogs in Package selection -> Harware handling
also you have to remove the --disable-resizer from the e2fsprogs.mk file else the resizer is not build.
I can't believe this build package from archos is very up-to-date it seems very strange that all these bugs are in there how where they ever building a good firmware.
but that builds dynamic linked binaries, doesn't it? but we need a static build, don't we?
chulri said:
but that builds dynamic linked binaries, doesn't it? but we need a static build, don't we?
Click to expand...
Click to collapse
Yeah stupid me it needs to run in the initramfs and that does not contain any libraries. Let me check to see if it's possible to link it statically.
and because it has to be statically linked, maybe we better just take the newest e2fsprogs (btw.: does this support FAT resizing?!) and compile it without that buildroot stuff (except for the toolchain of course, we need that to crosscompile)
chulri said:
and because it has to be statically linked, maybe we better just take the newest e2fsprogs (btw.: does this support FAT resizing?!) and compile it without that buildroot stuff (except for the toolchain of course, we need that to crosscompile)
Click to expand...
Click to collapse
Well I tried that and failed. That's why I wanted to do it in the buildroot. I'll try again later need to create a clean environment and do some diffs after I fixed all the stuff that's wrong.
wdl1908 said:
Well I tried that and failed. That's why I wanted to do it in the buildroot. I'll try again later need to create a clean environment and do some diffs after I fixed all the stuff that's wrong.
Click to expand...
Click to collapse
I think I got it.
Add
Code:
export BOARD=g8_arm
To your .bashrc then in the buildroot directory do a make it will take a while as it needs to build everything. This is just a precaution as i think the statically linked resize2fs needs some linking with uclib libraries.
After that is finished do a
Code:
make e2fsprogs LDFLAGS=-static
in the buildroot directory. You should find the resize2fs binary in the directory buildroot/project_build_arm/uclibc/root/sbin
Code:
$ file resize2fs
resize2fs: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped
resize2fs does not resize vfat so we probably need parted and some extra utils
How to compile parted with buildroot.
I found the attached files on some forum
e3fsprogs.mk is a replacement for the existing file.
Config.in parted.mk and parted-001-ui.cast.patch need to be placed in the directory buildroot/package/parted
then execute the following commands
Code:
make e2fsprogs LDFLAGS=-static
make e2fsprogs-libs
make parted LDFLAGS=-static
you can find the statically linked parted in buildroot/build_arm/parted-2.3/parted
and this is what i tried.
Code:
# [B]parted /dev/block/mmcblk1[/B]
GNU Parted 2.3
Using /dev/block/mmcblk1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) [B]print[/B]
print
Model: MMC MMC08G (sd/mmc)
Disk /dev/block/mmcblk1: 7466MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 8192B 7466MB 7466MB primary fat32 lba
(parted) [B]resize[/B]
resize
WARNING: you are attempting to use ./parted to operate on (resize) a file system.
./parted's file system manipulation code is not as robust as what you'll find in
dedicated, file-system-specific packages like e2fsprogs. We recommend
you use ./parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.
Partition number? [B]1[/B]
1
Start? [8192B]?
End? [7466MB]? [B]6466MB[/B]
6466MB
(parted) [B]check[/B]
check
WARNING: you are attempting to use ./parted to operate on (check) a file system.
./parted's file system manipulation code is not as robust as what you'll find in
dedicated, file-system-specific packages like e2fsprogs. We recommend
you use ./parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.
Partition number? [B]1[/B]
1
(parted) [B]quit[/B]
quit
Information: You may need to update /etc/fstab.
#[B]fdisk /dev/block/mmcblk1[/B]
The number of cylinders for this disk is set to 227840.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): [B]p[/B]
Disk /dev/block/mmcblk1: 7465 MB, 7465861120 bytes
4 heads, 16 sectors/track, 227840 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk1p1 1 197327 6314445+ c Win95 FAT32 (LBA)
Command (m for help): [B]n[/B]
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): [B]2[/B]
First cylinder (197327-227840, default 197327): Using default value 197327
Last cylinder or +size or +sizeM or +sizeK (197327-227840, default 227840): Using default value 227840
Command (m for help): [B]p[/B]
Disk /dev/block/mmcblk1: 7465 MB, 7465861120 bytes
4 heads, 16 sectors/track, 227840 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk1p1 1 197327 6314445+ c Win95 FAT32 (LBA)
/dev/block/mmcblk1p2 197327 227840 976426+ 83 Linux
Command (m for help): [B]w[/B]
The partition table has been altered!
Calling ioctl() to re-read partition table
# [B]mkfs.ext3 -v -I 128 /dev/block/mmcblk1p2[/B]
mke2fs 1.40.9 (27-Apr-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
61184 inodes, 244106 blocks
12205 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=251658240
8 block groups
32768 blocks per group, 32768 fragments per group
7648 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
# [B]tune2fs.static -c -1 -i 0 -m 1 /dev/block/mmcblk1p2[/B]
tune2fs 1.40.9 (27-Apr-2008)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds
Setting reserved blocks percentage to 1% (2441 blocks)
I leave the scripting to you but with these utils it should work perfectly to resize the partition and create the second partition.
I copied the mkfs.ext3, fdisk and tune2fs.static from the recovery initramfs
I started hacking around and I came to the conclusion that it would be better to change the initramfs to mount /data from mmcblk1p2 if that partition exists and not if it's not existing and move the whole partition resizing, partition creating, partition deleting (if you wan't to revert without dataloss) and again resizing into an app. so the user has more control over what he's doing and see's if something is failing and not just get's a bootloop or some fancy log file.
edit: /data is mounted by /init.rc script, all of the above can be done by an app, incl. modifying /init.rc script. no need for any special initramfs, yay!
everybody who has +rw rooting installed will be able to use that app. I'm starting development...
edit2: project page online: http://code.google.com/p/archos-gen8-sde-rooting/
stay tuned
First test app: http://code.google.com/p/archos-gen8-sde-rooting/downloads/detail?name=AppDataResizer_v0.1.apk
Release notes:
initial test version v0.1:
- parted binary added
- test button lists partitions of mmcblk1 device
Click to expand...
Click to collapse
note: 250 GB version of the A70 is currently not supported.
chulri said:
First test app: http://code.google.com/p/archos-gen8-sde-rooting/downloads/detail?name=AppDataResizer_v0.1.apk
Release notes:
note: 250 GB version of the A70 is currently not supported.
Click to expand...
Click to collapse
Nice. Yep I was thinking about the transition from standard to custom and also came to the conclusion it had to be done outside the boot process scripts.
Edit: Should this app be installable via the usual way or should it be a system app? (Copied to /system/app)
What I was thinking was split the process in 3 steps.
Step1: Resize storage partition, Add new-data partition and format.
Step2: Copy existing /data to /new-data
Step3: Enable/Disable new-data
Maybe a step2a: To run after upgrade of firmware to check things that have changed.
The step1 requires a reboot as the partitioning should be done in the initramfs if you do that when apps are running you're going to have a hell of a time getting the storage partition unmounted (I know I had the problem when testing the parted binary)
Step2 can be done without any problem when storage is mounted and Step3 requires a reboot after the init.rc is changed.
wdl1908 said:
Nice. Yep I was thinking about the transition from standard to custom and also came to the conclusion it had to be done outside the boot process scripts.
Edit: Should this app be installable via the usual way or should it be a system app? (Copied to /system/app)
Click to expand...
Click to collapse
usual way (download and install) (or maybe I include it in the initramfs (like the Superuser.apk) and copy it to /system/app, but I don't like modifying initramfs any further, no need for 100 different versions )
wdl1908 said:
What I was thinking was split the process in 3 steps.
Step1: Resize storage partition, Add new-data partition and format.
Step2: Copy existing /data to /new-data
Step3: Enable/Disable new-data
Maybe a step2a: To run after upgrade of firmware to check things that have changed.
Click to expand...
Click to collapse
great, that were my plans too.
wdl1908 said:
The step1 requires a reboot as the partitioning should be done in the initramfs if you do that when apps are running you're going to have a hell of a time getting the storage partition unmounted (I know I had the problem when testing the parted binary)
Click to expand...
Click to collapse
No API to unmount /sdcard/? I think I got one: IMountService it's not a public API but android.os.FileUtils isn't public either and it's working great. I think IMountService is the API that the popup, which pops up when you connect your android device to the computer, uses. I think, no need to worry because android handles everything pretty well when you connect your device to the computer, isn't it?
wdl1908 said:
Step2 can be done without any problem when storage is mounted and Step3 requires a reboot after the init.rc is changed.
Click to expand...
Click to collapse
agreed
chulri said:
usual way (download and install) (or maybe I include it in the initramfs (like the Superuser.apk) and copy it to /system/app, but I don't like modifying initramfs any further, no need for 100 different versions )
Click to expand...
Click to collapse
I tried to install it but it won't install. logcat gives something like
Pckage chrulri.gen8.AppDataResizer has no certificated at entry res/layout/main.xml
Yep I agree no need for different versions of the initramfs
chulri said:
No API to unmount /sdcard/?
Click to expand...
Click to collapse
The problem is not only the mount of /mnt/storage if the user has used move2sd there are a lot of other mounts present that also uses that partition.
maybe the API will do. Needs to be tested.
One other remark. Let the AppDataResizer check for the unionfs directory so that you can be sure you'r running on the correct initramfs.
K, time to give this a proper OP, if anyone wants any of the info that was here before you can look here
_________________________________________________________________________________________________
So, the whole idea here started with me reading an article on how part of the whole I/O problem with the transformer is partially caused by the hardware used as internal storage. I wanted to find out if this had any merit and I figured the best way to do it would be to "replace" the internal storage. I did this by mounting the /data partition to the exteral SD (which according to my research, my specific SD Card is better at writing speeds - allegedly the main problem with the transformer's internal storage hardware wise). Then I ran a bunch of benchmarks and have been running it that way for about 24 hours and so far it feels great. Anyone is welcome to give it a try, and hopefully with help, suggestions and feedback from the community, we can all take as much advantage of this idea as possible.
Before I go any further I want to give credit to those who helped me so far, because without them I would still be completely clueless, and not only have they helped be accomplishing what I got so far, but thanks to them I've also learned a bunch of things I didn't know before. So here it goes:
Rayman - For suggesting the method for mounting /data to the external SD.
lilstevie - For helping me get the new kernel flashed right.
Turge - For showing me how to properly repack the kernel.
Parastie - For suggesting doing the same thing to /cache (working on that now).
dagrim1 - For SQL patch and for suggesting a temporary remount (even though it didn't work it was a good thing to try).
_motley - For all his work on his awesome kernel.
_________________________________________________________________________________________________
Updates:
Update 1 (08-01-2012 File boot-data+cache+internal-AOKP6.1base.zip) :
Now both /data and /cache are moved to the external SD card. This means you need a third partition mmcblk1p3 in order to use this modification.
It will also mount the internal storage (previously inaccessible) to /mnt/sdcard_internal
It also attempts to (fail at this point) to mount the internal sd partition (what used to be /sdcard) to /sdcard/Internal_SD (which is why you will always see that folder get created but stay empty). If anybody knows how to make it work please advise.
Modified Lines:
init.cardhu.rc
Code:
# TweakerL MOD > original mount = mmcblk0p8 /data | mmcblk0p3 /cache
mount ext4 /dev/block/mmcblk1p2 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
mount ext4 /dev/block/mmcblk1p3 /cache wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > added mounts for internal storage
mkdir /mnt/sdcard_internal 0000 system system
mount ext4 /dev/block/mmcblk0p8 /mnt/sdcard_internal wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > give access to internal SD from /sdcard
mkdir /data/media/Internal_SD 0755 media_rw media_rw
mount /mnt/sdcard_internal/media /data/media/Internal_SD wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
Update 2 (08-01-2012 About backing up/restoring in recovery) : - READ UPDATE 5
One thing that worried me was that by using this mod people wouldn't be able to backup their data partition properly, but now I know that it's possible to do it. It will only work on TWRP though since it has basic terminal access and keyboard. To do it, go into Advanced > Terminal and in there type:
umount /dev/block/mmcblk0p8
mount /dev/block/mmcblk1p2 /data
And until you reboot, any backup/restore should use the external SD data partition instead of the internal. The same should be doable with the cache partition in case you want to backup/restore that.
Update 3 (08-02-2012 File flashme-kernel-motley305-aokp-data+cache2SD.zip) :
Put together a flashable zip that will install motley's 3.0.5 aokp kernel using this mod. Works like a charm so far though I only tried flashing on TWRP. Also, internal storage can be accessed in /data2 and internal sd can be accessed in /sdcardi . Current changes are as follow:
Code:
# TweakerL MOD > move /data and /cache to external SD card || original mount = mmcblk0p8 /data | mmcblk0p3 /cache
mount ext4 /dev/block/mmcblk1p2 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
mount ext4 /dev/block/mmcblk1p3 /cache wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > create mount for internal storage
mkdir /data2 0000 system system
mount ext4 /dev/block/mmcblk0p8 /data2 wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > symlink internal sd to a couple of easily accessible locations
symlink /data2/media /mnt/sdcard_internal
symlink /data2/media /sdcardi
Update 4 (08-03-2012 File boot-cm10-unofficial-data+internal.zip) :
Running the unofficial CM10 (no cherrypicks one) using this mod and so far it's pretty amazing. The rom itself is pretty stable and even snappier with /data mounted to external SD. Benchmarks are at the bottom. Current modifications:
fstab.cardhu:
Code:
#TweakerL MOD > Move /data to external SD and internal /data to /data2
/dev/block/mmcblk1p2 /data ext4 rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writeback wait
/dev/block/mmcblk0p8 /data2 ext4 rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writeback wait
init.cardhu.rc:
Code:
# TweakerL MOD > create mount for internal storage
mkdir /data2 0000 system system
mount_all /fstab.cardhu
# TweakerL MOD > symlink internal sd to a couple of easily accessible locations
symlink /data2/media /mnt/sdcard_internal
symlink /data2/media /sdcardi
Update 5 (08-03-2012 About backing up/restoring in recovery) :
So after doing some tests, and paying more attention to TWRP, I noticed something rather useful:
When you have this mod enabled, or whenever you have a mmcblk1p2 partiion, TWRP will have the sd-ext menu enabled. This means that to backup your data you can simply backup the sd-ext partition and to restore your data you can simply restore your sd-ext partition. No need to worry about manually switching the mount point for /data in recovery. I guess it was a whole lot easier than I thought.
Also congratulations and thanks to everyone who has contributed with this so far.
WE MADE IT TO FRONT PAGE ON XDA (08-03-2012)
_________________________________________________________________________________________________
Requirements:
There are a few things you will need to do in order for this to work right for you, and a couple of things you'll have to research before you even try it.
#1. Obviously, you have to be rooted/unlocked because you're not gonna be able to change much around otherwise.
#2. You MUST repartition your external SD. The kernel I've put together so far WILL ONLY mount /data to mmcblk1p2, which basically says "mount /data to the second partition in the external SD." also, the ramdisk expects that partition to be ext4, so essentially:
Make sure you have an external SD with at least two partitions and that the second partition is formatted to ext4. I personally use Gparted to repartition my stuff, but feel free to use whatever rocks your boat. Even if you're on windows you can still use gparted by using virtualbox, so I'm not gonna go look for a different windows solution.
#3. This is the research part... This will be beneficial or detrimental to each user depending on the SD card used. If you have a slow SD card this probably will do you no good. However, just because you have a class 10 SD card, that doesn't mean it will benefit you either. On my own research I have found that some class 6-10 SD Cards have extremely slow random write speeds, so if you happen to have one of those, even if it's a class 10, this might not be for you. This means that you're gonna have to do some research to find out if your SD Card will benefit you or not. You can always just give it a try, as far as I know this is entirely reversible, how easy or hard being just a matter of how bad you mess up on meeting the requirements and following the instructions.
#4. At this point (07-30-2012) I'm doing all this stuff using the AOKP milestone 6.1 kernel as base for my modified kernel, so if you're not using AOKP milestone 6.1, flashing my kernel might borke your system. You've been warned, feel free to proceed otherwise at your own peril.
_____________________________________________________________________________________________________________
Installation:
#1. Download attached file (boot-data2SD-AOKP6.1base.zip) and extract it to the root of your internal storage (/sdcard).
#2. Open a terminal.
#3. Type the following:
Code:
su
dd if=/sdcard/boot.blob of=dev/block/mmcblk0p4 bs=1
#4. Wait for it to complete.
#5. Reboot.
Upon rebooting you will know that it worked because it will look just as if you just flashed a new rom, that is, you'll get the device setup screen (assuming that the tablet booted at all lol). If you're planning to use TB to restore your apps, you'll probably want to copy the TB folder to your external SD's first partition so that you can copy it back once you're done with the device setup (at this point you will have no access - unless you manually mount it - to your internal storage).
_______________________________________________________________________________________
Reverting:
Follow the same exact steps for installation but use boot-default-AOKP6.1.zip instead.
_______________________________________________________________________________________
Optional:
#1. If you want to have access to everything you had on your data partition in the new data partition, you'll have to clone everything from one to the other. To do this, make sure that your new data partition (the one in your external SD) has enough storage space to fit everything you currently have in your data partition (the one in your internal storage). Then run the following command in your terminal.
Code:
dd if=dev/block/mmcblk0p8 of=dev/block/mmcblk1p2 bs=4096 conv=notrunc,noerror
BEWARE that if you have a lot of stuff this can take quite a while and even though I've read a way of getting the progress for this in Linux I'm not sure that you can check the progress on Android.
_______________________________________________________________________________________
Next steps in development:
#1. Move /cache as well.
#2. Find out what happens with recovery backups when the partitions are changed.
#3. Attempt to apply mod to motley's kernel.
#4. Create a script that is run on boot to eliminate need for replacing the kernel.
#5. With help from the community, find the best SD Card for this.
#6. Run the modified system for a while to have a good feel for performance benefits
#7. Come up with other interesting uses for this other than getting better I/O (maybe an easy - kinda easy - way to dual boot with ubuntu, maybe other stuff, dunno).
_______________________________________________________________________________________
How can I set my kernel to do this?
I didn't do a whole lot, and it's not like I want it to be a secret, so as I modify things I'll try to keep the steps listed here so that anyone modifying their own kernel who would like to try this modification can go ahead and do it.
You'll need to know how to unpack/repack a kernel. Turge has a SUPER EASY explanation here on how to do it on windows (I'll pack together the necessary binaries for linux later, maybe).
Mount /data to the second partition in your external SD (formatted as ext4 filesystem):
After unpacking the kernel navigate to the folder that has the ramdisk and open it
(DON'T USE ANY ASCII BASED TEXT EDITOR BECAUSE IT WILL PROBABLY MESS THINGS UP I USE NOTEPAD++)
Around line 26 change:
Code:
mount ext4 /dev/block/mmcblk0p8 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
to
Code:
mount ext4 /dev/block/mmcblk1p2 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
_______________________________________________________________________________________________________
SD Cards tested:
Samsung 32GB Class 10 MicroSDHC High Speed Memory Card - Very Good Results
SanDisk® microSDHCTM 8GB Memory Card - Very Good Results
"Either way, with this mod, the tablet feels like it should have right from the start. It's speedy and responsive, and apps being installed don't stall the system." - Turge - Post #59
_______________________________________________________________________________________________________
Benchmarks:
/data mounted to mmcblk0p8 (Internal Storage):
{
"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"
}
/data mounted to mmcblk1p2 (External SD):
RL Benchmark WITHOUT dagrim1's sql patch as per request:
/data mounted to mmcblk0p8 (Internal Storage):
/data mounted to mmcblk1p2 (External SD):
*Important thing to note: When running the benchmark with data in the internal SD it was about 220 seconds in the first run, then about 180, then about 130 and finally 118; whereas running it from the external SD was consistenly between 63 and 65 seconds every time. I think this more than proves that A) Asus used a cheap I/O storage, B) No matter what software changes are made, more than likely running the rw partitions from a better I/O storage, i.e. an external SD is a good idea.
As promised here are benchmarks on a JB rom (Unofficial CM10). Also sorry it took me a while to get these, I was going to use eos3 but I started getting random reboots. Then I decided to try cm10, and I messed up a flash and had to redo a bunch of things. Anyway, the only change here is the mod itself (no custom kernel or anything). Though one thing to note is that I moved /cache back to the internal partition after some thought that this allows /data and /cache to be written at the same time to different locations thus lowering the bottleneck.
/data mounted to mmcblk0p8 (internal storage):
/data mounted to mmcblk1p2 (external storage):
Now, as you can see, JB did bring a major improvement to I/O, bringing the benchmark down from about 115sec to 68 (almost reaching the modded ICS at 60 seconds). But as I expected, better software works better on better hardware and now the modded JB is running at 50 seconds instead of 60. Next I'm going to put dagrim1's sql patch and see how low the benchmark goes. Also will be posting the modded blob in just a little bit for anyone who wants to use it on CM10.
We don't have sd-ext it's an old trick when phones had very little /data partitions, you have the possibility to create a sd-ext partition on an external sdcard and mounting it as a secondary data. (like opt partition on Linux).
To see what block device is data just run 'mount' command in terminal emulator. I don't have my device here.
sdcard cache is already set to 2048 if I'm correct.
Your script would mean creating a sd-ext partition on an external sdcard, modify fstab to have it correctly mounted then applying the script.
Not really easy for common users.
I would rather look at kernel drivers (not I/O schedulers but drivers handling with file system format) but it's quite a hard work.
Hmmm...
Was talking to Rayman and it doesn't actually seem that hard to do... Just gotta change the init.cardhu.rc in the ramdisk to mount /data to /dev/block/mmcblk1p2 instead of /dev/block/mmcblk0p8
The thing is, that while I know every step that I have to take to get it done, I haven't used linux in forever and quite honestly I couldn't even compile blobtools right now if I wanted to to extract the ramdisk from the boot blob to make the necessary change... so yea anyone who knows how to edit a kernel should be able to do it, and then just repack it as a blob... I'll probably look into it later, but if anyone wants to type the terminal commands for to to get/compile blobtools I'll appreciate it...
As in just a mount of data to mmcblk1p2?
Would a temp solution (just to check if it works) be to remount data manually? (Tried it, to mmcblk1p1 btw since 1p2 didn't seem to exist for me, but it still mounts to mmcblk0p8.
Using:
mount -o remount,rw -t ext4 /dev/block/mmcblk1p1 /data
(as su in terminal)
dagrim1 said:
As in just a mount of data to mmcblk1p2?
Would a temp solution (just to check if it works) be to remount data manually? (Tried it, to mmcblk1p1 btw since 1p2 didn't seem to exist for me, but it still mounts to mmcblk0p8.
Using:
mount -o remount,rw -t ext4 /dev/block/mmcblk1p1 /data
(as su in terminal)
Click to expand...
Click to collapse
Reason why mmcblk1p2 didn't work is because you have to repartition the sd card to have an ext4 partition... personally what I did was take my 32gb sd card and have the first partition as a fat32 partition for storage and set the rest to an ext4 partition... also, you have to do that because the /data partition is already expected to be an ext4 partition on most of the current ROMs... Trying to set it without doing that most likely won't work.
Also, another thing that's important is that for this to be beneficial you have to have an SD Card with higher random write speed than your internal storage speed... my internal storage speed is about .25 mb/s and my sdcard is about 1.5mb/s so there should be a big difference... Oh and if you happen to have a class 10 sdcard that doesn't necessary mean that it has high random write speed... you actually have to go look up the specs or run benchmarks on it.
TweakerL said:
Reason why mmcblk1p2 didn't work is because you have to repartition the sd card to have an ext4 partition... personally what I did was take my 32gb sd card and have the first partition as a fat32 partition for storage and set the rest to an ext4 partition... also, you have to do that because the /data partition is already expected to be an ext4 partition on most of the current ROMs... Trying to set it without doing that most likely won't work.
Also, another thing that's important is that for this to be beneficial you have to have an SD Card with higher random write speed than your internal storage speed... my internal storage speed is about .25 mb/s and my sdcard is about 1.5mb/s so there should be a big difference... Oh and if you happen to have a class 10 sdcard that doesn't necessary mean that it has high random write speed... you actually have to go look up the specs or run benchmarks on it.
Click to expand...
Click to collapse
Thanks, makes sense yeah... will have to check if it's worth the hassle for now. Not at this moment anyway, but interesting concept...
Stuck... again...
So I figured how to unpack the boot.blob, then unpack the boot.blob.LNX, then decompress the ramdisk... made the necessary change to init.cardhu.rc... compressed the ramdisk to the same format it was before, repacked the boot.blob.LNX, repacked the boot.blob... dd if=blob of=dev/block/mmcblk0p4 seek=28 bs=1 ... and ... nothing... reboot and where you're supposed to get the quick progress bar nothing seems to happen... I'm assuming I messed up on the recompressing ramdisk/packing the boot.blob... but I'm not sure how...
Anyway... I'll post exactly how I did it tomorrow so maybe someone with more experience can help me figure out where I messed up...
But so far, I wanna say thanks to rayman and lilstevie for all the help they've given me so far with this idea.
TweakerL said:
... compressed the ramdisk to the same format it was before, repacked the boot.blob.LNX, repacked the boot.blob... dd if=blob of=dev/block/mmcblk0p4 seek=28 bs=1 ...
Click to expand...
Click to collapse
Just wondering, why did you choose to use seek=28?
I believe the TFP will need the first 28 header signature to be there in order to flash through the staging paritition (p4).
Your other option would be to flash using fastboot:
1. If you've installed the AndroidRoot.mobi bootloader (if you have nvflash), then you can directly flash the boot.blob.LNX file, as this is a raw image.
fastboot -i 0x0b05 flash boot boot.blob.LNX
2. If you don't have AndroidRoot.mobi bootloader, then I suggest you get NVFlash working first and get a backup... if not, you can use the following to flash the blob:
fastboot -i 0x0b05 flash boot blobfileyou'vecreated
3. Use fastboot to flash to the staging partition:
fastboot -i 0x0b05 flash staging blobfileyou'vecreated
TweakerL said:
So I figured how to unpack the boot.blob, then unpack the boot.blob.LNX, then decompress the ramdisk... made the necessary change to init.cardhu.rc... compressed the ramdisk to the same format it was before, repacked the boot.blob.LNX, repacked the boot.blob... dd if=blob of=dev/block/mmcblk0p4 seek=28 bs=1 ... and ... nothing... reboot and where you're supposed to get the quick progress bar nothing seems to happen... I'm assuming I messed up on the recompressing ramdisk/packing the boot.blob... but I'm not sure how...
Anyway... I'll post exactly how I did it tomorrow so maybe someone with more experience can help me figure out where I messed up...
But so far, I wanna say thanks to rayman and lilstevie for all the help they've given me so far with this idea.
Click to expand...
Click to collapse
I've repacked the boot.img for the Prime before to add init.d support so I'll post my method and the files needed in a few minutes once I get to work. It'll involve getting cygwin installed (with Perl support I believe) if you're on Windows.
Would it be better to move cache and maybe dalvik cache (assuming the SD random read/write is faster then internal memory) ? Since you're only moving data and leaving cache on internal, that'll still hit the issues of having bad IO. Moving cache (which I believe would have more random access) I think would be better.
Thoughts?
dagrim1 said:
As in just a mount of data to mmcblk1p2?
Would a temp solution (just to check if it works) be to remount data manually? (Tried it, to mmcblk1p1 btw since 1p2 didn't seem to exist for me, but it still mounts to mmcblk0p8.
Using:
mount -o remount,rw -t ext4 /dev/block/mmcblk1p1 /data
(as su in terminal)
Click to expand...
Click to collapse
Thanks for the idea, I tried to do that but nothing seemed to happen (checking on file manager /data partition is still taking the same amount of space as it did before). It would've been a really good way of testing this whole thing though
kokopuphz said:
Just wondering, why did you choose to use seek=28?
I believe the TFP will need the first 28 header signature to be there in order to flash through the staging paritition (p4).
Your other option would be to flash using fastboot:
1. If you've installed the AndroidRoot.mobi bootloader (if you have nvflash), then you can directly flash the boot.blob.LNX file, as this is a raw image.
fastboot -i 0x0b05 flash boot boot.blob.LNX
2. If you don't have AndroidRoot.mobi bootloader, then I suggest you get NVFlash working first and get a backup... if not, you can use the following to flash the blob:
fastboot -i 0x0b05 flash boot blobfileyou'vecreated
3. Use fastboot to flash to the staging partition:
fastboot -i 0x0b05 flash staging blobfileyou'vecreated
Click to expand...
Click to collapse
I used seek=28 out of despair and by lilstevie's suggestions... dd with or without seek had the same exact result, the staging just ignoring the whole thing lol...
Sounds like a plan (flashing with fastboot)... I've got one dumb question though before I do that (and yea i've got nvflash setup and all the backups and stuff). How do I actually go about restoring the system with NVFLASH if I go and borke the system ? XD
Turge said:
I've repacked the boot.img for the Prime before to add init.d support so I'll post my method and the files needed in a few minutes once I get to work. It'll involve getting cygwin installed (with Perl support I believe) if you're on Windows.
Click to expand...
Click to collapse
That would be much appreciated, I don't mind steps for windows or linux, I'll go either way
Parastie said:
Would it be better to move cache and maybe dalvik cache (assuming the SD random read/write is faster then internal memory) ? Since you're only moving data and leaving cache on internal, that'll still hit the issues of having bad IO. Moving cache (which I believe would have more random access) I think would be better.
Thoughts?
Click to expand...
Click to collapse
I agree that moving the cache is a good idea, one of the main reasons why I'm testing with /data though is that it will be much easier to have solid evidence of whether this works or not that way since all the benchmark apps seem to benchmark on the /data partition. I know benchmarks aren't real world results, but if I can run benchmarks on the same partition and it's 5 times faster on the SD card than on the internal memory, I think it should mean something. After that, if there are positive results, I'm thinking of moving both /data and /cache partitions and run that way for a while to see how well it performs, and then to run with just the /cache moved and see how that performs.
Turge said:
I've repacked the boot.img for the Prime before to add init.d support so I'll post my method and the files needed in a few minutes once I get to work. It'll involve getting cygwin installed (with Perl support I believe) if you're on Windows.
Click to expand...
Click to collapse
Here are the steps for repacking the boot.img. Some involve running the commands via cygwin, others involve running them via the Windows Command Prompt.
The instructions for installing cygwin, extracting and repacking the boot.img were found here: http://www.freeyourandroid.com/guide/extract-edit-repack-boot-img-windows
Once you have setup cygwin, extract the attached files in a folder under your "home" folder in cygwin.
copy boot.blob to the same folder and run the following via the Windows Command Prompt to extract the boot.img from the boot.blob:
Code:
BlobUnpack.exe boot.blob
ren boot.blob.LNX boot.img
From the cygwin bash terminal window, switch to the same folder and run the following to extract the ramdisk from the boot.img:
Code:
./extractboot boot.img
You now have an out/ramdisk folder that contains the files you want to edit.
Once done, repack the ramdisk and kernel into boot_new.img with the following command (via cygwin once again):
Code:
./packboot
then from the Command Prompt repack boot_new.img into boot2.blob using the following:
Code:
blobpack -s boot2.blob LNX boot_new.img
You can now flash the boot.blob to the staging partition via a command in updater-script:
Code:
package_extract_file("/boot.blob", "/dev/block/mmcblk0p4");
or by using adb while in recovery/android:
Code:
dd if=/sdcard/boot2.blob of=/dev/block/mmcblk0p4
Did anyone think of running iotop? If we know what part of /data is contributing to the stalls, maybe an interesting idea would be to just mount that part of the tree on SD?
tyvm will get on it now, will report back any results
Sent from my Transformer Prime TF201 using Xparent SkyBlue Tapatalk 2
what's iotop?
Though regardless, the problem I'm trying to deal with is the fact that apparently, the storage hardware in the Prime has limited I/O capabilities, namely random write speeds, regardless of software. Because of this the stalls are at least partially caused by the "where" the /data is rather than the "content" in the /data.
Sent from my Transformer Prime TF201 using Xparent SkyBlue Tapatalk 2
TweakerL said:
what's iotop?
Click to expand...
Click to collapse
ffs. Why do I bother?
tshoulihane said:
ffs. Why do I bother?
Click to expand...
Click to collapse
You know, I can just google it, but the fact that you care enough to post your opinion but not enough to explain it is the kind of mentality that keeps people who could potentially contribute to the community from doing so because they have to go research all over the internet, possibly going through bad information, for something that might be very simple. Read a few posts up and you'll see the right kind of mindset. Turge could've just*given some halfassed response and sent me on a wild goose chase but instead he took the time to explain in a way that anyone with any amount of knowledge could understand...
And I hope that since you can't bother to give an useful response, that you can't bother wasting you "precious time" justifying and complaining about how people ask questions that they could just look for elsewhere...
Hello,
This guide will help you merge userdata and media partitions in to one Big for 16gb Nooks is aprox. 14,3GB and for 8Gb is aprox 6.1GB
What are those?
userdata is your /data partition and in that one you can currently install the apps/games until is full.
Media is your internal sdcard(emmc)
What we are going to do?
We will delete both userdata and media and make a bigger userdata and inside that we are going to mount the media partition so will become like this /data/media.
Required
1.Working CyanoBoot aka 2ndary bootloader.
2.Fastboot drivers and adb shell drivers with both of them functional
3.A special recovery to perform the merge.
4. A little patience until is implemented into cm as a special recovery will be needed after this merge.
You cant use any existing recoveries after this is done.I or chrmhoffmann will post a special recovery after the changes are done on device tree.
A special thanks to meghd00t for the sgdisk tool. A very valuable tool for this task.
So how this is done already!
1. Download the special recovery from here
http://goo.im/devs/demetris/Acclaim/CM11//sgdisk-recovery.img
Mirror
http://s000.tinyupload.com/index.php?file_id=57668299249558322082
2. Download the new cm recovery from here
https://goo.im/devs/chrmhoffmann/cm-12.0/acclaim/recovery-L-acclaim-20150221-ENG.img/
Mirror
http://s000.tinyupload.com/index.php?file_id=07462035216933296298
3.Put both into your working fastboot folder.
4.Enter fastboot mode with holding N and select fastboot on Cyanoboot menu.
5. Copy&Paste the next lines
Code:
fastboot flash recovery sgdisk-recovery.img
fastboot reboot
6.Enter recovery with holding N and select Internal eMMC Recovery from Cyanoboot menu.
7. Copy&Paste the next lines
Code:
adb shell
You get a # and you are now in adb shell interface and you are root so, lets delete both partitions with:
Code:
sgdisk /dev/block/platform/mmci-omap-hs.1/mmcblk0 -d 11 -d 10
And merge into one
Code:
sgdisk /dev/block/platform/mmci-omap-hs.1/mmcblk0 -n 0:0:0
Name the new partition into userdata
Code:
sgdisk /dev/block/platform/mmci-omap-hs.1/mmcblk0 -c 10:userdata
Format our new partition into EXT4
Code:
make_ext4fs -L userdata /dev/block/mmcblk0p10
Check if all done ok
Code:
parted /dev/block/mmcblk0
Code:
print
It should print in the end (for 16GB nooks)
10 1611MB 15.9GB 14.3GB ext4 userdata
It should print in the end (for 8GB nooks)
10 1611MB 7734MB 61240MB ext4 userdata
Number 10 is your new partition, 14.3GB/6.1GB is the partition size ext4 is the filesystem and userdata is the name of the partition
After that you can issue a
reboot
Enter fastboot again and flash the new recovery [recovery-L-acclaim-20150221-ENG.img]
For F2FS support boot into new recovery
Code:
adb shell
Code:
#mkfs.f2fs /dev/block/platform/omap/omap_hsmmc.1/by-name/userdata
This guide is for an alternate way of #1 post guide using a big part of it throughout.
1.Download new recovery from #1
2.Flash it with fastboot
3.Boot in it
4.Download this
http://s000.tinyupload.com/index.php?file_id=14937290426749868964
unzip it and push it to /tmp with adb
Code:
adb push sgdisk /tmp/
Code:
adb shell
Code:
chmod +x /tmp/sgdisk
Code:
umount /storage/sdcard1/
Code:
/tmp/sgdisk /dev/block/platform/mmci-omap-hs.1/mmcblk0 -d 11 -d 10
Code:
/tmp/sgdisk /dev/block/platform/mmci-omap-hs.1/mmcblk0 -n 0:0:0
Code:
/tmp/sgdisk /dev/block/platform/mmci-omap-hs.1/mmcblk0 -c 10:userdata
Now depending what filesystem you want you must use the right command
EXT4 Use:
Code:
mkfs.ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/userdata
F2FS Use:
Code:
mkfs.f2fs /dev/block/platform/omap/omap_hsmmc.1/by-name/userdata
Thats it.
really
Dont do this yet. CM11 does not support this at the moment.
Chris
Sent from my TF300T using xda app-developers app
Sorry if I sound like a noob, but, why exactly is it so difficult to change internal SD to external in CM11 specifically for the Nook Tablet? I have switched up the external SD as my internal SD on my Samsung GS2 running CM11 HellKat ROM quite easily. But then again, CM11 HellKat has a functioning vold.fstab, but the Nook Tablet does not. Why is that? Just curious.
sagirfahmid3 said:
Sorry if I sound like a noob, but, why exactly is it so difficult to change internal SD to external in CM11 specifically for the Nook Tablet? I have switched up the external SD as my internal SD on my Samsung GS2 running CM11 HellKat ROM quite easily. But then again, CM11 HellKat has a functioning vold.fstab, but the Nook Tablet does not. Why is that? Just curious.
Click to expand...
Click to collapse
+1 on this.
The current partitoning scheme is a real hinderance. a HUGE hinderance.
are there any clear instructions anywhere to fuse sdcard to /data/media anywhere?
This would really take the Nook Tablet to a whole new level if both partitions could be merged into a single partition as described above. Are you still planning on creating a special recovery for this?
Thanks for all of your hard work on this and Bexus.
So, this merge died?
rpadula said:
So, this merge died?
Click to expand...
Click to collapse
If this is dead is there still an effort to make the media partition (internal storage) act as the SD card? Some apps (like minion rush for example) won't completely install without and external SD card. Used to be able to swap internal and external but can't find a way to do that anymore. Even then there were still issues like the media process frequently crashing. It would be nice to utilize all of the 16GB of the NT and not be required to also use an external SD card. That would be sublime.
Yeah I agree with you guys but cm maintainer don't so if we merge partitions then you won't be able to use official cm
ok guys this guide is adjusted for the new cm12 sdcard as emulated merge with f2fs filesystem support.
Enjoy
I previously resized emmc to ~9.5 GB ( and reduced data). I assume this method should work fine regardless of the relative sizes of these two partitions?
rete said:
I previously resized emmc to ~9.5 GB ( and reduced data). I assume this method should work fine regardless of the relative sizes of these two partitions?
Click to expand...
Click to collapse
Doesnt matter what repartitioning sheme you have as both partitions get deleted then merged so all will end up with the same size.
When i refer to all i mean users that repartioned and those who didnt.
I now added a new alternate guide on #2
Regards
Thanks. This is nice guide for cm12 with nightlies of 22 Feb 2015 and newer.
Chris
If emulated sdcard has been implemented, is it no longer ok to flash back to CM11? I'm sure F2FS is not supported, but is emulated sdcard also not ok?
Also, if we need to get back to stock after this repartition method, will AdamOutler's unbrick method restore the original partitions back?
If you dont merge the partitions there is no problem to go back to any rom cm or stock
? How to recover deleted files on rooted Android without USB Debug & PC connection?
Hello.
I have removed some important files in my DCIM folder on internal memory of my Android device. The USB socket of the phone is broken so I couldn't use any recovery software that using USB debug mode but I have Team Win I want to use the terminal of Team Win to make an image and copy it to SD Card of my Android device. I know that there is a command dd but how to use it in a proper way to make a full image of the partition including also free space.
Thank you very much in advance!
Yes, dd command could be used simmilar to this:
open terminal, cd to external SD folder
dd if=/dev/block/block/bootdevice/by-name/userdata of=data.img
or if you know number of partition
dd if=/dev/block/mmcblk0p18 of=data.img (p18 is on Huawei LDN, image size is that same as partition size 16GB/32GB/64GB..etc, so for bigger then 32GB need to use NTFS sdcard or exFAT sdcard and TWRP also has to support NTFS or exFAT).
Or edit etc/*.fstab and repack twrp. You can back up files from /data for now (as ext4 or f2fs). Just add line to back up full image of /data (as emmc).
If /data has ext4 filesystem it can easilly mount/unpack/scan/rip image. But if /data has f2fs ... got not cure.
Example:
/data f2fs /dev/block/bootdevice/by-name/userdata flags=length=-16384;backup=1;settingsstorage;encryptable=footer;
/data_image emmc /dev/block/mmcblk0p55 flags=display="Data Image";backup=1;flashimg;
adeii said:
Yes, dd command could be used simmilar to this:
open terminal, cd to external SD folder
dd if=/dev/block/block/bootdevice/by-name/userdata of=data.img
or if you know number of partition
dd if=/dev/block/mmcblk0p18 of=data.img (p18 is on Huawei LDN, image size is that same as partition size 16GB/32GB/64GB..etc, so for bigger then 32GB need to use NTFS sdcard or exFAT sdcard and TWRP also has to support NTFS or exFAT).
Or edit etc/*.fstab and repack twrp. You can back up files from /data for now (as ext4 or f2fs). Just add line to back up full image of /data (as emmc).
If /data has ext4 filesystem it can easilly mount/unpack/scan/rip image. But if /data has f2fs ... got not cure.
Example:
/data f2fs /dev/block/bootdevice/by-name/userdata flags=length=-16384;backup=1;settingsstorage;encryptable=footer;
/data_image emmc /dev/block/mmcblk0p55 flags=display="Data Image";backup=1;flashimg;
Click to expand...
Click to collapse
Thank you very much for you point to point reply!
Finally, I choose to use that option with some modifications because vfat doesn't support files larger than 4GB.
Code:
dd if=/dev/block/bootdevice/by-name/userdata conv=noerror,sync bs=100M | gzip -c | split -b1000000000 - mybackup.img.gz
I have mounted this *.img partition using OSFMount for Windows. But after the scanning process (I was using R-Studio that supports ext4 file system I found my deleted files in the tree structure /media/0/DCIM/Camera but all of the deleted files has 0 bytes size and have 2 flags: deleted, wiped.
I couldn't understand how that happened. I mean I didn't use my phone after deleting files at all. I also mounted this *.img as raw disk in Active Undelete but the result is actually the same all of the deleted files have 0 bytes file size.
Is that a bug of the program? Or I have made an image using wrong command? Or Android 9 actually wiping files after deletion?
The files have been accidentally deleted by AirDroid-web app but I don't think so that this app is wiping deleted files it doesn't make sense...
RaTr said:
Thank you very much for you point to point reply!
Click to expand...
Click to collapse
You are welcome. Thank you are for note about 4GB file size limit on vfat/fat32, will save us from a lot of headache.
---------- Post added at 10:03 AM ---------- Previous post was at 09:49 AM ----------
RaTr said:
actually the same all of the deleted files have 0 bytes file size.
Click to expand...
Click to collapse
Maybe to try DiskDigger on phone if it is rooted to scan internal sd?
PhotoRec for Windows/Linux: https://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step
There are few programs to try on your image on GNU/Linux like extundelete, ext4magic, AnalyzeEXT, ext3grep ...
Source: https://askubuntu.com/questions/217606/undelete-files-on-ext4
I am trying to use ext4magic to recover deleted files. But I need a copy of the journal when I am trying to use command
Code:
debugfs -R "dump <8> /var/tmp/home.journal" /dev/mapper/home
I see that Team win terminal do not have this command how to add it or how to make a copy of the journal of my ext4 partition where I am trying to recover my files.
adeii said:
Maybe to try DiskDigger on phone if it is rooted to scan internal sd?
Click to expand...
Click to collapse
I have tried to use DiskDigger. When I am putting a filter to show only deleted files it doesn't show anything. Which is pretty strange.
adeii said:
There are few programs to try on your image on GNU/Linux like extundelete, ext4magic, AnalyzeEXT, ext3grep ...
Source: https://askubuntu.com/questions/217606/undelete-files-on-ext4
Click to expand...
Click to collapse
Next program that I have tried was TestDisk but looks like it doesn´t support ext4 file system.
Thank you for the advice about PhotoRec. It has support of ext4 system. But it won't help. So, there are still some options. I will try to use extundelete as the next one.
If you have an image of EXT4, then you can use 7-Zip Archiver to read all the files inside it.
jwoegerbauer said:
If you have an image of EXT4, then you can use 7-Zip Archiver to read all the files inside it.
Click to expand...
Click to collapse
7-Zip will show deleted files also?..
I have tried 2 more utilities:
1. ext4magic without external journal file. It has done the job but I couldn't find any files that I need.
2. extundelete that program restored less files and also no files that I want to recover.
One more strange thing:
I have installed R-Studio and opened my image there. I fount full list of my deleted files, but all of the records of my deleted files have 2 flags: deleted, wiped and it shows me that the size of that specific files is 0 bytes.
{
"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"
}
I have checked other files from different dates, they can be recovered, there is no flag wiped and also I can see the size, in some of them there is a flag cross-link, but I think it is normal, that means part of that file is already overwritten by another one.
RaTr said:
I have tried 2 more utilities:
1. ext4magic without external journal file. It has done the job but I couldn't find any files that I need.
2. extundelete that program restored less files and also no files that I want to recover.
One more strange thing:
I have installed R-Studio and opened my image there. I fount full list of my deleted files, but all of the records of my deleted files have 2 flags: deleted, wiped and it shows me that the size of that specific files is 0 bytes.
I have checked other files from different dates, they can be recovered, there is no flag wiped and also I can see the size, in some of them there is a flag cross-link, but I think it is normal, that means part of that file is already overwritten by another one.
Click to expand...
Click to collapse
I am stuck in the same situation bro
See it here I described the issue very similar to yours. Any luck in trying to recover that `ext4` data
RaTr said:
I found my deleted files in the tree structure /media/0/DCIM/Camera but all of the deleted files has 0 bytes size and have 2 flags: deleted, wiped.
Click to expand...
Click to collapse
expected.
emmc/ufs flash storage is handled different from hard disk drive. there is FTL controller with own firmware that is wear-leveling whole storage all the time. not to mention files are fragmented.
file system sends TRIM on each deletion of file. note the discard mount flag for userdata partition.
Android 4.3 Update Brings TRIM to All Nexus Devices
www.anandtech.com
Hi, I tried dd command, and it returned
Code:
dd: data.img: Read-only file system
But ./adb pull /dev/block/mmcblk0p57 57.img worked, and created a NDIF image.
Why dd did not work?
And which format of image would dd create?
Thanks.
you're trying to write into phones / rootdir. you cannot dump partition into phone itself. external MicroSD card or OTG pendrive is required. but you could redirect to stdout into remote file (note the quotes make the difference where > redirection is executed)
Code:
adb root
adb shell 'dd if=/dev/block/mmcblk0p57 bs=1m status=none' > data.img
open data.img file with HxD editor and have a look into first bytes. search for magic 53 ef at offset 0x438 to confirm it's ext4 image.
dd is useful in case no usb connection available (topic of thread). the result is same as adb pull. you can increase speed with block size (bs= default 512 bytes) up to 1 MB.
Note: on FDE encrypted phone one can't pull userdata directly. instead pull whatever is mounted /data (like /dev/block/dm-0)
aIecxs said:
you're trying to write into phones / rootdir. you cannot dump partition into phone itself. external MicroSD card or OTG pendrive is required. but you could redirect to stdout into remote file (note the quotes make the difference where > redirection is executed)
Code:
adb root
adb shell 'dd if=/dev/block/mmcblk0p57 bs=1m status=none' > data.img
open data.img file with HxD editor and have a look into first bytes. search for magic 53 ef at offset 0x438 to confirm it's ext4 image.
dd is useful in case no usb connection available (topic of thread). the result is same as adb pull. you can increase speed with block size (bs= default 512 bytes) up to 1 MB.
Note: on FDE encrypted phone one can't pull userdata directly. instead pull whatever is mounted /data (like /dev/block/dm-0)
Click to expand...
Click to collapse
Thanks for your reply.
What would be the differences between
adb shell 'dd if=/dev/block/mmcblk0p57 bs=1m status=none' > data.img
and
the method described in this message: https://stackoverflow.com/a/41214172 ?
Thanks.
streaming over netcat avoids unwanted characters using stty raw. on macOS probably result is no difference (after unpacking gzip).
you don't need this as you wrote adb pull worked (which is the easiest method)
aIecxs said:
streaming over netcat avoids unwanted characters using stty raw. on macOS probably result is no difference (after unpacking gzip).
you don't need this as you wrote adb pull worked (which is the easiest method)
Click to expand...
Click to collapse
Thanks.
I searched Hex in 57dd.img created by adb shell 'dd if=/dev/block/mmcblk0p57 bs=1m status=none' > 57dd.img.
It showed
Is the 53EF on line 1080 in the image above is the one you mentioned "at offset 0x438"?
right, that is ext4 magic at offset/byte hex (0x438)16 = (1080)10 dec
I have a slightly different but related question /problem. My apologies if this is not the right place to post.
On my Samsung A10e, TWRP (and other recoveries) gives me a tarfork 255 error when trying to backup userdata. Normally this should be 32GB in size from Samsung specs.
I have used two alternatives :
* adb pull /dev/block/by-name/userdata data.img which creates a 26G file on my linux PC, that I can mount and inspect. When I run filesystem check it throws out errors, probably due to some of the data being encrypted - I am running AOSP Android 11 gsi. Perhaps the same errors that prevents TWRP from working ?
* alternatively I have put in a clean 32GB SD card, then via adb shell run dd if=/dev/block/by-name/userdata of=/dev/block/mmcblk1p1 to copy the full userdata partition over to the SD card. Once removed from the phone and put in a card reader, again this can be inspected on my linux PC, and gives the same filesystem check errors. I also ran dd if=/dev/external_sd of=data2.img on my linux PC to create a similar image file as adb pull but it is now the full 32GB that I would have intially expected.
So why the size difference between adb pull and dd ?? Does adb pull actually get everything - in other words if I try and restore with adb push will the phone recover to previous state and boot ?
I was hoping to then reduce the size of my data copy to 16GB since on my phone I am only using 12GB of the 32GB, but file errors are preventing me at the moment.
I was thinking about wiping data and then with arm32 parted and adb shell creating a 16GB userdata partition and an additional 16GB user shadow partition - the latter only to be used locally via dd to do backup and restore and avoid TWRP errors.
that is very lightly due to encryption issues....esp Magisk is known to break encryption.
if you can decrypt at TWRP level and then proceed to backup user data via ADB shell to memory card that is your best bed and then wipe the partition and then restore your app data individually for apps that you need e.g. contacts db for contact an SMS. I strongly doubt if you will be able to restore that entire partition and boot to that original partition successfully.... it may have become what what we can call "encryption tainted"
excuse my typos