Re: Determining whether we are doing pretty boot -- in olpc-configure - 12.1.0
On Fri, Apr 27, 2012 at 11:56 AM, Mikus Grinbergs wrote: > I see no reason why you should hold off testing with 12.1.0 (please use os8 I've tested it -- broken :-/ - I'm working on it. Fix is coming to os9. And perhaps even support for DisplayLink devices too. It's mostly working now :-) cheers, m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Determining whether we are doing pretty boot -- in olpc-configure - 12.1.0
On 04/27/2012 10:17 AM, Kevin Gordon wrote: Also, please let me know if 12.1.0 is ready for my battery of external USB device testing on all three platforms. I see no reason why you should hold off testing with 12.1.0 (please use os8 or following). [Note: I usually plug in USB storage devices only after the XO has booted. All too often, OFW stalls if I have too many USB devices plugged in at the time when I power on.] Do please note that as of Fedora 17, automounts are __NOT__ to directory /media Instead, on the XO they now are to directory /run/media/olpc/ mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Determining whether we are doing pretty boot -- in olpc-configure - 12.1.0
On Fri, Apr 27, 2012 at 10:22 AM, Martin Langhoff wrote: > On Fri, Apr 27, 2012 at 10:19 AM, Daniel Drake wrote: > > On Thu, Apr 26, 2012 at 5:05 PM, Martin Langhoff > wrote: > >> How do we determine whether we are doing pretty boot? I am looking at > >> olpc-configure at this moment. > > > > Curious why you need to know this. Anyway, the answer is just to see > > if plymouthd is running > > With sisusbvga devices, we have a cosmetic bug: when we bring up the > external monitor, we display a text console on the laptop display. > > If I cover it up -- which we may be able to do with a simple change -- > I want to ensure it's conditional on prettyboot. > Just my 2 cents : I like seeing the text screen on the XO in sisusb external monitor land. Kind of reinforces that everything is working well, and that the XO is 'alive'. Sometimes the external device doesn't sync properly (unsupported adapter, incompatible projector, bad connection) and it's nice to be able to limit the troubleshooting. Especially on the XO-1, which at 11.3.1 still doesn't seem to be at 100%. (Aside: Not sure if the DSD mods to pull SIS back into the main kernel have made it into the beast that is in that 11.3.1 build so far. If so, I'll do more rigorous SISUSB testing on that build on all three platforms.) As per a previous note, the test 883 kernel from San Fran that did accomplish working 100% on the external monitor on the XO-1, no longer auto-mounted the USB flash drives on boot. Easy workaround, but So from my narrow perspective, unless one can actually make the screens mirror, I'd always (marginally) prefer to see the text screen rather than a blank screen. Also, please let me know if 12.1.0 is ready for my battery of external USB device testing on all three platforms. I've been holding off, due to what are perhaps now-obsolete 'wait' instructions from PR. Cheers, KG > cheers, > > > > m > -- > mar...@laptop.org -- Software Architect - OLPC > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Determining whether we are doing pretty boot -- in olpc-configure - 12.1.0
On Fri, Apr 27, 2012 at 10:19 AM, Daniel Drake wrote: > On Thu, Apr 26, 2012 at 5:05 PM, Martin Langhoff wrote: >> How do we determine whether we are doing pretty boot? I am looking at >> olpc-configure at this moment. > > Curious why you need to know this. Anyway, the answer is just to see > if plymouthd is running With sisusbvga devices, we have a cosmetic bug: when we bring up the external monitor, we display a text console on the laptop display. If I cover it up -- which we may be able to do with a simple change -- I want to ensure it's conditional on prettyboot. cheers, m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Determining whether we are doing pretty boot -- in olpc-configure - 12.1.0
On Thu, Apr 26, 2012 at 5:05 PM, Martin Langhoff wrote: > How do we determine whether we are doing pretty boot? I am looking at > olpc-configure at this moment. Curious why you need to know this. Anyway, the answer is just to see if plymouthd is running Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Determining whether we are doing pretty boot -- in olpc-configure - 12.1.0
On XO-1.75 we have ttyS2 option passed by olpc.fth if the tick key is held down. Why not add an option that represents the tick key held down and use that for both purposes; enabling serial console and disabling the plymouth mediated display. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Determining whether we are doing pretty boot -- in olpc-configure - 12.1.0
How do we determine whether we are doing pretty boot? I am looking at olpc-configure at this moment. Right now our dracut module only looks at the dcon state -- but then it starts fiddling with it so those who come later are stuck. Could it frob /proc/cmdline, tacking a "prettyboot" at the end? Should we do that from olpc.fth instead? Any other sane mechanism for dracut-modules-olpc to pass on some global variables to userland? cheers, m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpc-configure
On 14 August 2010 13:35, Jerry Vonau wrote: > I don't want en_US.UTF-8, I want what I set in os-builders' > base/ksmain.10.core.inc file, I'm changing the install language there. This is basically just an unimplemented feature. We currently assume that all deployments want to default to the language in the mfg data, and don't need the opportunity to override that default from software. If you do want to add a software default which overrides the mfg data, I expect you'll have to patch the system here and there, you have discovered one such place. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpc-configure
Sorry for the long delay, I had overlooked this unreplied message. El Sat, 14-08-2010 a las 14:35 -0500, Jerry Vonau escribió: > On Sat, 2010-08-14 at 15:15 -0400, Bernie Innocenti wrote: > > Since you get en_US.UTF-8 either way, I would tend not to bother fixing > > this bug neither in olpc-configure nor in your mfg-data. > > I don't want en_US.UTF-8, I want what I set in os-builders' > base/ksmain.10.core.inc file, I'm changing the install language there. > Is there a reason not to do that? Now that you can switch between gnome > and sugar, though that might be a good way to keep the two in sync. The "lang" option in ksmain.10.core.inc gets stored into /etc/sysconfig/i18n by imgcreate. Regardless of the contents of the manifacturing data, olpc-configure will *always* override /etc/sysconfig/i18n on first boot. To prevent this, you could touch /.olpc-configure from olpc-os-builder. Take care to also perform the rest of the initialization usually done by olpc-configure. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpc-configure
On Sat, 2010-08-14 at 15:15 -0400, Bernie Innocenti wrote: > El Sat, 14-08-2010 a las 02:05 -0500, Jerry Vonau escribió: > > I've been using OSBuilder to spin up some custom images, I'm just > > wondering if my XO-1.5 is a little strange or if I uncovered a bug. > > When olpc-configure is run at first boot and reads the $MFG_DATA in /ofw > > the LO tag that is returned has "en_US.UTF8" in it which will never > > The LO tag in your laptop is incorrect. > > It should have been "en_US.UTF-8" (with an extra dash). I've already > seen another XO-1.5 like this, but it was a pre-production unit. > > Since you get en_US.UTF-8 either way, I would tend not to bother fixing > this bug neither in olpc-configure nor in your mfg-data. > I don't want en_US.UTF-8, I want what I set in os-builders' base/ksmain.10.core.inc file, I'm changing the install language there. Is there a reason not to do that? Now that you can switch between gnome and sugar, though that might be a good way to keep the two in sync. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpc-configure
El Sat, 14-08-2010 a las 02:05 -0500, Jerry Vonau escribió: > I've been using OSBuilder to spin up some custom images, I'm just > wondering if my XO-1.5 is a little strange or if I uncovered a bug. > When olpc-configure is run at first boot and reads the $MFG_DATA in /ofw > the LO tag that is returned has "en_US.UTF8" in it which will never The LO tag in your laptop is incorrect. It should have been "en_US.UTF-8" (with an extra dash). I've already seen another XO-1.5 like this, but it was a pre-production unit. Since you get en_US.UTF-8 either way, I would tend not to bother fixing this bug neither in olpc-configure nor in your mfg-data. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
olpc-configure
I've been using OSBuilder to spin up some custom images, I'm just
wondering if my XO-1.5 is a little strange or if I uncovered a bug.
When olpc-configure is run at first boot and reads the $MFG_DATA in /ofw
the LO tag that is returned has "en_US.UTF8" in it which will never
match:
if ! locale -a | grep -qx "${SYS_LANG/UTF-8/utf8}"; then
echo "olpc-configure: Locale $SYS_LANG is not supported;"
SYS_LANG="en_US.UTF-8" # better fallback than "C"
echo "olpc-configure: Falling back to locale $SYS_LANG"
fi
Then the default language becomes en_US.UTF-8... So my question becomes
do I have a funny tag in ofw or is this a bug? If this is a bug, would
it not be better to source /etc/sysconfig/i18n for a LANG= variable before
defaulting to the above? Is there some sugar specific reason for the above?
Just want to know what others think. I've patched olpc-configure to work
around the issue, but the LANG=C in OSBuilder's base routine should go away
as it's not being used anyway.
Jerry
--- olpc-configure.orig 2010-08-14 23:52:46.0 +
+++ olpc-configure 2010-08-15 02:02:26.0 +
@@ -144,7 +144,7 @@
# Some defaults
XKB_MODEL="olpc"
XKB_LAYOUT="us"
- SYS_LANG="en_US.UTF-8"
+ SYS_LANG_SET=`cat /etc/sysconfig/i18n | grep LANG= | awk -F= '{ print $2 }' `
XORG_CONF=xorg-emu.conf
@@ -198,11 +198,21 @@
fi
fi
fi
- if ! locale -a | grep -qx "${SYS_LANG/UTF-8/utf8}"; then
- echo "olpc-configure: Locale $SYS_LANG is not supported;"
+
+ if ! locale -a | grep $SYS_LANG; then
+ echo "olpc-configure: Locale $SYS_LANG from MFG Tag is not supported;"
SYS_LANG="en_US.UTF-8" # better fallback than "C"
echo "olpc-configure: Falling back to locale $SYS_LANG"
+ else
+ echo "olpc-configure: Setting locale to $SYS_LANG from MFG Tag"
fi
+
+ if [ -n "$SYS_LANG_SET" ]; then
+ SUGAR_LANG=$SYS_LANG_SET
+ echo "olpc-configure: Setting locale to $SUGAR_LANG from sysconfig"
+else
+ SUGAR_LANG=$SYS_LANG
+fi
}
rebuild_library_index() {
@@ -239,7 +249,7 @@
rm -f $OLPC_HOME/.i18n
cat >$OLPC_HOME/.i18n <<__EOF__
-LANG="$SYS_LANG"
+LANG=$SUGAR_LANG
__EOF__
chown olpc:olpc $OLPC_HOME/.i18n
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
[PATCH] Fallback to /ofw on missing DMI in olpc-configure
This fallback is necessary even if we ship an updated
OpenFirmware which enables SMBIOS within the signed OS
image, laptops will continue running with the previous
firmware until plugged to AC during boot.
If we run olpc-configure with no SMBIOS on first boot,
wrong keyboard settings will be stored permanently.
---
etc/rc.d/init.d/olpc-configure | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/etc/rc.d/init.d/olpc-configure b/etc/rc.d/init.d/olpc-configure
index 2ef93fc..175da3a 100755
--- a/etc/rc.d/init.d/olpc-configure
+++ b/etc/rc.d/init.d/olpc-configure
@@ -16,16 +16,20 @@ XO_VERSION=0
get_xo_version() {
# This requires an OFW that runs setup-smbios at boot.
- [ -e "/sys/class/dmi/id/product_name" ] || return
-
- name=$(http://lists.laptop.org/listinfo/devel
olpc-configure and upgrades: What to do about ~/isolation? Skipping 802?
Looking at /etc/init.d/olpc-configure -- which handles fixups after upgrades -- questions come to mind: - We are not using Rainbow on our F11 images. If we rm -fr ~/isolation some state will be lost -- for example browser cookies & cache. What other persistent data gets saved there & how important is it? Is it feasible to migrate it with a script? - There is some very unhappy code to handle upgrades from early releases to 802. I'd love to rip it out, but we may want to support deployments that skip 802. We sure have some deployments that are likely skip 802 in some hard-to-reach locations. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: i18n, olpc-configure and xorg.conf changes
Kim Quirk wrote: > Is this all in the wiki? Seems like a ton of good data. If it is, can > you provide a link for me? Yes, I should have done it before. A slightly edited version of the contents of my original mail is here: http://wiki.laptop.org/go/Olpc-utils I also fixed a bunch of other pages that contained obviously out-of-sync info. If you know more pages that need updating, let me know (or just go on and fix them :-) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] i18n, olpc-configure and xorg.conf changes
Marco Pesenti Gritti wrote:
> thanks for the exhaustive explanation... What's the quick recipe to
> turn on debug logging in the latest joyride?
$ cp .xsession-example .xsession
$ vi .xesssion
{enable the specific logs you need}
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [sugar] i18n, olpc-configure and xorg.conf changes
Bernardo, thanks for the exhaustive explanation... What's the quick recipe to turn on debug logging in the latest joyride? Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
i18n, olpc-configure and xorg.conf changes
Alexander M. Latham wrote:
> --- "Erik Blankinship" wrote:
> What is the secret to turning on reliable logs in Joyride?
> --- end of quote ---
>
> For some reason the .xinitrc and .sugar.debug files are no longer
> in the /home/olpc directory. Were they moved, or is there a
> completely different way of turning up logging?
My bad for not advertising these changes before people stumbled
into them.
The old scheme *had* to be changed, because we were installing
system files such as .xinitrc in $HOME, thus preventing updates
from really updating them. Moreover, we used to write to
several system files, which would require exceptional handling
in the update system and a few more of those horrible bind-mounts.
The new configuration scheme is implemented in olpc-utils (before,
it was scattered through initscripts, sugar and pilgrim).
The components are:
* /etc/init.d/olpc-configure
- As previously, it runs early at system boot to do some
OLPC-specific initializations and the first-boot configuration.
- For the first-boot configuration, it used to check for
/.olpc-configured. Now it uses /home/olpc/.olpc-configured
instead.
- olpc-configure used to rewrite /etc/sysconfig/i18n. Now it
writes language and keyboard settings to /home/olpc/.i18n,
overridable by users.
- I switched to specify XKB keyboards with the "layout(variant)"
syntax because it's more intuitive when you have two or more
layouts than the separate layout/variant keys. The old
syntax is still supported.
- For MP machines, I'll set the keyboard directly from mfg
data, without a hardcoded table to map KA tags to X11
keyboars.
- The Linux console keyboard is still not being set accordingly.
Not sure if we really want to do it. Power users can run
loadkeys themselves if they really want to.
* /etc/X11/xorg.conf
- This file is *no longer* hacked by olpc-configure
- actually, xorg.conf is not even a file: olpc-configure
creates a symlink to one of two possible configuration
files, which are read-only and can be upgraded normally
- We still handle some differences between Geode+DCON and
emulators. I'd like to get X to autodetect these things
better so we could kill off the configuration files
altogether.
- we're missing a way to allow user customizations in
xorg.conf. In the future, I could make olpc-dm check for
/home/olpc/.xorg.conf and use it if present.
But frankly, customizing xorg.conf is for power users who
may also want to customize other /etc entries. So if we
really want to support these use cases, we'd be better off
finding a generic way to preserve user customizations.
* /usr/bin/olpc-dm
- This is our "display manager". A streamlined version of
what gdm and kdm are. So streamlined that it doesn't even
have a UI. In the future, it could be extented to support
multiple users, XDMCP and other fancy things. That day,
I hope to be at a safe distance.
- olpc-dm still spawns X and the session through startx
and xinit. I'm planning to through them away shortly.
This will also allow us to do something smarter than
sysvinit's once/respawn modes for restarting X.
- olpc-dm still hogs the console and dies when you hit ^C.
the fix is not a one-liner, and it's not a critical bug,
but I'm planning to fix it some day.
* /usr/bin/olpc-session
- This script replaces /home/olpc/.xinitrc . It sources
/home/olpc/.i18n for $LANG, $XKB_LAYOUT and, optionally,
$XKB_VARIANT.
- olpc-session also replaces /usr/bin/sugar, which will
shortly go away, thus simplifying our boot process even more.
* /home/olpc/.xsession
- This is an "extensibility hook" for customizing your session.
It gets sourced near the end of /usr/bin/olpc-session.
A default is provided as .xsession-example, with some tips
you may want to review.
- This file also replaces the /home/olpc/.sugar.debug
The latest version of olpc-utils fixes a couple of important
gotchas. Please don't report bugs until you have
- updated to latest joyride (later than this mail)
- removed /home/olpc/.olpc-configured
- rebooted (really, not just CTRL-ALT-BS!)
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
