=== lopi is now known as Lopi [08:45] diwic: the contextgetstate.patch worked fine.. and solved the exception bug on arm [08:45] xranby, \o/ [08:46] xranby, was it enough to bring up the hajpa hajpa? [08:46] yeah at least for one of the two jvm's [08:46] the other jvm had its own classloader bug.. [08:47] xranby, but that was maybe unrelated to pulseaudio? [08:48] diwic: correct the pulse-audio java layer looks bugfixed now , thanks! the only thing that can break it now are if the java virtual machine have missed to implement some part of the jvm specification [08:48] ok [08:49] diwic: and for arm we are in the situation that oracle do not provide an opensource reference implementation like on x86 :/ so it takes time to get everything super polished [08:51] xranby, ok so a lot of that reference implementation is written in platform dependent language (e g assembly?) [08:51] xranby, vaguely remember you tried to explain some of that stuff at latest UDS [08:52] diwic: yes highly platform dependent, and optimized java virtual machine port contains about 80000 lines of platformspecific code [08:53] ouch [11:09] hm, is the ARM cross compiler toolchain for x86 currently broken? [11:09] (in oneiric) [11:12] apparently the libgcc1-armel-cross package is missing === Quintasan_ is now known as Quintasan [14:31] diwic: it turned out that the reverence implementation did not strictly implement the jni spec :) http://icedtea.classpath.org/hg/icedtea6/rev/23b9bb41de6d [14:31] now \o/ hajpa hajpa work on arm [14:32] hajpa hajpa! [14:35] infinity, ac100-tarball-installer in moderation queue [16:04] ppisati: Can you look at Bug 865479? Thanks. [16:04] Launchpad bug 865479 in linux-ti-omap4 "wl1271: ERROR ELP wakeup timeout" [Undecided,New] https://launchpad.net/bugs/865479 [16:04] Not sure that it is critical, just that it exists. [16:07] infinity: I'm still consistently getting oem-config to respawn. Looking at the log files, I believe this may be the problem: Oct 3 08:12:05 localhost ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable [16:09] Hard to tell, as that message is almost a minute before the respawn message, but it is the only negative message before the next instance of oem-config respawn in syslog. [16:12] I tried to get mongodb working over teh weekend but didn't make it very far [16:39] GrueMaster: I can't get this respawn thing happening at all. :/ [16:40] GrueMaster: I can get the installer to explode in general based on cron.daily eating the system alive. That's about it. [16:40] (And I plan to hack around that with a kludge today) [16:41] Pfft. Figures. Most of the bugs I find are easily reproducible here, but no where else. [16:44] I wonder if the cron.daily stuff is blocking me. Maybe it is doing an apt-get update at the same time? [16:45] That could explain why I see it and others don't. Timing. [16:46] Oh, and the slideshow works again. :) [17:03] what steps are involved in bringing support for a new chip like the Cortex A9 to an OS [17:05] The A9 is new? [17:05] GrueMaster: The cron.daily thing can just explode in general due to system load. I think the debconf DB thing might be a red herring, though. Let me check the log on a successful install run. [17:07] GrueMaster: Yeah, I have that same debconf locking spew on a successful install. [17:07] GrueMaster: So, while it's likely a bug somewhere, it's probably not causing an issue either. [17:08] infinity: new to that os :) [17:08] I just had ubiquity fall apart when I tried to run without any networking. Really bad. [17:09] brandini: Well, things like A8->A9 are really just about building support into toolchains and kernels for shiny new features you might care about, and building support into bootloaders to bring them up. [17:09] Hmm. Something caused the filesystem to remount read-only. [17:09] brandini: But since all your binaries already run (yay backward compat), it's not much effort. [17:10] ok [17:10] GrueMaster: Read-only filesystems usually point to hardware hating you, with a 5% chance of kernel bug... [17:10] (Well, less than 5%, since we tightly control our target platforms here, and we aren't all seeing ro filesystems) [17:11] infinity: I'm the guy that nails that 5%. [17:11] Or your hardware hates you. ;) [17:12] I hate to beat the same dead horse, but when working on SD, I'd tend to blame cards for a filesystem going tits-up before anything else. [17:12] And I really think we should do most of our test installs on hard drives. [17:12] Multiple SD cards and multiple Panda's? I highly doubt I can be having a complete failure here. The odds are against it being my HW. [17:12] Except hitting a card once in a while to make sure the code paths still do what we think they do. :P [17:13] GrueMaster: The odds for hardware are still higher than the idea that a deterministic automated installer only fails in one person's house. [17:13] infinity: Can't test on hard drives. The preinstalled images are designed around SD. It would be equivalent to testing in a VM. [17:13] GrueMaster: And you've been beating on the same SD cards for a while, I'd guess. [17:13] Some are almost brand new since A2. [17:14] GrueMaster: Preinstalled would work on an HDD just fine. [17:14] (Just need to write it differently) [17:14] But yeah. I know the situation we're stuck in. I just dislike it. :P [17:14] I have 5 cards in front of me, and I only trust one of them. [17:14] And that trust won't last forever. [17:16] I have ~2 different cards per board at my disposal. Varying sizes, speeds, an brands. To see these issues across multiple SD cards on Panda A1, A2, and A3 systems is extremely rare. [17:16] Well, wait, which issues? The ro filesystem above sounded like a one-off. [17:17] Remember, I have almost 10 years in hardware validation. I know very well how to triage hardware failures. [17:17] That was the first time I saw it, but also the first time I booted w/o networking. [17:17] Correlation and causation not being the same thing. :P [17:18] And ubiquity crashed with a UBI failure of some sort. Just getting ready to look at the log. [17:18] But it's possible 'fixrtc' stopped working or some such, which could lead to network->badtime->fsbreak. [17:18] But that should break early. [17:18] The log will be useless if the filesystem is ro. Unless you're really lucky. [17:19] dmesg is more likely to be useful. [17:19] fixrtc only runs during boot in initrd I thought. [17:19] Well, it's an at-boot thing. To fix the clock... [17:19] We don't then break the clock later. :P [17:19] Since these images don't have any way to get a terminal session without first modifying the image prior to boot, there is no way to debug a live session. [17:19] So, if it's not working, then without ntpdate, your clock will be a sad panda. [17:20] Yeah, that's so obviously an ARM preinstalled bug. I noticed it with the last week of debugging. :/ [17:21] Since a real live system has the "ubnutu" user, and a real oem-config system has an oem user. [17:21] But we fail to have either. [17:21] Not fixing that before release, though. [17:21] Worth having on the TODO if jasper survives. [17:23] Log files are a bust. complete corruption prior to any ubiquity info. Interesting to see network manager completely freak out though. [17:24] and I have asked for debug hooks of some sort since we started doing preinstalled images. [17:55] GrueMaster: When does the loop happen? [17:55] GrueMaster: I'm going to sit here and try to reproduce this... [17:56] Right around the time it says that it is copying log files. [17:56] GrueMaster: Does everything complete (including the removal)? [17:56] Does not start the removal. [17:57] Hrm. [17:57] I also might not be able to fix the anacron issue this cycle, the more I think about it. [17:57] The fix needs to be in ubiquity, and might be regression-inducing. [17:58] I realised I can't hack around it in jasper, because we don't actually have a sane clock yet. [17:58] Nothing (other than what I previously stated about the config.dat) indicates an issue in any log files I have. [18:00] Hmm. Doesn't appear to like me hacking in an additional debug user prior to oem-config running. It has been sitting on "Creating User" for a while now. [18:14] Grrr, Doesn't appear to like my shadow entry. [21:06] GrueMaster: *poke* [21:07] GrueMaster: Can you do some test runs on your problematic systems with 's/update-apt-xapian-index -q/update-apt-xapian-index -q -u/' in /etc/cron.daily/apt ? [21:07] GrueMaster: Seems to have made mine slightly less grumpy. === NCommander is now known as Guest45434 [21:30] infinity: On it now. [21:30] (took an extended lunch break). [21:30] GrueMaster: All good. Food sounds like a stellar plan to me too. [21:49] Starting the test now on a freshly zero'd & flashed drive. Even if this solves the oem-config respawn, we still have another issue where ubiquity crashes when no network available. === lopi is now known as Lopi [21:54] GrueMaster: Do you have logs for the no-network thing? That one couldn't have been silent... I hope. [21:54] GrueMaster: Or even an apport-filed bug would be nice. [21:55] Well, that was part of the problem. ubiquity crashed saying it would spawn a desktop session for debugging, but that failed to materialize. And nothing was captured in the logs as the system had gone read-only. [21:56] I'll try to reproduce it as well. I would really like to have an image that I can get to a login for testing though. Otherwise I am just spinning my wheels on useless stuff. [21:56] Oh, that was the read-only one, right. [21:56] I suspect that one might not be reproducible, but if it is, great. [21:57] If the FS isn't readonly, ubiquity crashes will spawn apport, which is good enough for filing bugs with logs, at any rate. [21:57] If jasper survives another cycle, we should remember to add the oem user, though. [21:58] I'll prep another SD to test that, but for desktop, I am kind of limited to single tasking (1 monitor & keyboard for Pandas). [21:58] Oh, wait. No. There shouldn't be one, it's deleted by oem-config-prepare before rebooting. [21:58] So, oem-config in general just has no way to debug it. Hrm. [21:59] Not that I have found useful. [21:59] I've been testing on my ac100 too. Which picks up slightly different bugs just due to the timing of having faster storage. [21:59] Panda and ac100 together seem to get most everything.. Except your respawn issue. :/ [21:59] And fail. The cron.daily fix is bust. [22:00] Well, it does address *a* problem. Just not yours, apparently. [22:00] And I honestly can't get ubiquity to crash/respawn at all (or finish/respawn, or any combination thereof), so I'm kinda stumped. [22:01] A full set of logs (heck, just /var/log tarred up) from the SD might be enlightening. [22:02] Unfortunately, it isn't as enlightening as one would expect. I have yet to find a significant entry in any logs under /var/log. [22:03] The best I had was the debconf config.dat file (which you said wasn't significant). [22:07] Sigh. I hate the automount "feature". It really annoys me. And what's with the AC100 showing (and mounting) all of the SERVICEV001 partitions? [22:09] GrueMaster: It doesn't? [22:09] GrueMaster: At least, it doesn't here. [22:10] GrueMaster: You sure that's not a freshly-flashed card? [22:10] Could be because I upgraded from Natty. [22:10] (It's only SERVICEV001 after it's booted) [22:10] I'm talking about the eMMC. [22:11] Oh. yeah, I get no weirdness here. [22:11] You might want to try the recent images. :) [22:11] They actually work better than OMAP. [22:11] Which is a bit sad. [22:11] But yay for faster storage. [22:11] As I said, if there is >.01% chance of weirdness, I will hit it. [22:12] Anyhow. Going to take a late lunch. [22:12] Back later to keep banging on things. [22:13] On the looping installer thing, if you can just let it settle a bit after it loops, so it's sure to have flushed some buffers, yank the card, and give me /var/log in a tarball, maybe I'll spot something that doesn't add up compared to one here. [22:14] I usually wait until it comes up, then switch to text console and 3-finger reset so everything shuts down cleanly. [22:16] You could just alt-sysrq-s to force a sync, wait for the SD light to go out, and yank it. That has the advantage of basically being a snapshot of the problem area without reboot fluff afterward. [22:17] reboot fluff is minimal (and tarball is in my people.c.c dir (firtname)/20111003-oem-fail-logs.tgz [22:18] Great, I'll look at it after lunch. [22:18] That's the re-spawn one? [22:18] starting on the network-less run. [22:18] Yes. [22:18] Kay. [22:19] W/o network crashes much more ugly before it even gets that far.\ [22:27] Grr. Network crash didn't happen this time around, but oem-config respan did. === Guest45434 is now known as NCommander === NCommander is now known as Guest61019 === NCommand1r is now known as NCommander === Guest16725 is now known as StevenK === Jack87|Away is now known as Jack87