Database Users

How do I convert rfs to ext2 or ext4 MANUALLY?

How do I convert partitions manually? What are the commands or procedures without using software?

If you have fugumod or g3mod kernel you can put a fs.convert in their respective folders.
Just make a file with notepad and write for example:
stl6 ext4
And save it without .txt extension and put in /sdcard/Android/data/fugumod (if you use fugumod) or sdcard/Android/g3mod (if you use fugumod)
Remember:
stl6 is system
stl7 is data
stl8 is cache
ale_bot from xda app

I said I wanted to know the manual method But thanks for you willing to help!
Because I have another Android phone as well and I want to make a universal file system conversion application... To make life easier for every Android owner.
I was hoping someone could tell me everything I needed...

djjonastybe said:
I said I wanted to know the manual method But thanks for you willing to help!
Because I have another Android phone as well and I want to make a universal file system conversion application... To make life easier for every Android owner.
I was hoping someone could tell me everything I needed...
Click to expand...
Click to collapse
For that u'll need the kernel to support the fs so it cant be universal
also the manual way is different in different devices
P.S. : This ain't development, ask your questions in general or q/a

Please notice that even if you do convert manually, kernel is still supposed to support ext2/4 file system. Stock kernel does not support it, so in some way you have always to take in consideration which kernel you are running.

My kernel supports ext2
All I need is now some scripts...
for example /dev/stl12 is /system

