New F11 for the XO-1 build 5-swap

[Yioryos Asprobounitis]

Hopefully nobody is in a wild goose chase yet...
My system does keep freezing sporadically at the loading initrd.img step but this may not be related to the swap partition (as you suggested) or anyother USB device (since I have non hooked up)
 
When it freezes _NO new dmesg file_ is generated, so what I am seeing is the last entry of the previous, apparently successful, session. The /var/log/messages just has the shoudown sequence from the last boot too.

I can only assume at this point that the "recovery" is not really related to fstab, swap or even SDcard but some other reason (init script?) that somehow changes during the repetitive boots in Sugar/Ubuntu, and is as erratic as the freezing itself. 

Any suggestions on how should I approach/debug this next time it happens will be greatly appreciated. eg are there/can be any logs during the initrd boot stage, even before dmesg gets recorded?

--- On Tue, 8/18/09, Mikus Grinbergs <mikus at bga.com> wrote:

> From: Mikus Grinbergs <mikus at bga.com>
> Subject: Re: New F11 for the XO-1 build 5-swap
> To: fedora-olpc-list at redhat.com
> Cc: "Yioryos Asprobounitis" <mavrothal at yahoo.com>
> Date: Tuesday, August 18, 2009, 7:01 AM
> > root at OLPC:~# tail
> /media/olpcmtd0/var/log/dmesg
> > [   25.269277] ip used greatest stack
> depth: 1732 bytes left
> > [   27.747985] Adding 258040k swap on
> /dev/mmcblk0p2.  Priority:-1 extents:1 ac
> > ross:258040k SS
> > 
> > _note the "SS" at the end_ normally not present when
> booting is OK
> 
> I still think you are mistaken when you blame bootup
> handling of the swap partition.  For instance, I
> normally have the "SS" at the end of that line in
> /var/log/dmesg -- yet for me bootup works correctly.
> [Except (see postscript) I do believe in 'internal timing'
> hurdles.]
> 
> My understanding of the way /var/log/dmesg works is that it
> is "buffered" - the system fills one "buffer" to a certain
> point, and on the XO [on Fedora?] it then stops writing to
> /var/log/dmesg (even though if from the command line one
> issues 'dmesg', what gets shown is additional lines beyond
> the one where /var/log/dmesg stops).  So the LAST line
> the system writes to the XO /var/log/dmesg file seems to be
> the one about adding the swap partition -- but my systems
> then continue bootup (without more lines being added to
> /var/log/dmesg).  That is why I'm not alarmed with you
> finding that particular line to be the last line in
> /var/log/dmesg
> 
> 
> Turns out that the same line is also copied into
> /var/log/messages.  Would you please do 'rm
> /var/log/messages' (this gives you a clean file -
> /var/log/messages is otherwise not erased between reboots),
> and then reboot.  After your bootup has stalled, use
> Ubuntu (or something) to look at /var/log/messages (not just
> /var/log/dmesg). _IF__ the "time stamp sequence" in
> /var/log/messages continues beyond the "Adding 25804k swap
> ..." line - then hooking up the swap partition was *not* the
> last thing the system tried -- and whatever it did later is
> also a candidate for "why did bootup stall".
> 
> mikus
> 
> 
> p.s.
> Note that for me, boot-up sometimes stalls with the last
> line showing on the screen being "loading ... initrd.img"
> (or whatever it loads).  [This is while the screen
> still has a white background -- I normally press 'check'
> while booting, so the screen switches to a black background
> as the bootup progresses.]
> 
> My XO systems have *lots* of external (USB) devices. 
> I interpret the bootup stalling before the screen can switch
> to black to be an indication that some sort of 'internal
> timing' did not work correctly, resulting in something or
> other not being recognized. What I do in case of such a
> stall is to pull out one or more USB cables (this seems to
> affect the 'internal timing') and repeat the bootup from
> power-on.  Sooner or later bootup progresses to the
> black background screen - then I'm "in like Flynn".
> 
>