"Cannot find root file system!" with 2009-06-03 SoaS on XO-1
by S Page
I made a live USB for my XO-1 in Kubuntu 9.04. I downloaded
http://people.sugarlabs.org/sdz/livecd-iso-to-disk.sh and the current
SoaS-2 snapshot. I installed the package dependencies. I synthesized
the overlapping instructions in
http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Linux and
http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC (the
latter only documents Fedora) , using commands like
sudo ./livecd-iso-to-disk.sh --overlay-size-mb 300 --home-size-mb 160
--unencrypted-home Soas2-200906031834.iso /dev/sdc1
sudo ./livecd-iso-to-disk.sh --overlay-size-mb 300 --unencrypted-home
--noverify --skipcopy --xo --xo-no-home Soas2-200906031834.iso
/dev/sdc1
I inserted this in my unlocked XO-1 running q2e41 firmware, and got:
...
starting udev4
creating devices
------------------------
WARNING: cannot find root file system!
------------------------
Create symlink /dev/root and then exit this shell to continue
the boot sequence.
bash: no job control in this shell
bash-4-0#
scsi 0:0:0:0: Direct-Access SanDisk Cruzer Pattern 7.01 PQ: 0 ANSI: 0 CCS
sd 0:0:0:0: [sda] (disk size stuff...)
(... more sda mesages)
This rings a bell, I think it happened to me months ago with Rawhide-XO.
It sounds like http://dev.sugarlabs.org/ticket/421 , marked Closed. I
looked through the comments in there and
https://fedorahosted.org/liveusb-creator/ticket/53 and didn't see
anything that helped: the overlay UUID matches, reinserting USB and/or
exiting shell doesn't help, etc.
Also, can anyone point to a reasonable explanation of what goes on
during a LiveUSB boot? initrd, syslinux.cfg, squash-fs, overlays...
This stuff clearly isn't bulletproof but is cloaked in obscurity-fu.
Thanks,
--
=S Page
14 years, 11 months
Fwd: plymouth performance
by Daniel Drake
FYI...
---------- Forwarded message ----------
From: Daniel Drake <dsd(a)laptop.org>
Date: 2009/6/11
Subject: plymouth performance
To: plymouth(a)lists.freedesktop.org
Hi,
I've done some timings of plymouth vs non-plymouth boots on my XO
laptops, to see how much of an impact it has on boot time.
I took each measurement 3 times and then averaged. All recorded times
were without much variance; these timings were reliable.
I measured by pausing OFW during boot, entering "boot", and then
starting a stopwatch at the same time as pressing enter to execute the
boot command.
On the XO-1 I stopped the stopwatch as soon as I saw the mouse cursor
(just before gdm comes up).
On the XO-1.5 I stopped the stopwatch as soon as I saw the text at the
center of the gdm login screen.
For the "without" tests, I removed the rhgb kernel parameter parameter
and added console=tty0
On the XO-1:
Without plymouth: 61.53 seconds bootup time
With plymouth: 79.82 seconds bootup time
+18.29 seconds increase, or 30% regression
On the XO-1.5:
Without plymouth: 24.78 seconds bootup time
With plymouth: 27.07 seconds bootup time
+2.29 seconds increase, or 10% regression
We have a similar problem with OLPC's boot animation code on the XO-1.
We recently found out that it slows down boot by about 15 seconds with
just a simple animation.
However, two superheroes came along and implemented an awesome new
algorithm which only redraws the parts of the screen that have changed
from the last frame. This completely cuts out the 15-second regression
to the point where when you measure timings like the above tests, it
often appears that it is tiny bit faster to boot *with* the animation...
I wonder if that could be implemented in plymouth. The code is here:
http://dev.laptop.org/git/users/bobbyp/bootanim/
Daniel
14 years, 11 months
[OT] Test run of 2009/05/25 image
by Mikus Grinbergs
Disclaimer: This post contains Off-Topic meta discussion
>>> Conclusion:
>>>
>>> fedora-olpc, to be a sucess, needs a much slimmer UI than that
>>> of GNOME.
>>
>> "Success" needs to be defined. Seems to me the OLPC was envisioned
>> mainly for a single-application environment. Except for being slow at
>> processing, I think it succeeds admirably.
>
> I'm not talking about the sugar interface, which is what you're talking
> about.
>
> Non-sugar interface is something I'm also interested.
The reason for my enthusiasm: I think the OLPC offers the bringing
of technological assistance to economically disadvantaged locations.
I think that people who focus on "slimming" the OLPC are missing the
point. What they end up with is a slow, small Linux system. But if
what they want is a small Linux system, today's 'netbooks' offer
more capability (and as netbooks continue to be produced by the
millions, I expect tomorrow's models to cost less than the OLPC).
For those who are interested in using the OLPC to bring conventional
applications to people who already have access to technology - why
not work with a netbook instead? For those who think the OLPC *is*
suited to the environments in which it is being deployed - let's
work on developing OLPC-scale applications to assist 'the things
people do' wherever such "computerization" could improve matters.
mikus
14 years, 11 months
Re: Reminder: no new Fedora 9 CVS branches
by Paul Fox
dennis wrote:
> As Fedora 11 is released on Tuesday June 9th there will be no
> new CVS branches allowed for F-9
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL
> lists the policy in effect. This means that F-9 is now in a
> maintenance only cycle, with EOL fast approaching, the exact
> EOL date will be set at the FESCo meeting this week.
so this means, from OLPC's standpoint, that until F11 is
available and useful on an XO, no new or revised packages
will be available to XO owners. is that right?
(i'm not disagreeing or complaining about the fedora policy --
i'm just thinking that since there was no F10, and F11 doesn't
yet run fully, the XO is further behind than it otherwise might
be.)
paul
=---------------------
paul fox, pgf(a)laptop.org
14 years, 11 months
Re: Test run of 2009/05/25 image
by Mikus Grinbergs
These days I do almost all my running with the most recent F11-based
builds available (e.g., 2009/05/25 image and newer). It is only the
lack of audio or video in F11-on-XO that keeps me from abandoning my
8.2.1 systems. Most of the items mentioned don't bother me:
[Note: My XOs all have a "permanent" SD card, which holds lots of
executables (including activities) + gigs of data + swap partition.]
> Forewarning: non scientific tests...
>
> * "occasional" creating devices hang
>
> For me, it was "occasional" boot. Once it took 16 boots, the last
> 3 of which separated by two hours from the other 13.
My *average* number of repeats before boot is successful: 5 or so
>
> * wasted memory
> GNOME just SHOULDN'T be there. A simpler window manager will
> make it much better. I installed OpenBox but it was very hard
> because of OOM killer :)
Looking only at what XO-1s I have powered up at this instant:
nand occupancy for 2009/05/28+: 516 MB
nand occupancy for build 801: 504 MB
[Both values are affected by how many Activities installed in nand.]
256 MB of RAM is not much. That's why I have an active swap
partition. I'm not sure how much a smaller "resident system"
would help.
I do experience [particularly when using 'find /'] unwanted system
stalls (OOM killer?) after the system has been running for a while.
My guess would be that there are memory leaks - which would be a
problem even if initially available amount of memory were greater.
Here's hoping that eventually enough people will be using F11-on-XO
to justify investigating such problems.
>
> * OpenBox launches way too many GNOME daemons.
> I had to kill a lot of them by hand in order to get some more
> free memory.
I normally run applications with Sugar instead of Gnome as the
manager. Haven't tried to overcommit with F11-on-XO builds, but in
my experience with F9-based builds, two "monster" applications
active simultaneously (e.g., Firefox + Adobe Reader) are as much as
the XO-1 can handle.
>
> * not enough memory for yum
> 99% of the attempts to install anything resulted in OOM kills
Helps to periodically do 'yum clean all'. Yum normally runs fine.
[Did cause a system stall once when trying to update glibc - but
that was on a 'yum upgrade' that was pulling in some 40 packages.]
>
> * speed of GNOME interface was acceptable
> really, this was the biggest surprise I had...
>
> Conclusion:
>
> fedora-olpc, to be a sucess, needs a much slimmer UI than that
> of GNOME.
"Success" needs to be defined. Seems to me the OLPC was envisioned
mainly for a single-application environment. Except for being slow
at processing, I think it succeeds admirably.
[GNOME-on-XO has the advantage of clarity and not-very-complicated.
Yes, other UIs can be fashioned, but work would have to be put in to
make them "do enough to make it easy for users". <See how much
effort it has taken to fashion Sugar.>]
mikus
14 years, 11 months
livecd-iso-to-xo for XO-1.5
by Daniel Drake
Hi,
Here's my initial attempt at an equivalent livecd-iso-to-xo.sh for the
XO-1.5. This involves a filesystem change to ext2 as we no longer have
raw flash access (right?).
Completely untested.
Open questions:
1. What should the root= kernel parameter be?
2. How would we distribute this to testers and developers?
The resultant file is 4gb, albeit sparse. Maybe rsync can handle
sparse files efficiently.
3. How do we use OFW to flash this, including a partition table etc?
Daniel
14 years, 11 months
working around boot problems
by Daniel Drake
It's frustratingly difficult to immediately work on the "unknown
filesystem jffs2" problem because more often than not, the same kernel
for me fails to even reach that stage (see my "another boot hang"
thread).
Switching to Deepak's 2.6.30-rc5 kernel for XO, both problems
mysteriously go away. Here are the files and the procedure if anyone
else wants to try it out.
http://dev.laptop.org/~dsd/20090604/
I don't know what else works or fails in Deepak's kernel, or if there
are any plans to ship it instead of the Fedora kernel for these XO-1
efforts.
Daniel
14 years, 11 months
jffs2 mounting problem
by Daniel Drake
Hi,
I've been digging into the "unknown filesystem type: jffs2" problem that
makes boot fail most of the time on XO-1.
First observation, this isn't the message that appears furthest down on
the screen, it's about halfway down. The one at the bottom of the screen
says "creating devices", making it appear like the hang has happened
there, but actually the screen is screwed up at this point and lines
being printed are appearing in something like this order:
5
6
7
8 unknown filesystem type jffs2
1
2
3
4 creating devices
I added some initrd debug messages and confirmed that jffs2 is not
loaded before the "mount" call is made. The mount procedure (on the
kernel side) is therefore responsible for loading the module.
Turning plymouth off (by commenting out the appropriate lines in the
initrd scripts) causes messages to appear on-screen in the right order
*and* seems to reliably work around the race bug.
At this point I'm having severe difficulty to boot this kernel to add
more diagnostics, even after a fresh reflash, even on a 2nd XO, due to
an even earlier hang problem (see my "another boot hang" thread).
Daniel
14 years, 11 months
another boot hang (not the jffs2 one)
by Daniel Drake
I'm seeing a hang during early boot of recent F11-XO images. Right now I
have reproduced on freshly-reflashed 20090528 and 20090525, on 2
different XOs. It is not the "Unknown filesystem jffs2" hang or the
"Creating devices" hang. It is much earlier, before the kernel has even
kicked the framebuffer.
At the point of the hang, the output on screen is:
Boot device: /nandflash:.......
Loading ramdisk image from nand:\boot\initrd0.img ...
(this screen is from the OpenFirmware boot process, the screen
background is still grey, the Linux kernel does not appear to have
become alive at all)
It hangs at this point, with no extra output on serial console, and is
unresponsive to OFW frame key for interruption.
Is anyone else seeing this? (please don't confuse this with other boot
hangs, where the screen contents are different)
Daniel
14 years, 11 months
Re: another boot hang (not the jffs2 one)
by Mikus Grinbergs
Console ends with
> Loading ramdisk image from nand:\boot\initrd0.img ...
The question is - how repeatable is this situation ?
I get these from time to time on my XO-1s. My usual response is to
repeat the boot sequence from the beginning, *after* having changed
my external device configuration (for instance, by pulling some
cables from the USB sockets on the XO). [My guess is that the boot
software gets "stuck" waiting for something -- and that by changing
the external devices I somehow change the internal timings of boot.]
----
For me, booting sometimes also gets "stuck" soon after
> Type the Esc key to interrupt automatic startup
My response is to just repeat the boot sequence from the beginning.
Without me doing anything except glaring at the XO, it appears to
alter its internal timings enough to next time get past this point.
mikus
14 years, 11 months
