[00:02] <prpplague> two line paste
[00:02] <prpplague> PandaBoard Revision: 001
[00:03] <prpplague> oops
[00:03] <prpplague> PandaBoard Revision: 001
[00:03] <prpplague> well darn
[00:03] <prpplague> GrueMaster / rsalveti  http://paste.ubuntu.com/484228/
[00:04] <GrueMaster> nice.
[00:04] <prpplague> question though, do you want it more human readable, or more parse friendly
[00:04] <GrueMaster> now to get other arch/platforms to follow suit.
[00:05] <prpplague> i.e. should i just report revision without referencing pandaboard?
[00:05] <GrueMaster> no, platform/revision is great info.
[00:06] <prpplague> okie dokie
[00:06]  * prpplague gets ready to send patch to L24.9 team
[00:06] <GrueMaster> This way we can differentiate between systems (i.e. Blaze/Panda or Beagle/BeagleXM/Gumstix, etc).
[00:09] <GrueMaster> I'm assuming this info is gathered through probing the system & using a lookup table of some sort?
[00:11] <rsalveti> argh, my system is trashing... very slow
[00:11] <rsalveti> opening the link
[00:11] <rsalveti> prpplague: cool :-)
[00:12] <prpplague> GrueMaster: 3-bit value on three gpios
[00:13] <GrueMaster> ok
[00:13] <rsalveti> prpplague: if we have a separator like : I guess it's ok for parsers
[00:13] <rsalveti> name : version
[00:13] <prpplague> rsalveti: thats what i was thinking
[00:13] <rsalveti> or something like that
[00:14] <prpplague> rsalveti: i was thinking
[00:14] <prpplague> rsalveti: something like this
[00:14] <prpplague> boardname - revision : revisionnumber
[00:15] <prpplague> PandaBoard - revision : 001
[00:15] <prpplague> is it that too much?
[00:15] <prpplague> just leave it
[00:15] <prpplague> PandaBoard : 001
[00:17] <rsalveti> hm
[00:17] <rsalveti> don't know, most of the time just the revision should be ok
[00:17]  * GrueMaster finds nothing wrong with the pastebin version.
[00:17] <rsalveti> like beagleboard: c4
[00:17] <rsalveti> pandaboard: es1
[00:17] <rsalveti> an example
[00:17] <prpplague> yea
[00:17] <prpplague> ok, do the KISS thing
[00:18] <rsalveti> :-)
[00:18] <rsalveti> always
[00:20] <GrueMaster> rsalveti: Back to the image issues, I am really having doubts as to what could be breaking the system.  I created a manifest of the A3 image and compared it with 20100809 (first failing image).  Upstart & ureadahead are unchanged.
[00:20] <rsalveti> hm...
[00:21] <rsalveti> maybe a dependency between the upstart services
[00:21] <rsalveti> waiting for something that doesn't get started
[00:21] <rsalveti> debugging upstart would be the way to go
[00:21] <GrueMaster> testing new theory.  We now have a new oem-config apparently.  Will flash 20100809 image and update oem-config on it.
[00:22] <GrueMaster> Two issues that I have seen; latest images fail oem-config and updating from A3 fails to boot.  I doubt there is any relation to the two.
[00:24] <GrueMaster> too many variables and not enough fast test systems.
[00:25] <rsalveti> now I can see 20100826.1
[00:25] <rsalveti> will also download it
[00:25]  * GrueMaster has spent a frustrating 2.5 weeks on this issue.
[00:25] <rsalveti> :-(
[00:25] <rsalveti> sd card performance is frustrating
[00:25] <GrueMaster> Yes.  Very.
[00:25] <GrueMaster> Even on my desktop.
[00:27] <rsalveti> GrueMaster: 152K/s of download is also frustrating
[00:28] <GrueMaster> yes.  Which is why I have my own mirror.
[00:28] <rsalveti> but this is for the image files
[00:29] <rsalveti> I have a cache server around
[00:29] <GrueMaster> 1Gb network throughout the house also helps
[00:29] <rsalveti> for normal stuff
[00:29] <rsalveti> for sure
[00:29] <rsalveti> but an sd card with 3, 4m/s doesn't help
[00:29] <rsalveti> haha
[00:29] <GrueMaster> I mirror both.  And retain dailys until final.
[00:30] <GrueMaster> Not that arm dailys take much room given the pool churn.
[00:32] <rsalveti> yep, will start mirroring the image stuff
[00:32] <rsalveti> the problem is that my stupid internet provider limits the amount of gb per month
[00:32] <rsalveti> I can download only 80gb I guess
[00:33] <rsalveti> with a 10m/s link
[00:33] <rsalveti> so I avoid doing mirror and downloading only what's needed
[00:33] <GrueMaster> ouch.  Some in the US are doing the same.  Fortunately, my ISP has been around since early '90s and has a fat pipe.
[00:33] <rsalveti> that's nice
[00:34] <rsalveti> with my previous provider I didn't have this issue, but doesn't reach my current city
[00:34] <rsalveti> so I had to change to the stupid one
[00:35] <GrueMaster> I'm currently limited by DSL speeds.  Which out here in the sticks is ~6.5M/768k
[00:35]  * GrueMaster wishes he could get FIOS.
[00:36] <rsalveti> mine is currently 10/1 m/s
[00:36] <GrueMaster> nice
[00:42] <persia> rsalveti, What blocks getting newest rootstock upstream into Ubuntu?
[00:43] <rsalveti> persia: a new release? :-)
[00:43] <rsalveti> persia: just 2 simple bug fix, still need to get some work at the ui to create a new release
[00:43] <persia> You don't happen to know any upstream rootstock folk that might feel like rolling a release, do you?
[00:44] <rsalveti> persia: it works fine with our version, but with upstream you'll always get the initrd and vmlinuz outside the rootfs
[00:44] <persia> Ah, makes sense.  Best to get the FFe filed *before* beta-release, as otherwise getting it into maverick will be sticky.
[00:44] <rsalveti> that's why I said GrueMaster to try it
[00:44] <rsalveti> easier to run mkimage later
[00:44] <rsalveti> persia: can you buy me some time? :P
[00:45] <persia> Unfortunately, time and tuits are the two things of which I currently have shortages :(
[00:45] <rsalveti> I'd love to do it, but have more important issues do solve atm
[00:45] <rsalveti> yup :-(
[00:52] <GrueMaster> rsalveti: Running now (got sidetracked by lack of lunch).
[00:52] <rsalveti> GrueMaster: with latest minimal image it boots...
[00:52] <rsalveti> let me start the upstart debugging session
[01:00] <GrueMaster> Looks like rootstock finished ok.
[01:00] <rsalveti> :-)
[01:01] <GrueMaster> oops.  All three of my microSD cards are preoccupied atm.  hrm.
[01:05] <GrueMaster> Gahhh.  Brb.  Need to start dinner (roast).
[01:25] <persia> Anyone good at picking the right place to drop casts for qreal != double issues?  Seems like the outstanding bit for koffice.
[01:28] <rsalveti> argh, nothing works today
[01:31] <GrueMaster> Ok, roast is now...roasting.
[01:31] <persia> Which part of nothing is most annoying at the moment?
[01:32] <rsalveti> haha, like boards not booting? :-)
[01:33] <GrueMaster> I get that all the time.
[01:33] <persia> Oh yeah.  that one.  This is why we need large volumes of consumer-grade hardware (although I think I once heard a story about a chicken and an egg...)
[01:33] <GrueMaster> I just file bugs and let the engineers fix it.  Oh, wait...
[01:34] <rsalveti> ...
[01:34] <GrueMaster> :P
[02:00] <rsalveti> that's weird, I can't see 20100826.1 anymore
[02:00] <rsalveti> wtf
[02:00] <rsalveti> some times it works, some times it doesn't
[02:00] <rsalveti> persia: any clue?
[02:01] <persia> transparent proxies should be removed, and everyone should use IPv6 with endpoint verification.
[02:01] <rsalveti> argh
[02:02] <rsalveti> and the weird thing is that my current wget is still working!
[02:02] <rsalveti> but I can't browse this link
[02:02] <rsalveti> clean cache, different browsers
[02:02] <rsalveti> just can't
[02:02] <persia> Once you get a hit that works, it will be fine.  But stale/erroneous cache data needs to wait for timeout to pass.
[02:02]  * persia forgets how to trick those offhand
[02:02] <rsalveti> yep
[02:08] <rsalveti> GrueMaster: weird, it hangs completely
[02:08] <rsalveti> the kernel, serial, everything
[02:10] <persia> rsalveti, Alternate thought: tell me which file you seek, and I can probably give you a deep URL (which may not be cached)
[02:11] <rsalveti> persia: now I'm able to download it! haha
[02:11] <rsalveti> persia: for the fs I'm still looking for it
[02:11]  * persia fails at parsing
[02:13] <rsalveti> nevermind :-)
[02:13]  * rsalveti needs a lot more coffee
[02:13] <persia> Or a good night's sleep...
[02:15] <rsalveti> well, that'd help, for sure
[02:19] <cooloney> rsalveti: you work so late and hard, man
[02:19] <cooloney> rsalveti: do you have chance to test the 2.6.35 on your es2?
[02:19] <rsalveti> cooloney: well... nothing better to do haha :-)
[02:19] <rsalveti> cooloney: not yet, too much problems during the day
[02:20] <rsalveti> cooloney: do you have a binary?
[02:20] <rsalveti> I can easily test
[02:22] <cooloney> rsalveti: i got an update patch from sebjan, will try to build again.
[02:22] <cooloney> rsalveti: if i am ready, i will post the url for you, thx
[02:22] <rsalveti> cooloney: cool, just ping me when you're done
[02:32] <rsalveti> hm, installed network-manager and rebooted, now it hangs
[02:33] <persia> Excellent!  Uninstall network-manager (from a cross-chroot mounted on something else), and see if that unhangs.
[02:34] <rsalveti> that's what I'm doing now
[02:34] <rsalveti> but got many other packages installed as a consequence, but let's se
[02:34] <rsalveti> see
[02:35] <persia> That's OK.  We can dig through dpkg.log, and find the responsible party.
[02:53] <rsalveti> GrueMaster: persia: seems to be dbus, will test more
[02:54] <persia> That's what ogra was finding
[02:54] <rsalveti> yep, will try to identify why
[02:54] <GrueMaster> Sorry, had to take a break.  Odd that dbus is giving you guys grief.  I had updated that a couple of days ago and it has worked fine.
[02:57] <rsalveti> yep, it's dbus :-)
[02:57] <rsalveti> initct dbus start -> hangs
[02:57] <rsalveti> *initctl
[02:57] <rsalveti> or some dependency from upstart
[02:58] <persia> Excellent!  Can you get a strace?
[02:58] <rsalveti> checking again
[02:58] <rsalveti> will try
[03:00] <GrueMaster> Is it dbus or network-manager?  Like I said, I updated dbus a couple of days ago while slowly churning through the 400+ package updates.  Didn't hang until network-manager update.
[03:01] <rsalveti> network-manager
[03:01] <GrueMaster> But oddly it doesn't appear to start anything after mounting root.
[03:01] <rsalveti> removed the dbus dependency and it started fine
[03:01] <rsalveti> not networkmanager got the hang
[03:01] <persia> It's obviously dbus if "initct dbus start -> hangs"
[03:02] <persia> Might only happen in combination with other stuff, but strace should tell us.
[03:02] <rsalveti> nops, remove the dbus trigger from networkmanager
[03:02] <rsalveti> then started by hand
[03:02] <rsalveti> and it hang
[03:02] <persia> stack trace (rather than syscall trace) would be better, but hard to get for a hang.
[03:02] <rsalveti> so it's probably nm
[03:02]  * persia suspects two bugs, rather than one
[03:02] <rsalveti> let me start nm with strace or logs
[03:02] <rsalveti> could be related with dbus also, on how it's using it
[03:03] <rsalveti> but would say it's closer with nm
[03:03] <rsalveti> let me check
[03:03] <rsalveti> 1 sec
[03:03] <persia> Please strace the initctl hang first: that's lower level.  it7s not worth masking it in nm if that makes it hard to find the dbus part.
[03:04] <rsalveti> one thing at a time
[03:04] <rsalveti> I want to first find the binary that's causing this
[03:04] <rsalveti> then we can trace that
[03:05] <persia> Honestly, strace the symptom.
[03:05] <persia> if you set strace to follow, you'll track over *many* binaries.
[03:05] <persia> then dpkg -S will tell you the package.
[03:05] <persia> Saves time doing it twive.
[03:06] <rsalveti> but for that I'd have to trace upstart
[03:06] <rsalveti> and not initctl start dbus
[03:06] <rsalveti> because when dbus is started, upstart tells nm to start
[03:07] <rsalveti> and that hangs
[03:07] <GrueMaster> hrm.  Having power & serial console on XM is not fun.
[03:08] <persia> Right.  strace -f -p ...
[03:08] <persia> Then run initctl, and wait for the hang.
[03:08] <persia> then check the strace to find out what hung it.
[03:08] <persia> then dpkg -S to find the offending binary.
[03:13] <GrueMaster> rsalveti: Did you need to use a null modem with your XM?
[03:13] <rsalveti> GrueMaster: nops
[03:14] <rsalveti> usb-serial only
[03:14] <rsalveti> same for panda
[03:14] <GrueMaster> Ok.
[03:15] <GrueMaster> Oops.  Forgot xloader & uboot.  That would explain things.
[03:19] <rsalveti> GrueMaster: :-)
[03:21] <GrueMaster> I only appear to be getting garbage on serial
[03:22] <GrueMaster> Same xloader & uboot as on the daily for beagle, right?
[03:22] <persia> speed?
[03:22] <rsalveti> GrueMaster: yep
[03:23] <GrueMaster> Serial works fine on the beagle.
[03:23] <GrueMaster> Not on XM
[03:24]  * GrueMaster was worried that the exterior renovations done with the dremel may have fouled serial usb adapter.
[03:28]  * persia wishes koffice would build faster.
[03:28] <GrueMaster> sigh.   Time to fix dinner.  Back later.
[03:29] <persia> GrueMaster, You still have spare buildd cycles about?
[03:29] <persia> Ah, not now :)
[03:35] <rsalveti> persia: GrueMaster: interesting, the hang happens when NM tries to activate the usb0 interface
[03:36] <rsalveti> if I give ifconfig usb0 up before initializing NM everything goes well
[03:36] <rsalveti> but if I try to load it directly, it'll hang when trying to activate the usb0
[03:43] <persia> What's the last syscall before it hangs?
[03:57] <rsalveti> a sendmsg to a socket
[03:57] <rsalveti> could be dbus
[04:00] <persia> Which PID does the sendmsg?
[04:01] <persia> And is the specific socket referenced earlier in the strace so you can determine if it's dbus?
[04:06] <rsalveti> cooloney: can you share the binary of your 2.6.35 kernel that works with your es1?
[04:07] <rsalveti> persia: sometimes just ifconfig usb0 up and ifconfig usb0 down gets the problem
[04:07] <rsalveti> the problem is that NM gives up to probe information and then put it down again
[04:07] <rsalveti> and put it up to configure
[04:07] <rsalveti> and this sequence is giving the issue
[04:07] <rsalveti> nm was updated, so this new sequence could be affecting ups
[04:08] <persia> Right.
[04:09] <persia> I'd suggest first concentrating on the ifconfig bit.  Once that's sorted, let's see if the other bugs are still present.
[04:09] <rsalveti> sure, that's what I'm doing
[04:10] <persia> It's clearly unsafe coding, but ifconfig should never cause a hang anyway, and that's the bit talking to the kernel, which is making the system hang (rather than just e.g. NM)
[04:10] <rsalveti> sure
[04:10] <rsalveti> that's why I want to test with latest kernel
[04:10] <rsalveti> from ti
[04:10] <persia> Is there a way to force a kerneloops during a hang?  I get lost when it gets to that level.
[04:10] <rsalveti> depends on the kind of hang
[04:11] <rsalveti> problem with code generally can show the trace and so on
[04:11] <rsalveti> but if the problem happens while communicating with the device, than things can be harder
[04:12] <persia> Not surprising.  I get confused as soon as I get below syscalls (and usually can only solve hangs where strace is looping, or waiting indefinitely for a response that will never come), rather than on the other side, but I imagine there's a few more barriers as one approaches control lines on hardware.
[04:35] <cooloney> rsalveti: it is quite slow for me upload my package, damn it.
[04:37] <rsalveti> it seems a kernel bug at the ethernet driver
[04:37] <rsalveti> will take a better look at the down code
[04:38] <rsalveti> it hangs when giving the ioctl to put the interface down
[04:46] <cooloney> rsalveti: http://people.canonical.com/~roc/kernel/omap4-2.6.35/
[04:47] <cooloney> rsalveti: finally uploaded. it is cross compiled
[04:47] <rsalveti> cooloney: nice, does it work fine with your es1?
[04:49] <cooloney> it boots up on my es1 and works fine with my maverick rootfs.
[04:49] <rsalveti> cool
[04:49] <cooloney> but not tested it on daily image
[04:49] <rsalveti> let me try it
[04:49] <cooloney> ok, thx
[04:49] <rsalveti> np, I'm using a minimal one atm
[05:19] <rsalveti> cooloney: do you have your usb working?
[05:20] <rsalveti> doesn't work for me
[05:20] <rsalveti> and the ethernet needs usb
[05:20] <rsalveti> :-(
[05:23] <cooloney> rsalveti: too bad, doesn't boot at all?
[05:23] <rsalveti> it boots, but doesn't work with usb
[05:23] <rsalveti> that that was the test I wanted to run
[05:23] <rsalveti> but thanks anyway
[05:24] <cooloney> oh, thx, for that. could you post your dmesg somewhere?
[05:24] <cooloney> i will discuss this with sebjan
[05:25] <rsalveti> cooloney: http://paste.ubuntu.com/484321/
[05:29] <cooloney> OMAP4430 ES1.0, is it ES2.0?
[05:29] <cooloney> I assume it is ES2.0, rsalveti
[05:39] <rsalveti> cooloney: es1
[05:40] <rsalveti> cooloney: I wanted to test on the board I know we have issues atm
[05:40] <rsalveti> :-)
[05:40] <GrueMaster> persia: yes, I have the dove ready for building.
[05:41] <rsalveti> cooloney: I can test your deb on my es2 if you want
[05:41] <rsalveti> just a sec
[05:46] <rsalveti> cooloney: usb works with es2
[05:46] <rsalveti> will reply your email
[05:47] <rsalveti> let me test it with 1gb
[05:48] <cooloney> rsalveti: great, man. thx for the testing in your mid night, i think
[05:49] <cooloney> sebjan: told me he fixed some EHCI or USB configuration on ES2.0, so maybe ES1.0 got some issue.
[05:49] <rsalveti> cooloney: hah, yeah
[05:49] <rsalveti> cooloney: oh, cool
[05:49] <rsalveti> they were also working on other things yesterday
[05:49] <rsalveti> mostly display and sound issues
[05:49] <rsalveti> let me put that on the email
[05:55] <cooloney> cool, man, thx a lot
[05:55]  * cooloney needs some food for his lunch
[05:57] <rsalveti> cooloney: sent
[06:12] <persia> GrueMaster, Excellent, although I found somewhere else to run that.  I'll let you know if I think I have another one solved.
[06:12] <persia> (but it might be too late by then)
[06:47] <GrueMaster> persia: If you are looking at ftbfs issues, can you check into ubiquity?  I looked at the lp page, and it indicates a version of ubiquity-frontend-gtk-2.3.8 was built 7 hours ago, but there are no armel packages
[06:47] <persia> https://launchpad.net/ubuntu/+source/ubiquity/2.3.8/+build/1935852
[07:06] <rsalveti> GrueMaster: ogra: lag: if you want usb with ES2 uses cooloney kernel, at http://people.canonical.com/~roc/kernel/omap4-2.6.35/linux-image-2.6.35-903-omap4_2.6.35-903.8_armel.deb
[07:06] <rsalveti> with mine (2.6.34) it doesn't work
[07:07] <rsalveti> ogra: lag: the hang while booting ("dbus" hang):  bug 625108
[07:07] <ubot2> Launchpad bug 625108 in linux-ti-omap4 (Ubuntu) "System hangs when you run ifconfig usb0 up and ifconfig usb0 down (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/625108
[07:07] <rsalveti> I'm still looking at it, but I can confirm that it doesn't happen with ES2 and cooloney's kernel
[07:08] <rsalveti> and the driver didn't get any major changes between 2.6.34 and 2.6.35, so it could be related with the board
[07:09] <rsalveti> ogra: regarding gdm, just now I got a "working" system that I can check this, and the only thing I saw is that doesn't get started
[07:09] <rsalveti> Aug 27 04:13:46 acorn init: gdm goal changed from stop to start
[07:09] <rsalveti> Aug 27 04:13:46 acorn init: gdm state changed from waiting to starting
[07:09] <rsalveti> but that's all
[07:09] <rsalveti> please continue the debugging and I can help looking into that tomorrow
[07:10] <GrueMaster> rsalveti: Don't you sleep?
[07:10] <rsalveti> GrueMaster: ogra: another interesting thing is that the hostname is now "localhost" but I can still get the builder's name at the messages
[07:10] <rsalveti> GrueMaster: I try, but doesn't work that well with me :-)
[07:10] <GrueMaster> That gets changed by oem-config.
[07:10] <rsalveti> I know, but if we want to avoid having the builder's name logged, we should fix that
[07:11] <GrueMaster> Too much Brazilian coffee.
[07:11] <GrueMaster> I need some.  :P
[07:11] <rsalveti> and messages I say the syslog messages of the first boot
[07:11] <rsalveti> GrueMaster: haha, possible
[07:11] <rsalveti> I can try to get you some at uds :-)
[07:11] <rsalveti> or even before, it all depends on ti :-)
[07:11] <GrueMaster> Sorry, can't make it.  Wife hexed me into a cruise.
[07:11] <GrueMaster> TI maybe.
[07:12] <rsalveti> ouch, true
[07:12] <rsalveti> too bad
[07:13] <GrueMaster> When I mentioned UDS and conflict in the same sentence, she started speaking in tongues and I swear her head spun a few times.
[07:13] <rsalveti> lol
[07:14] <GrueMaster> Currently testing the new oem-config fixes on babbage then off to bed.  Seams to work again.  I have hope that we might have a working image again soon.
[07:15] <GrueMaster> "Starting PC Card Services..."  We really need to clean up the image next release.
[07:15] <rsalveti> can't make oem-config to run here
[07:15] <rsalveti> because of gdm it seems
[07:16] <GrueMaster> Which version of oem-config?  2.3.8 is latest.
[07:16] <rsalveti> hm, 2.3.7
[07:16] <GrueMaster> Just finished.  Now to see if GDM starts.
[07:16] <GrueMaster> Oop, removing packages.
[07:17] <rsalveti> cool, good luck
[07:17] <rsalveti> need to go now
[07:17] <rsalveti> see ya in some hours
[07:17] <GrueMaster> yea, understand.
[07:18] <GrueMaster> get some sleep.
[07:27] <GrueMaster> Yea, I now have a booting image again.  20100826.1 + oem-config updates are running on babbage.  Very encouraging.  Night all.
[08:23] <mythripk> Morning All, If you any of you are interested in having a look at omap4 TRM it is now in http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123&navigationId=12667
 07:04:39> ogra: lag: the hang while booting ("dbus" hang):  bug 625108
