**** BEGIN LOGGING AT Fri Mar 19 02:59:56 2010 Mar 19 06:48:35 Hi, https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/535183 patch V2, which was now included in upstream pixman http://cgit.freedesktop.org/pixman/commit/?id=18f0de452dc7e12e4cb544d761a626d5c6031663, checks for uqadd8 with forced -marm, which means that when we build that binary with thumb enabled, then it will contain not available uqadd8 and fail with SIGILL on ie armv4t Mar 19 06:48:39 Launchpad bug 535183 in pixman (Ubuntu) "pixman doesn't autodetect SIMD support at build time on arm. (affects: 1)" [Undecided,Fix released] Mar 19 06:50:05 If you really want to do it this way, then there should probably be -marm also in coresponding ARM_SIMD_CFLAGS="-mcpu=arm1136j-s" Mar 19 07:00:07 ah, there is -marm in ARM_SIMD_CFLAGS but somehow not used somewhere.. Mar 19 07:00:29 JaMa: Am I reading the patch incorrectly? I'd expect the failure to unset have_arm_simd=yes, so that it wouldn't compile that bit in. Mar 19 07:00:52 I think we're expecting that failure for ARMv4t, so that ./configure can do the right thing. Mar 19 07:01:31 persia: but that 2nd run, detects uqadd8 usable but with -marm in CFLAGS Mar 19 07:02:00 persia: and than it builds pixmap probably without forced -marm (ARM_SIMD_CFLAGS is maybe used only in this configure test) Mar 19 07:02:27 persia: and resulting thumb binary is created with supposed uqadd8 support Mar 19 07:02:54 persia: trying that patch v1, which looks safer to me Mar 19 07:03:06 But shouldn't the second run only happen if the first run is successful? Mar 19 07:04:46 JaMa: are you setting -mthumb via CFLAGS? Mar 19 07:05:38 JaMa: see <20100314172510.GA3901@bee.dooz.org> on pixman@lists.freedesktop.org Mar 19 07:05:41 lool: yes Mar 19 07:05:47 here is my config.log http://paste.pocoo.org/show/191446/ Mar 19 07:05:58 http://article.gmane.org/gmane.comp.graphics.pixman/59 Mar 19 07:07:16 JaMa: So I think configure is kind of doing the right thing here, but in an ideal world we could avoid it Mar 19 07:07:54 JaMa: You're using CFLAGS which in autotools is an override over the per-file and global upstream CFLAGS Mar 19 07:08:52 JaMa: So even if we try with proper -mcpu= and -marm, it doesn't build because you override with -mthumb; perhaps the check could build the piece of code with a newer CPU and -mthumb as well to cover this case more nicely though Mar 19 07:09:10 It's a bit ugly as it is, and would make it worse I guess Mar 19 07:09:29 ideally, we'd move the code to a separate .S file and turn on what we need in there Mar 19 07:09:50 this is crosscompile build with OE, so I work-arounded it with --disable-arm-simd for now, but thanks for help, I'll try better, but now I have to go to work.. Mar 19 07:10:27 Ok Mar 19 07:10:45 I don't think you should have to --disable-arm-simd; it should be the default?! Mar 19 07:11:26 lool: after this commit it changes detected value from No to Yes Mar 19 07:11:49 lool: so with --disable-arm-simd only for armv4t I'm forcing it to stay disabled as it was before Mar 19 07:12:19 lool: as -mthumb was there for all builds before and after Mar 19 07:12:47 Your config.log indicates USE_ARM_SIMD is false?! Mar 19 07:13:33 lool: yes for 933540861383da27402680593edefe8d61e6fb02 and older Mar 19 07:13:42 Oh, that's an older config.log Mar 19 07:13:52 well I'm interested in a newer one :) Mar 19 07:15:06 lool: but that's I guess expected, because before it wasn't tried with -marm, mmt I'll pastebin new Mar 19 07:17:41 933540861383da27402680593edefe8d61e6fb02 http://paste.pocoo.org/show/191449/ Mar 19 07:19:14 18f0de452dc7e12e4cb544d761a626d5c6031663 http://paste.pocoo.org/show/191450/ Mar 19 07:19:28 and now really off, see you in an hour or so Mar 19 07:21:14 that's odd, I see only one compile with -mcpu=arm1136j-s, not the one wihtout Mar 19 07:23:56 JaMa: So it detects it, and then it fails to build? Mar 19 07:24:01 Hrm? That test certainly looked like "compile without, on success, compile with, on success, set variable" Mar 19 07:25:14 I wonder why it's called as: Mar 19 07:25:15 arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c -mcpu=arm1136j-s -marm Mar 19 07:25:24 I wrote: CFLAGS="$ARM_SIMD_CFLAGS $CFLAGS" Mar 19 07:25:46 So I would think it should look like arm-oe-linux-gnueabi-gcc -mcpu=arm1136j-s -marm -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c Mar 19 07:25:50 which should fail Mar 19 07:26:29 Could it potentially be doing $COMPILER_DEFAULT_CFLAGS $USER_SUPPLIED_CFLAGS ? Mar 19 07:26:45 $COMPILER_DEFAULT_CFLAGS doesn't appear on the cmdline usually Mar 19 07:26:59 True. Hrm. Mar 19 07:29:30 Looking at the command line, I wonder if maybe the -march and -mtune stuff is added later, using the same $NEW_CFLAGS $CFLAGS approach. Mar 19 07:29:42 They all seem to be based on arguments passed to configure. Mar 19 07:30:01 But I'm grasping at straws at this point. Mar 19 07:32:13 it seems configure is playing clever with the args Mar 19 07:32:22 arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c -isystem/OE/tmpdir-dev-shr/staging/armv4t-oe-linux-gnueabi/usr/include Mar 19 07:32:34 and then arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c -mcpu=arm1136j-s -marm -isystem/OE/tmpdir-dev-shr/staging/armv4t-oe-linux-gnueabi/usr/include Mar 19 07:32:52 so clearly the only way for flags to end up in the middle is that someone reorders them Mar 19 07:32:55 Indeed. That is being overly clever. Mar 19 07:33:37 and it's done before running CC since the flags only appear once Mar 19 07:33:53 Well, I'm tempted to walk away in disgust :-) Mar 19 07:35:03 ah perhaps I'm actually wrong Mar 19 07:35:16 -include stuff might be CPPFLAGS Mar 19 07:35:28 ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5' Mar 19 07:35:37 Aha! Mar 19 07:35:41 So $CC is the culprit. Mar 19 07:35:57 $CC is evaluating to "arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb" Mar 19 07:36:15 Followed by -c $CFLAGS $CPPFLAGS Mar 19 07:38:45 JaMa: So you're setting the flags in CC, not in CFLAGS? Mar 19 07:44:18 JaMa: are you getting pixman build failure or SIGILL at runtime? Mar 19 08:09:30 ssvb_: SIGILL at runtime Mar 19 08:10:19 lool: yes it's in CC Mar 19 08:12:50 lool: here is whole environment, how bitbake runs configure http://pastebin.ca/1845506 Mar 19 08:12:55 JaMa: that's pretty bad, looks like runtime cpu features detection is failing for you Mar 19 08:14:23 JaMa: can you add some debugging stuff in pixman-cpu.c to check whether/why 'arm_has_v6' variable gets set to true? Mar 19 08:14:29 JaMa: What breaks if you put that stuff in $CFLAGS instead of in $CC ? Having it in $CC subverts the test, causing the issue. Mar 19 08:15:09 ssvb_: runtime? this is crosscompile build and SIMD wasn't enabled before, so SIMD code should workarround missing uqadd8 in runtime? Mar 19 08:15:20 JaMa: I know that autodetection was behaving weird in qemu Mar 19 08:15:41 I don't use qemu here.. Mar 19 08:16:06 JaMa: so you haven't run your binary on real device yet? Mar 19 08:16:48 it works ok if I disable simd wiht --disable-arm-simd and probably also work if I disable thumb for whole pixman Mar 19 08:17:10 JaMa: if you don't want any armv6 simd optimizations and want to save some space, --disable-arm-simd is your choice Mar 19 08:17:13 the same bitbake build for armv5te works ok without any work-arround and with thumb enabled Mar 19 08:17:55 JaMa: what is your definition of 'works ok'? Mar 19 08:18:16 ssvb_: that's what I used before, but I'm asking why it's autodetected now as available (not respecting -mthumb, well in wrongly used CC) Mar 19 08:18:35 ssvb_: works ok = no SIGILL on device and Xorg running ok Mar 19 08:18:52 ssvb_: doesn't work at all = SIGILL when starting Xorg Mar 19 08:19:04 JaMa: so can you confirm SIGILL? Mar 19 08:19:19 ssvb_: yes Mar 19 08:19:28 ssvb_: that was first message I sent here :) Mar 19 08:20:13 JaMa: I just wanted to have a confirmation Mar 19 08:20:29 JaMa: do you have any way to debug this stuff on the device? Mar 19 08:21:17 ssvb_: and I already prepared --disable-arm-simd builds to get usable device again, because it "restores" old behavior for armv4t with thumb forced Mar 19 08:21:39 JaMa: function 'pixman_arm_read_auxv' is the most likely culprit if it detects availability of armv6 instructions wrong Mar 19 08:22:22 ssvb_: and do I really want simd enabled? as you already said I probably don't need it, so I can debug it, but I'm not sure it's worth it Mar 19 08:22:24 * lool is back Mar 19 08:22:28 JaMa: yes, if you don't want to debug this issue, then you can use this as a workaround for sure Mar 19 08:23:31 JaMa: So to recap, two issues here: one is SIMD gets turned on as intended when CFLAGS allow it (CFLAGS override CC, so it's correct); this is working as expected; second issue is runtime detection which triggers a SIGILL on your device, that's a bug Mar 19 08:24:05 JaMa: what I wanted to know is whether 'arm_has_v6' variable evaluates to true (that would be one possible bug), and if it is not, then where exactly is the location of the wrong instruction Mar 19 08:24:20 JaMa: In practice you don't care about SIMD, but perhaps you care that everybody with the same use case as yours doesn't have to pass --disable-simd Mar 19 08:25:20 lool: why cannot you pass -marm to CFLAGS if SIMD is enabled only in that second run? Mar 19 08:25:46 lool: this would if I get you right, enable working simd for cost of overriding thumb from CC Mar 19 08:25:58 JaMa: That's what's happening actually Mar 19 08:26:05 JaMa: which is why you can build and run it Mar 19 08:26:07 lool: but only in conftest not build Mar 19 08:26:16 That should be the case during build Mar 19 08:26:28 mmt I'll check Mar 19 08:26:30 JaMa: Note that it's only used to build a couple of files Mar 19 08:26:47 Only one actually, -pixman-arm-simd.c Mar 19 08:27:20 lool: with -mthumb moved from CC to CFLAGS, configure detects simd as "no" Mar 19 08:28:13 JaMa: Yes Mar 19 08:28:35 JaMa: that's a limitation due to the fact that user-specified CFLAGS override our CFLAGS Mar 19 08:30:12 JaMa: But as ssvb_ points out, the bug here is a runtime one; the only real life problem we're seeing is that you get a SIGILL, and it's not clear why Mar 19 08:30:31 it would seem the detection code reports v6 as present at runtime while it's not Mar 19 08:31:54 this is how it fails http://pastebin.ca/1845518 Mar 19 08:33:08 JaMa: can you also add 'info registers' output? Mar 19 08:33:46 ssvb_: sure mmt, have to reinstall faulty version Mar 19 08:34:00 I wonder whether it's a thumb/non-thumb issue Mar 19 08:34:18 I think so Mar 19 08:34:44 JaMa: What's your CPU again? Mar 19 08:35:31 samsung s3c2442 ARM920T rev 0 (v4l) Mar 19 08:36:17 JaMa: and in configure output, do you get NEON detected or not detected? Mar 19 08:36:57 lool: neon is disabled with configure option Mar 19 08:39:56 with thumb disabled in OE (resulting in -mno-thumb in CC) no SIGILL, but SIMD is detected as disabled, so it's not interesting case Mar 19 08:41:31 that's odd Mar 19 08:41:50 it should turn on SIMD if you only set -mno-thumb in CC Mar 19 08:41:55 (but not in cflags) Mar 19 08:42:06 JaMa: If you run that ./configure natively, does it work as expected? (I don't expect a real compile, just curious if it's an OE-only thing, or a hardware thing). Mar 19 08:44:06 JaMa: do you have -mthumb-interwork option somewhere? Mar 19 08:44:42 ssvb_: Oh good point Mar 19 08:45:42 JaMa: I wonder if not having it may also cause some kind of screwup in the linker (even if arm/thumb calls are not supposed to be happening at runtime) Mar 19 08:46:00 ssvb_: http://pastebin.ca/1845528 Mar 19 08:47:17 ssvb_: configure:11496: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mno-thumb -c -mcpu=arm1136j-s -marm Mar 19 08:48:05 ssvb_: and with thumb enabled Mar 19 08:48:10 ssvb_: configure:11479: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb Mar 19 08:48:11 JaMa: the most interesting address 0x401af86a (pc register value) is missing in the disassembly Mar 19 08:48:15 Weird, I don't find -mthumb-interwork in our Ubuntu defaults, but we don't seem to have screwups without it Mar 19 08:49:41 ssvb_: http://pastebin.ca/1845535 but still missing I'll try to disassm with objdump instead gdb Mar 19 08:52:52 JaMa: it could be that it is just some garbage padding data between functions and not a real instruction, in this case it would be interesing to know how it managed to get there Mar 19 08:54:19 JaMa: if it was a function call, then 'lr' register should point to the return address (and call instruction itself should be just before it) Mar 19 09:01:13 JaMa: what toolchain are you using? gcc, and binutils versions Mar 19 09:02:45 gcc-4.4.3 binutils-2.20 Mar 19 09:04:02 JaMa: now I suspect that the 'alien' object file with arm code may create some kind of bubble in the resulting binary and the function addresses may get all wrong and shifted on one of the sides of the 'bubble' Mar 19 09:04:39 mmt binutils for target already built, I'll provide disassm with thumb forced Mar 19 09:19:03 JaMa: just tried googling a bit: http://old.nabble.com/binutils-2.20.1-td27432353.html Mar 19 09:19:16 it says something about "broken thumb->arm intersection branches", don't know if it is relevant Mar 19 09:20:06 JaMa: but if you could downgrading binutils to 2.19 just for testing, it would be interesting Mar 19 09:22:18 ssvb_: http://jama.homelinux.org/org.openembedded.shr.images/om-gta02/pixman/ Mar 19 09:23:07 ssvb_: here is disassembled lib with objdump with and without -M force-thumb, but with it fails later on some instruction and Aborts Mar 19 09:26:07 JaMa: btw, I'm trying to reproduce your environment now (gcc, binutils, CC, CFLAGS), I have a gut feeling that it could be one of the bugs in binutils 2.20 Mar 19 09:26:37 ssvb_: trying to downgrade now Mar 19 10:32:45 JaMa: could not break anything here with CC="gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb" CFLAGS="-fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os" Mar 19 10:33:17 though I have armv7 CPU, and just noticed that I actually used binutils 2.20.1 Mar 19 10:34:38 ssvb_: on armv5te it works for me too Mar 19 10:36:12 JaMa: did you try running the same binary on armv5te? or it had its own CC and CFLAGS? Mar 19 10:38:13 JaMa: if something runs on armv5te but does not run on armv4t, then it could be a PLD instruction somewhere Mar 19 10:39:48 UQADD8 and the other ARM SIMD instructions would only run on armv6 and newer Mar 19 10:40:10 ssvb_: yeah same binary Mar 19 10:40:48 pld or clz Mar 19 10:42:35 JamieBennett: all fine wrt to langpack.mk ? Mar 19 10:42:48 or blocked ;) Mar 19 10:42:49 ? Mar 19 10:43:05 asac: still working on it, I have a branch if your available to inspect it Mar 19 10:43:18 (and using distutils) Mar 19 10:43:36 JamieBennett: yeah if you have that i can look ;) Mar 19 10:44:06 asac: Its not ready so I would appreciate pointers Mar 19 10:44:17 let me look Mar 19 10:44:20 https://code.edge.launchpad.net/~jamiebennett/+junk/webservice-office-zoho-translation-support Mar 19 10:44:20 i guess in +junk? Mar 19 10:44:37 ok found ;) . oh hehe Mar 19 10:44:49 lots of noise as I had to reorganise it Mar 19 10:46:00 asac: probably lots wrong at the moment Mar 19 10:46:18 hmm Mar 19 10:46:24 why was all that needed? Mar 19 10:46:33 thought we just needed to make .desktop translatable Mar 19 10:47:02 there was a comment about the code being translatable too and persia recommended doing it 'properly' Mar 19 10:47:13 Also had to add setup.py Mar 19 10:48:21 where is the bug? https://bugs.edge.launchpad.net/ubuntu/+source/webservice-office-zoho Mar 19 10:48:24 there is nothing ;) Mar 19 10:48:44 asac: It was the MIR which has now been approved Mar 19 10:49:05 JamieBennett: but you were supposed to file a high bug about this ;) Mar 19 10:49:09 also the MIR bug isnt even there ,) Mar 19 10:49:14 https://bugs.edge.launchpad.net/ubuntu/+source/webservice-office-zoho/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=& Mar 19 10:49:23 asac: https://bugs.edge.launchpad.net/webservice-office-zoho/+bug/539626 Mar 19 10:49:25 Ouch Mar 19 10:49:28 :) Mar 19 10:49:28 Launchpad bug 539626 in webservice-office-zoho "Needs translation support (affects: 1)" [Critical,Confirmed] Mar 19 10:49:54 JamieBennett: thats not an ubuntu bug Mar 19 10:50:09 added Mar 19 10:50:16 I know, the project got moved and now the bug is on the wrong project Mar 19 10:50:21 asac: thanks Mar 19 10:50:31 JamieBennett: where is the MIR bug? Mar 19 10:51:08 bug: 537323 Mar 19 10:51:28 JaMa: Don't know what to advise in this case, the problems could be also related to buggy/misconfigured kernel or silicon bugs in CPU. But in this case you would have stability issues with the other packages too. Mar 19 10:51:31 https://bugs.edge.launchpad.net/webservice-office-zoho/+bug/537323 Mar 19 10:51:33 lp #537323 Mar 19 10:51:33 Launchpad bug 537323 in webservice-office-zoho (Ubuntu) (and 1 other project) "[MIR] Main inclusion request for webservice-office-zoho (affects: 1)" [Undecided,New] Mar 19 10:51:35 Launchpad bug 537323 in webservice-office-zoho (Ubuntu) (and 1 other project) "[MIR] Main inclusion request for webservice-office-zoho (affects: 1)" [Undecided,New] https://launchpad.net/bugs/537323 Mar 19 10:52:23 ok added ubuntu there too Mar 19 10:53:03 i dont think upstream .desktop files can be translated with gettext Mar 19 10:53:06 but maybe i am wrong Mar 19 10:53:16 JaMa: extracting the problematic instruction at pc address from gdb somehow would provide some insights. Can you at least read it as just binary data (via x gdb command)? Mar 19 10:53:18 for real code stuff sure Mar 19 10:54:14 .desktop files should be .desktop.in Mar 19 10:54:21 asac: Upstream .desktop can be translated with gettext just fine. A large number of GNOME packages do that. Mar 19 10:55:32 JaMa: it would be 'x/4b $pc' when it dies with SIGILL Mar 19 12:01:21 what happen if I run Lucid on a armv5 board? (nothing|broken|just slow) Mar 19 12:09:09 gaspa: It won't run. Mar 19 12:09:27 SIGILL Mar 19 12:09:30 gaspa: I suspect that you won't even be able to boot, because upstart will SIGILL Mar 19 12:09:41 right, as expected, thanks. Mar 19 12:10:25 further question, given a binary, can I know for which armvX is compiled? Mar 19 12:19:47 I don't know of any way. There may be some trick you can do with magic numbers, but I'm unsure how far I'd trust it beyond ARM vs. Thumb Mar 19 12:23:58 ssvb_: 0x401af7c2 : -128 -24 -128 32 Mar 19 12:24:19 ssvb_: all info also sent to pixman list now Mar 19 12:29:15 persia: ok, thanks again. Mar 19 12:30:37 gaspa: I have a couple ARMv5 devices myself, but I have decided Debian is the right distribution for them. It's close enough, and it works. The alternative is sticking with Jaunty, but that expires soon enough. Mar 19 12:31:15 debian compiles for armv4, as i know. Mar 19 12:32:24 Yeah, but the performance difference isn't that huge. Mar 19 12:32:35 If you need performance, get a newer board :) Mar 19 12:32:53 and I got a big downspeed, in respect with the montavista default filesystem. Mar 19 12:33:24 lol. Mar 19 12:50:00 gaspa: readelf -a /binary Mar 19 12:50:49 gaspa: you can use gentoo :D Mar 19 12:57:22 armin76: Nifty! Thanks. Mar 19 13:08:06 persia: I heard you were looking into mending the chroot build scripts and pbuilder. Is that correct? Mar 19 13:08:25 Anything available for testing somewhere? Mar 19 13:09:10 Laibsch: Not sure how aligned it is with your research, but Mar 19 13:09:20 https://wiki.ubuntu.com/UbuntuDevelopment/Ports has some bits I wrote down and which might relate Mar 19 13:09:27 thanks Mar 19 13:09:29 * Laibsch is reading Mar 19 13:09:44 I've been out of the loop since about two weeks Mar 19 13:09:46 Let us know where it lacks Mar 19 13:09:53 Laibsch: I've pushed most of my stuff into Lucid. Mar 19 13:10:02 great Mar 19 13:10:09 I should already have it, then Mar 19 13:10:13 Laibsch: http://people.ubuntu.com/~persia/pull-soyuz-chroot may also interest you Mar 19 13:10:22 (that's still WIP) Mar 19 13:14:02 looks like you guys really did some amazing work on making this a *LOT* easier Mar 19 13:14:07 sudo pbuilder --create --basetgz /var/cache/base-armel.tgz --debootstrap qemu-debootstrap --mirror http://ports.ubuntu.com/ubuntu-ports/ --distribution lucid --architecture armel Mar 19 13:14:24 all there seems to be to it Mar 19 13:14:56 persia: Oh didn't know one can download premade chroots from LP Mar 19 13:14:59 that's great :-) Mar 19 13:15:19 persia: Do you actually require bash? Mar 19 13:16:43 I thought I did. Mar 19 13:17:01 I might not, at that. Mar 19 13:17:19 Give it a try. I think I started with sh and something broke. Mar 19 13:17:23 Maybe the getopts stuff. Mar 19 13:19:04 * Laibsch suggests /var/cache/pbuilder/base-armel.tgz instead of /var/cache/base-armel.tgz in the wiki instructions Mar 19 13:19:08 comments? Mar 19 13:19:32 fixed Mar 19 13:20:20 thanks Mar 19 13:20:28 persia: Is there any signing available for the soyuz chroot tarballs? Mar 19 13:20:56 This is great material because it puts people on par with lanuchpad buildds to start their buil Mar 19 13:20:59 builds Mar 19 13:22:25 lool: That's why wgrant exported them, and why I put together a script to grab them. Mar 19 13:22:39 I don't think there's signing now : that probably needs Soyuz extension. Mar 19 13:23:18 The part that's stumping me is how to use that chroot with pbuilder. I can't find the pbuilder configuration file that I need to tweak. Do you know how the last bit shoud work? Mar 19 13:23:21 persia: So you've just put up for a very nice alternative to the qemu-debootstrap stuff for the pbuilder use case Mar 19 13:23:38 persia: (Will get to your point in a sec) Mar 19 13:23:41 That's part of the idea. Mar 19 13:24:07 The other thing is that some stuff FTBFS on the buildds, and not locally, and it turns out to be some odd buildd config thingy. This helps track that down. Mar 19 13:25:45 persia: What I hate with the current approach is the "cp /usr/bin/qemu-arm-static /somechroot" approach; it's ugly because we mix files from various architectures with no tracking, e.g. no updates to them, pollute the namespace etc. Mar 19 13:26:14 Indeed. Mar 19 13:26:15 persia: Having a pbuilder hook which starts from an armel tarball but copies the qemu binary on every build would be an improvement already (I think) Mar 19 13:26:36 That's a much better idea, although I'd want it in sbuild :) Mar 19 13:26:52 Or better, in schroot, so it gets updated on every schroot instantiation. Mar 19 13:27:10 Back to your point, I think pbuilder is broken with respect to handling of .tar.bz2 tarballs, but "tar" will actually figure out compression if the file uses proper extension Mar 19 13:27:26 So it would be possible to remove the -z flag from tar calls and have pbuilder support .bz2 tarballs transparently Mar 19 13:28:05 persia: Note that until now the cp was needed to finish the debootstrap; it was kind of logical to keep that stuff around for actual chroot use Mar 19 13:28:12 * lool phone call & Mar 19 14:19:51 bug 517300 Mar 19 14:19:55 Launchpad bug 517300 in likewise-open (Ubuntu Lucid) (and 1 other project) "[armel] likewise-open needs porting to ARM (affects: 1)" [High,In progress] https://launchpad.net/bugs/517300 Mar 19 14:21:52 bug 537356 Mar 19 14:21:55 Launchpad bug 537356 in webservice-office-zoho (Ubuntu Lucid) (and 1 other project) "application menu entries dont do anything (affects: 1)" [High,Triaged] https://launchpad.net/bugs/537356 Mar 19 14:22:31 bug 457878 Mar 19 14:22:33 Launchpad bug 457878 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "imx51 on board ethernet plug/unplug events not detected (affects: 2)" [Medium,Confirmed] https://launchpad.net/bugs/457878 Mar 19 14:27:05 plars: were there any arm specific RC issues discovered in beta testing? Mar 19 14:28:47 bug 513732 Mar 19 14:28:49 Launchpad bug 513732 in gmp (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/513732 Mar 19 14:28:54 bug 528887 Mar 19 14:28:56 Launchpad bug 528887 in maximus (Ubuntu Lucid) (and 2 other projects) "maximus does not give default focus to newly started apps in combination with efl launcher (affects: 2)" [Medium,Triaged] https://launchpad.net/bugs/528887 Mar 19 14:29:07 bug 537083 Mar 19 14:29:08 Launchpad bug 537083 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "Suspend no longer works after updating to 2.6.31-605.9 kernel (affects: 2)" [High,In progress] https://launchpad.net/bugs/537083 Mar 19 14:29:37 qemu hang ? Mar 19 14:30:36 bug 499881 Mar 19 14:30:44 Launchpad bug 499881 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "usb storage with ext4 does not work in lucid on imx51 hardware (dup-of: 515023)" [High,Fix released] https://launchpad.net/bugs/499881 Mar 19 14:30:45 Launchpad bug 515023 in linux (Ubuntu) "ATA pass-through commands preventing external HDD to be mounted (affects: 10) (dups: 1)" [Undecided,Confirmed] https://launchpad.net/bugs/515023 Mar 19 14:30:46 ogra: qemu hang is RC still Mar 19 14:30:50 ok Mar 19 14:30:52 no news on that front afaik Mar 19 14:30:53 i wasnt sure Mar 19 14:34:09 bug 528524 Mar 19 14:34:11 Launchpad bug 528524 in totem (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps on dove (affects: 2)" [High,Invalid] https://launchpad.net/bugs/528524 Mar 19 14:39:36 bug 532733 Mar 19 14:39:38 Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 2)" [Medium,Incomplete] https://launchpad.net/bugs/532733 Mar 19 14:40:23 should probably be "in progress" Mar 19 14:40:38 incomplete was added by the server team ages ago Mar 19 14:43:53 hey ogra, testing 2.6.33-500-omap with an initramfs, it's been a long time, what should i normally add to the bootargs.. ;) Mar 19 14:44:32 root=UUID= should be in there Mar 19 14:44:52 beyond that "ro quiet splash" are ususally the defaults Mar 19 14:45:46 i dont know the exact runes for uboot (loadaddr etc) yet but i think you provided a rootstock patch for that (that i was planning to merge soon) Mar 19 14:47:19 ah found it.. initrd=address. ;) Mar 19 14:48:07 hmm, that shouldnt be needed Mar 19 14:48:38 bug 527720 Mar 19 14:48:40 Launchpad bug 527720 in klibc (Ubuntu Lucid) (and 1 other project) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [High,Triaged] https://launchpad.net/bugs/527720 Mar 19 14:48:45 as long as uboot loads it to the proper place in ram Mar 19 14:50:00 sorry, main reason i don't login to irc at work, people keep calling.. ;) Mar 19 14:57:07 okay, anything beyond 'sudo update-initramfs -c -k 2.6...' Mar 19 14:57:40 rcn-ee: The thing about IRC is that it can also be asynchronous. Lots of us idle here when we're out, when we're sleeping, when we're on the phone, etc., and just answer later. In many clients there are ways to show the last few lines where someone highlighted you. Mar 19 15:03:47 rcn-ee, i think you need to make an uInitramfs out of it Mar 19 15:03:54 or uInitrd Mar 19 15:04:20 yeap i did: mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d ./initrd.img-2.6.33-500-omap ./uInitrd Mar 19 15:04:37 i'm searching google for how other people have done it.. ;) Mar 19 15:04:45 that should be fine Mar 19 15:05:51 so i did this for the boot.scr : http://pastebin.com/byy5u0dR Mar 19 15:06:13 it loads the uIinitrd at boot... but the kernel doesn't like it.. Mar 19 15:06:55 [ 31.217498] Trying to unpack rootfs image as initramfs... Mar 19 15:07:01 [ 31.217803] rootfs image is not initramfs (junk in compressed archive); looks like an initrd Mar 19 15:08:42 i think you need to include the initrd address in your bootm command Mar 19 15:09:03 mmcinit; setenv bootargs 'console=ttymxc0,115200 console=tty0 root=UUID=bfdf1232-7400-4198-a89b-821e69e2fdd2 ro quiet splash'; fatload mmc 0:2 0x90800000 uImage; fatload mmc 0:2 0x91600000 /uinitrd; bootm 0x90800000 0x91600000 Mar 19 15:09:14 thats the line i use for an imx51 board with uboot Mar 19 15:09:38 it's weird cause i got away with it here: http://elinux.org/BeagleBoardDebian#Development_PC:_Setup_SD_U-boot_Partition Mar 19 15:09:47 i'll add the bootm change.. Mar 19 15:13:19 cool, the bootm change did change things.. Mar 19 15:13:40 works ? Mar 19 15:14:09 that would be too easy.. ;) now just: "[ 33.794677] Trying to unpack rootfs image as initramfs... " Mar 19 15:14:38 try to drop the initrd= option Mar 19 15:15:02 you shouldnt need it Mar 19 15:15:05 actually that was the other change i did.. Mar 19 15:15:14 was going to put it back.. ;) Mar 19 15:15:47 oh, wait Mar 19 15:15:55 -C gzip might be wrong Mar 19 15:16:38 should be none Mar 19 15:16:47 yeah wasn't sure about that one, pulled from a sheevaplug example... Mar 19 15:17:21 mkimage -A arm -O linux -T ramdisk -C none -a 0x0 -e 0x0 -n UbuntuInitrd -d "$INITRD" "$UINITRD" ... thats what we used for testing on imx51 Mar 19 15:18:07 thanks, i'll use that.. Mar 19 15:21:40 weird still no go, here's what i got.. http://pastebin.com/h8Hq2Ksh Mar 19 15:27:18 hmm Mar 19 15:28:02 i have week or two old .config from the imx tree, the initrd options seem to match up... Mar 19 15:28:48 well, try dropping rootwait rootfstype=ext3 Mar 19 15:29:01 sure Mar 19 15:32:19 no change... Mar 19 15:32:56 well, it definately loads it Mar 19 15:33:18 [ 33.773162] Trying to unpack rootfs image as initramfs... Mar 19 15:33:19 [ 34.684265] Freeing initrd memory: 7128K Mar 19 15:33:46 yeap, loads and then cleans it up.. Mar 19 15:33:58 wait, no change ? i.e. it still gets you a login prompt Mar 19 15:34:18 yeap, command prompt still comes up... Mar 19 15:34:29 but you dropped the rootwait ? Mar 19 15:34:43 yeap: [ 0.000000] Kernel command line: console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 ro vram=12M omapfb.mode=dvi:1280x720MR-16@60 Mar 19 15:34:57 rootwait is only really useful for usb rootfs... Mar 19 15:35:06 the sd card is happy without it.. Mar 19 15:35:12 i need it here to make the kernel not panic Mar 19 15:35:52 which board do you have again? Mar 19 15:36:07 revB Mar 19 15:36:25 this is on a B5, hopefully you don't have a really old B3/4 Mar 19 15:36:32 i do :) Mar 19 15:36:39 [ 45.171386] VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0) Mar 19 15:36:40 [ 45.178344] Please append a correct "root=" boot option; here are the available partitions: Mar 19 15:36:40 [ 45.186889] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Mar 19 15:37:32 OMAP3430-GP rev 2, CPU-OPP2 L3-133MHz Mar 19 15:37:45 its really old :) Mar 19 15:37:59 That's very weird.. are you: Ubuntu-2.6.33-500.2 or Ubuntu-2.6.33-500.1 Mar 19 15:38:08 same core here.. ;) Mar 19 15:38:10 500.2 Mar 19 15:38:37 ah, no its some kernel amitk uploaded for testing for me Mar 19 15:39:00 saldy my rootfs is ext4 (default) and there are ext4 issues atm so i cant try building an initramfs Mar 19 15:39:15 ogra: that kernel is equivalent to 500.2 Mar 19 15:39:26 yeah, i thought so Mar 19 15:39:39 yeah, 500.1 won't do anything.. other then uncompressing.. Mar 19 15:39:44 yep Mar 19 15:40:15 the lack of initramfs is the reason for most of those issues, including the rtc one. Mar 19 15:40:49 amitk, right, we just try to solve that :) Mar 19 15:40:52 I am in two minds whether to compile everything in now and then make them modules again when we have installable images with initramfs Mar 19 15:40:55 but see above Mar 19 15:41:01 [ 33.773162] Trying to unpack rootfs image as initramfs... Mar 19 15:41:06 [ 34.684265] Freeing initrd memory: 7128K Mar 19 15:41:14 so it loads but doesnt exec it Mar 19 15:41:27 initramfs size related? Mar 19 15:41:39 7M shouldnt be to bad Mar 19 15:41:49 amitk, full log: http://pastebin.com/h8Hq2Ksh Mar 19 15:42:10 well, 7M is a lot ... but still should work Mar 19 15:42:17 * amitk will be back in a few Mar 19 15:42:30 and it might be a kernel bug, we've never used an initrd in angstrom.. ;) Mar 19 15:42:36 ogra@babbage2:~$ ls -lh /boot/initrd.img-2.6.31-605-imx51 Mar 19 15:42:36 -rw-r--r-- 1 root root 3.8M 2010-03-12 09:57 /boot/initrd.img-2.6.31-605-imx51 Mar 19 15:42:59 rcn-ee, i think the ubuntu kernel uses the proper options for booting initramfs Mar 19 15:43:37 asac: sorry for the delay, on holiday today and away alot Mar 19 15:43:53 asac: probably the most critical issue I found was bug #540477 Mar 19 15:43:54 Launchpad bug 540477 in xorg-server (Ubuntu) "X restarted, but no .crash file (affects: 1)" [Undecided,New] https://launchpad.net/bugs/540477 Mar 19 15:44:08 asac: it's annoying, but can be worked past, and I think is a dup of an issue that was also seen on x86 Mar 19 15:44:27 asac: which is supposed to already be fixed, we just didn't catch the right version Mar 19 15:44:38 we are about 7M -rwxr-xr-x 1 root root 7.0M 2010-03-19 10:17 uInitrd Mar 19 15:44:47 ogra@beagle:~$ ls -lh /boot/initrd.img-2.6.33-500-omap Mar 19 15:44:47 -rw-r--r-- 1 root root 2.1M Jan 1 00:02 /boot/initrd.img-2.6.33-500-omap Mar 19 15:45:05 though it might not contain everything, i get a lot of ext4 errors while rolling it Mar 19 15:45:25 asac: also, I believe that GrueMaster hit some bad problems with the netboot images Mar 19 15:45:40 yeah, i haven't had good luck with ext4 on my beagles yet, whereas cwillu_at_work as been using brtfs just fine... Mar 19 15:45:51 bug #541399 on dove, and bug #541029 on imx51 Mar 19 15:45:53 well, ext4 is the default ubuntu uses Mar 19 15:45:54 Launchpad bug 541399 in linux-mvl-dove (Ubuntu) "netboot image fails to boot. (affects: 1)" [Undecided,New] https://launchpad.net/bugs/541399 Mar 19 15:45:55 Launchpad bug 541029 in linux-fsl-imx51 (Ubuntu) "netboot image fails to connect to the network (affects: 1)" [Undecided,New] https://launchpad.net/bugs/541029 Mar 19 15:45:55 asac: ^ Mar 19 15:46:01 so the beagle images will use that too Mar 19 15:46:05 plars: X crash ... reproducible? Mar 19 15:46:10 asac: yes Mar 19 15:46:14 asac: boot, press enter Mar 19 15:46:20 (unless you pick something differently on purpose) Mar 19 15:46:29 ok gdm bug Mar 19 15:46:40 can you make the title better for bug 540477 ? Mar 19 15:46:41 Launchpad bug 540477 in xorg-server (Ubuntu) "X restarted, but no .crash file (affects: 1)" [Undecided,New] https://launchpad.net/bugs/540477 Mar 19 15:46:44 thats a awful title ;) Mar 19 15:46:48 asac, plars, huh ? i thought that was fixed with the last plymouth upload Mar 19 15:47:07 (it was a plymouth bug afaik) Mar 19 15:47:35 ogra: I didn't check the version we had in that particular image, and can't really from where I'm at right now Mar 19 15:47:41 ogra: but yes, sounds like the same issue Mar 19 15:47:58 plars: Do you know which image it was? Mar 19 15:48:00 ogra, for refeence, what uboot version on your bx? Mar 19 15:48:35 rcn-ee, U-Boot 1.1.4 (Apr 2 2008 - 13:42:13) Mar 19 15:48:42 persia: candidate image on iso tracker - 20100317 Mar 19 15:48:43 the one that was in NAND Mar 19 15:49:16 ouch.. ;) i think we still have one of those laying around, going to track it down and try the latest u-boot for comparison.. Mar 19 15:49:35 * cwillu_at_work pokes his head in Mar 19 15:50:25 what's the problem with ext4? Mar 19 15:50:43 it makes my kernel panic Mar 19 15:50:57 but that might be a .33 bug, who knows Mar 19 15:50:57 that was the "cannot find rootfs"? Mar 19 15:51:01 no Mar 19 15:51:38 i can boot just fine but as soon as i start FS operations it spills lots of errors and at some point panics Mar 19 15:51:43 re: rootwait, I've always needed it Mar 19 15:51:55 you dont with initramfs :) Mar 19 15:52:08 but yes, without i also always needed it Mar 19 15:52:20 plars: libplymouth2 0.8.0~-16 Mar 19 15:52:21 thats what made me curious in rcn-ee's boot Mar 19 15:52:42 persia, outdated Mar 19 15:53:03 and this isn't something like a journal having worn out a section of an sd card because there was lots of writes performed while it was nearly full, right? :p Mar 19 15:53:10 been bit by that more times than I care to admit Mar 19 15:53:15 (hence the btrfs :p) Mar 19 15:53:15 no, the SD is new Mar 19 15:53:37 4GB and only carries ubuntu-minimal yet Mar 19 15:53:38 ogra: Right. Just confirming because plars couldn't look it up. Mar 19 15:53:48 ~17 has the fix Mar 19 15:54:05 https://launchpad.net/ubuntu/+source/plymouth/0.8.0~-17/+build/1566604 Mar 19 15:54:14 and obviously built fine Mar 19 15:54:18 right, so it *should* be fixed in the latest... just need to confirm that Mar 19 15:54:23 i wonder why its not on the image Mar 19 15:54:24 Right, just needed a respin. Mar 19 15:54:30 No respin, probably. Mar 19 15:54:38 aah Mar 19 15:54:41 But too late now. Mar 19 15:54:45 it was only uploaded last night Mar 19 15:54:54 Yes, which is why beta was delayed. Mar 19 15:55:04 * ogra didnt notice since KEybuk is raving about the fix since a week Mar 19 15:55:08 But nobody did the release coordination to get respins for all three images. Mar 19 15:55:15 i thought he had uploaded it since ages Mar 19 15:55:19 (-server is actually from the 15th still) Mar 19 15:55:27 Could have been stuck in unapproved Mar 19 15:58:29 ogra, just tested on the oldest bx board i have (b4) it boots, follow this for the latest uboot http://elinux.org/BeagleBoardUbuntu#Upgrade_U-Boot there is a lot of issues with 1.1.4... Mar 19 15:58:31 asac: there are also some other issues like 528887, that are medium, and thus not typically marked RC by default. However, I think they are likely important/annoying enough that we should make sure they are addressed before release Mar 19 15:58:41 bug #528887 Mar 19 15:58:42 Launchpad bug 528887 in maximus (Ubuntu Lucid) (and 2 other projects) "maximus does not give default focus to newly started apps in combination with efl launcher (affects: 2)" [Medium,Triaged] https://launchpad.net/bugs/528887 Mar 19 15:58:55 and make sure to follow the 'old' notes in that section.. Mar 19 16:00:06 rcn-ee, heh, my initrd boots fine here Mar 19 16:00:16 what? cool.. Mar 19 16:00:30 plars: maximus is on our RC list atm Mar 19 16:00:36 http://paste.ubuntu.com/397873/ Mar 19 16:00:41 https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid Mar 19 16:00:43 plars: ^^ Mar 19 16:00:44 asac: ok, good Mar 19 16:01:01 i will try to get some support fo rthat Mar 19 16:01:53 rcn-ee, try fatload mmc 0:1 0x80000000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80000000 0x81600000 Mar 19 16:02:16 though i'm worried about the size of your initrd Mar 19 16:02:27 mine definately only has 2.1M Mar 19 16:05:43 ogra: rcn-ee: so initramfs issue fixed? Mar 19 16:05:55 amitk, well see the above paste ... Mar 19 16:06:00 http://paste.ubuntu.com/397873/ Mar 19 16:06:03 * amitk likes it when problems get fixed behind his back Mar 19 16:06:05 though ext4 bugs me hard Mar 19 16:06:14 i cant modprobe rtc atm Mar 19 16:06:29 ogra: please file a bug on ext4, csurbhi is tracking those Mar 19 16:06:34 will do Mar 19 16:06:54 i haven't looked at the rtc yet to see if it's enabled right either.. ;) Mar 19 16:07:23 it is a module Mar 19 16:07:42 yeah Mar 19 16:07:43 as I said before, I am in two minds whether to compile everything in now and then make them modules again when we have installable images with initramfs Mar 19 16:07:44 ogra@beagle:~$ ls /lib/modules/2.6.33-500-omap/kernel/drivers/rtc Mar 19 16:07:45 [ 425.706848] EXT4-fs error (device mmcblk0p2): ext4_lookup: deleted inode referenced: 128377 Mar 19 16:07:45 ls: cannot access /lib/modules/2.6.33-500-omap/kernel/drivers/rtc: Input/output error Mar 19 16:07:50 i would love to load it :) Mar 19 16:08:07 amitk, i'll have images next week Mar 19 16:08:15 heh, your ext4 rootfs might be fried Mar 19 16:08:16 dont put time into it Mar 19 16:08:24 the address didn't change it for me, same as the last, although i forgot to log the boot... Mar 19 16:08:33 initramfs and bootloaders were my main concern Mar 19 16:08:41 both should be done on the weekend Mar 19 16:08:51 the rest is image build scripts fiddling Mar 19 16:09:11 exactly.. ;) you guys have a shippment of xm boards coming in right? Mar 19 16:09:48 already have 'em Mar 19 16:10:17 cool, i haven't got mine to boot yet either, so that's going to be fun this weekend.. Mar 19 16:13:16 0x8000000, doesn't help the initd.. http://pastebin.com/E22QL3iW as far as the size, i just ran 'sudo update-initramfs -c -k 2.6....' on the beagle... Mar 19 16:13:50 rcn-ee: 500.2 ought to boot on XM Mar 19 16:14:27 cool, i'll try that in an hour over lunch, i was trying to get my 2.6-dev (2.6.32) to work.. Mar 19 16:14:55 rcn-ee: I'm going to concentrate on core functionality next week (DSS2/PM) instead of flipping modules to built-ins since ogra will have images for us next week Mar 19 16:17:01 okay sounds good, get it working first, then move stuff around.. ;) I'll cleanup my dss2 patch in my 2.6.33 tree to easily merge into yours... Mar 19 16:17:21 rcn-ee, weird initramfs works even with a newer uboot here with the same commands Mar 19 16:17:40 U-Boot 2009.11 (Feb 24 2010 - 10:58:59) Mar 19 16:18:18 i guess i'm confused... where's the best indicator the initrd worked. ;) Mar 19 16:18:31 Loading, please wait... Mar 19 16:18:40 thats printed from /init in initramfs Mar 19 16:19:04 and all the: "Running /scripts/...." lines Mar 19 16:19:05 bug 541399 Mar 19 16:19:07 Launchpad bug 541399 in linux-mvl-dove (Ubuntu) "netboot image fails to boot. (affects: 1)" [Undecided,New] https://launchpad.net/bugs/541399 Mar 19 16:19:18 ahh.. okay, i'll look for that... Mar 19 16:19:31 rcn-ee, probably drop console=tty0 ;) Mar 19 16:19:38 or attach a monitor Mar 19 16:20:02 i can do that... monitor is attached, but dss2 isn't patched to work yet... ;) Mar 19 16:20:04 initramfs will definately spit out messages on the second console arg you set (if you set one) Mar 19 16:20:15 well, then just drop it from cmdline Mar 19 16:20:25 that should show the messages on serial Mar 19 16:23:30 hmm, I set it this way: console=tty0 console=ttyS2,115200n8 Mar 19 16:23:39 the second one is the one that gets kernel stdin, stdout, stderr. Mar 19 16:24:29 bingo, that did it.. http://pastebin.com/Y42WTD3S .... ;) so it's loading the initd... Mar 19 16:24:48 Starting kernel ... Mar 19 16:24:48 Uncompressing Linux... Mar 19 16:24:48 uncompression error Mar 19 16:24:48 -- System halted Mar 19 16:26:37 hmm, it might be good to revise install-me.sh to allow it to work on host system (without dpkg -i step, of course). Mar 19 16:26:58 no usb devices.. back to the config from this morning.. it doesn't look like it can be an external module .. http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.33.y.git&a=search&h=HEAD&st=grep&s=CONFIG_USB_MUSB_HDRC Mar 19 16:27:29 Yeah, DanaG i was thinking, if arch != arm stop. .. ;) Mar 19 16:27:58 On my host, mmcblk0p1 is still mmcblk0p1. Mar 19 16:28:08 rcn-ee, yeah, i was suspecting that, you dropping rootwait and cwillu_at_work confirming it's needs somehow indicated that :) Mar 19 16:28:09 so, install-me.sh works if I do "dpkg -i ... || true" Mar 19 16:28:21 weird... uncompression error on 2.6.33.1-dl2 Mar 19 16:28:23 but it could be as simple as... ". install-me.sh" -> arm... ". install-me.sh /dev/sdb1" -> on x86... Mar 19 16:28:50 ah yeah. Mar 19 16:29:05 Oh, and perhaps check if partition is already mounted somewhere. Mar 19 16:30:59 Or even better: pass it the dir, not the device. Mar 19 16:31:19 okay, so 33.1-dl2 doesn't uncompress. Mar 19 16:32:23 It just dies before uncompression? Mar 19 16:36:33 Yeah. Mar 19 16:37:08 Starting kernel ... Uncompressing Linux... uncompression error -- System halted (replaced line-breaks with 8 spaces.) Mar 19 16:37:59 DanaG: could be your addresses? Kernel overwriting itself? Mar 19 16:38:32 DanaG, it's close to lunch, so i'm going to put on my c4 lucid and test... Mar 19 16:39:24 You can do that after your lunch, if you want. =รพ Mar 19 16:39:43 nah, then i can 'unbrick' it during lunch.. ;) i run home... Mar 19 16:40:49 yeap, bricked it... 2.6.33.1-dl2 is bad.. Mar 19 16:41:50 what's weird, it's based off the head of https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-dev when i cross built in the lab for lucid/squeeze but with angstrom's 4.3.3... i'll investigate it tonight... Mar 19 16:42:21 2.6.33-dl1 had been fine on that machine... Mar 19 16:42:32 handily for me, I just stick the card back in my host laptop and replace uimage. Mar 19 16:43:48 i just saw sd cards between running beagles and run install-me.sh again.. ;) Mar 19 16:43:53 saw/swap Mar 19 16:45:50 tsk Mar 19 16:45:58 just dont break your installs all the time :) Mar 19 16:47:12 hehe.. it's okay, that's the 2.6-dev branch.. things are allowed to break... ;) 2.6-stable now that can't ever break.. ;) i removed it from rcn-ee.net, so it shouldn't propgate to the mirrors... Mar 19 16:47:52 what's scarry, it was just the kernel stable bump to 2.6.33.1... **** ENDING LOGGING AT Sat Mar 20 02:59:58 2010