djjonastybe said:
My kernel supports ext2
All I need is now some scripts...
for example /dev/stl12 is /system
Click to expand...
Click to collapse
I think "universal" is not so easy possible as you would like. Every device has another hardware and so the OS (although it's android) is not the same...
On Galaxy 3 the /system parition is /dev/stl6... not stl12
There is the app G3mod by Dympy / Dharam.
The "manual" way is advised here for you (convert.fs - file)
both ways only work on G3 with fugmod or G3mod-kernel...
If you wanna make your own "universal" app you need to do it the linux-way with mkfs -t ext?? /dev/stl??
with manual commands or within a script (maybe with cases --> "universal") in adb shell during CWM or script at booting, as the filesystems must not be mounted while converting!
However you won't be coming around learning to handle linux!

So I can do this?
su
mount -o remount,rw /dev/stl12 /system
busybox cp /system/* /sdcard/system_backup/
reboot recovery
Click to expand...
Click to collapse
# Now we are in CWM and we unmount /system manually (unless someone gives me the command I can replace this with the command to unmount /system???)
mkfs -t ext2 /dev/stl12
mount -o remount,rw /dev/stl12 /system
busybox cp /sdcard/system_backup/* /system/*
chmod 644 /system/*
sync
reboot
Click to expand...
Click to collapse
Do you think this process would work??? OR do I need to do something more? I believe ALL my commands are correct. Can I proceed or do I have to declare something somewhere so Android knows it's ext2 or is this fine ?

I hope this is ok ? I am going to try it out in two hours...

I tried it to convert it to ext2...
The conversion went succesfull
But after reboot it detects any partition I convert to ext2 as ext4... But ext4 is not supported :/ WTF?
Should I try mke2fs instead?

Upgrading to 4.2.2 Issue

I tried today to upgrade from 4.1.2 to 4.2.2 but it failed about 30% of the way through the upgrade and ended with the Droid on his back with a red x.
Its rooted but got stock recovery.
I did the same upgrade for my Nexus 4 to 4.2.2 from 4.2.1 and that upgraded fine.
What's causing the upgrade to fail?
Any help would be much appreciated.
Thanks
Jon
Sent from my Nexus 7 using XDA Premium HD app

look for the error message in /cache/recovery/recovery.log

If you comb thru the bigger threads on the 4.2.2 update....every imaginable problem and solutions are in there.
Sent from my cell phone telephone....

This is part of the log that shows the failure.
Any help would be much appreciated.
Thanks
Verifying current system...
failed to stat "/system/xbin/bttest": No such file or directory
file "/system/xbin/bttest" doesn't have any of expected sha1 sums; checking cache
failed to stat "/cache/saved.file": No such file or directory
failed to load cache file
script aborted: assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
E:Error in /cache/da55f917feee.signed-nakasi-JDQ39-from-JZO54K.da55f917.zip
Sent from my Nexus 7 using XDA Premium HD app

OK jonchill I will try to help out.
But only because you inadvertently disclosed a new OTA download (JZO54K->JDQ39) for nakasi.
Here's the deal:
The OTA process performs checksums on hundreds of individual files (and even partitions e.g. boot partition) before it begins any work. 100% of checksums must pass before anything gets changed by the OTA.
It's a safety feature meant to protect people from applying the wrong files to their tablets/phones. More importantly, the reason that it is done is because the OTA does not contain "replacement" files - it only has small binary "patch" files which can be used only in conjunction with the original file to create the intended replacement file. This is how OTAs can be so much smaller than a full ROM - the files already present are "patched" to create their replacements.
But the bottom line is that if *you* removed or altered any single file which is a target of the OTA patching process, these pre-installation checks will fail. (Even worse, it stops immediately - it is possible that you have more than one file involved in this. Because of this stop-on-first-fail behavior, you don't know yet whether or not there are more to come.)
When I say *you* I mean you personally plus any root-using apps which you installed and ran on your tablet. Could have been an app.
OK, now for the good news. I downloaded the OTA - thanks for providing the file name - and looked at the installer script; that installer script for JZO54K-> JDQ39 is shown here on pastebin. The file which your OTA is complaining about is "bttest" - and as it turns out, this check occurs on line 1040 - it is the third from last file checked. The only thing which comes after that is a check of
/system/xbin/dexdump
and
the boot partition ( EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX )
Now I don't have any idea what might have caused "bttest" to disappear from your ROM. On the off-chance that "dexdump" got deleted too, attached is a zip of those two files from the JZO54K distro.
This is not a flashable zip - it's just the two files. It's your responsibility to get them into /system/xbin/
Note their ownership info:
Code:
-rwxr-xr-x 1 root 2000 5448 Oct 2 14:49 /system/xbin/bttest
-rwxr-xr-x 1 root 2000 59828 Oct 2 14:49 /system/xbin/dexdump
If you restore them to /system/xbin/ make sure you
Code:
chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
chmod 755 /system/xbin/bttest /system/xbin/dexdump
I verified their SHA1 checksums (note these are the 2nd string of digits in the failing assert_check).
2bb363a3f434d165d1167d915c2ba44967e22071 bttest
e5e4d35038ed3e32a15194275806d90e64e003c6 dexdump
good luck.

I've downloaded the files and tried transferring them across to XBIN but it fails saying the folder isn't writable, I've tried changing the permissions on the folder but it errors saying can't set permissions.
What am I doing wrong?
Thanks

The /system partition is typically mounted "ro" - Read Only.
Root-aware file browsers typically have a toggle in their (root-related) menu to remount /system in rw mode, but you can easily do it yourself from the command line. (using a terminal emulator or adb). You just need to be root to do this. (Or you can just do everything in the custom recovery, in which case the /system mount point will be in "rw" mode by default)
C:\foo> adb shell
$ su
# mount -o remount,rw /system
(copy files into place, do chmods , etc)
# mount -o remount,ro /system

Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks

jonchill said:
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
Click to expand...
Click to collapse
Well, that's odd. I'm not really sure why that is happening. You could fool around with the mount command a little bit or just avoid all this nonsense and do what you need via adb in the custom recovery.
If your bootloader is unlocked, but you don't want to *flash* a custom recovery (I see you said you have stock recovery), you can nevertheless temporarily *boot* one, and just that temporarily booted custom recovery as in:
- put device in bootloader mode
C:\fubar> fastboot boot name-of-custom-recovery-image.img
(wait until it is booted)
C:\fubar> adb shell
# mount /system
# cp /sdcard/wherever/bttest /system/xbin/bttest
# cp /sdcard/wherever/dexdump /system/xbin/bttest
# chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
# chmod 755 /system/xbin/bttest /system/xbin/dexdump
# sync
# umount /system
reboot
I don't know how you originally rooted, but generally the adb connection from either custom recovery (TWRP/CWM) needs an additional USB driver (yes, even though you "already have ADB working with the normal OS"). I suppose most lazy folks use either a toolkit or the XDA Universal Naked driver for this. (No support will be given by me on driver installs - I need to draw the line someplace.)
good luck

Tried booting to a temp custom recovery (TWRP) and followed your instructions but still getting the Read-Only file system. At this stage would it be better to take a backup and re-flash a full image?
C:\NRT\data>adb shell
~ # ←[6n
~ # ←[6nmount /system
mount /system
~ # ←[6ncp /sdcard/bttest /system/xbin/bttest
cp /sdcard/bttest /system/xbin/bttest
cp: can't create '/system/xbin/bttest': I/O error
~ # ←[6ncp /sdcard/dexdump /system/xbin/dexdump
cp /sdcard/dexdump /system/xbin/dexdump
cp: can't create '/system/xbin/dexdump': Read-only file system
Thanks

Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?

bftb0 said:
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
Click to expand...
Click to collapse
Thanks for all your help, as this is going to be quite a bit more complex than first thought I'm going to leave the above until I come back from holiday.
Thanks again.

You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.

GedBlake said:
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
Click to expand...
Click to collapse
Ged
The OTA was what I received automatically.
I've already got XPlore and have tried what you suggested but get Can't write to file /system/xbin/bttest can't move temp file to /system/xbin/bttest.
Thanks

[SOLVED] Using Terminal Emulator to write to system

Not sure if this will help anyone else, but I searched forever trying to figure out how to write into the system folder using Terminal Emulator on the Note 3 to no avail. I found a slew of posts that said to type "mount -o rw,remount /system" to achieve this. When I used this command it didn't return any errors so I assumed it worked, however no files ended up being copied and pasted to the location I wanted. I found numerous other examples that were supposed to enable writing to the system as well, but none of them worked. I finally figured out how to get it to work on my Note 3 by typing "mount" in terminal emulator and noticing that at the very beginning of the string that was returned was "rootfs". So if you are wanting write to your system using Terminal Emulator on the VZW Note 3 here is what ended up working for me:
Code:
mount -o remount,rw rootfs
to return to read only enter:
Code:
mount -o remount,ro rootfs
I wanted to figure this out because a bug in TWRP v2.6.3.0 maimed my efs partition and bricklooped my phone. Even flashing the Stock Developer tar by Beans wouldn't bring it out of the brickloop. I was able to get out of the brickloop by following this thread, but even though my phone booted up and the IMEI # was correct, my /efs folder was missing in action. This caused odd things to happen like my lock screen not functioning and the power button instantly turning the phone off instead of bringing up the power menu. I discovered this was because the phone was placed into something called "factory mode" and that to fix it you needed to edit some files in the efs folder, which were completely missing on my device. Member js0uth graciously sent me his efs folder from his Developer Note 3 and when I copied it to my phone it began to function normally again (big shout out to js0uth!). However, this folder was completely deleted once again after a reboot. So now you can see why I was looking for a way to copy these files using Terminal Emulator. I ended up making a Tasker profile with the Secure Settings plugin that automatically copies the files from my ext SD card to my system folder on boot of the device. In order to mount, copy/paste the files while retaining the correct permissions from the folder that js0uth sent me, and unmount the system I had the set up my Secure Settings command as follows:
Code:
mount -o remount,rw rootfs;cp -Rpf /storage/extSdCard/efs/* /efs/;mount -o remount,ro rootfs
So now I have a livable workaround for my problem until I can discover a way for the phone to rebuild my own /efs folder.
Edit: See radionerd's post for a permanent fix to this issue and be sure to hit thanks under his name if it helps you.

I did the same to my DE. Corrupted EFS about a month ago after a few flashes using TWRP 2.6.3.0. Boot loops for 28 hours of hell until I followed your tracks to the trick that deleted my corrupted EFS folder, and created a new empty folder. I guess this would wipe out IMEI, Mac, and more in models that store phone specific data in EFS. We lucked out I've read that our phones have that info in a few other folder not EFS
Since wiping EFS I have run stock ROM, CM11, and now bean V6. I didn't see the factory mode popup until recently. I noticed that the screen will flash when leaving or entering cell service.
My corrupted EFS was 3MB. I'm curious what's the size of the EFS folder from js0uth?
Were you able to enter the factory mode on string? something like this?
Code:
# echo -n ON > /efs/FactoryApp/factorymode
this is from an S3
Thanks for documenting your steps to recovery.
radionerd

radionerd said:
My corrupted EFS was 3MB. I'm curious what's the size of the EFS folder from js0uth?
Click to expand...
Click to collapse
It's 1.04 MB. Sorry for taking so long to respond. I thought I had it set up to send instant emails for replies to this thread, but apparently I didn't.
radionerd said:
Were you able to enter the factory mode on string? something like this?
Code:
# echo -n ON > /efs/FactoryApp/factorymode
this is from an S3
Click to expand...
Click to collapse
Setting the Factorymode folder to ON is actually what disables that mode. Seems backwards I know, but when it's set to OFF (or if the folder is completely missing as in my case) that warning message will display. If that folder is intact on your phone then you should be able to use a string to disable or enable Factorymode.

It got worse before it got better
bodieism said:
It's 1.04 MB. Sorry for taking so long to respond. I thought I had it set up to send instant emails for replies to this thread, but apparently I didn't.
No worries, I went from an annoyance of no lock screen to bricked for over 6 weeks. This happened after trying to do an EFS backup.
I've learned a lot since back then, My DE is back 100%, EFS is repaired. I think we ran the same script which actually points to the wrong mount in our phones. It brought us out of bootloops, but efs was pointed to block12. Qualcom snapdragon Note-3's use mmblk0p11 to load /efs.
If you still have to load the tasker script, I think I figured out an easy fix to rebuild your original efs folder.
I would backup mounts first, delete /efs folder. Then run the original script, but this time change from 12 to 11.
Code:
adb shell
su
mke2fs /dev/block/mmcblk0p11
mkdir /efs
mount -t ext4 /dev/block/mmcblk0p11 /efs
Bet that would do the trick
Here is my thread
Click to expand...
Click to collapse

^ That did do the trick! :good:
Phone is back to 100% working order :highfive:

[Q&A] [DEV][19NOV] Native Mount DataOnEXT with DalvikOnNAND (Test #2)

Q&A for [DEV][19NOV] Native Mount DataOnEXT with DalvikOnNAND (Test #2)
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [DEV][19NOV] Native Mount DataOnEXT with DalvikOnNAND (Test #2). If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!

Hi, ph03n!x
I am using your DataOnExt in my htc vivo with vivokat 4.4.4 by Szezso and it works fine. However I have an unidentified problem with DalvikOnNand - nothing appeared in the logcat but mount was not done.
could you tell me what could be wrong with these commands (which are a part of my init.rc):
Code:
# create dalvik-cache and double-check the perms, so as to enforce our permissions
mkdir /data/dalvik-cache 0771 system system
chown system system /data/dalvik-cache
chmod 0771 /data/dalvik-cache
mount ext4 /dev/block/platform/msm-sdcc.2/by-num/p26 /data/dalvik-cache noatime nosuid nodev barrier=1,data=ordered,noauto_da_alloc,journal_async_commit,errors=panic,wait,check,encryptable=footer,length=-16384

MarsBlessed said:
Hi, ph03n!x
I am using your DataOnExt in my htc vivo with vivokat 4.4.4 by Szezso and it works fine. However I have an unidentified problem with DalvikOnNand - nothing appeared in the logcat but mount was not done.
could you tell me what could be wrong with these commands (which are a part of my init.rc):
Code:
# create dalvik-cache and double-check the perms, so as to enforce our permissions
mkdir /data/dalvik-cache 0771 system system
chown system system /data/dalvik-cache
chmod 0771 /data/dalvik-cache
mount ext4 /dev/block/platform/msm-sdcc.2/by-num/p26 /data/dalvik-cache noatime nosuid nodev barrier=1,data=ordered,noauto_da_alloc,journal_async_commit,errors=panic,wait,check,encryptable=footer,length=-16384
Click to expand...
Click to collapse
Can you post the output of mount command with this configuration? And all the mount command from init.rc?
While I'm not familiar with your device, have you tried using by-name/the_name_of_userdata instead of by-num in the mount command? You have check what it's name is.
I suspect that Dalvik mount is happening alright, otherwise your device will not boot. You can verify that by mounting data (the actual userdata partition) in recovery and seeing what it contains.

ph03n!x said:
Can you post the output of mount command with this configuration? And all the mount command from init.rc?
Click to expand...
Click to collapse
well, that's one of the problem - I can't see any output from these command at all. As far as I understand, it could be seen in kernel log, but I have no idea of how to enable it or where it is put by the kernel. As I mentioned, logcat has nothing of that.
the whole script is here (it's a boot.img-ramdisk.cpio.gz from the kernel) - I don't have the right for foreign links yet, but it should have been attached to this message
ph03n!x said:
While I'm not familiar with your device, have you tried using by-name/the_name_of_userdata instead of by-num in the mount command? You have check what it's name is.
Click to expand...
Click to collapse
I have used "by-num" because it was done this way in fstab. I guess my problem is in the mount-params, though, it would be nice to see the output.
ph03n!x said:
I suspect that Dalvik mount is happening alright, otherwise your device will not boot. You can verify that by mounting data (the actual userdata partition) in recovery and seeing what it contains.
Click to expand...
Click to collapse
I have checked this by mount-command after boot - It's not there and that is the reason for my concern. However, the boot works fine - dalvik is on the sd-ext (and I see it in the standard partition info)

MarsBlessed said:
well, that's one of the problem - I can't see any output from these command at all. As far as I understand, it could be seen in kernel log, but I have no idea of how to enable it or where it is put by the kernel. As I mentioned, logcat has nothing of that.
the whole script is here (it's a boot.img-ramdisk.cpio.gz from the kernel) - I don't have the right for foreign links yet, but it should have been attached to this message
I have used "by-num" because it was done this way in fstab. I guess my problem is in the mount-params, though, it would be nice to see the output.
I have checked this by mount-command after boot - It's not there and that is the reason for my concern. However, the boot works fine - dalvik is on the sd-ext (and I see it in the standard partition info)
Click to expand...
Click to collapse
The mount errors/ or anything related to mount will not show up in logcat, that is normal. Logcat is in the user space (after Android boots up), and all the mounts you do in init.rc happens in kernel space (When linux kernel boots, before it loads Android). DMESG or KMESG may have the mount commands (I haven't checked either in a long long time though).
I will look at the ramdisk later, but it will be helpful if you attach only the init.rc (rename it to init.rc.txt). I want to make sure you got the mount commands right, and you are mounting /data/dalvik-cache to /dev/block/platform/msm-sdcc.2/by-num/p26 AFTER mounting DataOnEXT is completed (otherwise /data/dalvik-cache will not be there for the Dalvik Cache to be mounted on /dev/block/platform/msm-sdcc.2/by-num/p26)
When you are in Android with the current configuration, connect it to your computer, do a go in to adb shell, do su if required (to get # prompt), and then type mount. Copy-paste what comes as output here.

ph03n!x said:
The mount errors/ or anything related to mount will not show up in logcat, that is normal. Logcat is in the user space (after Android boots up), and all the mounts you do in init.rc happens in kernel space (When linux kernel boots, before it loads Android). DMESG or KMESG may have the mount commands (I haven't checked either in a long long time though).
I will look at the ramdisk later, but it will be helpful if you attach only the init.rc (rename it to init.rc.txt). I want to make sure you got the mount commands right, and you are mounting /data/dalvik-cache to /dev/block/platform/msm-sdcc.2/by-num/p26 AFTER mounting DataOnEXT is completed (otherwise /data/dalvik-cache will not be there for the Dalvik Cache to be mounted on /dev/block/platform/msm-sdcc.2/by-num/p26)
When you are in Android with the current configuration, connect it to your computer, do a go in to adb shell, do su if required (to get # prompt), and then type mount. Copy-paste what comes as output here.
Click to expand...
Click to collapse
Thank you for the hint about dmesg - I've got the log finally but it doesn't have any error for the mount command either.
Even though the syntax of the mount command in the console is quite different, I will try it (a little later).
I have attached pure init.rc, although, it would be too simple to have a problem with the place of the mount-command in my case - the mkdir-command is not mine, it was there in the first place. I have also attached the dmesg dump file.

MarsBlessed said:
Thank you for the hint about dmesg - I've got the log finally but it doesn't have any error for the mount command either.
Even though the syntax of the mount command in the console is quite different, I will try it (a little later).
I have attached pure init.rc, although, it would be too simple to have a problem with the place of the mount-command in my case - the mkdir-command is not mine, it was there in the first place. I have also attached the dmesg dump file.
Click to expand...
Click to collapse
Ok, I think understand the issue now. fstab is mounting all your partitions AFTER init.rc is executed. So when you are mounting Dalvik on NAND from init.rc, it is probably being overridden by fstab when it mounts /data. Try the Dalvik on NAND mount in fstab...

ph03n!x said:
Ok, I think understand the issue now. fstab is mounting all your partitions AFTER init.rc is executed. So when you are mounting Dalvik on NAND from init.rc, it is probably being overridden by fstab when it mounts /data. Try the Dalvik on NAND mount in fstab...
Click to expand...
Click to collapse
Well, it turns out that it's not that simple at all. It's even simpler! In fact, I have misinterpreted the file-system manager's options - I misused them as the mount options which should have been shown in the log as an invalid argument error but never even appear there (at least in the kernel log). So, as far as I can understand the kitkat source code, it would be wrong to use another mount_all command in the post-fs-data section, which means that I can't use the fs_mgr-options at all.
The options I mean are these: wait,check,encryptable=footer,length=-16384
There is only one equivalent in the mount command for all of these options - the wait-flag.
I will check it later and post the result here.

The results of the check were not very helpful. The only thing that has changed was 5 seconds of wait_for_file timeout. Moreover, even when I rise the log-level up to 8, the only new thing was this couple of lines in the kernel-log:
Code:
<6>[ 8.995849] init: command 'loglevel' r=0
<6>[ 13.963317] init: command 'mount' r=-1
after which I checked the source and found that there was nothing more to expect. Thus, there is no way I could identify the problem in the kernel-log, though, the problem itself has been confirmed - it's an issue of the mount-command params.
ph03n!x said:
Try the Dalvik on NAND mount in fstab...
Click to expand...
Click to collapse
It seems to me that this is the only option left for me, but to implement it I'll have to create something like /dalvik directory in the root and after the mount_all, simlink it to the /data/dalvik-cache. This is going to be the next test.

/sdcard partition read only

My internal SD partition won't let me add or delete any contents on it. Anyone have a solution?

Could you please type "mount" in the terminal and copy it here?
It should be RW, you can try typing in the terminal: mount -o remount,rw /sdcard

Never mind. Got it working by rebooting to recovery, going through ADB, and chmod 777.

blackknightavalon said:
Never mind. Got it working by rebooting to recovery, going through ADB, and chmod 777.
Click to expand...
Click to collapse
Yes, I saw last nigh I was able to see your mount dump. You moved your /data and /sdcard partitions to f2fs. I have been trying to reproduce your issue and I have found the origin of it. It seems that you performed the backup of your internal sdcard using adb when switching to f2fs. In such case you indeed need chmod -R 777 /sdcard
I will update the guide accordingly.
Thanks for bringing this issue up.

Oki said:
Yes, I saw you had moved your /data and /sdcard partitions to f2fs. I have been trying to reproduce your issue and I have found the origin of it. It seems that you performed the backup of your internal sdcard using adb. In such case you indeed need chmod -R 777 /sdcard
I will update the guide accordingly.
Thanks for bringing this issue up.
Click to expand...
Click to collapse
It's not that I'm afraid of bricking a phone, it's that I want to keep it usable. That's probably why I won't ever buy another HTC phone until they get rid of CID and MID. And I was one of the guys who cracked the location of the ringtones/notifications on the original Galaxy Gear when it went to Tizen.
Anyway, I let it sit for 12 hours and, sure enough, the chmod fix stuck.

blackknightavalon said:
It's not that I'm afraid of bricking a phone, it's that I want to keep it usable. That's probably why I won't ever buy another HTC phone until they get rid of CID and MID. And I was one of the guys who cracked the location of the ringtones/notifications on the original Galaxy Gear when it went to Tizen.
Anyway, I let it sit for 12 hours and, sure enough, the chmod fix stuck.
Click to expand...
Click to collapse
Your sdcard dump was very useful. At least I was able to see it before you deleted it. It led me to the origin of this issue. We are lucky with the 2017U, it doesn't have the DFU mode of the 2017G. Ours at least is unbrickable due to the EDL mode. When doing testing or trying new things, a safe backup is all you need.