#9447 HIGH 10.1.3: fsck tweaks needed
Zarro Boogs per Child
bugtracker at laptop.org
Fri Oct 29 17:19:39 EDT 2010
#9447: fsck tweaks needed
-----------------------------------+----------------------------------------
Reporter: wad | Owner: dsd
Type: defect | Status: new
Priority: high | Milestone: 10.1.3
Component: initscripts | Version: not specified
Resolution: | Keywords:
Next_action: design | Verified: 0
Deployment_affected: | Blockedby:
Blocking: |
-----------------------------------+----------------------------------------
Comment(by martin.langhoff):
Looking more into this. On 10.1.2 builds...
fsck is not triggering during mount even if the mountcount is reached. If
I edit /etc/fstab to change the 'pass' of the / mountpoint from 0 to 1,
then it does fsck on boot. This happens post dracut chroots, controlled by
rc.sysinit
In that case, fsck seems to perform its job correctly -- specifically, it
seems we can remount /dev/mmcblk0p1 ro and then rw even though we're
chrooted deep into it. the kernel doesn't lose its marbles.
If you make the changes on this build, the fsck run finds a journal to
replay even if the shutdown was clean -- this means we're forcing the run
on the mounted-rw fs. One more hint that it's a bad idea to run fsck so
late...
Options:
* Stay where we are. fsck never runs, any fs corruption accumulates.
* Enable fsck late in the boot process. Fiddle rc.sysinit to remount ro,
or get dracut to only mount rw when needed (to write a lease!). Remounting
is fast on ext3, but slow on jffs2... the codepaths for this used to be
tangled -- check.
* Move fsck to happen in initramfs, include appropriate libs, etc.
Regardless of when we run it, we'd need some UI hint of what we're doing.
--
Ticket URL: <http://dev.laptop.org/ticket/9447#comment:20>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list