Hi,
I've been struggling for days installing any custom rom into my defy.
When I finally checked the log, I saw it interrupted with "no space left on device" about halfway through.
But there still is space, only 32% are in use (~100MB of~ 300MB).
/system just ran out of inodes.
Finally I succeeded after I removed most of the terminals in /etc/terminfo/* from the latest nightly before installing it. (CM10, 20130110, that is)
df -i /system
Filesystem Inodes Used Available Use% Mounted on
/dev/block/mmcblk1p21 1968 1915 53 97% /system
I don't understand, how come /system only has ~2000 inodes (typical should be ~10k)?
(I'm not the first owner, so I don't know what happened to the device before...I got it with some Vodafone branded firmware on it, but you never know..)
I'm afraid of simply formatting it, because bootmenu and recovery seem to be running from /system, and formatting might render the device nonfunctional.
How do I get back to a proper fs?
Is there a way to safely format /system?
Or should I better tune2fs?
Anyone seen this before?
Thanks,
mcr42
Ran out of inodes! ("No space left on device")
I seem to have the same problem. A few days after doing a fresh install of CyanogenMod7.2 + Googleapps, I start to get Gapps and other processes crashing all the time. Looking in the logfiles using "adb logcat -d" even immediately after bootup, it reports:
W/BatteryStats( 2274): Error writing battery statistics
W/BatteryStats( 2274): java.io.FileNotFoundException: /data/system/batterystats.bin.tmp (No space left on device)
and indeed I have lots of space, but no inodes left at all:
df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mmcblk1p25
130837 97898 32939 75% /data
df -i .
Filesystem Inodes Used Available Use% Mounted on
/dev/block/mmcblk1p25
1296 1296 0 100% /data
Can anyone suggest what's going on and how to fix it?
Thanks,
Richard
P.S. As a bit of background, I wonder if things have got messed up on an earlier install when a while back after using S2E to move most things to an ext4 partition on the SD card, I later used S2E to revert the system to normal, but it crashed half-way through the process. I believe that is sorted now as "mount" doesn't report looking for anything on sd-ext partition (which I have removed since anyway):
rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/mmcblk1p21 on /system type ext3 (ro,relatime,barrier=1,data=ordered)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk1p24 on /cache type ext3 (rw,nosuid,nodev,noatime,nodiratime,errors=continue,data=ordered)
/dev/block/mmcblk1p25 on /data type ext3 (rw,nosuid,nodev,noatime,nodiratime,data=ordered)
/dev/block/loop7 on /pds type ext3 (rw,nosuid,nodev,noatime,nodiratime,barrier=1,data=ordered)
ramfs on /tmp type ramfs (rw,relatime,relatime)
/dev/block/vold/179:1 on /mnt/sdcard type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0602,dmask=0602,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/block/vold/179:1 on /mnt/secure/asec type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0602,dmask=0602,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /mnt/sdcard/.android_secure type tmpfs (ro,relatime,size=0k,mode=000)
CM10 latest nightly is the unofficial late august build by sunnyqeen. If you have custom recovery, flash AROMA wiper (search) and fully wipe system, data and cache in ext4 and then immediately flash ROM and gapps.
Is there a way to increase the number of inodes on /data?
Following up my email, I've been looking through the full list of files on /data (the number closley tallies with the 1296 inodes available). There were quite a few (but not excessive number) of debug files in /data/system/dropbox which I've deleted to free up a few inodes. However 1296 inodes doesn't seem sufficient. Does this tally with what most people have on their Defy phones? Grateful if someone could connect to their phone and run the following:
adb shell df -i /data
I have seen there have been reports of ClockworkMod Recovery prior to version 6 corrupting inodes:
http://forum.xda-developers.com/showthread.php?t=2111734
Grasping at straws, could this be what is happening resulting in a loss of inodes?
(Rebooting to (Cyanmod) recovery mode on my phone reports "Bootmenu Recovery v5.0.6" - does that tie in with CWM v5 then?)
Richard
Related
So, I can't find an active thread that solves this issue, here goes.
I have a G1 running RC29 w/out fastboot. If I boot to recovery console, I can press Alt+L and get the command screen. I then get two errors:
Code:
E:Can't open /cache/recovery/command
E:Error in CACHE:recovery/log (No space left on device)
Alt+L and Call+Menu+End are the only button combinations that do anything. Alt+W and Alt+S do nothing, so I cannot load any update.zip files.
I can't adb shell, I have to telnet into the device.
If I type df, the results are:
Code:
/dev: 49564K total, 0K used, 49564K available (block size 4096)
/sqlite_stmt_journals: 4096K total, 0K used, 4096K available (block size 4096)
/data: 76544K total, 3836K used, 72708K available (block size 4096)
/cache: 69120K total, 69120K used, 0K available (block size 4066)
/sdcard: 1916856K total, 89424K used, 1827432K available (block size 4096)
Typing mount returns:
Code:
rootfs / rootfs ro 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
/dev/block/mtdblock3 /system yaffs2 ro 0 0
/dev/block/mtdblock5 /data yaffs rw,nosuid,nodev 0 0
/dev/block/mtdblock4 /cache yaffs rw,nosuid,nodev 0 0
/dev/block/mmcblk0p1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1000,fmash=0711,dmask=0700,codepage=cp437,iocharset=iso8859-1,utf8 0 0
So, clearly my /cache partition is full, which means I can't do much of anything. Attempting a Factory Data Reset from within the OS returns:
Code:
No reset was performed because the System Clear service is not available.
From within the telnet, if I ls from within /cache I have two directories, recovery and lost+found. I can delete and recreate /recovery. /lost+found, however refuses to delete, claiming "directory not empty" but when I cd to it and then ls, nothing appears.
At this point, I'm severely stuck and have been unable to find a solution with either Google or IRC. I'm told that I could fix it with
Code:
fastboot erase recovery
except I don't have fastboot and cannot load the SPL because the recovery console won't respond.
At this point, I'll try anything as the phone is pretty much useless. If you power it off, it reboots instead. I have to pull the battery to turn it off.
do you have adb installed?
oshizzle1991 said:
do you have adb installed?
Click to expand...
Click to collapse
Yes, I do.
I remember my G1 had a similar problem but I can't remember what I did to fix it but I'm pretty sure there is some helpful info around the site it's just going to be scatered all over
After hours reading tons of posts I got my ADP1 (Android Developer Phone1) rooted. My current setup is
Phone: ADP1 G1 | 32B | HTC Dream
Rom: COS-DS (http://forum.xda-developers.com/showthread.php?t=950765)
Recovery: Amon RA-Dream-v1.7.0 (http://forum.xda-developers.com/showthread.php?t=566669)
Radio: 2.22.28.25 (http://forum.xda-developers.com/showthread.php?t=831139)
SPL: 1.33.0013d (http://forum.xda-developers.com/showthread.php?t=831139)
microSD: 96MB swap + 512MB ext4 + FAT32
Code:
~ # free
total used free shared buffers
Mem: 112616 110680 1936 0 604
Swap: 23548 20476 3072
Total: 136164 131156 5008
# cat /proc/partitions
major minor #blocks name
7 0 668 loop0
7 1 4508 loop1
7 2 1760 loop2
31 0 256 mtdblock0
31 1 5120 mtdblock1
31 2 2560 mtdblock2
31 3 93184 mtdblock3
31 4 27648 mtdblock4
31 5 93952 mtdblock5
253 0 23552 zram0
179 0 992000 mmcblk0
179 1 398437 mmcblk0p1
179 2 500000 mmcblk0p2
179 3 93562 mmcblk0p3
~ # mount
rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mtdblock3 on /system type yaffs2 (ro,relatime)
/dev/block/mtdblock5 on /data type yaffs2 (rw,nosuid,nodev,relatime)
/dev/block/mtdblock4 on /cache type yaffs2 (rw,nosuid,nodev,relatime)
/dev/block/loop0 on /system/lib/modules type squashfs (ro,relatime)
/dev/block/loop1 on /system/fonts type squashfs (ro,relatime)
/dev/block/loop2 on /system/xbin type squashfs (ro,relatime)
/dev/block/vold/179:2 on /sd-ext type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered,noauto_da_alloc)
/dev/block/vold/179:1 on /mnt/sdcard type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/block/vold/179:1 on /mnt/secure/asec type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /mnt/sdcard/.android_secure type tmpfs (ro,relatime,size=0k,mode=000)
I would like to know if there is any optimization?
Why should I do the customMTD? (http://forum.xda-developers.com/showthread.php?p=7061471#post7061471)
I'm not using ClockworksMOD as described by COS-DS. Should I? (http://forum.xda-developers.com/showthread.php?t=950765)
My partition order is different as described by COS-DS. Does it matter?
Using customMTD you could assign your cache memory (around 27MB) as internal memory.
Clockwork, I don't like much, but this is my personal opinion. Advantage(?) of Clockwork: you can flash unsigned zip files.
Partition layout probably matters, because on system startup there is a chance, that they are not mounted.
Sent from my Gingerbread on Dream using XDA App
I found customMTD to be difficult to install (I did it with firerat's Magpie ROM), but worth it for the extra space it gave me. Prior to, I was getting low on disk space messages and random shutdowns galore.
I don't recall why, but during my research I recall learning that Amon-Ra is stable and Clockwork isn't if you're going to use customMTD.
# mount
mount
rootfs on / type rootfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mtdblock3 on /system type yaffs2 (rw,noatime,nodiratime)
/dev/block/mtdblock5 on /data type yaffs2 (rw,nosuid,nodev,noatime,nodiratime)
/dev/block/mtdblock4 on /mnt/cache type yaffs2 (rw,nosuid,nodev,relatime)
/dev/block/vold/179:1 on /mnt/sdcard type vfat (rw,dirsync,nosuid,nodev,noexec,r
elatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,
iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/block/vold/179:1 on /mnt/secure/asec type vfat (rw,dirsync,nosuid,nodev,noe
xec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=c
p437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /mnt/sdcard/.android_secure type tmpfs (ro,relatime,size=0k,mode=000)
#
Guys this is on hyperdoid, Don't know about others but i have other backups of different roms as well will give it a shot.
Is it the reason why most of the chef's says you should shutdown instead of reboot to avoid data lose? :-s
All the partition are given RW access.
What to do? Please help
didn't anyone find it strange or its just me?
I don't find this strange.
I wouldn't worry about it. If it does bother you, remount them R/O?
skymera said:
I don't find this strange.
I wouldn't worry about it. If it does bother you, remount them R/O?
Click to expand...
Click to collapse
ok thank you for response.
Then why OEM ROM Builders always set system partition as RO?
Isn't it if you have sudden crash or phone fall down there is more chances that you will lose data or be left with corrupted partitions?
Regards
Nevermind Fixed it myself.
Now i am sure i won't be having any bad effect on my System partition as its read only during the phone operation (after booted up).
I will ask Tytung to add this in his kernel.
Regards.
After installing new CM ROM: http://forum.xda-developers.com/showthread.php?t=1779324
Most things function fine, with a few hiccups. However, any time the phone is rebooted, it goes back to default settings. As if it cannot save anything.
So I pulled this out of dmesg:
Code:
VFS: Can't find ext3 filesystem on dev mmcblk1p25.
Which corresponds to /data in /system/etc/fstab.
Could anyone give some insight into this? Would it be safe to format to ext3?
t1nk_2 said:
After installing new CM ROM: http://forum.xda-developers.com/showthread.php?t=1779324
Most things function fine, with a few hiccups. However, any time the phone is rebooted, it goes back to default settings. As if it cannot save anything.
So I pulled this out of dmesg:
Code:
VFS: Can't find ext3 filesystem on dev mmcblk1p25.
Which corresponds to /data in /system/etc/fstab.
Could anyone give some insight into this? Would it be safe to format to ext3?
Click to expand...
Click to collapse
Not sure what the problem is, but do not format it to ext3. If you format it, there's a chance you'll brick since the key of the partition will change, and our locked bootloader requires them to be at a specific setting. All the format options in the recovery are really rm -rf commands (just deletes everything) and don't really format at all.
I'd wipe data\factory reset (from cwm) and reinstall the rom. If that doesn't work, then go here and download Quarx's latest build for the Bravo or over to my PA thread and download its latest. You can use PA exactly like CM10 by disabling PA's hybrid UI. I know for sure that PA version works cause I used if for a month before flashing a 7 port I'm started working on yesterday.
Good luck
skeevy420 said:
Not sure what the problem is, but do not format it to ext3. If you format it, there's a chance you'll brick since the key of the partition will change, and our locked bootloader requires them to be at a specific setting. All the format options in the recovery are really rm -rf commands (just deletes everything) and don't really format at all...
Click to expand...
Click to collapse
I did find in /default.prop:
Code:
# ADDITIONAL_DEFAULT_PROPERTIES (From bootmenu/config)
...
# Forbid format of these partitions in mount menu (use only rm -r)
ro.cwm.forbid_format=/misc,/devtree,/config,/boot,/recovery,/pds,/system,/logo
Most of those are mounted with an "emmc" filesystem/module I've never heard of in linux.
I'd wipe data\factory reset (from cwm) and reinstall the rom. If that doesn't work, then go ... and download Quarx's latest build for the Bravo or over to my PA thread and download its latest. You can use PA exactly like CM10 by disabling PA's hybrid UI. I know for sure that PA version works cause I used if for a month before flashing a 7 port I'm started working on yesterday.
Click to expand...
Click to collapse
Unfortunately, installing any ROM fails to fix the issue. Tried PA first, got stuck in a bootloop. That leads me to believe ROMs will always require a working file structure.
I did however 'factory reset/wipe cache' from stock recovery (which claimed to format /data), load ROM, reset/wipe, reboot.
This did appear to solve the absence of /data mount. But it did not resolve the userdata persistence between reboots.
I found in /data/system/uiderrors.txt:
Code:
11/2/12 5:19 PM: No settings file; creating initial state
I tried changing some permissions via adb shell, but these were reset on reboot.
I suspect something with the init scripts is reseting something (it shouldn't be) on boot, however this is an area unfamiliar to me. I know some of those files are readable, I guess I'll have to just go through them line by line and see what makes sense....
CM 10-20120912-NIGHTLY-mb520
Build: cm_mb520_userdebug 4.1.1 JRO03L eng. quarx.20120912.233429 test-keys
Bootmenu v2.0-beta + Bootmenu JB Recovery v5.7.0-kobe
Didn't find anything conclusive in the parsable sections of init.* files, however I did notice that they often mount partitions and setup permissions.
On further digging into my phone, I saw that my *original* /data mount was still failing to function. Even though it has been repopulated under rootfs.
My output of mount:
Code:
rootfs on / type rootfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/mmcblk1p21 on /system type ext3 (rw,relatime,barrier=1,data=ordered)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/loop7 on /pds type ext3 (rw,nosuid,nodev,noatime,nodiratime,barrier=1,data=ordered)
ramfs on /tmp type ramfs (rw,relatime,relatime)
/dev/block/vold/179:1 on /mnt/sdcard type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage
/dev/block/vold/179:1 on /mnt/secure/asec type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,cod
tmpfs on /mnt/sdcard/.android_secure type tmpfs (rw,relatime,size=0k,mode=000)
If someone could paste their output (working ROM) for comparison, please.
This might help explain why my internal storage reads as 0Gb available, preventing Play store installs (I can force copy backups via adb).
At least I can enjoy JB so long as I don't reboot/power off.
From Quarx CM10 Custom Kernel Defy Plus 11\04 (running on a Bravo)
Code:
rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk1p21 on /system type ext3 (ro,relatime,data=ordered)
/dev/block/mmcblk1p24 on /cache type ext3 (rw,nosuid,nodev,noatime,nodiratime,errors=continue,data=ordered)
/dev/block/mmcblk1p25 on /data type ext3 (rw,nosuid,nodev,noatime,nodiratime,errors=continue,data=ordered)
/dev/block/loop7 on /pds type ext3 (rw,nosuid,nodev,noatime,nodiratime,barrier=1,data=ordered)
ramfs on /tmp type ramfs (rw,relatime,relatime)
/dev/block/vold/179:1 on /mnt/sdcard type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/block/vold/179:1 on /mnt/secure/asec type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /mnt/sdcard/.android_secure type tmpfs (ro,relatime,size=0k,mode=000)
Here's one option you could try -- fsck to repair the filesystem of any damage.
reboot into recovery
start adbd (Advanced->Start adbd)
open a terminal\command prompt (on PC...)
adb remount
adb shell
su
umount /data
e2fsck -fv /dev/block/mmcblk1p25
reboot and hope it worked
While a crappy option, have you tried flashing the sbf yet? If flashing the sbf two or three time in a row doesn't fix your issues then (probably) nothing will.
Being that the fs was never mounted:
adb shell
su
e2fsck -fv /dev/block/mmcblk1p25
And output:
Code:
e2fsck 1.41.11 (14-Mar-2010)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/block/mmcblk1p25
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Which made me want to simply format. I don't know about "signatures", is there a blkid-like function under /system/bin? AFAICK init scripts only refer to /dev fs when mounting.
...have you tried flashing the sbf yet?...
Click to expand...
Click to collapse
In the course of events, yes, I did. This is how it went: from Bandroidx recovery + BravoX ROM (working fine), installed CM10 (w/o clearing anything, I was excited) managed to get a mostly working system w/o gapps. Not knowing it came with its own bootmenu, tried installing Bandroidx again. Led to bootloader error. Flashed fixed_bravo_sbf.sbf. Got CM back. Not sure when /data was corrupted...
I also have p4_kobe_umts_kobe_user_3.4.2-125_KOB_FFW-4_product-keys-ATT-US_ATT-signed.sbf, and noticed a size difference. If I go this route, should I try this one? Or fixed_bravo_sbf.sbf again? Thanks again for the input.
The umount command is just for safety . Here's the output from a working /data from CM10
Code:
[email protected]:/system/bin # e2fsck -fv /dev/block/mmcblk1p25
e2fsck 1.41.11 (14-Mar-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
662 inodes used (0.80%)
50 non-contiguous files (7.6%)
1 non-contiguous directory (0.2%)
# of inodes with ind/dind/tind blocks: 83/4/0
32693 blocks used (9.91%)
0 bad blocks
1 large file
329 regular files
320 directories
0 character device files
0 block device files
1 fifo
0 links
1 symbolic link (1 fast symbolic link)
2 sockets
--------
653 files
There is a major difference between the full and fixed sbf. The fixed sbf only contains the bootloader and devtree (maybe ramdisk as well). The full sbf contains the full stock system. The fixed is mainly for those that accidentally flash a Defy boot.img or devtree.img when flashing or porting Defy roms.
While it sucks, it sounds like you just need to flash the full sbf and start over from scratch. I usually flash the sbf once every other month even if nothing is wrong (just makes me feel better).
From what you said above, /data was probably corrupted when you flashed CM10 without wiping data. Unless I'm flashing the same rom over and over again (when testing ports out, etc) I always do a factory reset when flashing. Its the safest way to go and you'll get better support from devs when you flash onto a blank slate (easier to debug since /data not being wiped is usually the cause of random bugs). It may have been from installing BandroidX Recovery since it uses the stock init scripts. Never install BandroidX Recovery. It is very obsolete and only useful if you plan on using BravoX, and even then you can use Defy 2nd-init recovery (just set it to boot to stock). More than likely it was from the non-wiped flash.
Flashing original .sbf worked! :victory:
Rooted, installed 2ndInitDefy, and backed up everything from there to sdcard.
/data now mounts correctly, and userdata persistence in CM10 is functional. :highfive:
Learn something new every day.
t1nk_2 said:
Flashing original .sbf worked! :victory:
Rooted, installed 2ndInitDefy, and backed up everything from there to sdcard.
/data now mounts correctly, and userdata persistence in CM10 is functional. :highfive:
Learn something new every day.
Click to expand...
Click to collapse
Glad to here you're not screwed :victory:. The best thing about the Bravo is you can fix it just like you do Windows -- if it breaks, just reinstall -- if you can't reinstall then its time for an upgrade cause ya broke it .
I have a phone here (G935f) which has a problem in mounting the /efs, and /system
I am trying to play with it and mount those errors with adb command, after installing the TWRP I tried to observe and check the phones log.
I hope I am not wrong in mounting the efs location /dev/block/platform/155a0000.ufs/by-name/EFS at /efs
Basically this is what I have with it (with ls command)
Code:
boot property_contexts
cache recovery
charger res
data root
default.prop sbin
dev sdcard
efs seapp_contexts
etc selinux_version
external_sd sepolicy
file_contexts service_contexts
file_contexts.bak sideload
fstab.samsungexynos8890 sys
init system
init.rc tmp
init.recovery.samsungexynos8890.rc twres
init.recovery.service.rc ueventd.rc
init.recovery.usb.rc ueventd.samsungexynos8890.
license usb-otg
oem vendor
proc
When I check the efs directory its empty.
Also the mount command shows me this:
Code:
rootfs on / type rootfs (rw,seclabel,size=1676116k,nr_inodes=419029)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,seclabel,relatime)
/dev/block/sda18 on /data type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/sda18 on /sdcard type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/sda15 on /cache type ext4 (rw,seclabel,relatime,data=ordered)
I tried to mount it with "mount ext4 -w -t blabla", but this model of phone really hard for me to understand its system.
I hope someone outthere is willing to play me with this.
Thanks.