#11757 HIGH 11.3.1: /etc/adjtime in pristine corrupt in runin

[Zarro Boogs per Child]

#11757: /etc/adjtime in pristine corrupt in runin
---------------------------------------------+------------------------------
           Reporter:  martin.langhoff        |       Owner:  martin.langhoff
               Type:  defect                 |      Status:  new            
           Priority:  high                   |   Milestone:  11.3.1         
          Component:  manufacturing process  |     Version:  not specified  
         Resolution:                         |    Keywords:                 
        Next_action:  diagnose               |    Verified:  0              
Deployment_affected:                         |   Blockedby:                 
           Blocking:                         |  
---------------------------------------------+------------------------------

Comment(by Quozl):

 Some research.

 /etc/adjtime is in /etc/rwtab, /etc/rwtab is processed by /etc/rc.sysinit,
 /etc/rc.sysinit is called by upstart due to /etc/init/rcS.conf "start on
 startup", /etc/init.d/00-olpc-runin is called by upstart due to
 /etc/init/rc.conf "start on runlevel [0123456]", therefore /etc/rc.sysinit
 executes before /etc/init.d/00-olpc-runin, not concurrently, there should
 be no race,

 /var/log is also in /etc/rwtab, therefore if rwtab processing failed
 generally, there may be other evidence on the filesystem apart from
 /etc/adjtime, ... is an image of the filesystem available?

 runin-fscheck uses olpc-contents-verify which stops on the first error,
 and does not continue to process the filesystem after that point, so a
 missing /etc/rwtab might not have been noted.

 with some local testing, the rwtab processing phase of /etc/rc.sysinit may
 execute concurrently with libertas_sdio discovery, so the symptom may
 relate to wireless card latency.

 with some local testing, running a tight loop containing umount, cp, and
 mount of /etc/adjtime, a shutdown caused a slew of /etc/adjtime not
 mounted messages ... caused by /etc/init.d/halt calling umount on each
 tmpfs in /proc/mounts.  this umount occurs immediately after "hwclock
 --systohc" completes.  therefore it should not be the cause of the
 pristine /etc/adjtime being changed.

 adding a remove and reinsert of the wireless module concurrently ...

 {{{
 RW_MOUNT=/var/lib/stateless/writable
 FILE=/etc/adjtime
 for x in $(seq 10 -0.1 0.1); do
     (rmmod libertas_sdio && rmmod libertas && modprobe libertas_sdio)
     sleep $x
     (umount -n $FILE && cp -a --parents "$FILE" "$RW_MOUNT" && mount -n
 --bind "$RW_MOUNT$FILE" "$FILE")
 done
 }}}

 didn't work well ... at some point libertas_sdio would no longer load
 properly.

-- 
Ticket URL: <http://dev.laptop.org/ticket/11757#comment:3>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system