| plars | GrueMaster: are you testing on imx or dove currently? | 00:40 |
|---|---|---|
| * persia wonders why this is -arm and not -testing material. | 00:41 | |
| GrueMaster | Finished testing imx live (well, may test more deeply). Installer is still broken and fix is released but not built yet. | 00:41 |
| plars | GrueMaster: same installer bug you mentioned in the meeting earlier today? | 00:41 |
| GrueMaster | yes. | 00:42 |
| plars | ouch | 00:42 |
| plars | GrueMaster: you are going to have the same problem on dove | 00:43 |
| plars | GrueMaster: we have ubiquity 2.1.24 on dove, assuming the same on imx | 00:43 |
| plars | snap | 00:43 |
| GrueMaster | That's what I thought. yes. | 00:44 |
| GrueMaster | So, respin it is. | 00:44 |
| GrueMaster | wheee. | 00:44 |
| plars | GrueMaster: is there any workaround for it? | 00:44 |
| GrueMaster | Yes. Install 2.1.25 as soon as it gets built. | 00:45 |
| GrueMaster | (I know, not a good answer) | 00:45 |
| plars | GrueMaster: well, if you want to get unblocked... | 00:46 |
| plars | it's a 1-line change | 00:46 |
| GrueMaster | Correct me if I'm wrong, but it seems to me we hit this bug at least once per release. | 00:46 |
| plars | http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/3830#ubiquity/components/ubi-partman.py | 00:46 |
| GrueMaster | Does python rebuild the pyc file automatically? | 00:49 |
| plars | GrueMaster: hopefully that's true, and our one time is over :) | 00:49 |
| plars | GrueMaster: you can force it if needed by deleting the .pyc file | 00:49 |
| plars | it's going to be 1-2 hours before I can get much more testing done, but may be moot since it looks like we'll need a respin | 00:50 |
| GrueMaster | I've made the change and will test it quickly. | 00:50 |
| DanaG | hmm, marvell dove... what actual board uses that? | 00:50 |
| DanaG | I can find Kirkwood just fine (that Sheeva thingy), but what's Dove? | 00:50 |
| DanaG | What I have is BeagleBoard (OMAP3). | 00:51 |
| plars | GrueMaster: thanks, let me know, gotta go afk for a bit | 00:51 |
| GrueMaster | see you. | 00:51 |
| GrueMaster | DanaG: The sheeva plug is an older generation. | 00:51 |
| DanaG | I thought it was the other way around... kirkwood newer than dove. | 00:52 |
| DanaG | oh, I see. | 00:52 |
| persia | Age of processor != Age of instruction set revision :) | 00:53 |
| DanaG | http://armin762.wordpress.com/2010/02/14/armv7-socs-freescale-i-mx51-babbage-ti-omap3-marvell-dovearmada-qualcomm-snapdragon/ | 00:53 |
| DanaG | ah | 00:53 |
| GrueMaster | http://www.slashgear.com/marvell-plug-computer-3-0-updates-sheevaplug-with-wifi-bluetooth-hdd-0567674/ | 00:53 |
| DanaG | Do any of you talk directly to Marvell? | 00:54 |
| DanaG | http://www.flickr.com/photos/22046787@N03/sets/72157623160058996/ | 00:54 |
| DanaG | I saw comments on Engadget, asking essentially: why cripple battery life by using a tiny battery? | 00:54 |
| DanaG | Product suggestion: take that same thing, and give it a normal-size battery (for insane-o battery life). | 00:54 |
| persia | DanaG: I've had the "why cripple" discussion with a hardware vendor before. Apparently the goals are low cost and low weight with market-acceptable battery life. | 00:57 |
| persia | DanaG: The impression I get is that marketing teams don't believe people will pay more for heavier devices just for extended runtimes | 00:57 |
| DanaG | Ah, it'd be nice if they could make interchangeable different-size batteries. | 00:57 |
| DanaG | http://www.engadget.com/2010/01/05/marvell-shows-off-an-odm-smartbook-thinner-than-strict-decency-p/ | 00:58 |
| persia | Some do, but not enough :) | 00:58 |
| persia | armin76: Do you have a link for the "Prototype" identified as an i.MX51 product, or did you just mean "Various prototype devices"? | 00:59 |
| DanaG | As it is, 4 hours is no better than I get with my full-size laptop -- and lower than many Atom netbooks. | 01:00 |
| persia | Well, yeah, but it's "The thinnest thing around", which is the highlight point. | 01:00 |
| persia | There was talk about the "20-hour laptop", which is perfectly doable at about 1.5Kg, and we can hope someone releases one. | 01:00 |
| DanaG | If they put the battery at the back, then they could do one design to satisfy both. | 01:04 |
| DanaG | http://gigapple.files.wordpress.com/2009/04/hp_battery.png?w=161&h=149 | 01:05 |
| DanaG | old pic, but that's the idea. | 01:05 |
| persia | Either that, or something like the 3/6/9/12 cell modular batteries available for some laptops. | 01:06 |
| DanaG | oh, and are there plans for an official in-repo beagleboard config (or at least kernel)? | 01:06 |
| persia | I think not for the current generation. There is an expetation of 192MB RAM in Ubuntu (or maybe that got bumped to 256MB or even 384MB), and I thought the BeagleBoards only had 128MB. | 01:07 |
| DanaG | I believe it has 256, actually. | 01:07 |
| persia | Oh, then I've been misinformed :) | 01:07 |
| DanaG | I'm running Lucid on it just fine right now -- http://elinux.org/BeagleBoardUbuntu | 01:07 |
| DanaG | I think Rev.A had 128; it changed to 256 later. | 01:08 |
| persia | Oh, I know it works. We have lots of Beagle users. | 01:08 |
| persia | Ah. That explains the confusion. | 01:08 |
| persia | I think it's too late for this development cycle (although I might be wrong), but it would perhaps be something to raise with the kernel team during planning for the next cycle. | 01:08 |
| persia | It depends on the level of effort that is expected from them, and the number of people willing to volunteer to support it, etc. | 01:09 |
| persia | If we just ask the existing team "Please also do this" the answer is almost certain to be "No" unless it's trivial to do. | 01:09 |
| persia | If we can get more volunteers to help join the team, and the question becomes "Please accept these patches that we'll help maintain", it'S easier. | 01:10 |
| DanaG | Even something like the kernel-ppa (that is, not even a 'real ppa' that you can add to sources.list) would be good. | 01:23 |
| DanaG | Just, something like a "sanctioned list of kernels you should try". | 01:23 |
| DanaG | Or something like that. | 01:24 |
| persia | Well, PPAs don't handle armel very well. | 01:24 |
| persia | Best current recommendation for Beagle users is to use rcn-ee's kernel, which tends to be in good shape. | 01:24 |
| DanaG | oh yeah, and speaking of batteries... the way HP business notebooks work: 8-cell primary, PLUS either 8 or 12-cell secondary. | 01:24 |
| DanaG | oh yeah, though none of the .33-rc kernels are there for Lucid. | 01:25 |
| persia | That's also a reasonable model. | 01:25 |
| DanaG | And 8 is bigger than necessary for ARM stock battery. | 01:25 |
| DanaG | =þ | 01:25 |
| DanaG | You could go all day on 8. | 01:25 |
| persia | Lucid isn't using .33-rc right now for anything. It's 2.6.32 still. | 01:25 |
| persia | "All day" isn't necessarily enough :) | 01:26 |
| DanaG | taken absurdly literally, "all day" is 24 hours. | 01:26 |
| DanaG | =þ | 01:26 |
| DanaG | er, at least 18. | 01:26 |
| * persia has a laptop that (when the batteries were new) got 12 hours on two batteries. With travel, sleep, etc., this should have been enough (especially because the batteries recharge in 3.5 hours), but I've still run completely out of power. | 01:27 | |
| DanaG | My laptop got 4 hours when new, on the 8-cell standard battery. Now I have like 17% wear, one year later. | 01:28 |
| DanaG | Oh, and what's Marvell's GPU, anyway? | 01:33 |
| DanaG | (two questions: open source? capable of compiz?) | 01:33 |
| armin76 | persia: http://www.engadget.com/2010/01/04/freescale-reveals-7-inch-smartbook-reference-design-hopes-to-se/ | 05:41 |
| eggonlea | DanaG: OpenGL ES instead of OpenGL, so not capable of compiz. | 05:49 |
| DanaG | Bleh. | 05:49 |
| DanaG | Compiz is like 90% of the opengl I use in Linux. | 05:49 |
| DanaG | =þ | 05:49 |
| eggonlea | hi all, I did not see any ARM port of daily livecd. what's wrong with that? | 05:50 |
| DanaG | ARM + CD drive... does not compute, | 05:50 |
| DanaG | . | 05:50 |
| DanaG | Try "root filesystem image" or something. | 05:50 |
| eggonlea | I mean the livecd.img instead of .iso. | 05:51 |
| eggonlea | we usually had it everyday. | 05:51 |
| DanaG | ah. | 05:51 |
| eggonlea | Hope one day both of compiz and launcher chould have both of GL and GL ES backend. :P | 05:51 |
| eggonlea | Like ChromeOS | 05:52 |
| persia | armin76: Ah, that makes sense. I was thinking it would be interesting if someone tried to brand "Prototype" :) | 06:49 |
| lool | ogra: poke | 08:46 |
| ogra | ouch ! | 08:47 |
| ogra | :) | 08:47 |
| lool | 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 | 08:47 |
| ubot4 | 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 | 08:47 |
| lool | (To implement signing of these files in soyuz) | 08:47 |
| lool | for rootstock that is | 08:48 |
| ogra | lool, see if my comment suffices | 08:51 |
| lool | ogra: that helps, thanks | 08:52 |
| ogra | lool, btw, probably link bug 437636 to it (or make it a duplicate of 431790) | 08:53 |
| ubot4 | ogra: Bug 437636 on http://launchpad.net/bugs/437636 is private | 08:53 |
| lool | 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 | 08:58 |
| lool | ogra: I dup-ed; I don't really care if it's separate or not, up to you | 08:59 |
| ogra | no, thats fine | 08:59 |
| ogra | ynezz, a fix for your segfaulting installs should be in the latest bzr | 09:59 |
| ynezz | ogra: thanks, which revision is that? | 10:20 |
| ynezz | ogra: did you get this "11:20:17 < ynezz> ogra: thanks, which revision is that?" ? | 10:28 |
| ogra | ah, no, i didnt | 10:28 |
| ogra | commit 78, the very last one | 10:29 |
| ogra | 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 | 10:30 |
| ogra | apparently that fixes it ... i had the code in there but disabled since i didnt want to hack around the gslice/malloc issue | 10:31 |
| ogra | ynezz, so make sure you have the hack from commit 73 as well ;) | 10:34 |
| persia | Aha! is that why all the buildds were disabled for a while. That should make everything better. | 10:38 |
| ogra | persia, ?? | 10:38 |
| persia | 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. | 10:39 |
| ogra | i was commenting on rootstock issues :) | 10:40 |
| ogra | and you know we cant update the kernels on the buildds :) | 10:40 |
| persia | 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. | 10:42 |
| ogra | 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 | 10:42 |
| ogra | bah, crap ... 1000 steps are not enough for the rootstock progressbar when doing a netbook install | 10:44 |
| persia | Right. That's why we can't do it: the hardware is special :) | 10:44 |
| ogra | well, not *that* special | 10:44 |
| persia | No ?!?! | 10:44 |
| ogra | its just that nobody has it | 10:44 |
| persia | That's what makes it special. | 10:44 |
| ogra | i surely would be able to make it work if i had such a device here | 10:44 |
| persia | 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. | 10:46 |
| ogra | ah, sure, we're about to replace the machines anyway ... its in the process | 10:47 |
| persia | Oh cool! | 10:47 |
| ogra | no idea how long it takes though ... might be past lucid | 10:48 |
| ogra | but i'm starting to get tired of doing a handfull give-backs per day for random build failures | 10:48 |
| ogra | so i hope rather sooner :) | 10:48 |
| ynezz | ogra: ah, ok | 10:52 |
| ynezz | ogra: will try later today and will let you know | 10:52 |
| hrw | hi | 10:59 |
| hrw | any infos when armv7a 12" 1GB ram systems will hit market? :D | 11:00 |
| ogra | *soon* | 11:00 |
| ogra | :P | 11:00 |
| hrw | I am more and more tired with cursing intel developers after each update of debian on my laptop | 11:01 |
| persia | hrw: You could install Ubuntu, and then you wouldn't have to curse them after debian updates anymore :) | 11:06 |
| hrw | persia: I will curse after each 'apt-get upgrade' anyway | 11:09 |
| hrw | persia: i855gm is forgotten baby | 11:09 |
| hrw | and distro does not change it | 11:09 |
| persia | is there a patch that doesn't break anything for anyone else? | 11:10 |
| suihkulokki | indeed.. intel x11 has been broken for thinkpad x40 with a old intel chip for several upstream releases.. | 11:10 |
| Noisi | 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. | 11:54 |
| ynezz | ogra: it still segfaults here :p | 12:01 |
| ogra | whats your host release ? | 12:01 |
| ogra | i'm running it on a lucid host as well | 12:02 |
| ogra | so using the lucid qemu | 12:02 |
| ynezz | karmic here | 12:02 |
| ynezz | I'm building same image/params but for karmic and will tell you result | 12:08 |
| ynezz | ogra: karmic builds on karmic | 12:55 |
| ogra | yeah, thought so | 12:56 |
| ogra | you could run in a lucid chroot :) | 12:56 |
| ynezz | I'll try kvm | 12:56 |
| ogra | i doubt thats fun | 12:57 |
| ogra | running one vm in another will be horribly slow | 12:57 |
| ogra | if it works at all | 12:57 |
| ynezz | I wonder about that too | 12:57 |
| ynezz | I don't share same opinion about speed tho | 12:57 |
| ogra | qemu-system is very slow in itself | 12:58 |
| ogra | at least the armel version | 12:58 |
| ogra | running that inside kvm (which is what rootstock does) will likely be lots slower than on real iron | 12:58 |
| hrw | ogra: run it on x86-64 instead of plain x86 | 12:59 |
| ogra | that doesnt change the fact that you stack VMs | 12:59 |
| ogra | i dont have any amd64 machines around to prove that ... nor any kvm capable HW though | 13:00 |
| ogra | but i cant imagine running a VM in kvm can be any faster or equally fast than running it in a real chroot | 13:01 |
| ynezz | I don't think it will be faster | 13:02 |
| ynezz | slower, but not that much to be unusable | 13:02 |
| ogra | mikeul, ah, you are already here :) | 14:23 |
| ogra | so whats the problem you see ? | 14:23 |
| mikeul | 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. | 14:25 |
| mikeul | rootstock seems to run fine to completion, and I have e.g. qemu-armel-201002241455.img (I ran with --keepimage) | 14:26 |
| === Stskeepz is now known as Stskeeps | ||
| mikeul | then, following instructions from https://wiki.ubuntu.com/ARM/RootfsFromScratch "Using a qemu image", I try booting with it inside qemu. | 14:27 |
| mikeul | 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... | 14:28 |
| mikeul | VFS: Mounted root (ext2 filesystem) readonly. | 14:29 |
| ogra | thats using a jaunty kernel, if you built a karmic system you need a different kernel | 14:29 |
| mikeul | Freeing init memory: 136K | 14:29 |
| mikeul | ah ha | 14:29 |
| ogra | http://people.canonical.com/~ogra/arm/qemu/vmlinuz-2.6.31-rc3versatile1-cortex-a8 | 14:29 |
| lool | ogra: Can we start pointing people at the versatile lucid kernel? | 14:30 |
| mikeul | OK, I'll go give that a go... | 14:30 |
| lool | mikeul: I'd be interested if you could try http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/ | 14:30 |
| ogra | lool, well, that means unpacking the deb | 14:30 |
| lool | vmlinuz | 14:30 |
| ogra | until d-i built it for versatile | 14:31 |
| ogra | oh ? | 14:31 |
| ogra | since when is that there ? | 14:31 |
| lool | mikeul: The vmlinuz there should allow booting anything from jaunty to lucid included | 14:31 |
| ogra | mikeul, yes, do what lool said | 14:31 |
| ogra | i wasnt aware that kernel exists yet | 14:31 |
| lool | I did the changes perhaps a week ago and d-i was uploaded perhaps a couple of days ago | 14:31 |
| ogra | that explains why i didnt see it on the weekend when i checked :) | 14:32 |
| mikeul | alright, I'll try lool's suggestion. brb. | 14:33 |
| mikeul | you mean that the lucid kernel (at URL given) can boot with my karmic RFS? | 14:34 |
| ogra | yes | 14:35 |
| ogra | the kernels are backwards compatible ... just not forward :) | 14:36 |
| chimp | 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 | 14:44 |
| ogra | you were cut after " and if i should fil" | 14:45 |
| chimp | file a bug report | 14:46 |
| chimp | It results in lsusb not seeing any devices | 14:46 |
| mikeul | I must be doing something wrong. Both the ...-cortex-a8 kernel and the vmlinuz kernel cause qemu to crash almost immediately. | 14:52 |
| mikeul | using the karmic kernel, I get a bunch of lines, "arm_sysctl_write: Bad register offset 0xc94", etc. | 14:56 |
| mikeul | then a reg dump and qemu exits | 14:56 |
| mikeul | 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" | 15:01 |
| mikeul | That line shows up at the end of the karmic kernel boot attempt, too (but with "c94" instead of "44") | 15:02 |
| ogra | and you run that on a karmic system as well (i.e. the qemu you use is the one from ubuntu) | 15:03 |
| mikeul | yes, qemu was installed by apt upon installing rootstock. | 15:03 |
| ogra | is your host machine amd64 or i386 ? | 15:05 |
| mikeul | uname -a says i686 | 15:08 |
| lool | mikeul: What's your qemu? | 15:09 |
| mikeul | 'qemu -version' => QEMU PC emulator version 0.11.0 (qemu-kvm-0.11.0) | 15:10 |
| mikeul | was that the right answer? Same result with 'qemu-system-arm -version', of course. | 15:12 |
| lool | 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? | 15:13 |
| mikeul | lool: affirmative | 15:13 |
| lool | mikeul: This is usually the result of either the network not coming up, or the prompt coming on the serial console | 15:13 |
| lool | mikeul: For the network to come up, you either need to setup /etc/network/interfaces or install network-manager | 15:14 |
| lool | For serial console, it depends how you launch rootstock and qemu, but you should have it with Ctrl-Alt-2 IIRC | 15:14 |
| lool | or -3 | 15:14 |
| mikeul | 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. | 15:17 |
| lool | mikeul: Ok; so it's likely the network of console setup | 15:20 |
| mikeul | i.e. following the directions in http://people.canonical.com/~ogra/arm/qemu/kernel/README, I can get it to boot. | 15:20 |
| mikeul | 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. | 15:22 |
| lool | mikeul: no, in the image | 15:22 |
| ogra | lool, well, if it crashes before loading the kernel .... | 15:23 |
| lool | 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 | 15:23 |
| lool | mikeul: It doesn't crash anymore, does it? | 15:23 |
| mikeul | Yes, qemu crashes immediately. Perhaps I misspoke a second ago with "long before kernel boots"- it seems to crash immediately upon booting the kernel. | 15:25 |
| lool | mikeul: How do you start it? | 15:25 |
| mikeul | Here's my qemu command line just to be clear... | 15:25 |
| mikeul | qemu-system-arm -M versatilepb -kernel ../downloaded/vmlinuz-lucid -hda qemu-armel-201002241455.img -m 256 -append "root=/dev/sda mem=256M ro" | 15:29 |
| mikeul | sorry for the delay, it's a different machine, I can't cut-and-paste here... | 15:29 |
| mikeul | ...where "../downloaded/vmlinuz-lucid" is of course the kernel you pointed me to, renamed | 15:31 |
| ogra | that should definately not crash on unpacking the kernel | 15:31 |
| lool | mikeul: You miss -cpu | 15:32 |
| lool | mikeul: You want -cpu cortex-a8 | 15:32 |
| ogra | and the wikipage does as well | 15:32 |
| * ogra slaps forehead | 15:32 | |
| mikeul | indeed, now it boots. | 15:33 |
| ogra | fixed | 15:34 |
| ogra | well ... if the wiki ever saves | 15:34 |
| mikeul | lool, ogra, you have made me happy(er) | 15:38 |
| ogra | mainly lool :) | 15:38 |
| lool | mikeul: I wish you'd list here all the pages which need fixing | 15:39 |
| lool | or places | 15:39 |
| mikeul | I still haven't landed at a prompt, but perhaps I should play around with that myself a bit... | 15:39 |
| mikeul | 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. | 15:41 |
| lool | mikeul: Which broken docs you came across basically | 15:41 |
| lool | mikeul: Well we can continue debugging for the prompt part | 15:41 |
| lool | mikeul: What does it do on boot now? | 15:42 |
| mikeul | (a few lines to follow) | 15:44 |
| mikeul | mount: mount point /dev/pts does not exist | 15:44 |
| mikeul | mountall: mount /dev/pts [45] terminated with status 32 | 15:45 |
| mikeul | mountall: Filesystem could not be mounted: /dev/pts | 15:45 |
| mikeul | [repeats for /dev/shm and /dev/pts (again) and /dev/shm (again)] | 15:46 |
| mikeul | Mount of root filesystem failed | 15:46 |
| mikeul | A maintenance shell will now be started. | 15:46 |
| lool | That's probably devtmpfs again | 15:46 |
| lool | Problem is karmic's mountall with a lucid kernel which has devtmpfs mount | 15:47 |
| mikeul | then let me try with -cpu correct and the karmic kernel... | 15:47 |
| lool | mikeul: Please pass devtmpfs.mount=0 on the kernel cmdline | 15:49 |
| lool | 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 | 15:50 |
| ogra | ++ | 15:50 |
| mikeul | 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: | 15:51 |
| mikeul | One or more of the mounts listed in /etc/fstab cannot yet be mounted: (ESC for recovery shell) | 15:52 |
| mikeul | /: waiting for /dev/root | 15:52 |
| mikeul | /tmp: waiting for (null) | 15:52 |
| mikeul | and then it doesn't make it any further. | 15:52 |
| lool | 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 | 15:54 |
| lool | That should output the kernel and userspace error messages on your terminal as to copy-paste | 15:55 |
| lool | mikeul: You can paste to e.g. paste.ubuntu.com | 15:55 |
| lool | 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 | 15:55 |
| ogra | note that you need a second terminal from where you stop qemu then | 15:57 |
| ogra | ctrl-C wont work | 15:57 |
| mikeul | yeah, I just noticed that :) | 15:57 |
| mikeul | lool: Here are the last few lines of the boot (that paste.ubuntu.com is really handy!) | 16:00 |
| * ogra struggles with proper quoting for the rootstock /bin/installer script ... | 16:01 | |
| mikeul | [ 5.560643] md: ... autorun DONE. | 16:01 |
| mikeul | [ 5.587783] VFS: Mounted root (ext2 filesystem) readonly on device 8:0. | 16:01 |
| ogra | why is preserving variables in here documents so hard .... sigh | 16:01 |
| mikeul | [ 5.603695] Freeing init memory: 152K | 16:01 |
| mikeul | One or more of the mounts listed in /etc/fstab cannot yet be mounted: | 16:01 |
| ogra | mikeul, sudo chown $USER <path to rootfs image> | 16:01 |
| ogra | i guess i should build that into rootstock somehow | 16:02 |
| ogra | (the point is that i never use qemu but real HW) ... | 16:02 |
| * ogra files a reminder bug | 16:03 | |
| mikeul | I intend to be using real hardware, too | 16:03 |
| lool | mikeul: can you please give us the URL? | 16:04 |
| lool | mikeul: The point of paste.ubuntu.com is to send the output there and give us the URL | 16:04 |
| mikeul | you mean you want my qemu-armel-*.img to be the same user that's running qemu? It already is. | 16:04 |
| mikeul | "Oh, that makes sense", he said embarrassed, "here's my paste": http://paste.ubuntu.com/383077/ | 16:05 |
| * ogra filed bug 527159 | 16:05 | |
| ubot4 | Launchpad bug 527159 in project-rootstock "rootstock script should produce world writable qemu images (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527159 | 16:05 |
| ogra | mikeul, its not your fault, dont be embarrassed ... | 16:06 |
| lool | mikeul: So you don't have the /dev/pts errors etc. at least | 16:06 |
| ogra | i should be :) | 16:06 |
| lool | mikeul: Could you paste the contents of your fstab? | 16:06 |
| ogra | or lool for fixing the wikipage but not filing a bug :) | 16:06 |
| ogra | originally we had a sudo in front of the qemu command there ;) | 16:06 |
| mikeul | ogra: I already was the owner of the *.img because I had copied the original. | 16:09 |
| mikeul | lool: here's my fstab: http://paste.ubuntu.com/383084/ | 16:13 |
| ogra | mikeul, i bet he meant the one in the image :) | 16:13 |
| ogra | lool, by default rootstock adds /proc and nothing else | 16:13 |
| mikeul | ogra: you're probably right, then I posted the wrong one of course. I'll go get the one from the image. | 16:14 |
| lool | mikeul: sudo mount -o loop <yourimg> /mnt; then paste the contents of /mnt/etc/fstab | 16:14 |
| ogra | it will onyl contain a line for proc | 16:14 |
| lool | Don't forget to umount | 16:14 |
| ogra | unless you modified it manually | 16:14 |
| mikeul | proc /proc proc defaults 0 0 | 16:15 |
| ogra | i think mountall is misleading here | 16:15 |
| lool | I just have / in my fstab | 16:16 |
| lool | Something like: | 16:16 |
| lool | UUID=a5a3cdd1-1f8a-4070-8b86-5eb22d754897 / ext3 relatime,errors=remount-ro 0 1 | 16:16 |
| ogra | you should have proc too | 16:16 |
| ogra | afaik d-i adds it | 16:16 |
| ogra | at least it did | 16:16 |
| ogra | though having it wont do any harm | 16:16 |
| ogra | hmm, you said your image was writable now ? | 16:18 |
| ogra | [ 5.587783] VFS: Mounted root (ext2 filesystem) readonly on device 8:0. | 16:18 |
| ogra | that somehow doesnt indicate it is | 16:18 |
| lool | mikeul: Here it boots a karmic chroot with just / added | 16:18 |
| lool | mikeul: i do need that devtmpfs.mount=0 too though | 16:19 |
| ogra | i think the fstab error is bogus and just a wrong errormessage | 16:19 |
| mikeul | that "ro" came from my kernel cmd line. | 16:19 |
| lool | mikeul: You don't need /proc | 16:19 |
| ogra | it tries to mount / rw but cant | 16:19 |
| lool | mikeul: But you want / in fstab | 16:19 |
| mikeul | what's "d-i"? | 16:19 |
| lool | debian-installer | 16:19 |
| ogra | you dont need / in fstab | 16:19 |
| lool | ogra: Well let's see if it helps | 16:20 |
| mikeul | I lied- I didn't have "ro" in my args anymore. | 16:20 |
| lool | mikeul: Please add a / line in /mnt/etc/fstab | 16:20 |
| lool | mikeul: Change the UUID to the one you get with "file <your image>" | 16:20 |
| ogra | lool, i never had any other fstab than the one created with rootstock for my qemu images | 16:20 |
| ogra | Mounted root (ext2 filesystem) readonly is a clear indicator that something with the image permissions is wrong | 16:21 |
| ogra | mountall might remount it rw if it finds it in fstab indeed | 16:21 |
| lool | 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 | 16:22 |
| ogra | sure, because mountall remounts with the fstab options if something is added | 16:22 |
| ogra | but it works without so the image permissions are wrong | 16:23 |
| ogra | do you remember asking me if my img is writable when we discussed the need of sudo ? | 16:23 |
| lool | I don't think it's the same issue | 16:25 |
| lool | mikeul said he owns the image already | 16:25 |
| ogra | well, but i definately never needed an fstab entry | 16:26 |
| ogra | and if that would become a requirement i'd remove the .img option from rootstock | 16:26 |
| ogra | which is a sideeffect anyway, rootstock isnt intended as image builder | 16:27 |
| ogra | but i'm sure it isnt a requirement ... | 16:28 |
| ogra | else casper wouldnt work either :) | 16:28 |
| ogra | or ltsp ... or anything else that doesnt use an fstab | 16:28 |
| lool | You can't compare these, they are initramfs based | 16:29 |
| ogra | well, still | 16:29 |
| ogra | it used to work all the time ... why should that suddenly become a requirement | 16:29 |
| ogra | especially on a released system | 16:30 |
| mikeul | OK, I added the / line in fstab and now it hung up in a strange place... http://paste.ubuntu.com/383113 | 16:41 |
| ogra | try running it without the serial console now | 16:41 |
| lool | ogra: So I would recommend you generate a / entry in fstab | 16:42 |
| === Guest5903 is now known as NCommander | ||
| ogra | lool, no | 16:42 |
| ogra | 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 | 16:43 |
| mikeul | from your chatter earlier, it sounded like I would be better off to create the img file from the tgz? | 16:43 |
| ogra | no | 16:43 |
| lool | 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 | 16:44 |
| ogra | 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 | 16:44 |
| ogra | lool, it was never needed before | 16:44 |
| ogra | not through the whole of karmic and not until last week in lucid | 16:45 |
| mikeul | can I kill the qemu process w/o breaking my img? | 16:46 |
| lool | ogra: You can stand on your argument, in practice it didn't work without it | 16:46 |
| ogra | sure | 16:46 |
| ogra | lool, i wouldnt have added --keepimage if it hadnt worked without it | 16:46 |
| lool | ogra: So is there a process for people to create a bootable qemu image from root tarballs? | 16:47 |
| ogra | 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 | 16:47 |
| ogra | i'm actually working on fixes that even remove the persistent rules from udev to make sure there are no HW related bits | 16:48 |
| ogra | lool, well, you know the process ... dd an image together, loop mount and untar | 16:48 |
| lool | ogra: I'm asking where I can point people who want to achieve this | 16:49 |
| lool | ogra: Including the fstab part | 16:49 |
| ogra | feel free to add a rootstock errata page somewhere | 16:49 |
| lool | 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 | 16:49 |
| ogra | mikeul, would you do me a favor ? | 16:50 |
| mikeul | ogra: yes, I owe you one | 16:50 |
| ogra | and mv fstab in your image to fstab.bakl, then touch fstab so you create an empty one and then run qemu with sudo ? | 16:50 |
| ogra | *bak | 16:50 |
| mikeul | btw, I have a console in qemu now. I'm quite happy about that. | 16:51 |
| ogra | you can move it back afterwards if it doesnt work | 16:51 |
| lool | ogra: Were you using an initrd? | 16:53 |
| ogra | lool, never | 16:53 |
| ogra | lool, an i had the same prob the first time when i didnt use sudo because you insisted i wouldnt have to ... | 16:54 |
| ogra | a chmod 766 solved it for me back then | 16:54 |
| lool | ogra: I can reproduce mikeul's problem here without sudo being involved in anyway | 16:54 |
| lool | Just commenting out / from my fstab | 16:54 |
| ogra | and if you use sudo ? | 16:55 |
| lool | It wont change a thing | 16:55 |
| ogra | under karmic ? | 16:55 |
| ogra | i really dont get why it worked for so many people including me all the time | 16:55 |
| lool | Yes | 16:55 |
| lool | Well I have an idea, but I didn't demonstrate it completely | 16:55 |
| lool | It's quite time consuming to find out and I know adding / in fstab is really best | 16:56 |
| ogra | well | 16:56 |
| ogra | can we assume people using --keepimage will never use the filesystem on a real machine ? | 16:56 |
| ogra | 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 | 16:58 |
| mikeul | 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 | 17:09 |
| ogra | ok | 17:09 |
| ogra | thanks | 17:09 |
| ogra | 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 :/ | 17:11 |
| mikeul | 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? | 17:11 |
| ogra | somehow mountall fuzzes around with the fstab entries during boot | 17:12 |
| mikeul | I much appreciate the help. | 17:14 |
| ogra | well, you also helped a lot :) | 17:14 |
| mikeul | I'd like to continue to help, you might not have seen the last of me :) | 17:15 |
| mikeul | lool, you wanted me to summarize suggested changes to RootfsFromScratch? | 17:15 |
| ogra | great ! | 17:15 |
| lool | mikeul: Yes | 17:16 |
| mikeul | Should I e-mail them? Post them here? Bug report somewhere? | 17:16 |
| lool | You could do them in the wiki page, or mention them here | 17:16 |
| ogra | ++ | 17:16 |
| mikeul | OK. That won't be until tomorrow. | 17:18 |
| lool | 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 | 17:18 |
| ogra | ah | 17:18 |
| ogra | hmm, right, when we discussed the sudo stuff first thing i tried was rw on the cmdline ... | 17:19 |
| ogra | only then it struck me that the img was readonly ... i re-used the same qemu command afterwards | 17:19 |
| lool | So I just confirmed that without an fstab and with rw on the cmdline, it boots | 17:19 |
| * ogra hugs lool | 17:20 | |
| ogra | lool, sorry for being such a hard opponent sometimes | 17:20 |
| ogra | i know i annoy you with that | 17:20 |
| lool | It's very energy consuming to fight each and every claim | 17:21 |
| ogra | 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 | 17:21 |
| lool | I still believe people would be better off with a fstab with / on real systems (even virtual) | 17:22 |
| ogra | yes, i'll add the code for --keepimage | 17:22 |
| lool | mikeul: So recipe is vmlinuz from ports + rw and devtmpfs.mount=0 on cmdline | 17:22 |
| ogra | for real systems we can add documantation | 17:22 |
| mikeul | yeah, I just removed the UUID from fstab and booted with rw on the cmdline to test, and it worked. | 17:23 |
| mikeul | How is devtmpfs getting in the way? | 17:24 |
| ogra | udev in karmic didnt know about it, i think it steals /dev, not sure though | 17:24 |
| ogra | devtmpfs is something new that only showed up in 2.6.32 kernels | 17:25 |
| ogra | it pre-populates /dev so udev doesnt need to execute all its scripts to find the devices | 17:26 |
| lool | I filed LP #527216 on the mountall issue | 17:27 |
| ubot4 | 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 | 17:27 |
| * ogra subscribes | 17:27 | |
| ogra | heh, its tagged amd64 :) | 17:27 |
| mikeul | I see. Well, thanks again lool and ogra. I'm signing off. | 17:29 |
| ogra | ciao | 17:30 |
| ogra | oh, finally ! | 17:30 |
| lool | mikeul: devtmpfs doesn't have the /dev/pts dirs etc. | 17:30 |
| ogra | my here document quoting works ! | 17:31 |
| lool | mikeul: lucid's mountall can cope with that, but not karmic's | 17:31 |
| lool | mikeul: You don't need the devtmps arg for a lucid vm | 17:31 |
| ogra | lool, i guess it wont do harm to use it with lucid though, would it ? | 17:36 |
| * ogra thinks about a universal cmd we can put on the wiki | 17:36 | |
| ogra | i think it would just boot a little slower | 17:37 |
| lool | ogra: Yes, I did mean for mikeul to document using "devtmpfs.mount=0 rw" for all dists, not just karmic | 17:39 |
| ogra | right, given that i changed the kernel link on the page i'll do that for now | 17:39 |
| === hrw is now known as hrw|gone | ||
| ogra | http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/80 | 17:58 |
| ogra | lool, ^^^ fyi | 17:58 |
| lool | ogra: Do you want to hardcode ext3? I'd put auto there perhaps | 18:01 |
| ogra | well, we format it ext3 anyway, but yes | 18:01 |
| ogra | changed | 18:02 |
| |nfecteD | does anyone have any idea why my beagleboard doesn't seem to want to use USB devices when running ubuntu arm? | 18:53 |
| |nfecteD | i have a powered USB hub, yes | 18:53 |
| |nfecteD | and USB devices work with angstrom and android | 18:54 |
| |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 | 18:55 |
| |nfecteD | got the same problem with debian too | 18:55 |
| |nfecteD | (not the same kernel) | 18:56 |
| Hoonse | hi guys | 18:59 |
| rcn-ee | |nfecteD, web irc log only goes back to the start of the hour.... did your usb port work? | 19:23 |
| rcn-ee | 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.. | 19:24 |
| |nfecteD | rcn-ee: it works with angstrom and android, yes | 19:32 |
| rcn-ee | |nfecteD, what board (bx/c2-3/c4) ehci/musb? | 19:33 |
| |nfecteD | C4 ehci | 19:35 |
| rcn-ee | okay.. have you touched u-boot at all... (my wiki relies on you leaving it at the factory version..) | 19:36 |
| |nfecteD | i've changed the u-boot, yes | 19:36 |
| rcn-ee | what version? | 19:36 |
| |nfecteD | lesse... | 19:37 |
| rcn-ee | i think 'version' prints it out... (in u-boot) | 19:37 |
| |nfecteD | http://rcn-ee.net/deb/tools/u-boot-beagleboard-2009.08+r37+gitr1590f84007e2b50ad346a482fff89195cb04ff4e-r37.bin | 19:37 |
| |nfecteD | should be that one | 19:37 |
| rcn-ee | that's the problem... | 19:38 |
| |nfecteD | U-Boot 2009.08 (Dec 01 2009 - 05:37:28) | 19:38 |
| |nfecteD | (from beagleboard) | 19:38 |
| rcn-ee | 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... | 19:39 |
| |nfecteD | ah | 19:39 |
| |nfecteD | thanks for clearing that up | 19:39 |
| rcn-ee | no problem... | 19:40 |
| |nfecteD | NEXT QUESTION (hoho) | 19:40 |
| |nfecteD | rootstock... | 19:40 |
| rcn-ee | 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) | 19:40 |
| |nfecteD | I can't get it to enter stage 2 | 19:41 |
| |nfecteD | E: Second stage build in Virtual Machine failed ! | 19:41 |
| |nfecteD | is this because i try to build a lucid image in a karmic ubuntu? | 19:42 |
| rcn-ee | what os/version are you initiating the rootstock call from? | 19:42 |
| |nfecteD | Ubuntu 9.10 | 19:42 |
| |nfecteD | x32 (if it matters) | 19:42 |
| rcn-ee | well the version that came with karmic, doesn't support lucid... you need to tweak the rootstock script.. | 19:42 |
| |nfecteD | got a quick tweak on hand or should i just install lucid on the dev computer? | 19:43 |
| rcn-ee | 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.. | 19:44 |
| Hoonse | can i delete the --serial ttyS2 flag from rootstock AFTER i made the image? | 19:44 |
| rcn-ee | Hoonse, depends, but why did you add the flag? | 19:45 |
| Hoonse | 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 | 19:45 |
| Hoonse | i set the flag by making the rootstock image from ubuntu | 19:45 |
| Hoonse | sudo ./rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --dist lucid \ | 19:45 |
| Hoonse | --script fixup.sh --serial ttyS2 \ | 19:45 |
| rcn-ee | Hoonse, it'll be "/etc/event.d/ttyS2" | 19:45 |
| |nfecteD | rcn-ee: thank you very much | 19:45 |
| |nfecteD | hopefully now i'll be able to help myself for a while | 19:46 |
| Hoonse | thanks i will try this now | 19:46 |
| rcn-ee | Hoonse, just remove that file and it'll never start at boot... | 19:46 |
| Hoonse | k i will try... | 19:46 |
| rcn-ee | |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... | 19:47 |
| |nfecteD | alrighty :) | 19:48 |
| rcn-ee | Hoonse, sorry, that was for Jaunty.. For karmic+ it's "/etc/init/ttyS2" | 19:49 |
| rcn-ee | "/etc/init/ttyS2.conf" | 19:49 |
| Hoonse | remove this? | 19:49 |
| rcn-ee | Yeah, upstart reads that... | 19:50 |
| Hoonse | and the ttyS1 3 4 ...? | 19:50 |
| rcn-ee | --serial only modifies one... the rest are ubuntu default setups... | 19:51 |
| Hoonse | k i am rebooting right now | 19:52 |
| rcn-ee | 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... | 19:52 |
| Hoonse | i did this before on the bootargs and on the ubuntu.cmd file (=boot.scr) | 19:53 |
| Hoonse | i deleted the file but its still there... | 19:54 |
| rcn-ee | Hoonse, by deleting the file, the 'login' part shouldn't show up... eveything else is just kernel message... | 19:54 |
| Hoonse | the problem not the file | 19:54 |
| Hoonse | but the login part still shows up... | 19:54 |
| Hoonse | ohh wait a sevond | 19:56 |
| Hoonse | second | 19:56 |
| Hoonse | there is the ttyS2 file | 19:56 |
| Hoonse | i will delete this... | 19:56 |
| rcn-ee | well that doesn't make sense.. upstart -> "/etc/init/ttyS2.conf" calls "getty" -> prompt.. | 19:56 |
| Hoonse | yes sorry i deleted the tty2 not the ttyS2 file... | 19:57 |
| rcn-ee | oh, easy miss... | 19:57 |
| Hoonse | omg thanks now it works =) call me whenever you are in austria i will buy you a beer =) | 19:58 |
| Hoonse | thanks | 19:58 |
| rcn-ee | 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.. | 19:58 |
| rcn-ee | good to here Hoonse | 19:58 |
| |nfecteD | oh yeah! rootstock entered stage 2 | 20:29 |
| * |nfecteD crosses fingers | 20:29 | |
| armin76 | ogra: lool: NCommander: is dove gigabit eth? | 20:33 |
| NCommander | armin76: it is | 20:34 |
| NCommander | 1000 Mb/s, full duplex, flow control disabled | 20:34 |
| armin76 | oh nice, thanks | 20:34 |
| NCommander | Makes shooting stuff across my LAN so much easier | 20:34 |
| armin76 | NCommander: when i'm getting one? *g* | 20:35 |
| lool | armin76: I think only one port is native though | 20:35 |
| zumbi | armin76: the question is when is dove-next (a comercial laptop) going to be selled out on the market :-) | 20:37 |
| NCommander | armin76: when you sell your soul to Marvell :-) | 20:38 |
| armin76 | NCommander: oh, nice, i can sell it :D | 20:39 |
| |nfecteD | can the GPIO pins in the expansion connector be used to trigger scripts? | 20:40 |
| |nfecteD | when ubuntu is running that is | 20:41 |
| |nfecteD | perhaps i should mention that im talking about the beagleboard :P | 20:44 |
| lool | armin76: You already sold your soul 4 or 5 times | 20:45 |
| lool | armin76: no mode hardware for you now | 20:45 |
| armin76 | i did? :D | 20:46 |
| kblin | rcn-ee: pong | 21:01 |
| kblin | 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. | 21:03 |
| |nfecteD | rcn-ee: looks like rootstock locks up while unpacking the debs in stage 2... any idea what that might be? | 22:18 |
| |nfecteD | Unpacking usbutils (from .../usbutils_0.86-2ubuntu1_armel.deb) ... | 22:18 |
| |nfecteD | thats where it is | 22:18 |
| |nfecteD | and has been for 30 minutes | 22:18 |
| termitor | hello | 22:48 |
| termitor | how to have the same theme on pc ? | 22:49 |
| mygalaxia | hello | 22:50 |
| mygalaxia | or can I find the theme for an arm platform x86 ubuntu thanks you | 22:50 |
| persia | termitor: mygalaxia: The themes are precisely the same as on other architectures. | 22:56 |
| rcn-ee | |nfecteD, can you pastebin your rootstock log? i'll be back in a bit, tweaking a server.. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
