**** BEGIN LOGGING AT Fri Feb 26 02:59:57 2010 Feb 26 03:11:23 Is it possible to buy an ARM laptop today and easily install the latest Ubuntu Linux on it? Feb 26 10:31:20 woah, mounting /proc in a qemu-arm-static chroot and then installing mono explodes in a funny way Feb 26 10:56:38 ogra: So how does it fail? Feb 26 10:56:43 ogra: Could you file a bug about that? Feb 26 10:57:02 lool, well, it tries to enable binfmt :) Feb 26 10:57:19 i doubt there is any easy way around Feb 26 10:57:57 apart from having a fake proc, afaik persia and lifeless had some fuse based ideas for that during the sprint Feb 26 10:57:57 It didn't fail for me Feb 26 10:58:05 update-binfmts: warning: /usr/share/binfmts/cli: no executable /usr/bin/cli Feb 26 10:58:06 found, but continuing anyway as you request Feb 26 10:58:06 update-binfmts: warning: found manually created entry for python2.6 in Feb 26 10:58:06 /proc/sys/fs/binfmt_misc; leaving it alone Feb 26 10:58:31 (apt-get install mono-runtime) Feb 26 10:58:34 right and then it tries to use the existing cli handler during package install Feb 26 10:58:38 ah Feb 26 10:58:44 i did apt-get install tomboy Feb 26 11:00:17 lool, did you ever have contact with hppfs ? Feb 26 11:00:30 seems that could work as a fake proc in a chroot Feb 26 11:00:30 No Feb 26 11:01:03 I'm not sure I'm in line with the fake proc idea Feb 26 11:01:24 I think qemu-arm would have to emulate some of it due to the emulation it does Feb 26 11:01:27 well, how else would you handle stuff that needs proc in a foreign chroot Feb 26 11:01:45 right, so you still need to fake something Feb 26 11:02:04 I'd personally prefer to use containers if we want to support this Feb 26 11:02:26 thats a lot of overhead Feb 26 11:02:30 No Feb 26 11:02:41 It's almost zero overhead Feb 26 11:02:42 well, we only need proc containers do so much more Feb 26 11:03:04 and are quite complicated to set up for a user Feb 26 11:08:30 lool, http://paste.ubuntu.com/384298/ Feb 26 11:09:10 so ita a SIGABRT and i guess because it sees the binfmt handler and tries to exec it Feb 26 11:09:29 ogra: Could you file a bug? Feb 26 11:10:08 gar, apport doesnt know about qemu-arm-static Feb 26 11:13:52 The unsupported syscall 242 ones are probably harmless (affinity stuff) Feb 26 11:14:23 The unuspported syscall 26 is just a consequence of trying to run gdb under qemu-arm, wont work because ptrace() isn't emulated (and far from trivial I'm afraid) Feb 26 11:15:16 yep Feb 26 11:15:26 bug 528377 Feb 26 11:15:27 Launchpad bug 528377 in qemu-kvm (Ubuntu) "qemu-arm-static fails installing mono assemblies if /proc is mounted in the chroot (affects: 1)" [Undecided,New] https://launchpad.net/bugs/528377 Feb 26 11:17:17 i actually only started experimenting with mono in chroot again out of desparation, i have no idea what to do with the iso-codes hang Feb 26 11:18:00 seems no matter what kernel or config i use, installing the ubuntu-netbook task hangs reliably at iso-codes unpacking Feb 26 11:19:44 i thought its caused by swapping but that was a red herring Feb 26 11:42:01 ogra: So the way you word the bug report, it sounds like of /proc is NOT mounted in the chroot, one can actually install mono; is this correct? Feb 26 11:42:11 no Feb 26 11:42:19 but i dont get the segfaults Feb 26 11:42:31 What do you get? Feb 26 11:42:36 it simply doesnt execute the installation of the assmeblies Feb 26 11:42:43 and dpkg fails Feb 26 11:43:08 i'll add a log for comparison once my machine has spare cpu cycles (rootstock running atm) Feb 26 11:58:50 hi doko ;9 Feb 26 11:59:49 oh, a rare guest :) Feb 26 11:59:57 hehe Feb 26 12:03:09 I was forced :-/ Feb 26 12:05:16 NCommander: you might want to look at Mikael's comments in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860 (tracked down to the very same binutils change) Feb 26 12:05:21 gcc.gnu.org bug 40860 in libgcj "[4.4/4.5 regression] regressions in libjava testsuite on arm-linux" [Normal,Unconfirmed] Feb 26 12:46:07 hey ogra, oem-config question... Should it run in an endless loop in lucid? ;) Feb 26 12:47:22 no, it shouldnt, boot with debug-oem-config on the cmdline and file a bug with /var/log/oem-config.log attached please Feb 26 12:47:28 against ubioquity Feb 26 12:49:11 Thank so, debug-oem-config's the trick... First thing i'll do when i get to work.. Feb 26 12:50:01 thanks :) Feb 26 12:51:00 anyluck with the weird iso-codecs lockup today? ;) i'm seeing it to on my machines... Whats weird In debian it's actually locking up at I: Extracting zlib1g... Feb 26 12:52:13 with debians qemu ? Feb 26 12:52:27 squeeze.. so (ssh's in) Feb 26 12:52:54 i'm trying to debug that since yesterday but given the time it takes to get to the hang its might still take more :) Feb 26 12:53:20 i'm just trying it in a normal VM so that i can exclude rootstock here Feb 26 12:54:13 rcn-ee, btw, if you file a bug for oem-config under rootstock, please subscribe ubuntu-armel Feb 26 12:54:23 so we get the mails in the arm team Feb 26 12:54:29 i know what you mean.. (QEMU PC emulator version 0.11.1)... what's weird, when i was building 'google os' images in a chroot, it locked up on that same package file.. Feb 26 12:55:02 i think its something in qemu not handling a certain amount of CPU load or disk I/O Feb 26 12:55:11 but its so damned hard to track down Feb 26 12:56:38 isn't that "I: Extracting zlib1g..." Feb 26 12:56:46 oh damn keyboard Feb 26 12:56:58 funnily i can just install iso-codes just fine if i install it standalone Feb 26 12:57:08 ynezz, thats not in the VM Feb 26 12:57:10 seems very reasonable.. do you guys have a dedicated qemu hacker at ubuntu? Feb 26 12:57:41 rcn-ee, well, lool is very passionate to get all qemu bugs solved and has the knowledge ... Feb 26 12:58:04 he's not a "dedicated qemu hacker" per se i think though :) Feb 26 12:59:30 yeah he's good.... anything show up weird in the vm machine log's file? (i could dump it too..) Feb 26 13:00:21 i'm only just running it in a VM Feb 26 13:00:45 before i suspected rootstock to be at fault ... thats to closed Feb 26 13:00:57 hmm, fun Feb 26 13:01:02 my VM doesnt even boot Feb 26 13:01:30 whoops typoing the command doesnt really help :P Feb 26 13:03:54 /tmp/ccQPoJy6.s:1847: Error: selected processor does not support `rsc r7,r7,#0' Feb 26 13:03:57 hmm Feb 26 13:04:36 whats that ? Feb 26 13:04:37 reverse substract with carry Feb 26 13:04:44 right Feb 26 13:04:50 is that thumb only instruction? Feb 26 13:04:53 or too old Feb 26 13:04:59 only available on ARM, not Thumb Feb 26 13:05:05 in the arm reference i have open its named in the thumb section Feb 26 13:05:09 yeah thats what i expected Feb 26 13:06:39 asac: there's a regular substract though Feb 26 13:07:01 asac: sbc r7,#0,r7? Feb 26 13:07:21 Hmm don't think you can pass an immediate as first arg though Feb 26 13:08:41 what i find odd is that its not even marked as arm only in the reference quick card ... strange Feb 26 13:09:37 asac: I certainly see it marked as such Feb 26 13:10:26 asac: RSC is 5th in the substract instructions, and the fifth entry in Notes is "A" Feb 26 13:10:43 So not in Thumb Feb 26 13:12:57 oh right. i misinterpretetd the table Feb 26 13:13:13 there's a blank which is hard to read Feb 26 13:21:57 ogra: lool: Did you want the breakdown of the fuse proc idea? I think StevenK fiddled with some initial implenetation stuff. Feb 26 13:23:00 persia, i would, seems lool doesnt ... he wants containers Feb 26 13:23:47 containers are a more correct solution. Feb 26 13:23:59 but way more complex Feb 26 13:24:16 no Feb 26 13:24:21 and do they guarantee i dont see the system kernel in /proc ? Feb 26 13:24:36 no Feb 26 13:24:44 right Feb 26 13:25:06 The fuse hack was just to use fuse.pm to check the filename and if it matched one of a set of predefined files, perform some operation (either cat a fake file, or run the real file through a filter). If it doesn't match, feel the original file (or feed through an identity filter, depending on operation) Feb 26 13:25:15 what we need is a /proc that emulates a generic arm machine Feb 26 13:26:55 hrm, now i cant even purge iso-codes from my VM Feb 26 13:27:08 just sits there in the ldconfig triggers Feb 26 13:28:49 ogra: The fuse hack can give us that (at least enough to fake most stuff). Feb 26 13:29:04 Just needs someone to write up the perl. Feb 26 13:29:21 yeah Feb 26 13:29:44 persia: I find it hard to imagine that we will get cpuinfo emulation in containers in the short term Feb 26 13:29:48 Your python is better than your perl, right? How are you at python regexes? Feb 26 13:29:57 persia: However I do believe we should use containers for things like binfmt Feb 26 13:30:16 persia, i come from perl ... just needs a little refresh i guess Feb 26 13:30:16 lool: So you think it makes sense to combine a container and the fuse-proc hack? Feb 26 13:30:23 persia: The cpuinfo hack could either be done with fuse or in qemu; I think I find it more useful in qemu though Feb 26 13:30:47 ogra: StevenK suggested perl was the better language for it because it's mostly just matching regexes and then running text filters. Feb 26 13:30:55 I find things are complex and fragile enough that I'd prefer not to have to fiddle with fuse, personally Feb 26 13:30:57 yeah Feb 26 13:31:32 lool, to run containers you need to do massive changes to yxour chroot (which is the part i find complex) Feb 26 13:31:35 lool: The advantage of fuse over qemu is that it's trivial to write such a hack in perl, but fixing qemu requires real thought. If you're up for doing it, it would be loads better. Feb 26 13:32:16 ogra: No Feb 26 13:32:20 huh ? Feb 26 13:33:09 you need at least to create lots of stuff in /dev, need to hack mountall defaults etc Feb 26 13:34:52 ogra: Shouldn't it be as simple as http://blog.bodhizazen.net/linux/lxc-configure-debian-lenny-containers/ ? Feb 26 13:34:59 no Feb 26 13:35:06 lenny is way easier :) Feb 26 13:35:12 no upstart ... etc Feb 26 13:35:32 he wrote one for lucid too Feb 26 13:35:35 http://blog.bodhizazen.net/linux/lxc-configure-ubuntu-lucid-containers/ Feb 26 13:35:58 but effectively /proc will stil show you the host CPU and features Feb 26 13:36:03 Why doesn't udev work? Feb 26 13:36:10 so its pointless to use containers imho Feb 26 13:36:16 Again, containers are not going to solve the cpuinfo problem Feb 26 13:36:20 Containers solve other issues. Feb 26 13:36:24 They don't solve /proc Feb 26 13:36:39 They actually help a lot with /proc, but not for cpuinfo Feb 26 13:36:40 (well, they solve other /proc issues, but mostly of type /proc/nnnn) Feb 26 13:36:47 Right. Feb 26 13:37:06 Well, also not proc/[a-z]* mostly. Feb 26 13:37:18 would they be able to solve binfmt ? Feb 26 13:37:23 (i doubt that) Feb 26 13:38:08 given that binfmt would still need a qemu-arm-static wrapper around the interpreter calls Feb 26 13:39:48 * ogra goes for some lunch Feb 26 14:15:58 urgh Feb 26 14:16:32 maximizin the qemu window while it does something and then restoring it to its original size reults in massively blurry fonts Feb 26 14:18:14 the funny think is that its only blurry in the center of the window ... top and bottom are crisp Feb 26 14:24:14 I have a couple of patch suggestions for rootstock, where should I submit them? On launchpad? Feb 26 14:24:31 mikeul: Ideally, submit them as merge proposals Feb 26 14:24:44 via launchpad Feb 26 14:24:50 yes Feb 26 14:24:59 mikeul: bzr branch lp:project-rootstock my-feature; cd my-feature && hack && bzr commit; bzr send Feb 26 14:25:26 they're trivial, but it'll be a good getting-to-know-launchpad exercise. Feb 26 14:25:55 bzr send? I did bzr push" Feb 26 14:27:36 mikeul: Checkout "bzr help send" then ;-) bzr push is when you want to do things manually Feb 26 14:29:01 lool, send requires an email setup, no ? Feb 26 14:29:53 * ogra checks the help Feb 26 14:30:46 ah, not a local mailserver, just a client Feb 26 14:31:20 why? who gets an e-mail? Feb 26 14:31:32 mikeul: the email contact of the lp project Feb 26 14:31:43 mikeul: if you prefer, you can just submit your branch for merging via the web ui Feb 26 14:31:45 right Feb 26 14:32:30 OK, so having pushed it to a personal branch, can I do that with "Propose for merging"? Feb 26 14:32:45 yep Feb 26 14:33:07 Or should I push it to the project-rootstock page instead and propose-for-merge there? Feb 26 14:34:43 mikeul: I usually push to some personal lp page (e.g. lp:~mikeul/project-rootstock/make-everything-better ) and then do the merge proposal on LP. Feb 26 14:40:52 mikeul, hmm, why do you add rmdir $BUILDDIR to the usage() function ? Feb 26 14:41:09 $BUILDDIR wont exist if usage() is executed Feb 26 14:45:14 mikeul, i think that requires more restructuring, i'm not really comfortable with creating $BUILDDIR just because non root users call --help, could you move the variables around a bit instead of adding the rmdir ? Feb 26 14:46:53 its a good approach though Feb 26 14:54:00 $BUILDDIR _did_ exist when usage() is executed. I called "sudo rootstock --help" a few times and ended up with several empty /tmp/tmp.xxxxxx dirs. Feb 26 14:54:25 right, thats the actual bug :) Feb 26 14:54:30 I'd be happy to move some things around to fix it differently. Feb 26 14:55:07 e.g. to avoid creating /tmp/tmp.xxxxxx in the first place. Feb 26 14:55:12 yes, BUILDDIR= and all variables that use ${BUILDDIR} need to move down a bit ... best is below the uid 0 check Feb 26 14:56:08 (the script started as 50 lines ... and grew functions in several directions) Feb 26 14:56:58 ogra, I'm familiar with that. Feb 26 14:57:04 :) Feb 26 15:00:48 OK, then move all the variable defs to after the cmdline parsing. I'll move the qemu-system-arm and debootstrap checks, too, since they're also not needed e.g. for --help Feb 26 15:02:12 be careful though, some need to be initialized before the cmdline parsing Feb 26 15:02:38 best to only move everything with $BUILDDIR in it Feb 26 15:02:47 Oh yeah, that's why I went the quick-and-dirty rmdir route. Feb 26 15:04:22 OK, can you give me an overview of how to handle that with bazaar? I can start from scratch and just post a new branch, but I'm guessing there's a different way. Feb 26 15:05:15 just delete the rmedir with your next change ... the moving of the uid 0 check is fine Feb 26 15:05:19 *rmdir Feb 26 15:06:11 ah, OK, so just dump more commits on top of my existing ones? Feb 26 15:06:28 right "revert last change and .... " Feb 26 15:08:40 fyi, I'm a git'ter. Do you mean a) I can change the history in bzr to remove mention of 'rmdir' or b) I should make the changes "on top of" the existing ones. Feb 26 15:09:00 i would just do it on top Feb 26 15:09:07 OK Feb 26 15:09:13 easy peezy Feb 26 15:10:55 whois mikeul Feb 26 15:10:59 oops Feb 26 15:11:00 :) Feb 26 15:27:57 FYI, I'm not going to get around to doing even those small changes today, will get to it soon. Signing out. Feb 26 15:29:12 lool, so i am testing the same iso-codes issue in a real VM now instead of using rootstock, i'm at the point where apt stops moving in "unpacking iso-codes" ... i see nothing in the logs, apt-get and dpkg dont seem to consume to much CPU, one intresting thing i see is that dpkg.log seems to be behind and getting slowly filled ... dou you have any idea where else to look at ? Feb 26 15:29:20 mikeul, dont worry :) Feb 26 15:29:28 mikeul, thanks for doing the work :) Feb 26 15:30:05 Kein Problem, ogra, have a nice weekend. Feb 26 15:30:13 du auch :) Feb 26 15:31:15 grmbl ... i should have installed iotop first Feb 26 15:37:51 ogra: build karmic image today, using rootstock r82 and it boots :) Feb 26 15:38:02 cool ! Feb 26 15:41:51 sigh ... no strace either in ubuntu-minimal Feb 26 15:42:22 ogra: Are you swapping? Feb 26 15:42:45 ynezz: We figured out the mountall issues with mikeul BTW Feb 26 15:42:46 i created a swapfile on the virtual disk after it hung already for 20min Feb 26 15:42:50 ynezz: Missing rw on the kernel cmdline Feb 26 15:43:15 ogra: can't login tho, maybe it's related to useradd http://paste.ubuntu.com/384439/ Feb 26 15:43:34 yeah, looks like a bug Feb 26 15:43:55 lool: yep, saw it in bzr log, thanks Feb 26 15:44:06 i switched the default to install oem-config instead ... i havent tested with username/pw for a while ... its on my list Feb 26 15:44:37 ynezz, i fear you need to mount your image and chroot into it to create the user Feb 26 15:44:58 did it already, no problem Feb 26 15:45:02 ah, k Feb 26 15:45:04 just letting you know Feb 26 15:45:11 yeah, thanks Feb 26 15:45:29 seems the options are wrong, i'll look into it on the weekend Feb 26 15:45:58 lool, so swapon after it was already stuck didnt help ... Feb 26 15:46:19 even though i see 204 bytes of the swap being used now after 1h Feb 26 15:46:33 err, 240 Feb 26 15:46:56 apt-get now jumps between 80 and 95% CPU Feb 26 15:47:07 but nothing happens beyond that Feb 26 15:53:04 ogra: it's missing " around one param http://paste.ubuntu.com/384443/ Feb 26 15:53:48 oh, right, it used to live directly in the installer script ... when i moved it i didnt add proper quoting Feb 26 15:53:53 ynezz, thanks ! Feb 26 15:54:14 np, that was easy :p Feb 26 15:54:19 (in fact i didnt really care about it because oem-config should become the default) Feb 26 15:54:31 but i'll add your fix with the next commit Feb 26 16:14:59 bug 507503 Feb 26 16:15:01 Launchpad bug 507503 in linux-mvl-dove (Ubuntu Lucid) (and 3 other projects) "VFP/NEON state is not preserved around signal handlers, causing state corruption between user processes (affects: 1)" [High,Fix committed] https://launchpad.net/bugs/507503 Feb 26 16:16:19 ramana: morning (or afternoon) Feb 26 16:18:50 bug 528524 Feb 26 16:18:52 Launchpad bug 528524 in pulseaudio (Ubuntu Lucid) (and 1 other project) "Sound not working in all apps on dove (affects: 1)" [High,New] https://launchpad.net/bugs/528524 Feb 26 19:24:56 I got this problem with ubuntu karmic http://paste.ubuntu.com/384586/ . I fixed it at Mamona with this patch (http://gitorious.org/mamona/openembedded/commit/4d4933fd97b85a52e48a5fa1a97bd34532864e32). Anyone with this problem? Feb 26 20:39:56 ARGH($*)(@*#$)(*@!$#@$ Feb 26 20:39:59 * NCommander hates OOo Feb 26 21:18:26 alecrim_: Could you file a bug with your patch? Feb 26 21:18:48 alecrim_: I'm pretty sure I saw this in the past, I think it was on the sheevaplugs Feb 26 21:21:37 alecrim_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314334 Feb 26 21:21:38 Debian bug 314334 in apt "apt: APT doesn't work on filesystems without shared writable mmap(), like JFFS2." [Wishlist,Open] Feb 26 21:43:47 lool, ok! Feb 26 22:05:29 <|nfecteD> rcn-ee: you around? Feb 26 22:20:27 ramana: ping? Feb 26 22:21:10 <|nfecteD> anyone want to give me whatever boot.scr they are using for lucid alpha 3? Feb 26 22:25:08 |nfecteD: what are you trying to do? Feb 26 22:25:14 * NCommander is the boot.scr writer guy Feb 26 22:25:18 <|nfecteD> getting it to boot :/ Feb 26 22:25:26 |nfecteD: which SoC? Feb 26 22:26:11 <|nfecteD> beagleboard Feb 26 22:26:49 <|nfecteD> init: plymouth-log main process (227) terminated with status 111 Feb 26 22:26:56 |nfecteD: Beagleboard isn't officially supported by Ubuntu Feb 26 22:27:00 <|nfecteD> thats the last thing i get during boot before it seems to hang Feb 26 22:27:05 |nfecteD: http://elinux.org/BeagleBoardUbuntu - but here's the best set of directions I can give Feb 26 22:27:17 oh wow Feb 26 22:27:21 * NCommander feels honored Feb 26 22:27:27 Beagle adopted my boot.scr mechanism Feb 26 22:27:54 or something similar Feb 26 22:28:16 |nfecteD: sounds like your making it to the initramfs and then its crashing. Feb 26 22:28:21 <|nfecteD> yup Feb 26 22:28:25 <|nfecteD> seems so... Feb 26 22:28:35 I'd recommend trying #beagle and if no response, come back here Feb 26 22:29:45 <|nfecteD> plymouth needs kms/framebuffer and initramfs i believe... Feb 26 22:29:45 <|nfecteD> early patch, i'm messing with: Feb 26 22:29:45 <|nfecteD> http://bazaar.launchpad.net/~robertcnelson/project-rootstock/initramf... Feb 26 22:29:45 <|nfecteD> and boot.scr needs to be updated (simple) to also load the initramfs Feb 26 22:29:45 <|nfecteD> into ram.. Feb 26 22:29:59 <|nfecteD> found that on the beagleboard group now Feb 26 22:31:09 <|nfecteD> i would think rcn built the newest rootfs with that patch so what im missing is what goes in the boot.scr Feb 26 22:31:31 * |nfecteD pokes rcn-ee **** ENDING LOGGING AT Sat Feb 27 02:59:56 2010