[08:39] <ubot2> Launchpad bug 625108 in linux-ti-omap4 (Ubuntu) "System hangs when you run ifconfig usb0 up and ifconfig usb0 down (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/625108
[08:39] <lag> Doh
 ogra: lag: the hang while booting ("dbus" hang):  bug625108 <- I don't have working Panda
[08:39] <lag> ES1.0
[08:39] <ogra> :(
[08:49] <lag> ogra: Is there anything wrong with this line?
[08:49] <lag> sudo mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.script boot.scr
[08:59] <ogra> looks ok to me
[09:06] <lag> Weird
[09:06] <lag> It's churning out boot.scr's with no header?
[09:08] <ogra> lag, why sudo ?
[09:08] <lag> Does it make a difference?
[09:08] <ogra> no ideas
[09:08] <lag> I'll try
[09:08] <ogra> never used sudo with mkimage
[09:09] <lag> Didn't make a difference
[09:09] <lag> Still no header
[09:10] <lag> Ah
[09:10] <lag> No
[09:10] <lag> It's just that cat doesn't print it
[09:10] <lag> Emacs displays it fine
[09:13] <ogra> and cat or less dont ?
[09:15] <lag> cat doesn't
[09:15] <lag> less does
[09:16] <persia> what nonprintables do you have in it?
[09:16] <persia> Maybe `TERM=dumb cat ...`?
[09:16] <lag> '^E^YV<A7><a.Lwmm^@^@^A^U^@^@^@^@^@^@^@^@<80><C8>΄^E^B^F^@Ubuntu boot script^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^M^@^@^@^@
[09:16] <lag> :)
[09:16] <lag> It's okay
[09:16] <lag> I can use less/emacs
[09:16] <persia> Yeah, cat should show that with TERM=dumb
[09:16] <lag> It's not a problem
[09:16] <lag> So long as I know
[09:18] <lag> ogra: When do you think the oem-* bug will be fixed?
[09:19] <ogra> lag, i just kicked off a build
[09:19] <ogra> it shoudl be fine in the next image
[09:19] <ogra> though the usb0 bug will hit us hard
[09:19] <lag> Which usb0 bug?
[09:19] <ogra> do you read the channel backlog if you get up ?
[09:20] <persia> That ifconfig up usb0; ifconfig down usb0; ifconfig up usb0 hangs the machine.
[09:20] <ogra> its a useful practice ;)
[09:20] <lag> ogra: No
[09:20] <persia> bug 625108
[09:20] <ubot2> Launchpad bug 625108 in linux-ti-omap4 (Ubuntu) "System hangs when you run ifconfig usb0 up and ifconfig usb0 down (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/625108
[09:20] <lag> Well, I flick though
[09:20] <lag> Usually it's dribble
[09:20] <persia> (which you mentioned to us earlier, so you ought have seen it)
[09:20] <lag> d
[09:21] <lag> Does this happen with TI's new patches?
[09:21] <persia> Hard to say.  The reporter went to bed.
[09:21] <lag> I'll give it a go
[09:21] <persia> Try it with TI's new patches and find out :)
[09:22] <lag> This is Panda ES1.0
[09:22] <lag> I was under the impression that all support for ES1.0 is to be halted?
[09:22] <persia> Bug report is for ES1.0.  I'm not sure it's been tested with ES2.0
[09:23] <persia> Perhaps, but let's make sure the bug is ES1.0 only before we ignore it :)
[09:23] <ogra> hmm, theer is no bug about the dbus hang ?
[09:23] <ogra> lag, tricky for beta we dont have es2 yet
[09:24] <persia> The dbus hang is dbus running NM init once dbus<->NM comes up, which is NM hanging on configuring usb0, which is 625108
[09:24] <ogra> lag, so i guess beta has to stay es1 ... also we dont have bootloader or kernel for es2
[09:24] <persia> rsalveti spent hours hunting it down specifically.
[09:24] <ogra> persia, hmm, i thought i saw initctrl mentioned above
[09:24] <ogra> yes, i see that
[09:24] <persia> Right.  initctl start dbus hangs the machine, by the process I just described.
[09:24] <ogra> ok, then its fine with me ... just not sure what to do ...
[09:25] <persia> kernel bug.  lag's on it.
[09:25] <ogra> apart from disabling usb0 :)
[09:25] <persia> Let's give lag a couple hours to hunt before we use the big hammer :)
[09:25] <ogra> persia, lag doesnt have working usb, no ?
[09:25] <ogra> (on the es1)
[09:26] <persia> Ugh.
[09:26]  * persia dreams of a day when mass commercial HW is available, and all these niggles go away
[09:26] <ogra> natty FTW :)
[09:27] <lag> lag, so i guess beta has to stay es1 ... also we dont have bootloader or kernel for es2 - <Yes we do>
[09:27] <ogra> lag, show me the package on ports.ubuntu.com please
[09:27] <ogra> *packages
 07:06:13> and the driver didn't get any major changes between 2.6.34 and 2.6.35, so it could be related with the board
