New F11 for the XO-1 build 5-swap

[James Cameron]

On Tue, Aug 18, 2009 at 02:23:34AM -0700, Yioryos Asprobounitis wrote:
> OK... my last failed boot was even more interesting... 
> As "usually" booted Ubuntu from the SD-card and removed the swap line
> from fstab hopping for a recovery, but the system kept loading swap on
> /dev/mmcblk0p2 as you can see below in the logs and kept failing boot
> with the "loading ... initrd.img" as the last message on the ofw
> screen.

I'm not sure we support Ubuntu here, but the symptom you describe above
"loading ... initrd.img as the last message" is consistent with a kernel
that is not configured to display any messages on the frame buffer
console.  This can happen regardless of swap issues.

> Logs after loading to Ubuntu and mounting NAND (olpcmtd0)
> root at OLPC:~# more /media/olpcmtd0/etc/fstab 
> /dev/root  /         ext3    defaults,noatime 0 0
> devpts     /dev/pts  devpts  gid=5,mode=620   0 0
> tmpfs      /dev/shm  tmpfs   defaults         0 0
> proc       /proc     proc    defaults         0 0
> sysfs      /sys      sysfs   defaults         0 0
> /tmp            /tmp            tmpfs         rw          0 0
> varcacheyum     /var/cache/yum  tmpfs         rw,mode=755 0 0
> vartmp          /var/tmp        tmpfs         rw          0 0
> none            /ofw            promfs        defaults    0 0

There is no explicit mounting of a swap partition.  This is consistent
with the /etc/fstab of os5 on my units.

> root at OLPC:~# tail /media/olpcmtd0/var/log/dmesg
> [   19.910660] olpc-ec:  received 0x4b
> [   19.911678] olpc-ec:  received 0xce
> [   19.915229] olpc-ec:  running cmd 0x15
> [   19.917259] olpc-ec:  received 0x41
> [   19.917278] olpc-ec:  running cmd 0x18
> [   19.918299] olpc-ec:  sending cmd arg 0x5f
> [   19.920322] olpc-ec:  received 0x22
> [   19.987194] mice: PS/2 mouse device common for all mice
> [   25.269277] ip used greatest stack depth: 1732 bytes left
> [   27.747985] Adding 258040k swap on /dev/mmcblk0p2.  Priority:-1 extents:1 across:258040k SS
> 
> _note the "SS" at the end_ normally not present when booting is OK

Looks fine to me.  /var/log/dmesg is a copy of the kernel ring buffer at
the time the syslog starts.  Once the copy is made, it is not changed
until the next boot.  You can see where this is done at line 815 of the
file /etc/rc.sysinit.

> Removing the card altogether, kept failing trying to load the
> non-existing /dev/mmcblk0p2 swap partition.

What makes you think that?

> So there is something strange with the swap handling and/or dev
> loading in these builds.

I've analysed the initrd.img from os5, it contains no explicit scripted
swapon.  /etc/fstab contains no swap.  /etc/init.d/ contains no swapon
except for the halt.  The only place that swapon is done is in
/etc/rc.sysinit.

> It would appear that there is (occasionally
> generated) a persisting swap loading entry somewhere or swap is not
> unmounted cleanly 

Swap cannot be unmounted cleanly ... swap consists of a partition with a
swap signature, and the existence of the signature is the only important
thing.  The signature can be created using mkswap.

I think you are looking at a /var/log/dmesg file from a previous
successful boot!  Check the md5sum or date next time.

> This event is (visually) associated with the inability the boot
> process to go to the console mode (when pretty boot is inactivated)
> although the process goes on as evident by the dmesg log.

Again, it merely sounds like a kernel that is not presenting any
messages on the frame buffer.  Have you attached a serial console?

> An additional indication about swap/dev handling may be that if you
> have a swap partition on a card defined in fstab and then remove the
> card, the messages during boot (pressing the check game key) in udev
> /etc/fstab swaps show a nice green "[OK]" (!?) where with F9 builds
> the message was a red "[FAIL]" when the card was missing.

The detection and mapping of swap partitions in F11 XO1 os5 is handled
by /etc/rc.sysinit, which uses "swapon -a -e" ... and -e is --ifexists,
which means "Silently skip devices that do not exist."  Therefore [FAIL]
will no longer appear.

This seems fine.  I agree with Mikus ... you have a symptom "failure to
boot" and you have focused on an incorrect sign ... namely the swap
partition messages found at the end of a known terminated log file
/var/log/dmesg.  And the log file you were looking at is out of date.

> I do not know if this is intentional or if it is an F11 or an OFW
> issue (I'm using q2e41).

It certainly won't have anything to do with OFW!

> All I can tell is that in my system
> occasionally there are issues with the loading of the swap partition
> that lead to system freezes during boot.

It seems much more likely that you have a jffs2 problem or something
else is preventing boot from completing.  And you don't have a log of
the boot yet to find out what is causing it.

> Now if this needs further examination, is up to the persons directly
> involved with the development to decide. 

I'm not directly involved with the development of F11, but I think you
haven't captured enough technical detail yet on this problem to make it
possible for it to be further examined.

I don't see this problem happening on the units that I have running os5.

-- 
James Cameron
http://quozl.linux.org.au/