New F11 for the XO-1 build 5-swap

[Mikus Grinbergs]

> 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".