FORUMS
Remove All Ads from XDA

[REF] Details about /system RFS corruption and HOWTO correct it (fix included)

3,546 posts
Thanks Meter: 5,089
 
By supercurio, Retired Senior Recognized Developer on 22nd November 2010, 11:42 PM
Post Reply Email Thread
Hi there!

First, i probably need to reassure people who were scared by my posts: no there is no risk this corruption makes your phone die. It"s just about the state of the filesystem.

So, what triggers the corruption ?

Mounting any RFS filesystem without check=no

How is the filesystem corrupted ?

There are several symptoms:
  • Directory names gets CAPSED: Example: /system/bin becomes /system/BIN
  • files becomes unreadable, or directories becomes unlistable
  • user.log is created (seems it could be created in other situations)
Unfortunately, these errors are random.
I made previously an attempt of auto-detection + correction for Voodoo lagfix but didn't succeed because the filesystem errors seems to vary at each mount.

The more you write on a non-check=no mounted RFS, the more the corruption grows.
This is valid not only for /system but for any RFS.

I use a kernel which you say creates corruption but everything works! Are you a big fat lier who wants me to use Voodoo instead?

Hehe, I read that

Lots of things are strange about RFS and i hit several bugs during Voodoo 5 development, which is able to converts /system back to RFS
This is just another example of an RFS inconsistency. Why the hell should all filesystem be mounted only with -o check=no ?
Good question, this is absurd ^^

However, a RFS filesystem mounted without check=no stay usable as long as you continue to mount it without check=no. This is why sztupy and a lot of people didn't noticed it.
But I'm sure a few people had the issue after re-flashing another kernel and thought they made a mistake.
Official Samsung kernel don't boot, or boot but the /system has errors. Missing media files (sound?) or binary ? Yes, this is the cause.


Is this corruption report your personal interest ?

Yes, because it prevents migrating from an old ULF kernel to a Voodoo kernel.
But it's also the case with every other kernel except ULF based ones (not corrected in git ATM)
I lost a lot of hours because of this issue ^^
You know, it's just a bug. Needs to be corrected, that's all.

If the filesystem works fines on ULF kernels, why call this corruption?

Because it only mount properly on ULF kernels.
It does not work on every other including official Samsung ones.


Reaction of hardcore, Speedmod kernel's author:
Quote:
Originally Posted by hardcore

Chill out guys. Let me try to simply the situation:

1. Supercurio found a bug with ULFK 0.3. It was probably a typo or oversight, but it results in /system not getting mounted correctly, which corrupts /system in some slow way.

2. The corruption is there, but also not that bad because it will work fine for most people. The chance of it crashing or causing immediate harm is slim. And its fixable by a new firmware flash.

3. But nevertheless, its still a bug. And its fixable, and has been fixed in ULFK scripts. I have posted the fixed ULFK scripts already, so all the ULFK kernel makers can update it.

4. Since it is a ULFK bug, it is likely that all the active ULFK kernels devs will update their kernels to fix it.

5. When that happens, users of the older ULFK kernels will run into the same problem (unable to boot) that they run into when flashing back to stock/Voodoo/other fixed kernels. They will have to either (i) use this tool or other methods to fix it, or (ii) reflash their firmware.

The point is: It's a real problem with ULFK 0.3. But it won't cause much *immediate* harm. But its been fixed anyway in newer ULFK. And eventually all ULFK users will have to update and go through the 'conversion' hassle.

----------

Now for something non-technical. I really want to thank Supercurio for finding and sharing this problem. He didn't have to and we could just have continued to be un-informed. But he did, and even tries to make an 'easy' fix (which may not even be possible!).

I can't say the same for everyone, but if I know that there is a bug with the software, and there *is* a fix, then I'd rather implement the fix. Even though not doing so may not cause me any immediate damage. But it's really the individual person's choice.


In second post: how to correct the issue.

Big thanks to lots of people that took time to send the log helping understanding this issue during the development of Voodoo.
 
 
22nd November 2010, 11:43 PM |#2  
supercurio's Avatar
OP Retired Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,089
 
Donate to Me
More
Howto correct the /system RFS corruption issue
2 methods available
Quote:
Originally Posted by hardcore

Hi curio. Its not a proven working procedure but it might work.

http://forum.xda-developers.com/show...postcount=2709


And mine:


Okay!
My fully-automated solution attempt is ready.
Backup first.

Introducing Voodoo /system RFS fixer

Download: http://project-voodoo.org/downloads/...r-kernel-2.tar
Flash without repartition.


What does it do?

This kernel boots and detects current filesystems.

- If there is a RFS /system, this filesystem will be mounted with corrupted-compatible mount options
- A internal backup to the sdcard is made
- /system is formatted as RFS with fat.format using adequate parameters
- the backup is restored on the fresh /system mounted with correct options

After that, your all refreshed /system should free from corruption (if the source /system was)


Do I need this fix ?

If you plan to continue using the same kernel without changing in the future, no. Forget about it.

If you use an ULF-based kernel except Speedmod kernel from hardcore starting with K9, you should consider it before switching to a standard kernel.

The latest Voodoo lagfix converts /system as Ext4, that's why it's sensible to /system corruptions. But maybe you would not notice by yourself some missing media file or a strange crash because a lib was corrupt.


Is it 100% reliable?

Unfortunately it's not, and it cannot. I have reports of a small % of failures, that's why i don't recommend running it if you don't need it, and also doing backup of your /system if there is something interesting here.


Is it a lagfix?

No, it's based on Voodoo lagfix code but not a lagfix.
You cannot use it as a real Kernel, the conversion RFS<->RFS is run at each boot.


How much time does it take?

