**** BEGIN LOGGING AT Wed Feb 24 03:00:02 2010 Feb 24 05:41:55 persia: http://www.engadget.com/2010/01/04/freescale-reveals-7-inch-smartbook-reference-design-hopes-to-se/ Feb 24 05:49:21 DanaG: OpenGL ES instead of OpenGL, so not capable of compiz. Feb 24 05:49:28 Bleh. Feb 24 05:49:49 Compiz is like 90% of the opengl I use in Linux. Feb 24 05:49:50 =รพ Feb 24 05:49:59 hi all, I did not see any ARM port of daily livecd. what's wrong with that? Feb 24 05:50:26 ARM + CD drive... does not compute, Feb 24 05:50:27 . Feb 24 05:50:40 Try "root filesystem image" or something. Feb 24 05:51:02 I mean the livecd.img instead of .iso. Feb 24 05:51:11 we usually had it everyday. Feb 24 05:51:18 ah. Feb 24 05:51:53 Hope one day both of compiz and launcher chould have both of GL and GL ES backend. :P Feb 24 05:52:06 Like ChromeOS Feb 24 06:49:57 armin76: Ah, that makes sense. I was thinking it would be interesting if someone tried to brand "Prototype" :) Feb 24 08:46:50 ogra: poke Feb 24 08:47:03 ouch ! Feb 24 08:47:04 :) Feb 24 08:47:19 ogra: I need to give my input on the priority of bug #431790; would need to know whether you plan to use d-i kernels or archive kernels Feb 24 08:47:22 Launchpad bug 431790 in debian-installer (Ubuntu) (and 1 other project) "debian-installer images aren't signed in the archive (affects: 1)" [Undecided,New] https://launchpad.net/bugs/431790 Feb 24 08:47:35 (To implement signing of these files in soyuz) Feb 24 08:48:32 for rootstock that is Feb 24 08:51:41 lool, see if my comment suffices Feb 24 08:52:12 ogra: that helps, thanks Feb 24 08:53:37 lool, btw, probably link bug 437636 to it (or make it a duplicate of 431790) Feb 24 08:53:40 ogra: Bug 437636 on http://launchpad.net/bugs/437636 is private Feb 24 08:58:01 ogra: I mentionned that it would be nice if the feature was available in the next weeks or month; feel free to give a more sensible deadline if you have one Feb 24 08:59:02 ogra: I dup-ed; I don't really care if it's separate or not, up to you Feb 24 08:59:12 no, thats fine Feb 24 09:59:48 ynezz, a fix for your segfaulting installs should be in the latest bzr Feb 24 10:20:20 ogra: thanks, which revision is that? Feb 24 10:28:33 ogra: did you get this "11:20:17 < ynezz> ogra: thanks, which revision is that?" ? Feb 24 10:28:49 ah, no, i didnt Feb 24 10:29:35 commit 78, the very last one Feb 24 10:30:51 the kernel that was used up to now for licud builds was compiled under karmic, the new code now makes it use the lucid archive kernel Feb 24 10:31:22 apparently that fixes it ... i had the code in there but disabled since i didnt want to hack around the gslice/malloc issue Feb 24 10:34:12 ynezz, so make sure you have the hack from commit 73 as well ;) Feb 24 10:38:13 Aha! is that why all the buildds were disabled for a while. That should make everything better. Feb 24 10:38:41 persia, ?? Feb 24 10:39:46 At some point recently I looked at lp.net/builders and 4 of the armel builders were disabled. Based on your comments, I now beleive that to be due to the kernel upgrade. Given the differences in kernels, I'm hoping lots more stuff builds. Feb 24 10:40:07 i was commenting on rootstock issues :) Feb 24 10:40:21 and you know we cant update the kernels on the buildds :) Feb 24 10:42:06 Ah, I hadn't realised rootstock had a special kernel poke that was different. And I suspect the kernels on the buildds could be updated, but yes, we can't do that. Feb 24 10:42:57 the kernels cant be updated as long as nobody makes it work ... which would require someone havin the HW to roll a new kernel with the required patch and to work out the flashing Feb 24 10:44:02 bah, crap ... 1000 steps are not enough for the rootstock progressbar when doing a netbook install Feb 24 10:44:08 Right. That's why we can't do it: the hardware is special :) Feb 24 10:44:18 well, not *that* special Feb 24 10:44:19 No ?!?! Feb 24 10:44:24 its just that nobody has it Feb 24 10:44:37 That's what makes it special. Feb 24 10:44:42 i surely would be able to make it work if i had such a device here Feb 24 10:46:06 Well, there are new dev boards announced regularly using supported chips, so we can hope there's retail boxes with real network, real disk, enough memory, and auto-boot-on-power-connect in the future. Feb 24 10:47:19 ah, sure, we're about to replace the machines anyway ... its in the process Feb 24 10:47:44 Oh cool! Feb 24 10:48:10 no idea how long it takes though ... might be past lucid Feb 24 10:48:42 but i'm starting to get tired of doing a handfull give-backs per day for random build failures Feb 24 10:48:50 so i hope rather sooner :) Feb 24 10:52:32 ogra: ah, ok Feb 24 10:52:42 ogra: will try later today and will let you know Feb 24 10:59:35 hi Feb 24 11:00:00 any infos when armv7a 12" 1GB ram systems will hit market? :D Feb 24 11:00:33 *soon* Feb 24 11:00:35 :P Feb 24 11:01:08 I am more and more tired with cursing intel developers after each update of debian on my laptop Feb 24 11:06:04 hrw: You could install Ubuntu, and then you wouldn't have to curse them after debian updates anymore :) Feb 24 11:09:11 persia: I will curse after each 'apt-get upgrade' anyway Feb 24 11:09:28 persia: i855gm is forgotten baby Feb 24 11:09:36 and distro does not change it Feb 24 11:10:12 is there a patch that doesn't break anything for anyone else? Feb 24 11:10:49 indeed.. intel x11 has been broken for thinkpad x40 with a old intel chip for several upstream releases.. Feb 24 11:54:14 hi there! i try to cross compile with arm-linux-gcc a sqlclient in c++ to arm720t and i need lib mysqlclient. Must i compile it from soucre? How? it would give me great pleasure for some tip. Feb 24 12:01:19 ogra: it still segfaults here :p Feb 24 12:01:52 whats your host release ? Feb 24 12:02:03 i'm running it on a lucid host as well Feb 24 12:02:10 so using the lucid qemu Feb 24 12:02:15 karmic here Feb 24 12:08:54 I'm building same image/params but for karmic and will tell you result Feb 24 12:55:53 ogra: karmic builds on karmic Feb 24 12:56:04 yeah, thought so Feb 24 12:56:39 you could run in a lucid chroot :) Feb 24 12:56:57 I'll try kvm Feb 24 12:57:09 i doubt thats fun Feb 24 12:57:22 running one vm in another will be horribly slow Feb 24 12:57:29 if it works at all Feb 24 12:57:38 I wonder about that too Feb 24 12:57:56 I don't share same opinion about speed tho Feb 24 12:58:14 qemu-system is very slow in itself Feb 24 12:58:24 at least the armel version Feb 24 12:58:53 running that inside kvm (which is what rootstock does) will likely be lots slower than on real iron Feb 24 12:59:11 ogra: run it on x86-64 instead of plain x86 Feb 24 12:59:57 that doesnt change the fact that you stack VMs Feb 24 13:00:32 i dont have any amd64 machines around to prove that ... nor any kvm capable HW though Feb 24 13:01:44 but i cant imagine running a VM in kvm can be any faster or equally fast than running it in a real chroot Feb 24 13:02:04 I don't think it will be faster Feb 24 13:02:15 slower, but not that much to be unusable Feb 24 14:23:14 mikeul, ah, you are already here :) Feb 24 14:23:21 so whats the problem you see ? Feb 24 14:25:01 First of all, I installed rootstock using apt in Karmic. But I've also built it with a copy from bazaar, and I'm having the same problem. Feb 24 14:26:22 rootstock seems to run fine to completion, and I have e.g. qemu-armel-201002241455.img (I ran with --keepimage) Feb 24 14:27:14 then, following instructions from https://wiki.ubuntu.com/ARM/RootfsFromScratch "Using a qemu image", I try booting with it inside qemu. Feb 24 14:28:39 using the exact same qemu-system-arm line from that site, it fails to boot completely. The last 3 lines of the boot sequence are... Feb 24 14:29:02 VFS: Mounted root (ext2 filesystem) readonly. Feb 24 14:29:10 thats using a jaunty kernel, if you built a karmic system you need a different kernel Feb 24 14:29:15 Freeing init memory: 136K Feb 24 14:29:28 ah ha Feb 24 14:29:31 http://people.canonical.com/~ogra/arm/qemu/vmlinuz-2.6.31-rc3versatile1-cortex-a8 Feb 24 14:30:29 ogra: Can we start pointing people at the versatile lucid kernel? Feb 24 14:30:39 OK, I'll go give that a go... Feb 24 14:30:50 mikeul: I'd be interested if you could try http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/ Feb 24 14:30:52 lool, well, that means unpacking the deb Feb 24 14:30:54 vmlinuz Feb 24 14:31:00 until d-i built it for versatile Feb 24 14:31:04 oh ? Feb 24 14:31:13 since when is that there ? Feb 24 14:31:14 mikeul: The vmlinuz there should allow booting anything from jaunty to lucid included Feb 24 14:31:25 mikeul, yes, do what lool said Feb 24 14:31:35 i wasnt aware that kernel exists yet Feb 24 14:31:58 I did the changes perhaps a week ago and d-i was uploaded perhaps a couple of days ago Feb 24 14:32:18 that explains why i didnt see it on the weekend when i checked :) Feb 24 14:33:51 alright, I'll try lool's suggestion. brb. Feb 24 14:34:42 you mean that the lucid kernel (at URL given) can boot with my karmic RFS? Feb 24 14:35:52 yes Feb 24 14:36:16 the kernels are backwards compatible ... just not forward :) Feb 24 14:44:12 Here is a weird issue I'm wondering if anyone else has run into. The rootstock filesystem I created using karmic results in my arm board not creating usb device nodes in /dev/bus/usb , I actually sorted the problem by replacing the line in /lib/udev/rules.d/50-udev-defaults.rules that creates the device nodes to the line that was there in jaunty (they differ). This solves the problem but I'm wondering if anyone else has come across this and if i should file Feb 24 14:45:13 you were cut after " and if i should fil" Feb 24 14:46:04 file a bug report Feb 24 14:46:31 It results in lsusb not seeing any devices Feb 24 14:52:37 I must be doing something wrong. Both the ...-cortex-a8 kernel and the vmlinuz kernel cause qemu to crash almost immediately. Feb 24 14:56:23 using the karmic kernel, I get a bunch of lines, "arm_sysctl_write: Bad register offset 0xc94", etc. Feb 24 14:56:53 then a reg dump and qemu exits Feb 24 15:01:24 booting with the lucid kernel lool pointed to doesn't cause qemu to spit out quite as many lines, but still ends in "qemu: hardware error: pl050_write: Bad offset 44" Feb 24 15:02:08 That line shows up at the end of the karmic kernel boot attempt, too (but with "c94" instead of "44") Feb 24 15:03:02 and you run that on a karmic system as well (i.e. the qemu you use is the one from ubuntu) Feb 24 15:03:51 yes, qemu was installed by apt upon installing rootstock. Feb 24 15:05:07 is your host machine amd64 or i386 ? Feb 24 15:08:41 uname -a says i686 Feb 24 15:09:13 mikeul: What's your qemu? Feb 24 15:10:43 'qemu -version' => QEMU PC emulator version 0.11.0 (qemu-kvm-0.11.0) Feb 24 15:12:21 was that the right answer? Same result with 'qemu-system-arm -version', of course. Feb 24 15:13:27 mikeul: Sorry, I'm not sure what the issue is; your expectation is a console prompt, but you don't get any, is that correct? Feb 24 15:13:48 lool: affirmative Feb 24 15:13:52 mikeul: This is usually the result of either the network not coming up, or the prompt coming on the serial console Feb 24 15:14:11 mikeul: For the network to come up, you either need to setup /etc/network/interfaces or install network-manager Feb 24 15:14:38 For serial console, it depends how you launch rootstock and qemu, but you should have it with Ctrl-Alt-2 IIRC Feb 24 15:14:41 or -3 Feb 24 15:17:19 But I don't think this is a qemu setup issue, because when I download the kernel and RFS (rather than build my own RFS), I can get a prompt in qemu. Feb 24 15:20:41 mikeul: Ok; so it's likely the network of console setup Feb 24 15:20:51 i.e. following the directions in http://people.canonical.com/~ogra/arm/qemu/kernel/README, I can get it to boot. Feb 24 15:22:14 lool: I don't understand that conclusion- you mean the network or console setup of qemu? Or of the RFS? Because the RFS never gets a chance- qemu crashes immediately, long before the kernel boots or the RFS is mounted. Feb 24 15:22:42 mikeul: no, in the image Feb 24 15:23:15 lool, well, if it crashes before loading the kernel .... Feb 24 15:23:17 mikeul: Either no console is spawned because serial console was chosen (I'm not sure what rootstock does there), or the consoles (tty1 tty2...) don't come up until network comes up Feb 24 15:23:38 mikeul: It doesn't crash anymore, does it? Feb 24 15:25:00 Yes, qemu crashes immediately. Perhaps I misspoke a second ago with "long before kernel boots"- it seems to crash immediately upon booting the kernel. Feb 24 15:25:41 mikeul: How do you start it? Feb 24 15:25:41 Here's my qemu command line just to be clear... Feb 24 15:29:12 qemu-system-arm -M versatilepb -kernel ../downloaded/vmlinuz-lucid -hda qemu-armel-201002241455.img -m 256 -append "root=/dev/sda mem=256M ro" Feb 24 15:29:32 sorry for the delay, it's a different machine, I can't cut-and-paste here... Feb 24 15:31:08 ...where "../downloaded/vmlinuz-lucid" is of course the kernel you pointed me to, renamed Feb 24 15:31:35 that should definately not crash on unpacking the kernel Feb 24 15:32:02 mikeul: You miss -cpu Feb 24 15:32:07 mikeul: You want -cpu cortex-a8 Feb 24 15:32:42 and the wikipage does as well Feb 24 15:32:48 * ogra slaps forehead Feb 24 15:33:24 indeed, now it boots. Feb 24 15:34:20 fixed Feb 24 15:34:44 well ... if the wiki ever saves Feb 24 15:38:39 lool, ogra, you have made me happy(er) Feb 24 15:38:49 mainly lool :) Feb 24 15:39:01 mikeul: I wish you'd list here all the pages which need fixing Feb 24 15:39:10 or places Feb 24 15:39:33 I still haven't landed at a prompt, but perhaps I should play around with that myself a bit... Feb 24 15:41:18 lool: you mean you want me to indicate which web pages were outdated? I can do that. Really, I was only using RootfsFromScratch, so I can summarize which parts of that page could be updated. Feb 24 15:41:41 mikeul: Which broken docs you came across basically Feb 24 15:41:56 mikeul: Well we can continue debugging for the prompt part Feb 24 15:42:10 mikeul: What does it do on boot now? Feb 24 15:44:12 (a few lines to follow) Feb 24 15:44:56 mount: mount point /dev/pts does not exist Feb 24 15:45:16 mountall: mount /dev/pts [45] terminated with status 32 Feb 24 15:45:41 mountall: Filesystem could not be mounted: /dev/pts Feb 24 15:46:10 [repeats for /dev/shm and /dev/pts (again) and /dev/shm (again)] Feb 24 15:46:21 Mount of root filesystem failed Feb 24 15:46:36 A maintenance shell will now be started. Feb 24 15:46:48 That's probably devtmpfs again Feb 24 15:47:05 Problem is karmic's mountall with a lucid kernel which has devtmpfs mount Feb 24 15:47:33 then let me try with -cpu correct and the karmic kernel... Feb 24 15:49:04 mikeul: Please pass devtmpfs.mount=0 on the kernel cmdline Feb 24 15:50:12 mikeul: I'd personnally recommend staying with the lucid kernel and just turning off devtmpfs mounting as above; the kernel has been fairly tested at this point, and we'd probably do best in supporting only one kernel which is able to work on all dists given the number of other issues we have to resolve Feb 24 15:50:24 ++ Feb 24 15:51:32 lool: fair enough, but I already tried it :) it hung up in the same manner as lucid is with "devtmpfs.mount=0". The both say: Feb 24 15:52:08 One or more of the mounts listed in /etc/fstab cannot yet be mounted: (ESC for recovery shell) Feb 24 15:52:22 /: waiting for /dev/root Feb 24 15:52:31 /tmp: waiting for (null) Feb 24 15:52:46 and then it doesn't make it any further. Feb 24 15:54:39 mikeul: It would help if you could paste the full output; to do so, pass console=ttyAMA0,115200 on the kernel cmdline and "-nographic" to QEMU Feb 24 15:55:08 That should output the kernel and userspace error messages on your terminal as to copy-paste Feb 24 15:55:15 mikeul: You can paste to e.g. paste.ubuntu.com Feb 24 15:55:52 At least the last lines of the kernel output and all of the userspace output of a boot with devtmpfs.mount=0 would be nice Feb 24 15:57:29 note that you need a second terminal from where you stop qemu then Feb 24 15:57:34 ctrl-C wont work Feb 24 15:57:47 yeah, I just noticed that :) Feb 24 16:00:48 lool: Here are the last few lines of the boot (that paste.ubuntu.com is really handy!) Feb 24 16:01:03 * ogra struggles with proper quoting for the rootstock /bin/installer script ... Feb 24 16:01:17 [ 5.560643] md: ... autorun DONE. Feb 24 16:01:29 [ 5.587783] VFS: Mounted root (ext2 filesystem) readonly on device 8:0. Feb 24 16:01:33 why is preserving variables in here documents so hard .... sigh Feb 24 16:01:47 [ 5.603695] Freeing init memory: 152K Feb 24 16:01:56 One or more of the mounts listed in /etc/fstab cannot yet be mounted: Feb 24 16:01:58 mikeul, sudo chown $USER Feb 24 16:02:19 i guess i should build that into rootstock somehow Feb 24 16:02:55 (the point is that i never use qemu but real HW) ... Feb 24 16:03:00 * ogra files a reminder bug Feb 24 16:03:50 I intend to be using real hardware, too Feb 24 16:04:19 mikeul: can you please give us the URL? Feb 24 16:04:37 mikeul: The point of paste.ubuntu.com is to send the output there and give us the URL Feb 24 16:04:54 you mean you want my qemu-armel-*.img to be the same user that's running qemu? It already is. Feb 24 16:05:28 "Oh, that makes sense", he said embarrassed, "here's my paste": http://paste.ubuntu.com/383077/ Feb 24 16:05:44 * ogra filed bug 527159 Feb 24 16:05:45 Launchpad bug 527159 in project-rootstock "rootstock script should produce world writable qemu images (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527159 Feb 24 16:06:10 mikeul, its not your fault, dont be embarrassed ... Feb 24 16:06:12 mikeul: So you don't have the /dev/pts errors etc. at least Feb 24 16:06:15 i should be :) Feb 24 16:06:19 mikeul: Could you paste the contents of your fstab? Feb 24 16:06:31 or lool for fixing the wikipage but not filing a bug :) Feb 24 16:06:53 originally we had a sudo in front of the qemu command there ;) Feb 24 16:09:02 ogra: I already was the owner of the *.img because I had copied the original. Feb 24 16:13:06 lool: here's my fstab: http://paste.ubuntu.com/383084/ Feb 24 16:13:41 mikeul, i bet he meant the one in the image :) Feb 24 16:13:59 lool, by default rootstock adds /proc and nothing else Feb 24 16:14:20 ogra: you're probably right, then I posted the wrong one of course. I'll go get the one from the image. Feb 24 16:14:36 mikeul: sudo mount -o loop /mnt; then paste the contents of /mnt/etc/fstab Feb 24 16:14:37 it will onyl contain a line for proc Feb 24 16:14:40 Don't forget to umount Feb 24 16:14:50 unless you modified it manually Feb 24 16:15:44 proc /proc proc defaults 0 0 Feb 24 16:15:52 i think mountall is misleading here Feb 24 16:16:10 I just have / in my fstab Feb 24 16:16:13 Something like: Feb 24 16:16:14 UUID=a5a3cdd1-1f8a-4070-8b86-5eb22d754897 / ext3 relatime,errors=remount-ro 0 1 Feb 24 16:16:21 you should have proc too Feb 24 16:16:26 afaik d-i adds it Feb 24 16:16:31 at least it did Feb 24 16:16:59 though having it wont do any harm Feb 24 16:18:19 hmm, you said your image was writable now ? Feb 24 16:18:23 [ 5.587783] VFS: Mounted root (ext2 filesystem) readonly on device 8:0. Feb 24 16:18:30 that somehow doesnt indicate it is Feb 24 16:18:56 mikeul: Here it boots a karmic chroot with just / added Feb 24 16:19:05 mikeul: i do need that devtmpfs.mount=0 too though Feb 24 16:19:07 i think the fstab error is bogus and just a wrong errormessage Feb 24 16:19:16 that "ro" came from my kernel cmd line. Feb 24 16:19:22 mikeul: You don't need /proc Feb 24 16:19:23 it tries to mount / rw but cant Feb 24 16:19:29 mikeul: But you want / in fstab Feb 24 16:19:34 what's "d-i"? Feb 24 16:19:39 debian-installer Feb 24 16:19:41 you dont need / in fstab Feb 24 16:20:05 ogra: Well let's see if it helps Feb 24 16:20:07 I lied- I didn't have "ro" in my args anymore. Feb 24 16:20:20 mikeul: Please add a / line in /mnt/etc/fstab Feb 24 16:20:33 mikeul: Change the UUID to the one you get with "file " Feb 24 16:20:54 lool, i never had any other fstab than the one created with rootstock for my qemu images Feb 24 16:21:18 Mounted root (ext2 filesystem) readonly is a clear indicator that something with the image permissions is wrong Feb 24 16:21:31 mountall might remount it rw if it finds it in fstab indeed Feb 24 16:22:15 I get the same read-only mount output, the same / and /tmp output, but then it proceeds, I'm pretty sure adding / in fstab will help Feb 24 16:22:51 sure, because mountall remounts with the fstab options if something is added Feb 24 16:23:20 but it works without so the image permissions are wrong Feb 24 16:23:50 do you remember asking me if my img is writable when we discussed the need of sudo ? Feb 24 16:25:35 I don't think it's the same issue Feb 24 16:25:51 mikeul said he owns the image already Feb 24 16:26:26 well, but i definately never needed an fstab entry Feb 24 16:26:46 and if that would become a requirement i'd remove the .img option from rootstock Feb 24 16:27:10 which is a sideeffect anyway, rootstock isnt intended as image builder Feb 24 16:28:11 but i'm sure it isnt a requirement ... Feb 24 16:28:21 else casper wouldnt work either :) Feb 24 16:28:59 or ltsp ... or anything else that doesnt use an fstab Feb 24 16:29:13 You can't compare these, they are initramfs based Feb 24 16:29:30 well, still Feb 24 16:29:54 it used to work all the time ... why should that suddenly become a requirement Feb 24 16:30:05 especially on a released system Feb 24 16:41:28 OK, I added the / line in fstab and now it hung up in a strange place... http://paste.ubuntu.com/383113 Feb 24 16:41:53 try running it without the serial console now Feb 24 16:42:11 ogra: So I would recommend you generate a / entry in fstab Feb 24 16:42:17 lool, no Feb 24 16:43:06 from your chatter earlier, it sounded like I would be better off to create the img file from the tgz? Feb 24 16:43:07 lool, i would like to know why thats suddenly needed if i didnt need it throughout the whole karmic cycle and until last week when i used my last qemu image with lucid Feb 24 16:43:24 no Feb 24 16:44:26 ogra: I'm not sure I have the time to debug why it's needed, but you mentionned that d-i writes a /proc entry, it certainly writes an entry for / too, and you really want one Feb 24 16:44:30 rootstock is designed to crate a tarball ... so you can untar that to your root device for any system, the .img file is just used to run qemu actually ... but since people found it convenient i added the --keepimage option Feb 24 16:44:53 lool, it was never needed before Feb 24 16:45:23 not through the whole of karmic and not until last week in lucid Feb 24 16:46:04 can I kill the qemu process w/o breaking my img? Feb 24 16:46:08 ogra: You can stand on your argument, in practice it didn't work without it Feb 24 16:46:09 sure Feb 24 16:46:29 lool, i wouldnt have added --keepimage if it hadnt worked without it Feb 24 16:47:13 ogra: So is there a process for people to create a bootable qemu image from root tarballs? Feb 24 16:47:39 i'm still sure it can be handled differently, and if not i'll drop --keepimage because it goes far beyond the purpose of rootstock to do anything HW related like writing UUIDs Feb 24 16:48:30 i'm actually working on fixes that even remove the persistent rules from udev to make sure there are no HW related bits Feb 24 16:48:56 lool, well, you know the process ... dd an image together, loop mount and untar Feb 24 16:49:09 ogra: I'm asking where I can point people who want to achieve this Feb 24 16:49:19 ogra: Including the fstab part Feb 24 16:49:36 feel free to add a rootstock errata page somewhere Feb 24 16:49:52 I mean obviously it doesn't work without / in fstab right now; it's best to have it there anyway, so I'd like to make sure people who want to run qemu against an .img get it setup in some way Feb 24 16:50:08 mikeul, would you do me a favor ? Feb 24 16:50:26 ogra: yes, I owe you one Feb 24 16:50:45 and mv fstab in your image to fstab.bakl, then touch fstab so you create an empty one and then run qemu with sudo ? Feb 24 16:50:51 *bak Feb 24 16:51:00 btw, I have a console in qemu now. I'm quite happy about that. Feb 24 16:51:08 you can move it back afterwards if it doesnt work Feb 24 16:53:36 ogra: Were you using an initrd? Feb 24 16:53:41 lool, never Feb 24 16:54:21 lool, an i had the same prob the first time when i didnt use sudo because you insisted i wouldnt have to ... Feb 24 16:54:36 a chmod 766 solved it for me back then Feb 24 16:54:45 ogra: I can reproduce mikeul's problem here without sudo being involved in anyway Feb 24 16:54:50 Just commenting out / from my fstab Feb 24 16:55:01 and if you use sudo ? Feb 24 16:55:08 It wont change a thing Feb 24 16:55:19 under karmic ? Feb 24 16:55:42 i really dont get why it worked for so many people including me all the time Feb 24 16:55:43 Yes Feb 24 16:55:59 Well I have an idea, but I didn't demonstrate it completely Feb 24 16:56:14 It's quite time consuming to find out and I know adding / in fstab is really best Feb 24 16:56:24 well Feb 24 16:56:41 can we assume people using --keepimage will never use the filesystem on a real machine ? Feb 24 16:58:15 i guess its a two liner in /bin/installer to add it based on teh --keepimage option ... but it massively bugs me that it worked all the time without a single issue Feb 24 17:09:35 ogra: I did your favor. Starting qemu as root, using an empty fstab, it again stopped after "One or more of the mounts listed in /etc/fstab cannot yet be mounted:"console Feb 24 17:09:45 ok Feb 24 17:09:47 thanks Feb 24 17:11:04 i'll follow lool's suggestion then and add the two lines to dump the img UUID into fstab for --keepimage and have a sleepless night over why it worked all the time :/ Feb 24 17:11:34 ogra,lool: I haven't understood everything that's happened here- why doesn't passing the "root=/dev/sda" kernel arg to QEMU work to boot the RFS? Feb 24 17:12:10 somehow mountall fuzzes around with the fstab entries during boot Feb 24 17:14:04 I much appreciate the help. Feb 24 17:14:17 well, you also helped a lot :) Feb 24 17:15:33 I'd like to continue to help, you might not have seen the last of me :) Feb 24 17:15:40 lool, you wanted me to summarize suggested changes to RootfsFromScratch? Feb 24 17:15:57 great ! Feb 24 17:16:16 mikeul: Yes Feb 24 17:16:17 Should I e-mail them? Post them here? Bug report somewhere? Feb 24 17:16:28 You could do them in the wiki page, or mention them here Feb 24 17:16:36 ++ Feb 24 17:18:29 OK. That won't be until tomorrow. Feb 24 17:18:39 I think it's a bug in mountall; either you need to pass rw to your kernel or you need to have the fs in fstab Feb 24 17:18:53 ah Feb 24 17:19:29 hmm, right, when we discussed the sudo stuff first thing i tried was rw on the cmdline ... Feb 24 17:19:53 only then it struck me that the img was readonly ... i re-used the same qemu command afterwards Feb 24 17:19:54 So I just confirmed that without an fstab and with rw on the cmdline, it boots Feb 24 17:20:02 * ogra hugs lool Feb 24 17:20:17 lool, sorry for being such a hard opponent sometimes Feb 24 17:20:34 i know i annoy you with that Feb 24 17:21:02 It's very energy consuming to fight each and every claim Feb 24 17:21:51 i'll try to improve but i knew it was working before and i didnt want to change code without knowing what was going on Feb 24 17:22:26 I still believe people would be better off with a fstab with / on real systems (even virtual) Feb 24 17:22:43 yes, i'll add the code for --keepimage Feb 24 17:22:54 mikeul: So recipe is vmlinuz from ports + rw and devtmpfs.mount=0 on cmdline Feb 24 17:22:58 for real systems we can add documantation Feb 24 17:23:38 yeah, I just removed the UUID from fstab and booted with rw on the cmdline to test, and it worked. Feb 24 17:24:06 How is devtmpfs getting in the way? Feb 24 17:24:55 udev in karmic didnt know about it, i think it steals /dev, not sure though Feb 24 17:25:34 devtmpfs is something new that only showed up in 2.6.32 kernels Feb 24 17:26:22 it pre-populates /dev so udev doesnt need to execute all its scripts to find the devices Feb 24 17:27:11 I filed LP #527216 on the mountall issue Feb 24 17:27:12 Launchpad bug 527216 in mountall (Ubuntu) "Boot hangs waiting for local filesystems if / isn't in fstab and / is only mounted ro (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527216 Feb 24 17:27:37 * ogra subscribes Feb 24 17:27:59 heh, its tagged amd64 :) Feb 24 17:29:49 I see. Well, thanks again lool and ogra. I'm signing off. Feb 24 17:30:10 ciao Feb 24 17:30:53 oh, finally ! Feb 24 17:30:56 mikeul: devtmpfs doesn't have the /dev/pts dirs etc. Feb 24 17:31:04 my here document quoting works ! Feb 24 17:31:04 mikeul: lucid's mountall can cope with that, but not karmic's Feb 24 17:31:15 mikeul: You don't need the devtmps arg for a lucid vm Feb 24 17:36:17 lool, i guess it wont do harm to use it with lucid though, would it ? Feb 24 17:36:35 * ogra thinks about a universal cmd we can put on the wiki Feb 24 17:37:01 i think it would just boot a little slower Feb 24 17:39:27 ogra: Yes, I did mean for mikeul to document using "devtmpfs.mount=0 rw" for all dists, not just karmic Feb 24 17:40:00 right, given that i changed the kernel link on the page i'll do that for now Feb 24 17:58:16 http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/80 Feb 24 17:58:20 lool, ^^^ fyi Feb 24 18:01:36 ogra: Do you want to hardcode ext3? I'd put auto there perhaps Feb 24 18:01:56 well, we format it ext3 anyway, but yes Feb 24 18:02:47 changed Feb 24 18:53:43 <|nfecteD> does anyone have any idea why my beagleboard doesn't seem to want to use USB devices when running ubuntu arm? Feb 24 18:53:57 <|nfecteD> i have a powered USB hub, yes Feb 24 18:54:13 <|nfecteD> and USB devices work with angstrom and android Feb 24 18:55:32 <|nfecteD> it does find the hub and devices during boot, but the blue lights that indicate that using are plugged in and ready for use never light up Feb 24 18:55:42 <|nfecteD> got the same problem with debian too Feb 24 18:56:00 <|nfecteD> (not the same kernel) Feb 24 18:59:16 hi guys Feb 24 19:23:37 |nfecteD, web irc log only goes back to the start of the hour.... did your usb port work? Feb 24 19:24:58 kblin, some news... I moved hardware around and i've been able to trigger musb problems on my rev Bx.. Strangely my C2 isn't having the issue.. Feb 24 19:32:53 <|nfecteD> rcn-ee: it works with angstrom and android, yes Feb 24 19:33:51 |nfecteD, what board (bx/c2-3/c4) ehci/musb? Feb 24 19:35:46 <|nfecteD> C4 ehci Feb 24 19:36:30 okay.. have you touched u-boot at all... (my wiki relies on you leaving it at the factory version..) Feb 24 19:36:52 <|nfecteD> i've changed the u-boot, yes Feb 24 19:36:58 what version? Feb 24 19:37:02 <|nfecteD> lesse... Feb 24 19:37:18 i think 'version' prints it out... (in u-boot) Feb 24 19:37:53 <|nfecteD> http://rcn-ee.net/deb/tools/u-boot-beagleboard-2009.08+r37+gitr1590f84007e2b50ad346a482fff89195cb04ff4e-r37.bin Feb 24 19:37:57 <|nfecteD> should be that one Feb 24 19:38:10 that's the problem... Feb 24 19:38:24 <|nfecteD> U-Boot 2009.08 (Dec 01 2009 - 05:37:28) Feb 24 19:38:29 <|nfecteD> (from beagleboard) Feb 24 19:39:35 the C4 is still too new... the ehci power setup is controlled thru u-boot, only the version on the C4 and the one listed here: http://www.angstrom-distribution.org/demo/beagleboard/u-boot.bin will work... Feb 24 19:39:47 <|nfecteD> ah Feb 24 19:39:54 <|nfecteD> thanks for clearing that up Feb 24 19:40:16 no problem... Feb 24 19:40:28 <|nfecteD> NEXT QUESTION (hoho) Feb 24 19:40:37 <|nfecteD> rootstock... Feb 24 19:40:57 i need to update the elinux wiki page... (there's a note about the C4 at the top about it, but i need to test it on all boards) Feb 24 19:41:25 <|nfecteD> I can't get it to enter stage 2 Feb 24 19:41:30 <|nfecteD> E: Second stage build in Virtual Machine failed ! Feb 24 19:42:00 <|nfecteD> is this because i try to build a lucid image in a karmic ubuntu? Feb 24 19:42:11 what os/version are you initiating the rootstock call from? Feb 24 19:42:28 <|nfecteD> Ubuntu 9.10 Feb 24 19:42:39 <|nfecteD> x32 (if it matters) Feb 24 19:42:41 well the version that came with karmic, doesn't support lucid... you need to tweak the rootstock script.. Feb 24 19:43:40 <|nfecteD> got a quick tweak on hand or should i just install lucid on the dev computer? Feb 24 19:44:02 support for lucid was added to the trunk of rootstock, no *.tar.gz release files yet with the lucid change: "bzr branch lp:project-rootstock" will get you what you need.. Feb 24 19:44:09 can i delete the --serial ttyS2 flag from rootstock AFTER i made the image? Feb 24 19:45:17 Hoonse, depends, but why did you add the flag? Feb 24 19:45:25 i made the image with rootstock and all works fine but now i dont want that the terminal listens on the ttyS2 port all the time Feb 24 19:45:39 i set the flag by making the rootstock image from ubuntu Feb 24 19:45:50 sudo ./rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --dist lucid \ Feb 24 19:45:50 --script fixup.sh --serial ttyS2 \ Feb 24 19:45:53 Hoonse, it'll be "/etc/event.d/ttyS2" Feb 24 19:45:54 <|nfecteD> rcn-ee: thank you very much Feb 24 19:46:04 <|nfecteD> hopefully now i'll be able to help myself for a while Feb 24 19:46:07 thanks i will try this now Feb 24 19:46:37 Hoonse, just remove that file and it'll never start at boot... Feb 24 19:46:49 k i will try... Feb 24 19:47:52 |nfecteD, your welcome, most things should be straightforward.. any other issues just post to the beagleboard group, as i'm not on irc at work... Feb 24 19:48:11 <|nfecteD> alrighty :) Feb 24 19:49:19 Hoonse, sorry, that was for Jaunty.. For karmic+ it's "/etc/init/ttyS2" Feb 24 19:49:37 "/etc/init/ttyS2.conf" Feb 24 19:49:50 remove this? Feb 24 19:50:07 Yeah, upstart reads that... Feb 24 19:50:30 and the ttyS1 3 4 ...? Feb 24 19:51:09 --serial only modifies one... the rest are ubuntu default setups... Feb 24 19:52:27 k i am rebooting right now Feb 24 19:52:31 Hoonse, the kernel will still post message on boot, so don't forget to remove "console=ttyS2,115200n8" from your boot.scr... the early bootstuff takes a kernel recompile... Feb 24 19:53:25 i did this before on the bootargs and on the ubuntu.cmd file (=boot.scr) Feb 24 19:54:05 i deleted the file but its still there... Feb 24 19:54:33 Hoonse, by deleting the file, the 'login' part shouldn't show up... eveything else is just kernel message... Feb 24 19:54:35 the problem not the file Feb 24 19:54:55 but the login part still shows up... Feb 24 19:56:21 ohh wait a sevond Feb 24 19:56:24 second Feb 24 19:56:32 there is the ttyS2 file Feb 24 19:56:36 i will delete this... Feb 24 19:56:38 well that doesn't make sense.. upstart -> "/etc/init/ttyS2.conf" calls "getty" -> prompt.. Feb 24 19:57:00 yes sorry i deleted the tty2 not the ttyS2 file... Feb 24 19:57:23 oh, easy miss... Feb 24 19:58:22 omg thanks now it works =) call me whenever you are in austria i will buy you a beer =) Feb 24 19:58:25 thanks Feb 24 19:58:38 with 'console=ttyS2,115200n8' and '/etc/init/ttyS2.conf" gone, there will still be the intiall serial traffic.... something like 'quiet' in boot.scr would make it even less.. Feb 24 19:58:58 good to here Hoonse Feb 24 20:29:52 <|nfecteD> oh yeah! rootstock entered stage 2 Feb 24 20:29:58 * |nfecteD crosses fingers Feb 24 20:33:56 ogra: lool: NCommander: is dove gigabit eth? Feb 24 20:34:32 armin76: it is Feb 24 20:34:39 1000 Mb/s, full duplex, flow control disabled Feb 24 20:34:43 oh nice, thanks Feb 24 20:34:51 Makes shooting stuff across my LAN so much easier Feb 24 20:35:04 NCommander: when i'm getting one? *g* Feb 24 20:35:08 armin76: I think only one port is native though Feb 24 20:37:43 armin76: the question is when is dove-next (a comercial laptop) going to be selled out on the market :-) Feb 24 20:38:30 armin76: when you sell your soul to Marvell :-) Feb 24 20:39:10 NCommander: oh, nice, i can sell it :D Feb 24 20:40:47 <|nfecteD> can the GPIO pins in the expansion connector be used to trigger scripts? Feb 24 20:41:05 <|nfecteD> when ubuntu is running that is Feb 24 20:44:50 <|nfecteD> perhaps i should mention that im talking about the beagleboard :P Feb 24 20:45:06 armin76: You already sold your soul 4 or 5 times Feb 24 20:45:10 armin76: no mode hardware for you now Feb 24 20:46:01 i did? :D Feb 24 21:01:58 rcn-ee: pong Feb 24 21:03:59 rcn-ee: ok, for me it seems to be the hub's fault. I've switched hubs between my two beagles, and now the c3 is fine and the b6 is having problems. Feb 24 22:18:03 <|nfecteD> rcn-ee: looks like rootstock locks up while unpacking the debs in stage 2... any idea what that might be? Feb 24 22:18:08 <|nfecteD> Unpacking usbutils (from .../usbutils_0.86-2ubuntu1_armel.deb) ... Feb 24 22:18:14 <|nfecteD> thats where it is Feb 24 22:18:20 <|nfecteD> and has been for 30 minutes Feb 24 22:48:55 hello Feb 24 22:49:16 how to have the same theme on pc ? Feb 24 22:50:42 hello Feb 24 22:50:46 or can I find the theme for an arm platform x86 ubuntu thanks you Feb 24 22:56:30 termitor: mygalaxia: The themes are precisely the same as on other architectures. Feb 24 23:58:35 |nfecteD, can you pastebin your rootstock log? i'll be back in a bit, tweaking a server.. **** ENDING LOGGING AT Thu Feb 25 02:59:58 2010