On May 6, 2008, at 4:12 PM, Martin Langhoff wrote:
On Wed, May 7, 2008 at 1:38 AM, John Watlington [EMAIL PROTECTED]
wrote:
Dennis correctly debugged the problem. This is due to the
attempt to produce a build for 586 machines, hoping to
run on the VIA C3.
that's great to hear - though I have to confess that I'd like to see
the build process (and to be able to repro it). I had forgotten that
161 had a different kernel from 160 with the ViaC3 changes.
Build process for 162:
I went into the xs/testing/updates/7/i386 repo, restored the 686
versions of the
kernel, and did a createrepo
I made the changes I wanted to xs-config, pushed them back onto git.l.o,
built the package on xs-dev, copied it into xs/testing/olpc/7/i386
repo and did a createrepo.
http://dev.laptop.org/git?p=projects/xs-config;a=summary
On duplicator.l.o, I built the livecd. I rebooted duplicator on
noticing that /dev was munged,
then copied the ISO back onto xs-dev for distribution and burned it
onto a USB key for local testing.
I'm building 162 right now, which should fix this problem.
I became aware of it last night. I guess all the build 161
installs I did were AP based...
H. Perhaps at 1CC I was testing mainly with 160? I'm sure I got
161 working at some point, or perhaps I had 160 + new packages. In any
case, I think I pushed out some xs-config changes.
Umm, yes. git.l.o doesn't show any check-ins by you (and I pulled
before starting
my changes). I built release 2, copied it into the repo, not knowing
that you had
already bumped up to release 3... I'm rebuilding 163 w. release 4,
and will rebuild
with release 5 when you merge and commit your changes...
I've installed and used build 161 on at least four servers (AMD and
Intel), and they
all worked fine through various loopholes in the problems
(domain_config worked
OK if the machine hadn't DHCP'ed, if using APs the libertas driver
wasn't loaded, etc..)
QA !I already know to test on at least two wired network
configurations, now we need
to start ensuring tests in both AP and mesh mode.
(Already checked into xs-config 2.7.1r2) I had a script which
over-wrote /etc/resolv.conf after dhclient wrote it, but it was
erroneously keeping some of the DNS servers. Instead of
fixing it, in build 161 I deleted it...
I'll look into that one. Once dhclient writes its resolv.conf, we need
to write a forwarders { $dnsservers }; forwarders only; config for
BIND.
I would suggest not using forwarders only unless necessary (the
VSAT case for this in Peru was static IP assignment.) If the
upstream DNS
goes down, the school server is perfectly capable of working down
from the roots.
Debian has the resolvconf package, which does this, or we can cook
our own.
We also want to update the provided external address in the
nameserver, and
provide the update to an upstream nameserver...
I'll do some smoke testing of 162 this morning.
Cool. I'm on IRC.
cheers,
m
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
