yungjeng1119 wrote:
請問這帖k9-300的核心是不是以修正使用第二項voodooo無法開機問題
因為小弟剛剛直接載下來換了核心可以開機目前正常運作沒有使用voodoo-system-rfs-fixer-kernel.tar修正檔
不是刷K9系列，就一定會無法開機
而且未必要刷K9才會無法開機
之前有些人選voodoo後無法開機，也應刷Voodoo修正核心來修理
簡單的說，只要刷K9成功，就是代表/system問題已經解決了
所以..恭喜你成功了
所以我也照著刷(我的2.2是官方版 )
想當然，災情不少，
所以一開始先刷fix kernel
再刷k9 256
果然，不會卡在開機畫面，
但是，
進k9之後
首先就是wifi一直在取得ip位址
再來是我的root不見了。
還有我的re管理員也不見
再來就是k9 256 順暢度 遠輸我的 k8 256 (launcher pro+ voodoo)
後來我整個還原原廠設定、wipe(data+cache)、關機再開機重新lagfix和安裝super user
ok，root有了，wifi抓到了
但是re管理員還是不在，再來就是順暢度還是輸我的k8 256
所以…目前動態是，還原剛刷好官方jpd的狀態後，刷回k8-256，對k9死心。
應該是個案，僅供參考。
danieliememe wrote:
，而且是出在/system掛載在rfs格式 filesystem上，也就是選用voodoo 選項。
謝謝d大的說明，不過針對d大上面的說法，有個看法。
根據xda的討論串，在ULF kernel中，所有的lagfix選項都不會去轉換/system，所以/system都會一直是以rfs的格式運作。因此跟選不選用ULF kernel中的voodoo是沒有關係的。只要是使用過未修正的ULF kernel，/system都會有corruption的可能，跟選那一種lagfix選項無關。所以SpeedMod的作者才會建議還是需要去修正它。基本上這個問題跟用不用voodoo選項是沒有關係的。
------------
引用一下hardcore原文
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.
「試想，三星怎會在/system 設定為r/o之後，還用init來寫入/system呢？
事實上，我的sciprt之再掛載/system r/o都是在init已經啟動之後，而不是init啟動前」
-----------ULK作者sztudy說-------------
1. I don't know how severe this corruption is. Except from supercurio I didn't heard any problems about this.
2. the only real corruption I've found is when an rfs partition gets mounted as vfat (and mount -t auto will always mount an rfs parition as vfat).
3. there is no fsck.rfs, as it's included in samsung's init script (it gets exdecuted on the line exec apply_disk_policy)
4. samsung mounts /system as ro,check=no and after that it WRITES to the /system partition (wtf?)
From this, and if this corruption thing is actually true, I think that there are some strange things happening in the "exec apply_disk_policy" part, and that's where the corruption (might) happen. Or it can also be, that /system never gets checked on my setting as it's not actually mounted as "ro". (If _not_ mounting a filesystem as "ro,check=no" will corrupt it, then rfs is probably more flawed than anything else in the universe), or it can be that fsck.rfs gets run, but it corrupts /system as it's not mounted ro (fscking a device while it's mounted rw is bad for health). I don't know, never encountered this problem (mainly because I stick with ULTK).
If using the mount option ro,check=no solves this issue then only one question is remaining: WHY DOES SAMSUNG'S init.rc WRITE TO /system IF IT'S MOUNTED ro? (My script remounts /system ro after init has run, and not before running init, so init.rc can do it's modifying in /system)
__________________
當然，從bug角度而言，少了這指令是有可能會發生無法掛載的currption情形，雖然不是每次都有，但這的確算是bug。
上面的紅字就是講到順序上的問題所在
如果直接解讀這指令的字面意義是「重新掛載後，設定為r/o，然後要去check=no」，是不是很難理解這指令為何要去檢查之後，才讓init.rc寫入/system?
換成是三星時，不會在已經將/system設定為r/o後，還要執行init.rc（因為寫不進去啊...所以會當掉）
因為真正造成currption的原因，Voodoo作者在FAQ講了
Mounting any RFS filesystem without check=no
--->是什麼狀況下，會需要remounting，然後才會"偶爾"發生mounting currption?
--->就是還保留使用rfs格式的lagfix選項...也就是八項裡的第二及第三項 Voodoo會需要remount rfs，而且是重做lagfix之後的remount，就會需要remount rfs.
--->這也是為何其他選項不會出事的原因所在，也解釋了之前有人在轉換lagfix至voodoo選項時會卡住的原因所在（我之前也弄不清楚這神秘事件，直到今天）
--->而一旦重刷了K9版，因為有了這項新指令要mount 還要check=no，而將原本不會currption的ULK核心（也包括我今天試刷的例子）給currption!!
所以我才說，大家講的都是正確
但真的會讓不清楚狀況的人，更多遲疑
danieliememe wrote:
這篇我昨天已經看過，但真正將問題全貌點出來的，是ULK作者sztudy說的
「試想，三星怎會在/system 設定為r/o之後，還用init來寫入/system呢？
事實上，我的sciprt之再掛載/system r/o都是在init已經啟動之後，而不是init啟動前」
是的，這段我也有看到，這是sztudy對於這個問題所提出的質疑。認為在整個程序中有著奇怪及矛盾的現象。然而面對RFS這個黑盒子來說，這些疑問可能要有samsung的insight source才能清楚了。至於算不算bug? 如果 mount without -o check=no不會進一步破壞檔案系統內的資料而且使用者以後都打算只用sztudy原生UFL kernel，那可能可以不算是bug。
至於voodoo，不管是supercurio的vooodoo kernel還是UFL kernel的voodoo option跟這個"bug"實際上是沒有因果關係的。
這部份才是我在看完xda討論串後對d大認為bug是在voodoo的說法感到疑惑的地方。
內文搜尋
從 APP 打開
X