[09:33] <lag> Don't you read your back-log? =;-)
[09:34] <ogra> Well, I flick though
[09:34] <ogra> :P
[09:34] <lag> That's the wrong message
[09:34] <lag> Doh
 07:05:01> I'm still looking at it, but I can confirm that it doesn't happen with ES2 and cooloney's kernel
[09:35] <lag> That's the one I meant to post
[09:35] <ogra> doesnt really help
[09:35] <ogra> we need to have booting images by thu. no matter what
[09:35] <ogra> and since we only have software for es1 it needs to be es1 images
[09:36] <lag> I can't help you there I'm afraid
[09:38] <lag> The ES1.0 will boot, it just won't have USB working
[09:38] <ogra> is the NIC driver a module so we can at least blacklistz it ?
[09:39]  * ogra can apply a jasper hack that puts a blacklist file in place
[09:40] <lag> You know the NIC drivers needs USB right?
[09:40] <ogra> that wasnt my question :)
[09:41] <ogra> is it modular so we have a worst case solution to get the images booting again ?
[09:42] <lag> I don't believe it is
[09:43] <ogra> damned
[09:46]  * ogra goes to get more coffee while the images build
[09:47] <lag> CONFIG_USB_NET_SMSC95XX=y
[09:47] <persia> What happens if we make that =m ?
[09:47] <persia> Should get us booting, and then we can track down other stuff whilst sorting the problem.
[09:47] <lag> The world implodes
[09:47] <persia> Ah.  That may impair a few things.
[09:47] <lag> I don't know
[09:48] <lag> But do you want to get that config change though SRU?
[09:48] <persia> Could you find out?  The other option is trying to tell NM to ignore usb0.
[09:48] <persia> Sure.  Without it, there's no booting images.
[09:48] <persia> So no beta.
[09:48] <lag> I can't give anything a go ...
[09:48] <lag> I don't have a working ES1.0
[09:48] <persia> But let's let ogra come back: he's more awake than me, to document the issue.
[09:49] <persia> Ah.
[09:53] <cooloney> lag: from the kernel dmesg on my es1, i found
[09:53] <cooloney> [    1.573303] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[09:53] <cooloney> [    1.580200] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd 96
[09:53] <cooloney> [    1.580322] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
[09:53] <cooloney> [    1.580322] ehci-omap ehci-omap.0: starting TI EHCI USB Controller
[09:53] <cooloney> [    1.580352] ehci-omap ehci-omap.0: failed to start ehci
[09:53] <ogra_cmpc> lag, SRU ? you mean asking for a freeze exception
[09:53] <cooloney> it looks like we missed some ehci port0 regulator configuration or driver?
[09:53] <cooloney> lag: any idea about that? maybe it cause our USB failed.
[09:54] <lag> cooloney: You'll have to fix it - I don't have an ES1.0 :(
[09:54] <ogra_cmpc> died you send back both already ?
[09:54] <ogra_cmpc> *did
[09:54] <cooloney> lag: got it, man
[09:56] <lag> ogra_cmpc: Nope, they are both here on my shelf
[09:57] <lag> cooloney: Does your HDMI port work with the current image?
[09:57] <ogra_cmpc> lag, well, the one with broken HDMI might have working USB ;)
[09:57] <ogra_cmpc> and surely has working serial
[09:57] <lag> ogra_cmpc: That's what I was thinking
[09:58]  * ogra_cmpc curses TIs timing ... 
[09:59] <ogra_cmpc> if we only would have been having everything (HW/SW) one week earlier ....
[10:00] <ogra_cmpc> cooloney, will we get the new sebjan tree uploaded before beta ?
[10:00] <cooloney> ogra_cmpc: when is the beta, i guess we are going to upload it soon
[10:01] <ogra_cmpc> beta is on thu but we need the package earlier, i think serious images are due monday or so
[10:02] <cooloney> ogra_cmpc: next thu? or yesterday.
[10:02] <ogra_cmpc> yesterday was beta feeeze, next thu is beta release
[10:03] <cooloney> oh, i c.
[10:03] <cooloney> i am not sure about that.
[10:03] <cooloney> still need to fix audio issue and this USB issue
[10:03] <ogra_cmpc> we wont have probs to get an upload approved but it need to happen very soon
[10:03] <ogra_cmpc> *needs
[10:04] <ogra_cmpc> does the audio issue block anything apart from the obvious ?
[10:04] <ogra_cmpc> else i'd say keep that for post beta
[10:04] <lag> ogra_cmpc: FATAL: Could not load /lib/modules/2.6.35-903-omap4/modules.dep: No such file or directory
[10:04] <ogra_cmpc> we can live with non working audio for beta
[10:05] <ogra_cmpc> lag, you package should have called depmod during package install
[10:05] <ogra_cmpc> looks like a bug in the klinux package
[10:05] <ogra_cmpc> *linux
[10:06] <lag> ogra_cmpc: I'm installing on my chroot
[10:06] <ogra_cmpc> doesnt matter, the postinst of the package should call depmod
[10:06] <lag> Do I just need to copy over the *.dep file from the shroot to the SD card to get it to work
[10:07] <ogra_cmpc> that might workm, though i'd just call it on the SD
[10:07] <persia> Better to call depmod afresh.  Less prone to oddities.
[10:07] <cooloney> ogra_cmpc: i just got 2 patches from sebjan to fix audio issue,
[10:07] <ogra_cmpc> cooloney, ah, cool
[10:07] <cooloney> maybe we can fix it soon
[10:19] <lag> It turns out that pivot-root isn't console specific - Doh!
[10:19] <ogra_cmpc> pivot-root ???
[10:20] <lag> I just pivot-root(ed) into an Arm /
[10:20] <ogra_cmpc> ubuntu hasnt used pivot-root since 2004
[10:20] <lag> I wanted to use it
[10:20] <lag> To run depmod
[10:20] <persia> Why not chroot?
[10:20] <ogra_cmpc> yeah, i was about to ask :)
[10:21] <lag> Because you can't specify the out dir
[10:21] <lag> of depmod
[10:21] <persia> The "out dir"?
[10:21] <ogra_cmpc> ??
[10:21] <lag> Oh, can you chroot into a given /
[10:21] <lag> Rather than a saved one
[10:21] <lag> Hold on
[10:21] <ogra_cmpc> sudo chroot /target/chroot depmod -a
[10:22] <ogra_cmpc> (needs qemu-arm-static installed for armel chroots)
[10:22] <lag> I have that
[10:23] <persia> And you need to copy the interpreter
[10:23] <lag> But my usual chroot != /SDCard/rootfs
[10:23] <persia> So?
[10:23] <persia> chroot takes the target on the command line
[10:23] <ogra_cmpc> mount /dev/mmcblk0p2 /target/chroot ;)
[10:23] <lag> I didn't know you could chroot into random directories
[10:23] <persia> that's the point :)
[10:23]  * lag shrugs 
[10:24] <lag> Every day's a school day
[10:24] <persia> If you don't need that flexibility, schroot is probably more feature-rich.
[10:25] <lag> sudo schroot /media/rootfs/
[10:25] <lag> E: default: Chroot not found
[10:25] <lag> Ahhhhhhhhhhhh, that's the difference between schroot and chroot
[10:26] <lag> root@system1:/# uname -a
[10:26] <lag> Linux system1 2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:12:52 UTC 2010 armv7l GNU/Linux
[10:27]  * ogra_cmpc applauds
[10:27] <lag> ogra_cmpc: Sarky baboon
[10:27] <lag> It still doesn't work
[10:27] <lag> WARNING: Couldn't open directory /lib/modules/2.6.32-24-generic: No such file or directory
[10:27] <lag> Wrong kernel
[10:28] <ogra_cmpc> man depmod :)
[10:29] <lag> -v?
[10:29] <ogra_cmpc> no
[10:29] <lag> version
[10:29] <ogra_cmpc> the manpage summary at the top is a bit confusing i admit
[10:29] <ogra_cmpc> right just give the version
[10:29] <ogra_cmpc> no -v
[10:29] <lag> Oh, they're separate arguments
[10:30] <lag> They should be separated
[10:30] <ogra_cmpc> the text below makes it clearer
[10:30] <ogra_cmpc> If a version is provided, then that kernel version's module directory is used rather  than  the  current
[10:30] <ogra_cmpc>        kernel version (as returned by uname -r).
[10:30] <lag> Who reads more than 5 lines of a manpage?
[10:30] <lag> ;)
[10:30] <ogra_cmpc> heh
[10:30] <lag> Yeah, that's what I read to get 'version'
[10:31] <lag> But I thought -v and version were related
[10:31] <lag> I was correct
[10:31] <ogra_cmpc> -v --verbose
[10:31] <lag> I'm guessing -v would churn out depmod's version
[10:31] <lag> Oh!
[10:31] <lag> Doh!
[10:31] <ogra_cmpc> -V --version
[10:31] <ogra_cmpc>               Show version of program and exit. See below for caveats when run on older kernels.
[10:31] <lag> I would have found it - I was on the right lines
[10:32] <ogra_cmpc> funny that there is no "below" in the manpage anymore
[10:32] <ogra_cmpc> (probably refers to depmod.conf or so)
[10:33] <lag> sudo chroot /media/rootfs/ depmod 2.6.35-903-omap4
[10:33] <ogra_cmpc> yeah
[11:09] <lag> Does anyone know how to do a remote single lined bash command
[11:09] <lag> Something like:
[11:10] <lag> chroot /root bash "for i in \`ls /lib/modules/\`; do echo \$i; done"
[11:10] <ogra> remote ? through ssh =
[11:10] <ogra> ?
[11:10] <lag> chroot /root bash -- for i in `ls /lib/modules/`; do echo $i; done
[11:11] <lag> Actually through chroot
[11:11] <lag> But I guess the principle is the same
[11:11] <ogra> sh -c "mycommand"
[11:11] <persia> Similar, but not quite.
[11:11] <persia> `ssh foo bar` runs command "bar" on host "foo"
[11:11] <ogra> or just leave the shell out og it completely
[11:11] <ogra> *of
[11:12] <persia> `chroot foo bar` runs command "bar" with "foo" as root.
[11:12] <persia> So `chroot foo "for i in ..."` ought do what you seek.
[11:12] <ogra> right
[11:12] <persia> quotes may not be required, but may be safer.
[11:14] <ogra> yes, the quotes were more for ssh :)
[11:15] <lag> I've tried those
[11:15] <lag> Not working
[11:15] <persia> !doesntwork
[11:15] <ubot2> Doesn't work is a strong statement. Does it sit on the couch all day? Does it want more money? Is it on IRC all the time? Please be specific! Examples of what doesn't work tend to help too.
[11:16] <lag> You and your ridiculous !cmds
[11:16] <lag> Do you have a list next to you?
[11:16] <ogra> he has the bot sitting next to him :)
[11:16] <lag> Quite
[11:17] <lag> sudo chroot /media/rootfs/ "for i in `ls /lib/modules/`; do echo $i; done"
[11:17] <lag> chroot: cannot run command `for i in 2.6.28-18-generic\n2.6.31-21-generic\n2.6.32-21-generic\n2.6.32-22-generic\n2.6.32-23-generic\n2.6.32-24-generic; do echo 2.6.32-24-generic; done': No such file or directory
[11:17] <persia> Oh, right.
[11:18] <persia> yeah, for chroot you *do* need to specify the interpreter.
[11:18] <persia> So "/bin/bash for i ...
[11:18] <lag> sudo chroot /media/rootfs/ bash -c "for i in `ls /lib/modules/`; do echo $i; done"
[11:18] <lag> /bin/bash: -c: line 1: syntax error near unexpected token `2.6.31-21-generic'
[11:18] <lag> /bin/bash: -c: line 1: `2.6.31-21-generic'
[11:18] <lag> Tried that too
[11:18] <persia> Otherwise it tries to find "for" in the path, and fails.
[11:18] <lag> Correct
[11:18]  * ogra crosses fingers and boots the latest image
[11:19] <persia> But `chroot /media/rootfs ls /lib/modules` works?
[11:19] <lag> Yes
[11:20] <lag> It's a problem with the bash part
[11:21] <lag> bash -c "for i in `ls /lib/modules/`; do echo $i; done"
[11:21] <lag> That's broken in some way
[11:21] <lag> for i in `ls /lib/modules/`; do echo $i; done
[11:21] <lag> Works fine
[11:21] <persia> How about echo `for i in $(ls /lib/modules/); do echo $i; done" > /media/rootfs/script; chroot /media/rootfs /bin/bash /script`
[11:21] <lag> Got it
[11:21] <lag> It wanted ' not "
[11:22] <XorA> your backticks are executed too early?
[11:22] <persia> Aha!
[11:22] <persia> XorA, On the nose.
[11:24] <lag> sudo chroot /media/rootfs/ bash -c 'for i in `ls /lib/modules`; do depmod $i; done'
[11:24] <lag> That is the winning formula
[11:30] <ogra> GRRR
[11:30] <ogra> so resizing and rebooting works fine
[11:31] <ogra> but it hangs after the fourth dot in plymouth was printed
[11:31] <XorA> see there is a reason I hate all this gui obfuscation
[11:31] <persia> How is plymouth obfuscation?
[11:32] <XorA> it hides the kernel messages
[11:32]  * persia isn't even convinced it's gui with the text profile
[11:32] <persia> Doesn't passing noquiet show them again?
[11:32] <XorA> no idea
[11:33] <persia> Has since Breezy or so.  I think it's not plymouth, but the kernel command line that causes the sense of obfuscation.
[11:33] <persia> But I haven't run with noquiet since jaunty or so, so I may be mistaken.
[11:33] <lag> If you press left/right arrow, you can see the messages
[11:34] <ogra> yeah, seems to be the same issue ricardo sees
[11:35] <ogra> hangs right after ureadahead when trying to start apparmor
[11:35]  * ogra tries to add /e/n/i to üprevent NM
[11:40]  * ogra glares at the gdm screen
[11:40] <ogra> hrm
[11:40] <ogra> where is my oem-config
[11:45] <ogra> k, i think i'll add a hack to jasper to set up /e/n/i, that seems to work fine
[11:51] <ogra> uploaded
[11:51] <ukleinek> moin, does anyone here use a display with an i.MX51 (e.g. Babbage)?  If yes, did you invest some efforts to improve the Freescale driver?
[11:53] <persia> ukleinek, I used to do so, and no.
[11:54] <persia> I remember it not having acceptable acceleration.
[11:54] <persia> (but I was mostly interested in using the device to track down build failures, etc.)
[11:55] <ogra> ukleinek, the display driver around 10.04 time was completely unusable (and non free) so we dont have it, out netbook images used fbdev only
[11:56] <ogra> s/out/our/
[11:57] <amitk> ukleinek: are you working on the fb driver for i.mx51? Robert mentioned something about pengutronix's involvement on linaro-dev...
[12:00] <persia> We'd certainly be happy to ship a better driver, if someone wanted to help maintain it :)
[12:03] <rsalveti> ogra: lag: all you need to do to have a working image is to give "ifconfig usb0 up" before initializing network-manager service :-)
[12:03] <rsalveti> then you'll get everything working fine
[12:03] <rsalveti> with network
[12:03] <rsalveti> as I described at the bug already
[12:04] <rsalveti> so if you bring that up before, starting the services, will probably get everything working
[12:05] <ogra> rsalveti, i uploaded a hack already, waiting for approval
[12:05] <rsalveti> ogra: what did you do?
[12:05] <ogra> rsalveti, just adding usb0 to /etc/network/interfaces
[12:06] <ukleinek> amitk: yes (Robert's my boss in case you don't know)
[12:06] <ogra> that prevents NM from managing it
[12:06] <rsalveti> ogra: hm, ok
[12:06] <rsalveti> will work but no valid network
[12:06] <ogra> its a hack but will get us through beta
[12:06] <amitk> ukleinek: I figured that might be the case :)
[12:06] <rsalveti> yep, but if you give ifconfig usb0 up it'll work *with* network
[12:06] <rsalveti> so, better hack
[12:06] <rsalveti> but anyway
[12:06] <ogra> rsalveti, well, it seems to work, i got the time from ntp during oem-config
[12:06] <lag> rsalveti: Eh?
[12:06]  * rsalveti back to bed
[12:07] <rsalveti> ogra: oh, so cool
[12:07] <rsalveti> lag: what?
[12:07] <ogra> go to bed we need you fresh in the morning :)
[12:07] <rsalveti> if you bring the interface up NM will not bring up/bring down while starting
[12:07] <ogra> right, /e/n/i has the same effect
[12:08] <rsalveti> what could have happened is that the new NM is doing this procedure to get info from the interface
[12:08]  * persia thought it *was* morning
[12:08] <rsalveti> that's why it wasn't happening before
[12:08] <rsalveti> I'd say
[12:08] <rsalveti> ok, see ya in some hours :-)
[12:09]  * rsalveti hopes to see a better image when starts working :-)
[12:09] <ogra> well, its still shaky
[12:09] <persia> rsalveti, Do I have the time wrong?  Is it 8am local for you?
[12:09] <ogra> but gets quite far
[12:10] <rsalveti> persia: yep
[12:10] <rsalveti> cool
[12:10] <persia> Ah, good.
[12:10] <rsalveti> lag: don't you have a working es1 already?
[12:10] <rsalveti> I thought davidm would sent you one
[12:10] <lag> I have two borked ones
[12:10] <rsalveti> lag: two borked?
[12:10] <lag> Yea, but HDMI doesn't work on the new one
[12:11] <rsalveti> so you're the problem
[12:11] <lag> They have different issues
[12:11] <rsalveti> lag: to reproduce this bug you don't need hdmi
[12:11] <lag> Correct
[12:11] <rsalveti> just ifconfig usb0 up/down
[12:11] <lag> That's what I'm working on now
[12:11] <lag> Yeah, I read it
[12:11] <lag> Go to bed ;)
[12:11] <rsalveti> I tried to activate the debugging messages from the module but than I got a huge trace
[12:12] <rsalveti> probably wrong untested code at the debug messages
[12:12] <rsalveti> :-)
[12:12] <rsalveti> ok
[12:12] <rsalveti> see ya
[12:13]  * ogra dances around a working desktop 
[12:13] <ogra> wohooo
[12:14] <persia> \o/
[12:15] <lag> On ES1.0?
[12:15] <ogra> still way to many panels on my screen
[12:15] <ogra> lag, yep, current image with some hacks
[12:15] <lag> Get it built
[12:16] <ogra> well, there is the paperwork ...
[12:16] <ogra> its uploaded but someone needs to approve it
[12:16] <ogra> and it will fail after reboot because of the issues with the old u-boot, we need the new one before beta
[12:17] <ogra> bug #623242
[12:17] <ubot2> Launchpad bug 623242 in pulseaudio (Ubuntu) "speex-float-1 provides poor performance on armel (affects: 1) (heat: 8)" [Low,Triaged] https://launchpad.net/bugs/623242
[12:32]  * ogra_panda waves
[12:36] <lag> ogra_panda == goon :)
[12:37] <lag> hrw: Are you around?
[12:37] <ogra> hey, i'm no bully !
[12:40] <hrw> lag: yes
[12:41] <lag> hrw: What is the module which controls usb0 on the XM? Is it smc91x?
[12:41] <hrw> smsc95xx?
[12:41] <lag> Do you know what it is on the Panda?
[12:49] <lag> hrw: ?
[12:59] <ndec> ogra: hi. is maverick moving to connman or staying with nm?
[12:59]  * ogra twiddles thimbs waiting for the daily archive admin to get up
[12:59] <ogra> ndec, *we* stay with NM
[13:00] <ndec> ogra: thx.
[13:00] <ogra> (our images do)
[13:04]  * persia grumbles.  Why is fpc *still* not bootstrapped?
[13:14] <zumbi_> persia: i though it was
[13:15] <zumbi_> but maybe it is not, later upstream release had arm fixes
[13:15] <persia> zumbi_, It was in Debian, and there was a ticket to have it done in Ubuntu for lucid, and it hasn't been.
[13:15] <persia> zumbi_, feel like trying a bootstrap in Ubuntu, and see if it works?
[13:15] <zumbi_> persia: oh! ok, i was just talking with debian hat
[13:15]  * persia tracks down the relevant bug number
[13:16] <persia> heh
[13:16] <persia> bug #67544
[13:16] <ubot2> Launchpad bug 67544 in fpc (Debian) (and 2 other projects) "Bootstrapping needed for fpc for armel (heat: 5)" [Unknown,Fix released] https://launchpad.net/bugs/67544
[13:22] <zumbi_> persia: for testing ubuntu, is it maverick the right suite?
[13:22] <lag> ogra: I think you'd best check the Kernel Mailing list
[13:22] <persia> That's the one we're working on just now.
[13:23] <zumbi_> i just setup 8 chroots for debian builds (4 suites for i386, amd64) adding a couple more won't hurt :)
[13:24] <persia> Only 8?  I'd have expected you to have armel and armhf build chroots as well.
[13:25] <zumbi_> persia: well this is x86 + cross builds; native arm stuff is in the stack, maybe in some weekend
[13:25] <zumbi_> and arm + qemu .. this is really becoming insane
[13:25] <persia> heh.
[13:26] <persia> arm+qemu is too painful
[13:26] <zumbi_> arm + qemu + croco
[13:26] <persia> madness
[13:26] <persia> I thought you had a few fairly fast settop boxes to play with though?  Why cross-build?
[13:27] <zumbi_> at work we cross build some stuff
[13:27] <zumbi_> usually cross building is very useful for kernels and custom applications
[13:28] <persia> for kernels mostly because getting hardware with decent RAM is nigh impossible these days.
[13:28] <persia> For custom stuff, I still prefer native, unless working on deep embedded targets, but that might just be my prejudice.
[13:29] <zumbi_> for development, cross building helps you being faster
[13:29] <persia> Depends on the HW you can get.
[13:29] <persia> But yeah, fast big RAM hardware is hard to find for ARM.
[13:30] <zumbi_> our hardware is PXA270
[13:32] <persia> Ouch.  Now your propensity to cross-build makes sense :)
[13:42] <zumbi_> Available chroots: lenny_i386 stable_i386 squeeze_i386 testing_i386 sid_i386 unstable_i386 experimental_i386 rc-buggy_i386 maverick_i386 lenny_amd64 stable_amd64 squeeze_amd64 testing_amd64 sid_amd64 unstable_amd64 experimental_amd64 rc-buggy_amd64 maverick_amd64
[13:42] <persia> heh
[13:43] <zumbi_> hrw: which are maverick cross compilers?
[13:43] <zumbi_> http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ || http://ppa.launchpad.net/hrw/arm-cross-compiler/ubuntu ?
[13:47] <hrw> zumbi_: first
[13:47] <hrw> zumbi_: my ppa is empty now
[13:48] <zumbi_> thanks :)
[13:49] <hrw> in few hours there will be binutils + eglibc + linux headers + libgcc there
[13:49] <zumbi_> hrw: built with viro's changes?
[13:49] <zumbi_> (well, for the libgcc part)
[13:52] <hrw> no, I use ubuntu packages now
[13:52] <hrw> zumbi_: when 4.4.4-10(ubuntu1) will land then I will get Al's changes
[13:53] <hrw> zumbi_: Ubuntu versions have all I need now
[13:53] <zumbi_> ok, great! - viro's changes are very cool
[13:57] <ogra> lag, for what ?
[13:57] <lag> The USB issue
[13:57] <lag> Or information on said issue
[13:57]  * ogra only sees 2 linaro pull requests 
[13:58] <ogra> bah, sigh, why do people always need to add a ton of CCs
[13:59] <lag> ogra: I told you the reason to that yesterday
[13:59] <ogra> yeah, its still annoying
[14:00] <lag> Not everyone has the masses of spare time that you do ...
[14:00] <ogra> you cant properly reply to it, and it ends up in the wrong folders
[14:00] <lag> Depends on your filters
[14:00] <ogra> evo filters on ML headers
[14:00] <lag> s/mv/cp ;)
[14:00] <lag> ML?
[14:01] <ogra> mailing list
[14:04] <hrw> zumbi_: better check armel-cross-toolchain-base source package in my ppa
[14:04] <lag> Anyway ... we digress
[14:05] <zumbi_> hrw: i was asking for the maverick chroot setup, I would like to have in the maverick chroot official maverick cross compilers
[14:05] <zumbi_> hrw: i guess i need to check ppa source for the packaging (to get into Debian)
[14:06] <lag> zumbi_: Cross compilers?
[14:06] <zumbi_> hrw: I looked you were basically calling dpkg -x
[14:06] <zumbi_> lag: yeap
[14:07] <lag> Why would you need to cross compile if you're in a chroot?
[14:07] <zumbi_> i am on an amd64 chroot wanting to cross compile a kernel, for example
[14:07] <ogra> usen an armel chroot then ;)
[14:08] <lag> Exactly
[14:08] <zumbi_> ogra: we talked on that arm+qemu+croco is nice, but only work for arm
[14:08] <zumbi_> i would like to keep qemu stuff aside
[14:08] <hrw> armel chroot? its insane waste of resources
[14:09] <ogra> zumbi_, sudo apt-get install qemu-arm-static, sudo qemu-debootstrap armel ...
[14:09] <zumbi_> hrw: they fake armel native compiler with cross compilers
[14:09] <hrw> ogra: and wait 6h to build kernel?
[14:09] <ogra> better than 18h on a beagle ;)
[14:09] <lag> hrw: My armel builds take 20mins
[14:09] <hrw> worse then 0.5h with cross compiler
[14:09] <ogra> or 16h on a qemu vm
[14:09] <lag> From scratch
[14:10] <zumbi_> E: Unable to locate package qemu-arm-static,
[14:10] <ogra> zumbi_, lucid or maverick ?
[14:10] <suihkulokki> kernel is a special case, you dont need qemu or target arch userspace - just a crosscompiler
[14:10] <hrw> or debian?
[14:10] <zumbi_> hold on, i copied from your paste
[14:10] <ogra> well, debian has static packages too but differently named
[14:10] <hrw> suihkulokki: to build other packages I can use xdeb
[14:11] <zumbi_> ogra: maverick
[14:11] <hrw> zumbi_: add universe
[14:11] <ogra> yeah
[14:12] <ogra> though it might be that the transitional package was dropped ... qemu-arm-static points to a hilariously named qemu package
[14:12] <suihkulokki> hrw: sounds interesting.. where can I get it?
[14:12] <ogra> qemu-kvm-extras-static
[14:12] <hrw> suihkulokki: maverick/universe?
[14:12] <ogra> thats the actual package name
[14:13] <hrw> suihkulokki: but you also need cross compiler
[14:13] <zumbi_> suihkulokki: https://blueprints.launchpad.net/ubuntu/+spec/arm-m-xdeb-cross-compilation-environment
[14:13] <hrw> suihkulokki: http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ has ones
[14:13] <zumbi_> suihkulokki: xdeb is a rebranding of cjwatson work for chromeOS
[14:14]  * hrw -> off
[14:14] <zumbi_> bye hrw|gone, and thanks :)
[14:15] <zumbi_> Failed to fetch http://aptcache:3142/uk.archive.ubuntu.com/ubuntu/pool/main/b/binfmt-support/binfmt-support_1.2.18_all.deb  Size mismatch
[14:15] <zumbi_> E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
[14:15] <hrw|gone> zumbi_: once done I will discuss with #emdebian team to merge it to Debian
[14:15] <hrw|gone> al8
[14:15] <zumbi_> hrw|gone: ok, thanks :)
[14:17] <zumbi_> ogra: on maverick, "sudo apt-get install qemu-arm-static" fails :/
[14:17] <ogra> well, try qemu-kvm-extras-static instead
[14:17] <zumbi_> uhm... i wonder if it is taking the one from the cache with it is a debian one
[14:17] <ogra> qemu-arm-static was a transitional package
[14:19] <zumbi_> ogra: it was my aptcache fault
[14:19] <ogra> ah
[14:23] <lag> ogra: Any ideas?
[14:23] <lag> sudo chroot /mnt1
[14:23] <lag> chroot: cannot run command `/bin/bash': No such file or directory
[14:24] <lag> ls -l /mnt1/bin/bash
[14:24] <lag> -rwxr-xr-x 1 root root 658216 2010-08-27 14:23 /mnt1/bin/bash
[14:24] <ogra> hmm, no, check your mount options
[14:24] <zumbi_> ogra: btw, http://pastebin.com/k39xjk2Y
[14:24] <ogra> zumbi_, heh, sorry typo
[14:24] <lag> ogra: /dev/sdc2 on /mnt1 type ext3 (rw)
[14:24] <ogra> --arch armel was indeed the right one
[14:25] <zumbi_> i guess
[14:25] <ogra> zumbi_, and all the other typical debootstrap options too
[14:25] <ogra> the script is just a wrapper around debootstrap
[14:25] <ogra> to copy the static interpreter into your chroot
[14:26] <lag> ogra:
[14:26] <lag> sudo chroot /mnt1 ls
[14:26] <lag> chroot: cannot run command `ls': No such file or directory
[14:27] <ogra> lag, no idea, sorry
[14:27] <lag> :(
[14:27] <ogra> must have something to do with mounting i guess
[14:27] <ogra> since it works in your normal chroot
[14:29] <lag> It _did_ work on the card
[14:29] <ogra> oh, really ?
[14:29] <lag> I've just tried the card it used to work on
[14:29] <ogra> now thats weird
[14:29] <lag> Same thing
[14:29] <lag> Yeah
[14:30] <lag> /dev/sdc2 on /media/549d738f-1c48-4c0a-a8d2-e12286a9fab1 type ext3 (rw,nosuid,nodev,uhelper=udisks)
[14:30] <lag> Oh, this is the daily build
[14:30] <lag> The last one was my homebrew
[14:30] <ogra> nosuid,nodev ?
[14:30] <lag> I didn't specify it
[14:30] <ogra> thats automounted by nautilus i guess
[14:30] <lag> Yeah
[14:30] <ogra> dont do that, the mount options in udisks prevent chrooting
[14:31] <lag> Okay, it still works with my homebrew
[14:32] <lag> /dev/sdc2 on /media/rootfs type ext3 (rw,nosuid,nodev,uhelper=udisks)
[14:32] <lag> That works
[14:32] <lag> Same mount options
[14:32] <lag> How does rootstock and the daily build differ?
[14:34] <lag> SD card too big?
[14:34] <ogra> rootstock builds a tarball daily is a partitioned image
[14:34] <lag> Doesn't support HC devices?
[14:35]  * rsalveti back
[14:36] <lag> rsalveti: It's bed time!
[14:45] <ogra> rsalveti, so for the images, the jasper fix sits in the release queue, i'm waiting for someone in #ubuntu-release to process it and we are waiting for the u-boot-linaro package thats stuck in NEW (and needs some script changes i have to do on the build server)
[14:45] <ogra> then we should have relatively usable images
[14:46] <rsalveti> ogra: awesome
[14:46] <rsalveti> ogra: and how about the oem, gdm and efl session?
[14:46] <rsalveti> is it all working now?
[14:46] <ogra> no
[14:46]  * rsalveti still reading the backlog
[14:46] <ogra> oem-config had a crash after first reboot but worked for me on second
[14:46] <rsalveti> hm
[14:46] <ogra> i havent researched that yet
[14:47] <rsalveti> ok
[14:47] <ogra> gdm is just fine now after the usb0 hack
[14:47] <rsalveti> let me download the latest image
[14:47] <rsalveti> nice
[14:47] <ogra> it doesnt have the usb0 hack yet
[14:48] <rsalveti> ogra: is the 20100827 the latest?
[14:48] <rsalveti> had that issue while browsing the webserver yesterday
[14:48] <rsalveti> ogra: np, I can change that by hand
[14:49] <ogra> rsalveti, right 0827
[14:51] <lag> Does anyone get the SYNC_LOST_DIGIT errors?
[14:51] <ogra> nope
[14:52] <rsalveti> lag: with current kernel, yes
[14:52] <rsalveti> lag: with my LG monitor
[14:52] <rsalveti> this can be fixed with latest hdmi patches
[14:52] <rsalveti> that's why I'm maintaining my own kernel until we get rebased for 2.6.35
[14:53] <lag> When we get rebased, we won't be able to use ES1.0 any longer
[14:55] <rsalveti> lag: I know, but we didn't get the display patches merged because we thought we would have the new version one or two weeks ago
[14:55] <rsalveti> :-)
[14:56] <rsalveti> lag: anyway, if you want to check that out http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-ti-omap4
[14:56] <lag> ASSumption makes ASSes of people ;)
[14:56] <rsalveti> :-)
[15:02] <robclark> lag: fwiw at least on TI kernel tree, it is possible to build for either ES1.0 or ES2.x..  although it still has to be a compile time decision..
[15:10] <rsalveti> robclark: does it work with usb at es1?
[15:10] <rsalveti> robclark: can you say what config should I set? so I can test the ethernet issue
[15:11] <robclark> rsalveti: on es1, you need to use musb instead of ehci..
[15:11] <robclark> so almost need two different defconfig's
[15:11] <rsalveti> hm, ok
[15:11] <rsalveti> makes sense
[15:12] <robclark> anyways, see CONFIG_OMAP4_ES1
[15:12] <rsalveti> robclark: nice, will try, thanks
[15:12] <robclark> np
[15:12] <rsalveti> lag: any progress with the ethernet issue?
[15:13] <lag> On ES1.0?
[15:14] <rsalveti> yep, just wanted to know if you actually spent some time on that
[15:14] <lag> I haven't managed to get a shell yet
[15:14] <rsalveti> we have a workaround and will be switching to es2 (that works) soon, so not a high priority
[15:14] <lag> Yes, do you know why it works?
[15:15] <rsalveti> it's expected to work, the question is why it's not working on es1
[15:15] <lag> USB on the ES1.0 only works due to a hack
[15:15] <rsalveti> but didn't dig further
[15:15] <lag> There is a hardware bug on ES1.0
[15:15] <rsalveti> yep
[15:15] <lag> Hence the stupid cable
[15:15] <ogra> ndec, bug 623242
[15:15] <ubot2> Launchpad bug 623242 in pulseaudio (Ubuntu) "speex-float-1 provides poor performance on armel (affects: 1) (heat: 8)" [Low,Triaged] https://launchpad.net/bugs/623242
[15:15] <rsalveti> lots related with usb
[15:16] <lag> Well ES2.0 doesn't need/have/contain that hack
[15:16] <lag> ES1.0 uses the OTG port
[15:16] <lag> ES2.0 uses true host
[15:17] <rsalveti> yup, true
[15:19] <lag> rsalveti: I'm checking out your kernel now
[15:19] <rsalveti> lag: want the deb file?
[15:20] <rsalveti> http://people.canonical.com/~rsalveti/maverick/kernel/linux-image-2.6.34-903-omap4_2.6.34-903.7rsalveti1_armel.deb
[15:20] <lag> Ta
[15:20] <rsalveti> with this kernel your lg monitor should work fine
[15:24] <lag> I have two monitors
[15:24] <lag> My Phillips one just worked
[15:25] <lag> Until the last couple of builds
[15:25] <lag> Now the SYNC_* happens every time on both monitors
[15:31] <prpplague> ho ho hum
[15:33] <prpplague> davidm: you on the conference call?
[15:34] <ogra> prpplague, we all are
[15:34] <ogra> wanna join ? :)
[15:34] <prpplague> ogra: i'm on
[15:34] <ogra> oh
[15:34] <davidm> yes I am prpplague
[15:34]  * prpplague keeps quiet
[15:34] <lag> Party on PSTN!
[15:34] <ogra> prpplague, dont be shy !
[15:41] <lag> ogra: Snitch!
[15:41] <lag> ;)
[15:41] <ogra> *g*
[15:41] <rsalveti> hm :-)
[15:42] <lag> rsalveti: I get SYNC_ errors, even with your kernel
[15:42] <rsalveti> lag: hm, this shouldn't happen
[15:42] <lag> I told you lot, it's screwed
[15:42] <lag> I know it _shouldn't_ happen
[15:43] <lag> USB is borked on one, HDMI on the other!
[15:43] <rsalveti> haha
[15:46] <ogra> did they tell you to only touch the boards with gloves ?
[15:47] <prpplague> lag: which boards? panda
[15:47] <rsalveti> lol
[15:47] <ogra> prpplague, es1
[15:47] <prpplague> ahh
[15:48] <lag> Yeah
[15:48] <lag> We are caught in the middle of two boards at the moment
[15:49] <lag> rsalveti: Can you send me a paste of an "lsmod" on your Panda?
[15:49] <rsalveti> lag: es1 or es2?
[15:49] <lag> 1
[15:50] <rsalveti> lag: http://paste.ubuntu.com/484517/
[15:51] <lag> ubuntu@panda:~$ ifconfig usb0 up
[15:51] <lag> usb0: ERROR while getting interface flags: No such device
[15:51] <prpplague> odd, neither of those should be loaded for the panda
[15:51] <rsalveti> hm, do you have usb working?
[15:51] <lag> Nope
[15:52] <prpplague> lag: which kernel are you using?
[15:52] <lag> rsalveti's
[15:52] <rsalveti> I have it working here
[15:52] <lag> *shrugs*
[15:52] <prpplague> lag: you got the little black dongle plugged in?
[15:54] <prpplague> davidm: can you give me the url for that wiki page?
[15:54] <lag> http://paste.ubuntu.com/484518/
[15:54] <lag> prpplague: Yep
[15:56] <dcordes> hey guys
[15:56] <dcordes> anybody using netbook interface on a touchscreen only device ? I am wodnering about on screen keyboard
[15:56] <ogra> lag, !
[15:56] <dcordes> I used the onboard keyboard in karmic
[15:56] <lag> ogra: Yes?
[15:57] <rsalveti> lag: http://paste.ubuntu.com/484521/
[15:57]  * ogra just had the idea whats wrong with your chrooting :)
[15:57] <rsalveti> the whole boot log
[15:57] <ogra> lag, you need the interpreter in the SD
[15:57] <rsalveti> usb 1-1.1: adding 1-1.1:1.0 (config #1, interface 0)
[15:57] <rsalveti> smsc95xx 1-1.1:1.0: usb_probe_interface
[15:57] <rsalveti> when your usb is recognized you'll easily notice at the boot log
[15:58] <ogra> lag, cp your /usr/bin/qemu-arm-static binary into the same place on the SD, then you can chroot ... silly i didnt think of that in the beginning
[15:58] <lag> usbcore: registered new interface driver smsc95xx
[15:58] <lag> Does that already exist in my home brew then?
[15:59] <ogra> check for it :)
[15:59] <ogra> very likely
[16:00] <dcordes> a keyboard like this would be nice http://www.youtube.com/watch?v=viSW_RGXzwA
[16:02] <lag> ogra: That worked
[16:02] <ogra> :)
[16:02] <lag> ogra: Can we have it put into the daily build?
[16:02] <ogra> sorry i should have thought of that earlier
[16:02] <dcordes> prpplague: you should put a redirect to the new page http://www.elinux.org/Panda_Bambo
[16:03] <lag> If not, I'll just add it to my scripts
[16:03] <ogra> lag, no, that would require it to be in main
[16:03] <ogra> right, thats the best
[16:03] <dcordes> prpplague: and add internal link for PandaBoard
[16:11] <prpplague> dcordes: mainly just there for early adopter feedback
[16:11] <prpplague> http://www.elinux.org/Panda_Bamboo
[16:11] <lag> rsalveti: Can you dd your entire image (with USB working) and make it available to me please?
[16:13] <dcordes> prpplague: just saying
[16:14] <prpplague> dcordes: yea
[16:14] <prpplague> dcordes: i'll add more as i am allowed, hehe
[16:15] <dcordes> forgot my elinux login
[16:15] <rsalveti> lag: let me post my fat partition stuff and the rootfs tarball
[16:15] <rsalveti> hold on
[16:15] <lag> Just the rootfs would be good
[16:15] <lag> In fact, screw it, I'll take both
[16:16] <rsalveti> ok, will ping you when I'm done
[16:18] <lag> This is from my other board (the one USB is properly borked
[16:18] <lag> usb 1-1: device descriptor read/64, error -110
[16:18] <lag> usb 1-1: device descriptor read/64, error -110
[16:18] <lag> usb 1-1: device not accepting address 4, error -110
[16:18] <lag> usb 1-1: device not accepting address 5, error -110
[16:18] <lag> hub 1-0:1.0: unable to enumerate USB device on port 1
[16:23] <sebjan> ogra: now that mainline u-boot is used, how is x-loader built? (still relying on old u-boot headers?)
[16:24] <rsalveti> sebjan: same way as before
[16:24] <rsalveti> yep, I think it's included at the deb package as a patch
[16:24] <ogra> sebjan, its still the same binary, but we plan to upgrade to the 1GB version
[16:24] <ogra> we'll have to see how that needs to be treated
[16:24] <rsalveti> but even the latest one I'd say that needs the old headers
[16:24]  * ogra would prefer to not have to carry a megabyte big patch for the headers
[16:25] <sebjan> rsalveti, ogra: ok, we still have a small dependency on the old u-boot sources then
[16:25] <rsalveti> yup, at least it didn't compile with latest source from u-boot
[16:25] <ogra> well, in ubuntu i made a patch, the package doesnt use and u-boot tree directly
[16:26] <rsalveti> didn't waste too much time on that, but it seems the they changed a lot the headers
[16:26] <sebjan> ogra: yes, I remember looking at this package, with a big patch for u-boot headers :)
[16:29] <GrueMaster> sigh.  Today's image hangs.  Likely the network manager issue.
[16:29] <ogra> right
[16:29] <ogra> GrueMaster, next will work
[16:29] <GrueMaster> respinning or tomorrow?
[16:29] <ogra> GrueMaster, you shoudl just add usb0 to /e/n/i in advance
[16:29] <ogra> then you wont have the issue
[16:29] <GrueMaster> ok
[16:31] <ogra> GrueMaster, http://bazaar.launchpad.net/~ogra/jasper-initramfs/trunk/revision/67
[16:31] <ogra> was just stuck in the release queue until 20min ago
[16:31] <GrueMaster> perfect.
[16:31] <ogra> now i'm waiting for the linaro u-boot to get out of NEW and into main and i can re-roll images
[16:32] <ogra> oh, and indeed i need to change the build scripts to make use of linaro u-boot :)
[16:33] <rsalveti> :-)
[16:33] <rsalveti> cool, we're getting better
[16:36] <GrueMaster> The jasper fix is just a bit of hackery to move the ball forward, I hope.
[16:37] <rsalveti> GrueMaster: yup
[16:37] <rsalveti> avoiding bring the usb0 down/up
[16:37] <rsalveti> will be fixed once we move to es2
[16:37] <rsalveti> but, not for beta
[16:37] <GrueMaster> ah
[16:39] <GrueMaster> I assumed we missed the boat on beta.  If we can get a prerelease kernel, xloader, and uboot, I can test them on the beta image once I have tested beta.  Help pick up lost time.
[16:39] <GrueMaster> whee.  it's alive!
[16:39] <rsalveti> GrueMaster: ok, ping me when you're ready to test es2
[16:40] <GrueMaster> Anytime.  I'm running today's image with the nic fix now.
[16:41] <GrueMaster> All I need is the kernel package, uboot & xloader.  I can manually munge them into the es1 image from there.
[16:41] <rsalveti> GrueMaster: ok, will just check latest cooloney kernel and let you know about it
[16:41] <rsalveti> lag: 5 minutes to go, tested here already
[16:42] <lag> Remind me what this problem is again: http://paste.ubuntu.com/484545/
[16:42] <lag> rsalveti: Thanks
[16:43] <dcordes> lag: use an initrd that will run fsck on the rootfs on every boot
[16:43] <lag> I make my own initrd
[16:44] <lag> How do I tell it to do that?
[16:44] <dcordes> I bootl ike this
[16:44] <dcordes> http://htc-linux.org/wiki/index.php?title=Rootfs/Userfriendly
[16:44] <lag> I thought Jasper took care of that
[16:44] <rsalveti> ogra: ^
[16:44] <ogra> lag, what image is that ?
[16:45] <ogra> seems not the latest
[16:45] <ogra> (sorry i'm in the release meeting)
[16:45] <lag> It's the daily build with my initrd
[16:45] <dcordes> lag: rootfs is in a file on vfat card and initrd will fsck on it on every boot. works bullet proof for me
[16:45] <ogra> not todays
[16:45]  * lag checks
[16:45] <dcordes> lag: and it allows windows users to switch rootfs. hence the Userfriendly page title
[16:46] <lag> Yes, todays
[16:46] <lag> -rw-r--r-- 1 root    root    2175791104 2010-08-27 08:04 maverick-preinstalled-netbook-armel+omap4.img
[16:46] <ogra> lag, its not todays jasper
[16:46] <ogra> lag, in any case, file a bug and attach that jasper lof
[16:46] <ogra> *log
[16:46] <lag> You mean I have to update Jasper every day
[16:46] <ogra> sorry, but i need to follow the meeting now
[16:47] <ogra> lag, see my conversation with GrueMaster above
[16:47] <dcordes> lag: feel free to reuse anything of it
[16:47] <ogra> there were two jasper fixes uploaded the last 24h
[16:47] <dcordes> I need to ask the initial author of the script for license
[16:47] <rsalveti> lag: http://people.canonical.com/~rsalveti/maverick/lag/
[16:47] <rsalveti> rootfs and first partition content
[16:49] <lag> dcordes: Sorry, that's not going to help
[16:50] <dcordes> lag: hehe yes it's very hacky and I'm sure you will not release images that way
[16:51] <ogra> lag, i suspect there is something wrong at build time, i need to research that before beta but have different issues with higher prio first
[16:51] <ogra> so a bug will help
[16:51] <lag> ogra: Don't worry about it - I'll file the bug and use rsalveti's image in the mean time
[16:51] <ogra> k
[16:51] <dcordes> lag: personally I also used to put rootfilesystems on partitioned cards directly. but that method has many advantages
[16:52] <lag> dcordes: But we're don't going to use that method for our released images :)
[16:56] <dcordes> lag: yes as I anticipated I thought you wouldn't
[16:56] <dcordes> as it can be useful in certain cases it can't harm
[16:57] <dcordes> for me it is a tool to supply people who are new to Linux with ubuntu for their cell phones
[16:58] <GrueMaster> hrm.  gdm is failing now.
[16:58] <ogra> GrueMaster, after install ?
[16:58] <ogra> worked here
[16:58] <dcordes> GrueMaster: in the latest maverick netbook build ?
[16:58] <GrueMaster> Yes
[16:58] <rsalveti> GrueMaster: any error?
[16:59] <GrueMaster> Today's current build + ogra's network fix.
[16:59] <ogra_panda> weird
[16:59] <dcordes> GrueMaster: ok. I am preparing a rootfs with yesterday's .1 build
[16:59] <ogra_panda> id definitely works here
[16:59] <GrueMaster> None.  Startx works fine.  Will deep dive to see what's amiss.
[17:00] <ogra> my usualy question, is the system dbus running ?
[17:00] <dcordes> GrueMaster: is that network fix a user space thing ?
[17:01] <GrueMaster> yes
[17:01] <rsalveti> ogra: GrueMaster: weird, seems oem-config failed
[17:01] <rsalveti> got the gdm screen directly
[17:01] <ogra> rsalveti, reboot
[17:01] <rsalveti> oh, ok
[17:01] <dcordes> GrueMaster: where can it be found ?
[17:01] <ogra> i saw that too, we will need to research
[17:01] <ogra> but only once out of three test installs
[17:03] <dcordes> ogra: is there a mailing list or website to keep track of such things regarding latest maverick arm ?
[17:03] <GrueMaster> dcordes: Need to fix network in the omap4 image before second stage (oem-config) will boot.  http://paste.ubuntu.com/484552/
[17:04] <dcordes> GrueMaster: ah ok. that's not relevant to me
[17:04] <dcordes> htc leo has usb net but I use it in host mode
[17:04] <GrueMaster> That's my "fix it" script.  Run as root.
[17:04] <rsalveti> ogra: nops, gdm still
[17:04] <rsalveti> let me get a console
[17:04] <ogra> look for a crash report in /var/crash
[17:05] <lag> rsalveti:
[17:05] <lag> ubuntu@panda-maverick:~$ dmesg | grep -i smsc
[17:05] <lag> usbcore: registered new interface driver smsc95xx
[17:05] <lag> ubuntu@panda-maverick:~$
[17:05] <GrueMaster> Gah.  6 apport crash reports to wade through.
[17:05] <GrueMaster> None are gdm
[17:05] <ogra> what are they ?
[17:05] <ogra> GrueMaster, oh, and are you on panda ?
[17:05] <rsalveti> lag: ok, but did you get the usb0 interface?
[17:06] <dcordes> ogra: something like launch
[17:06] <lag> rsalveti: Nope
[17:06] <lag> rsalveti: That's the same message I get with my own builds
[17:06] <dcordes> ogra: sorry. something like a launchpad page. or are you only using IRC to discuss such things ?
[17:06] <GrueMaster> Ubuntu one service, indicator-session, gnome-disk-utility, and policy kit.
[17:06] <ogra> PK is a bit worrying
[17:06] <rsalveti> lag: you're out of luck
[17:07] <lag> rsalveti: It can't 'just so happen' that USB is broken on two of my boards!!
[17:07] <GrueMaster> dcordes: We are having a lot of issues atm.  Trying to file bugs and wade through them.  Next week is beta release.  It will have a list of current issues.
[17:08] <lag> ogra: What should I call this bug? In the title?
[17:08] <GrueMaster> lag: fyi:  you aren't supposed to lick the boards before booting.  Thought you should know.  :P
[17:08] <lag> "Jasper is borked"
[17:09] <lag> GrueMaster: Doh!
[17:09] <dcordes> GrueMaster: As I am going to do some work with yesterday's image I would like to contribute in that process
[17:09] <ogra> lag, has nothing to do with jasper
[17:09] <lag> GrueMaster: But they're to tasty!
[17:09] <dcordes> GrueMaster: In that case I will just let you know here if I find something
[17:09] <lag> ogra: What's the issue then?
[17:09] <rsalveti> ogra: there's one crash: ubiquity
[17:09] <ogra> filesystem corruption
[17:09] <lag> What do I file it against then?
[17:09] <ogra> rsalveti, open it (less)
[17:09] <rsalveti> lag: my current daily image went fine
[17:09] <lag> rsalveti: Good for you!
[17:09] <rsalveti> ogra: is it expected to break?
[17:09] <lag> ;)
[17:10] <rsalveti> lag: I mean, without any fs corruption
[17:10] <GrueMaster> dcordes: If you are going to be testing the images, get the latest (which I think ogra will respin soon).  If you find any bugs (highly possible), please subscribe ubuntu-armel-porters.  Thanks.
[17:10] <dcordes> GrueMaster: cool.
[17:10] <rsalveti> ogra: weird: XStartupError: X server exited with return code 1
[17:11] <lag> I'll leave it then
[17:11] <lag> It's probably my borked boards
[17:11] <ogra> rsalveti, nothing more ?
[17:11] <lag> I've had enough
[17:11] <lag> See you on Monday!
[17:11] <ogra> lag, against cdimage please
[17:11] <rsalveti> lag: haha, have a nice weekend! :-)
[17:11] <GrueMaster> lag: Go to the pub and have a cold one.  You've earned it.
[17:12] <lag> ogra: You still want me to report it? rsalveti Said he's not had any trouble?
[17:12] <lag> GrueMaster: I intend to
[17:12] <ogra> hmm, k, i guess once he looks into jasper.log he will see some ;)
[17:12] <lag> I think I'm just going to have to work on ES2.0
[17:12] <lag> rsalveti: Do it
[17:12] <lag> less /var/log/jasper.log
[17:13] <rsalveti> lag: http://paste.ubuntu.com/484554/
[17:14] <lag> I'll leave it then
[17:14] <lag> I'm off
[17:14] <lag> Have a good weekend
[17:15] <ogra> wohoo, i wasnt grilled :)
[17:15] <ogra> dmart, that didnt work, i saw you *all* the time !
[17:16] <ogra> rsalveti, oh, awesome !!!
[17:16]  * ogra likes that log :D
[17:16] <rsalveti> :-)
[17:16] <dmart> heh
[17:17] <ogra> rsalveti, but thats es2 with your own kernel, right ?
[17:17] <rsalveti> ogra: es1, with my kernel (only hdmi fixes), latest image
[17:18] <rsalveti> with ubs0 fix at jasper
[17:18] <ogra> rsalveti, great
[17:18] <ogra> thats calming
[17:18] <rsalveti> weird, now I'm the one who is getting usb errors :-(
[17:19] <dcordes> what is the policy about joining a restricted team ?
[17:20] <ogra> ask the owner
[17:22] <dcordes> davidm: ping
[17:22] <ogra> dcordes, what team is that ?
[17:23] <dcordes> ogra: ubuntu-armel
[17:24] <ogra> you need to be a core dev for that iirc
[17:25] <dcordes> ok I will try to find a bug to report first ;)
[17:25] <davidm> dcordes, yes?
[17:25] <davidm> Ah, ogra answered good enough
[17:25] <dcordes> davidm: ok
[17:27] <dcordes> I like the well organized hierarchical development infrastructure
[17:27] <GrueMaster> ogra: Seems like all 6 of the crash reports I have are Sig 5 crashes.
[17:27] <rsalveti> ogra: ok, after 3 reboots I got oem-config working
[17:27] <rsalveti> probably a racing condition
[17:28] <rsalveti> x and oem-config
[17:28] <ogra> rsalveti, yeah, pretty sure
[17:29] <rsalveti> interesting, even with more ram ureadahead doesn't generate the pack file
[17:29] <rsalveti> so, useless atm
[17:29] <ogra> let me guess, it exists with status 5
[17:30] <rsalveti> don't have the boot log
[17:31] <rsalveti> ogra: my host name is localhost but if I go the the logs, inside /var/log, I can still see the builder's name
[17:31] <rsalveti> sycamore
[17:31] <rsalveti> at daemon.log, for example
[17:31] <rsalveti> or messages
[17:31] <ogra> hmm
[17:31]  * ogra goes to #ubuntu-installer i guess oem-config needs to restart rsyslog
[17:32] <dcordes> very nice. htc leo touchscreen works out of the box with yesetrday's image. I suppose it is using evdev
[17:33] <rsalveti> updated the bug
[17:33] <rsalveti> oh now, another irc channel!
[17:33] <rsalveti> hahah
[17:33] <ogra> heh
[17:33] <dcordes> what is the default login ?
[17:34] <ogra> dcordes, the one you gave during oem-config
[17:34] <dcordes> ogra: it booted straight to the login screen
[17:34] <ogra> then there si something wrong with jasper or the initrd
[17:34] <ogra> *is
[17:35] <rsalveti> well, installing :-)
[17:35] <rsalveti> oem-config window is smaller
[17:35] <rsalveti> can't read all the banner
[17:35] <dcordes> ogra: Ok. I am not using the initrd. I extracted the second partition from the raw image and use it as bare rootfs.
[17:35] <ogra> smaller than the slideshow even, yeah
[17:35] <rsalveti> anyway, /me heads to lunch now
[17:35] <ogra> dcordes, that wont work
[17:36]  * dcordes reads up on oem-config
[17:36] <ogra> you *need* the initrd
[17:36] <ogra> its an essential part
[17:37] <dcordes> ok I will extract it and see what it does
[17:38] <GrueMaster> dcordes: YOu should just dd the entire image to an SD and let it boot.
[17:38] <GrueMaster> After gunzip of course.
[17:39] <dcordes> GrueMaster: That seems like the option for testint purpose. In the long run I will need to find a way to include it with the 'Userfriendly' rootfs method
[17:39] <GrueMaster> ?
[17:39] <GrueMaster> This is about as user-friendly as it gets.
[17:40] <dcordes> GrueMaster: assuming user has Linux
[17:41] <GrueMaster> Ok, before release we will add a link to something like https://launchpad.net/win32-image-writer for the windows crowd.
[17:42] <dcordes> file uInitrd
[17:43]  * ogra goes afk ... i'll come back later and chaneg the build scripts and trigger a build with the new u-boot
[17:44] <GrueMaster> See you later.
[17:44] <dcordes> GrueMaster: That looks interesting, thanks
[17:44] <dcordes> GrueMaster: bye
[17:47] <dcordes> I cannot find how to extract uImage
[17:49] <GrueMaster> dcordes: I'm not going anywhere.
[17:49] <GrueMaster> Why are you trying to extract uImage?
[17:50] <dcordes> GrueMaster: sorry.. of course your replied to ogra.
[17:51] <dcordes> GrueMaster: I want to find out what happens in oem-config . Can't see a wiki page on that
[17:52] <dcordes> s/uImage/uInitrd/
[17:52] <GrueMaster> It only prompts for timezone, keyboard, user info, and system name for the most part.  Beyond that it only removes packages needed for firstboot.
[17:52] <GrueMaster> And it isn't in uImage.
[17:53] <dcordes> Ok. Yeah I confused uInitd with uImage there
[17:53] <GrueMaster> uImage contains jasper on first boot.  It is a script that resizes the root partition to fill the SD card and contains minor hacks to get around current bugs.
[17:54] <GrueMaster> uImage is the kernel of course.
[17:54] <GrueMaster> If you want to see what jasper does, it is here:  https://launchpad.net/ubuntu/+source/jasper-initramfs
[17:56] <dcordes> Thanks. Reading the scripts
[17:59] <dcordes> mkdir -p /root/var/lib/oem-config
[17:59] <dcordes> touch /root/var/lib/oem-config/run
[18:00] <GrueMaster> Simple semaphore to signal oem-config to run.
[18:01] <dcordes> Can you also point me to the sources/scripts used in the initramfs (oem-configs and whatever else it does)
[18:02] <rsalveti-panda> yee
[18:02] <rsalveti-panda> cool, let's see how it goes on my es2 later on
[18:03] <rsalveti-panda> wrong bars still
[18:03] <GrueMaster> rsalveti: XM is running first-boot.  Wheee.
[18:04] <GrueMaster> Errr.  Fail.  Doesn't appear to have run jasper.
[18:06] <GrueMaster> oem-config is coming up, though.
[18:08] <dcordes> GrueMaster: Can you think of a way to run oem-config without the initramfs ?
[18:09] <GrueMaster> yes, just do what jasper does.
[18:09] <GrueMaster> mkdir -p /var/lib/oem-config
[18:09] <GrueMaster> touch /var/lib/oem-config/run
[18:10] <dcordes> ok
[18:14] <dcordes> GrueMaster: I will have to manually add a user first in order to run the commands
[18:14] <dcordes> GrueMaster: It will be better to automate it
[18:19] <dcordes> GrueMaster: is it a problem to have X running (the gdm login screen) when signaling oem-config to run ?
[18:20] <GrueMaster> Why can't you just boot the entire image ant let it do it's thing?
[18:20] <GrueMaster> It is already automated there.
[18:21] <dcordes> Yes I see that. As I mentioned earlier I agree that is the sane thing to do. As I will be using the loopfile on vfat card method it is not suitable
[18:22] <dcordes> I could simply write the configuration in the shipped rootfs but that will cut the advantage of oem-config
[18:22] <dcordes> So it will be best to put a mechanism that will call oem-config once on first boot
[18:22] <dcordes> (from the bare rootfs w/o initrd)
[18:23] <GrueMaster> How are you getting the bare rootfs to the SD now?
[18:23] <dcordes> GrueMaster: like so http://htc-linux.org/wiki/index.php?title=Rootfs/Userfriendly
[18:25] <dcordes> The vfat formatted storage card contains rootfs.ext2 which is loop mounted and ran using an initrd.
[18:27] <GrueMaster> I still am not following.  Our preinstalled images are pre-partitioned.  All the user needs to do is write it to an SD and boot, or is there a bootloader issue involved?
[18:28] <dcordes> Yes, there is no u-boot
[18:28] <GrueMaster> Our image has that.
[18:28] <GrueMaster> And xloader.
[18:30] <dcordes> GrueMaster: can you outline your boot chain ?
[18:30] <GrueMaster> http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage has instructions from Linux.  Use the win32-imagewriter to write from Windows.
[18:31] <GrueMaster> As to boot chain, I think it is documented in the blueprint https://blueprints.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap
[18:32] <dcordes> Awesome
[18:33] <dcordes> What I am wondering is how exactly the boot process operates from kernel execution to target rootfs init execution
[18:33] <dcordes> So I can evaluate if I can implement it on my device
[18:36] <GrueMaster> Essentially, on first boot, jasper copies the data from the vfat partition and reformats it to conform to CHS standards (needed for xloader), then rewrites the data back.  It then resizes root partition to fill the SD card based on the size of the card used (4G or greater required).
[18:38] <GrueMaster> After resizing, it triggers oem-config to run and also does a little house cleaning to work around some other bugs.  Then it reboots and initrd mounts the root partition after a chkdisk scan.  Oem-config is launched by init and if the semephore exists, will prompt for timezone, keyboard, and user info.
[18:39] <GrueMaster> Oem-config then configures those areas and removes first-boot only apps (jasper, oem-config, etc).  After it finishes, it restarts GDM and you are done.
[18:39] <dcordes> Ok thank you very much
[18:40] <dcordes> Are you making use of kernel modules in the entire preparation process ?
[18:41] <GrueMaster> I don't think so.  Most are built in (audio, network, etc).
[18:41] <GrueMaster> I can't think of any that would need to be loaded by uInitrd.
[18:41] <dcordes> Ok that's what I was wondering
[18:42] <dcordes> So basically it seems like I can do that
[18:42] <GrueMaster> Some may get loaded after root is mounted./
[18:42] <dcordes> ..on my device
[18:42] <dcordes> But I will have to modify the initramfs
[18:43] <dcordes> My bootloader can only load normal .cpio or .cpio.gz initrd
[18:45] <GrueMaster> what bootloader are you using?
[18:47] <dcordes> HaRET
[18:48] <dcordes> http://htc-linux.org/wiki/index.php?title=HaRET
[18:50] <dcordes> GrueMaster: where can I find the initramfs ingredients ?
[18:51] <GrueMaster> Are you running a linux desktop atm?  You can extract the entire thing with some manual trickery.
[18:53] <dcordes> GrueMaster: yes I am running Lucid on my x86 laptop
[18:54] <dcordes> GrueMaster: I guess it has some uboot header I need to chop off ?
[18:54] <dcordes> web searches wouldn't help me find how to
[18:54] <GrueMaster> Yes.  dd bs=1 skp=64 if=uInitrd of=initrd.img
[18:54] <GrueMaster> s/skp/skip
[18:55] <GrueMaster> Then zcat initrd | cpio -ivd
[18:57] <dcordes> http://htc-linux.org/wiki/index.php?title=Rootfs/Userfriendly&diff=prev&oldid=2213
[18:57] <dcordes> Ok thanks
[19:02] <GrueMaster> rsalveti: It looks like today's image is hanging on oem-config on my XM.  It has been sitting at getting the time from time server for a while now.
[19:04] <dcordes> GrueMaster: gzip claims the resulting initrd.img is not in gzip format
[19:04] <GrueMaster> right.  Use zcat.
[19:06] <GrueMaster> The above is exactly what I used and it worked.
[19:06] <GrueMaster> (although it should be zcat initrd.img |cpio -ivd ).  forgot the .img
[19:08] <GrueMaster> gzip/gunzip fails for some reason, but zcat works.
[19:11] <ukleinek> GrueMaster: that's not because gzip without further option doesn't write to stdout?
[19:11] <dcordes> GrueMaster: Then something might be wrong on my end
[19:13] <dcordes> GrueMaster: http://pastebin.ca/1927032
[19:17] <GrueMaster> What image are you pulling uInitrd from?
[19:17] <GrueMaster> hrm.  Seeing an issue with today's image now.
[19:18] <dcordes> GrueMaster: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100826.1/maverick-preinstalled-netbook-armel+omap4.img.gz
[19:19] <dcordes> I have very slow internet
[19:22] <GrueMaster> You should be using the omap image, not omap4 (unless your system is omap4).
[19:25] <dcordes> GrueMaster: Why ?
[19:25] <GrueMaster> Different systems.  Different kernels.
[19:25] <GrueMaster> Rest of the image is the same.
[19:25] <dcordes> ok then it does not matter as I use my own kernel
[19:26] <dcordes> GrueMaster: So what's foul with the uInitrd ?
[19:26] <GrueMaster> If you are using your own kernel, and building your own image, then you should just use rootstock to build the image and not try to mess with the preinst image stuff.
[19:27] <GrueMaster> I'm not sure what is up with the uInitrd.
[19:30] <dcordes> GrueMaster: I made the decision to use the preinstalled image as a base for two reasons: rootstock is a time consuimg process which can come with several hurdles. with the preinst I hope to get your guys latest and greatest work with sane configuration
[19:36] <dcordes> GrueMaster: Which build has a uInitrd that you are able to convert ?
[19:36] <dcordes> GrueMaster: Is there no uInitrd 'source package' ?
[19:37] <GrueMaster> I don't know.  One of the older images.  I'm doing testing on multiple platforms.
[19:39] <dcordes> GrueMaster: I would like to look at the script that modifies the rootfs to perform the first boot oem-config
[19:39] <GrueMaster> That would be jasper.
[19:41] <dcordes> mkdir -p /root/var/lib/oem-config
[19:41] <dcordes> touch /root/var/lib/oem-config/run
[19:41] <dcordes> all it has is that
[19:42] <dcordes> I perform that in my rootfs before boot and it will normally boot up to gdm login
[19:42] <dcordes> [...] "Oem-config is launched by init and if the semephore exists, will prompt for timezone, keyboard, and user info."
[19:43] <dcordes> that doesn't seem to happen for me
[19:44] <dcordes> I greped jasper for oem-config and all it shows are those two lines plus the package dependency
[19:44] <dcordes> So if I am missing something it is not in jasper
[19:44] <dcordes> ogra: any hint ?
[19:51] <dcordes> rootfs# ls root/var/lib/oem-config
[19:51] <dcordes> run
[19:51] <dcordes> It is present but does not show the desired effect
[20:03]  * dcordes drops a few pins
[20:03] <dcordes> office time over ?
[20:04] <GrueMaster> No, just caught up in multiple tasks.
[20:04] <dcordes> :>
[20:05] <dcordes> GrueMaster: can you give me some extracted initramfs so I can go find the answer on my own ?
[20:05] <GrueMaster> I'll see what I can do.
[20:06] <dcordes> Thanks
[20:19] <dcordes> My /etc/init.d/oem-config does not seem to check for semephore
[20:56] <dcordes> I don't understand how this initramfs is such a mystery
[20:56] <dcordes> how is it generated ? where are teh sources ?
[21:00] <GrueMaster> I really am busy atm.  But I can tell you that we use livecd-rootfs to create the images.  Beyond that I only really test them and don't know all the sorcery required.
[21:22] <ogra_cmpc> rsalveti, GrueMaster, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100827.1/ there is an omap4 image with linaro u-boot
[21:24] <rsalveti> ogra_cmpc: great! was looking for it right now
[21:24] <rsalveti> even better
[21:24] <rsalveti> want to look at the possible oem-config racing condition
[21:28] <dcordes> rsalveti, ogra_cmpc: I would like to have the bare rootfs start oem-config on first time boot
[21:28] <rsalveti> dcordes: rootstock does that for you
[21:28] <ogra_cmpc> right
[21:28] <rsalveti> you can check the code
[21:29] <dcordes> where is it ?
[21:29] <ogra_cmpc> in ubuntu, apt-get install rootstock
[21:29] <dcordes> 'touch /root/var/lib/oem-config/run' alone does not do the trick. it will still boot to gdm login
[21:30] <ogra_cmpc> did you read the code of jasper carefully ?
[21:30] <dcordes> I am not bootstrapping but still using the autobuild
[21:30] <rsalveti> dcordes: http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/annotate/head:/rootstock#L1136
[21:30] <dcordes> ogra: grep -ri oem-config
[21:30] <ogra_cmpc> thats not reading
[21:30] <ogra_cmpc> read what the code does
[21:30] <ogra_cmpc> or use rootstock
[21:31]  * ogra_cmpc now really ends thye day
[21:32] <GrueMaster> ogra_cmpc: Have a good weekend (and a beer if you can).\
[21:32] <dcordes> rsalveti: it seems to me that is the part that will install oem-config . the preinstalled build I have here has that included already
[21:33] <dcordes> rsalveti: I am just about the init
[21:35] <rsalveti> dcordes: sorry, what are you trying to do?
[21:37] <dcordes> rsalveti: apply the 'first time boot oem-config magic' to rootfs extract from preinstall image
[21:37] <dcordes> rsalveti: (without initramfs)
[21:38] <rsalveti> dcordes: but I don't think you need initramfs to run oem-config
[21:39] <rsalveti> doing what rootstock does is enough
[21:39] <rsalveti> it'll be an upstart init file
[21:40] <GrueMaster> dcordes: Bear in mind that you need to start with either Alpha 3 image or 20100827 as anything in between had a broken oem-config.
[21:45] <rsalveti> yup
[21:45] <dcordes> ok thanks
[21:46] <dcordes> rsalveti: the interesting lines are
[21:46] <dcordes> apt-get install -y --no-install-recommends \$PACKAGE
[21:46] <dcordes> touch /var/lib/oem-config/run
[21:47] <dcordes> rm /usr/lib/ubiquity/plugins/ubi-tasks.py*
[21:47] <dcordes> right ?
[21:48] <dcordes> I basically did that before
[21:48] <dcordes> so it must be broken oem-config problem
[21:51] <rsalveti> dcordes: probably
[21:53] <DanaG> fsck: Error 2 while executing fsck.btrfs for /dev/sde1
[21:53] <DanaG> Can't use btrfs root.
[21:53] <Baybal_> hmmm
[22:01] <jcrigby> DanaG:I see in a pastebin that you posted a week ago the same problem I am seening.  Aug 20 00:50:08 <DanaG> hmm, ubuntu kernel fails on beagleboard: http://pastebin.com/WTjJgxgm
[22:02] <jcrigby> #
[22:02] <jcrigby> [    1.966705] WARNING: at /build/buildd/linux-linaro-2.6.35/arch/arm/mm/ioremap.c:207 __arm_ioremap_pfn_caller+0x20c/0x214()
[22:03] <dcordes> jcrigby: are you using the latest build ? It seems like development is moving fast here
[22:03] <jcrigby> actually latest build -1
[22:03] <jcrigby> I maintain the linaro kernel that does not have the latest Ubuntu diffs
[22:03] <jcrigby> the rcn patches from yesterday
[22:04] <jcrigby> do those fix this problem?
[22:06] <dcordes> jcrigby: what's rcn patches ?
[22:07] <jcrigby> three omap3 patches that went into ubuntu kernel yesterday
[22:12] <dcordes> jcrigby: can't comment there sorry. I only work with qualcomm devices now
[22:13] <jcrigby> dcordes, no problem
[22:13] <dcordes> jcrigby: why don't you use vanilla ?
[22:14] <jcrigby> dcordes, the linaro kernel is an upstream linaro-next kernel merged with ubuntu
[22:15] <jcrigby> we have had display problems since the last merge and I'm trying to find out which upstream is the source of the problem
[23:30] <dcordes> aesome guys it works !
[23:36] <rsalveti> dcordes: cool
[23:37] <dcordes> rsalveti: thanks a lot for the help
[23:38] <rsalveti> np
[23:43] <dcordes> rsalveti: first hurdle in removing hackiness taken
[23:43] <dcordes> rsalveti: now I need to sort out networking
[23:43] <rsalveti> but nice anyway
[23:46] <dcordes> rsalveti: does the netbook interface have restrictions regarding resolution ?
[23:46] <dcordes> rsalveti: by default Xorg will give me portrait display i.e. 480x800
[23:46] <rsalveti> hm
[23:46] <rsalveti> never tried
[23:47] <dcordes> oem-config finished, restart gdm and I only see the wallpaper