About 3 minutes with a standard system. Smaller roms takes less time.
You'll hear step1 step2 and it will boot.


3 minutes? nope, it takes forever

Sorry, this automated fix is unable to repair your /system.
Now you can try another method or quick: flash a stock kernel.


Are my personal data modified?

No.
Only /system is modified.
If something goes wrong, you can simply reflash a ROM or only a system using Odin.


Are my personal data modified?

What about backups ?
You can make/restore backups booting into recovery.
Default recovery is CWM Recovery, and when you boot in recovery there is no conversion involved.
Standard boot triggers the conversion/un-corruption.


I have a problem

This is young code. Tested but still young.
You can help by sending or joining your sdcard/Voodoo/logs directory zipped here.


Full source of the solution used :
https://github.com/project-voodoo/la...stem-rfs-fixer
The Following User Says Thank You to supercurio For This Useful Post: [ View ] Gift supercurio Ad-Free
23rd November 2010, 12:14 AM |#3  
Senior Member
Thanks Meter: 0
 
More
Damn it... I've been CAPSED!
23rd November 2010, 01:13 AM |#4  
supercurio's Avatar
OP Retired Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,089
 
Donate to Me
More
Code:
/system # ls
ls: ./FONTS: No such file or directory
ls: ./MEDIA: No such file or directory
ls: ./XBIN: No such file or directory
ls: ./APP: No such file or directory
ls: ./USR: No such file or directory
ls: ./ETC: No such file or directory
ls: ./firmware: No such file or directory
ls: ./BIN: No such file or directory
ls: ./user.log: No such file or directory
build.prop    default.prop  lib           lib
Trying to restore a CWM backup from a non-corrupting kernel don't work.
The RFS /system needs to be reformatted entirely.

A few minutes later:

Code:
ls -l
drwxr-xr-x    1 root     root             0 Nov 23 00:40 APP
drwxr-xr-x    1 root     shell            0 Nov 23 01:07 BIN
drwxr-xr-x    1 root     root             0 Nov 23 01:00 ETC
drwxr-xr-x    1 root     root             0 Nov 23 00:39 FONTS
drwxr-xr-x    1 root     root             0 Nov 23 00:39 MEDIA
drwxr-xr-x    1 root     root             0 Nov 23 00:40 USR
drwxr-xr-x    1 root     shell            0 Nov 23 00:39 XBIN
-rw-r--r--    1 root     root          1956 Nov 23 01:10 build.prop
-rw-r--r--    1 root     root             0 Nov 23 01:10 default.prop
drwxr-xr-x    1 root     root             0 Nov 23 00:40 firmware
drwxr-xr-x    1 root     root             0 Nov 23 01:10 lib
drwxr-xr-x    1 root     root             0 Nov 23 01:10 lib
-rw-rw-rw-    1 root     root           552 Nov 23 01:00 user.log
23rd November 2010, 01:18 AM |#5  
supercurio's Avatar
OP Retired Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,089
 
Donate to Me
More
After formatting system in official CWM:

Code:
~ # ls system
ls: system/lib: No such file or directory
23rd November 2010, 01:19 AM |#6  
supercurio's Avatar
OP Retired Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,089
 
Donate to Me
More
I think i'll build a custom kernel using Voodoo 5 guts to repair /system
gpnda
23rd November 2010, 01:20 AM |#7  
Guest
Thanks Meter: 0
 
More
Hmm so there is no way to fix it beside a complete reflash?
23rd November 2010, 01:22 AM |#8  
supercurio's Avatar
OP Retired Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,089
 
Donate to Me
More
Quote:
Originally Posted by gpnda

Hmm so there is no way to fix it beside a complete reflash?

Not yet.

My current recommendation is :
- make a CWM backup of your running working without problem system
- flash a stock firmware
- flash a non-affected kernel with CWM support (K9, Voodoo 5 snapshot)
- restore
23rd November 2010, 01:27 AM |#9  
betoNL's Avatar
Senior Member
Here, there, everywhere
Thanks Meter: 2,310
 
Donate to Me
More
Ok.. I got lost over there.....too many posts per hour or shall I say , per minute?

@ SUPERCURIO...
I flashed SpeedMod K8 300hz 341 MB ram this morning and evrything is working pretty fine .... iGo Motonav voice instructions dont stutter anymore. Wifi , Games, evrything smooooooth.

But about the file system corruption thing:
I didnt apply any lag scheme, only the tweaks...That means I am safe right?
Or those extra 40MB Ram took some bribing as well??

Hardcore brought up the K9...what's different? changelogs? details??

Thanks in advance....

Btw.....is there a tweak to improve sgs's FM sound quality?
23rd November 2010, 01:30 AM |#10  
Senior Member
Flag Enschede
Thanks Meter: 10
 
More
Quote:
Originally Posted by supercurio

Not yet.

My current recommendation is :
- make a CWM backup of your running working without problem system
- flash a stock firmware
- flash a non-affected kernel with CWM support (K9, Voodoo 5 snapshot)
- restore

My personally preferred alternative method (because it's all in CWM :P).
- make a CWM backup
- Use CWM to format .system & wipe the dalvik-cache.
(You may need to unmount /system before it can format /system)
- flash a non-affected kernel with CWM support (K9, Voodoo 5 snapshot)
- use CWM for Advanced restore -> system [/QUOTE]
23rd November 2010, 01:50 AM |#11  
Account currently disabled
Thanks Meter: 422
 
Donate to Me
More
I don't us that initramfs in my kernel. I hope that would be safe then.
But i get some question that people can't leave speedmod kernel and flash my kernel. It won't work, but if they flash back speedmod kernel it works. Maby it something else..


Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes