=== JaMa|Theater is now known as JaMa|Zzzz [00:02] Getting better with the --no-root switch, but "No space left on device" : where does the image build process occurs ? I will stretch the mount point [00:02] /tmp ? [00:02] I suspect it is /tmp, but I'm just guessing. [00:03] Maybe check with df just when you fill up the filesystem? [00:03] Ok :) [00:04] Strange, df shows me : sysfs 5160576 3176456 1721976 65% /sys [00:04] No /, /home , /var, .. [00:04] Are you in the chroot? [00:05] I run a debian lenny host, and a maverick chroot. I'm building the .img file from the chroot, to install it on a phone after [00:05] I don't want to install the img in the maverick chroot [00:06] Ah ok, df always show those mount point from inside a chroot, must be normal [00:06] pwork, if your going to run rootstock, i'd either run in on a 10.10 host, or in a armel machine running atleast squeeze.. otherwise you will have qemu issues... [00:06] Right. You need to run df in lenny to find out what is full. [00:06] rcn-ee, Doesn't a lucid host work also? [00:07] the qemu in maverick is much more reliable.. (i can get small xfce images built in maverick that fail n lucid) [00:07] rcn-ee, So I can't build a img from inside a chroot. Will I be able to make it from a maverick live CD if it exists ? [00:08] pwork, i'd use virtual box over a live cd... it's going to eat a lot of ram creating the arm rootfs.. [00:10] rcn-ee, You mean I can run the maverick live cd ISO from Virtualbox running on my lenny's host OS ? [00:10] I can do this [00:11] I'd probably run an *install* of maverick in Virtualbox running on lenny. [00:11] persia, Strange, the host df shows nothing full [00:11] Odd. Something wonky. [00:11] yeah... but i mean create the virtual harddrive and install the iso on lenny in virtual box.. rootstock is going to eat 2gig's of space, so you'd run out of ram in any live cd pretty quick... [00:12] Or use heaps of swap, but allocated storage is usually faster than swap. [00:14] persia, Ok. I have a big swap partition, but on the host OS. I imagine that if it fails with "No space left", swap was filled before filling hard disk space [00:15] I don't know if a chroot benefit from the swap partition. I imagine yes [00:15] chroot relies on the running kerne. [00:16] I'll be back to you if this succeeds in a vbox ran from host ;) [00:16] Thanks for advice [00:16] I'm not convinced that the binfmt-misc/qemu hacks used in rootstock work properly against a Debian kernel, but they may. [00:17] Is a kernel distribution specific ? it's a linux 2.6.32 kernel [00:17] Doesn't sound debian specific :s [00:19] If I do this from vbox, will it uses the virtual OS kernel, or the host one ? [00:19] If I run it from a live CD, I understand memory will be too short, but it will use a ubuntu kernel [00:20] Many folk run kernels with distribution-specific patches added on. Many don't. I have no idea how much of the binfmt-misc stuff is Ubuntu-specific vs. upstream. [00:21] pwork, What we're advising is to create a ~5G virtual disk in VBox, and install Maverick into that from the CD, and then use that VBox environment to run rootstock. [00:21] Once you have an image, you ought be able to scp it back to your host, and then get it to your target. [00:22] Ok, wrote it down :) [00:22] persia, You're my favorite video game ! [00:22] :p [00:23] Tell you tommorow what the result is [00:23] Good night/day === ian_brasil___ is now known as ian_brasil === asac_ is now known as asac [03:38] Say, how "official" is the Ubuntu support for ARM, and how "official" is it for PowerPC? I'd say the ARM support is better than PPC, right? === sumitsemwal is now known as sumits === JaMa|Zzzz is now known as JaMa [09:30] DanaG: They are equivalently official. Right now, powerpc is slightly more completely ported, gets slightly better user support, and is used by more flavours. That said, more individual people are working on armel, so in the future you may be correct. [09:32] persia, well, i'd say one is more official than the other if you look at canonical backed support [09:33] ogra, Does canonical offer commercial support for armel currently? I thought still not. [09:34] But I certainly see much more interest in ARM from Canonical than in PPC. [09:35] persia, not commercial support, but donated developer time [09:35] Indeed, hence "more individual people are working on armel" [09:36] and guaranteed upgrades for 18 months [09:36] in that it doesnt differ from x86 [09:36] at least for main [17:55] hi what is the package name for boot time splash [17:56] plymouth [18:01] ogra_ac, this does moth i mean boot animation and logger ,is there any just usplashy type deb package for armel [18:02] i think there is still usplash in universe and debians splashy [18:06] ogra_ac, i am not sure which is stable and best for ubuntu armel [18:06] which will be good [18:14] plymouth [18:14] thats what we ship by default in the images [18:26] plymouth works sometimes and sometimes not [18:26] we're going to "port" psplash because it is simpler and doesn't require all that fancy stuff [18:26] one day plymouth would be awesome [19:03] Neko, mountall requires plymouth [19:04] yeah it is in the initrd here it just never starts [19:04] you need it in any case ... you dont need to use it as splash though [19:04] i think the framebuffer is basically taking too long to init [19:04] we will keep it there [19:04] then your users will end up with messed up filesystems [19:04] just have psplash [19:04] there is no way I am removing plymouth it's too much hassle [19:04] all user interaction of mountall fsck is done through plymouth [19:05] but while it doesn't DO anything.... we need a splash [19:05] plymouth does work but it never shows anything [19:05] so if you dont have it, your filesystems might corrupt themselves over time since you will never get successfull fscks [19:06] then your kernel is broken [19:06] I know [19:06] we are not dumping it [19:06] we are just remediating the lack of framebuffer activity [19:06] make sure fbcon is running and all your frambuffer drivers are loaded early enough [19:06] it DOES do that "press C to continue or S to recover" stuff but over serial terminal [19:07] framebuffer is built-in and fbcon is built-in [19:07] ah [19:07] well, then your kernel cmdline is messed up [19:07] root=/dev/mmcblk0p2 quiet splash [19:07] ? [19:07] dont put serial stuff on it [19:07] oh the serial stuff [19:07] hmm okay [19:07] noted. [19:08] if users really need that they are surely clever enough to edit the bootloader options in a serial terminal [19:08] you think this is why plymouth doesn't start? [19:08] i know thats the reason why plymouth doesnt start :) [19:08] console is not a framebuffer at the point it loads, therefore? [19:08] :D [19:08] you're amazing [19:08] it worked [19:08] :D [19:08] thats the reason why the ubuntu images dont have serial consoles enabled by default [19:08] let's try it 100 more times and make sure [19:09] * ogra_ac wishes he could use an ubuntu initrd with plymouth on his ac100 here [19:10] silly fastboot hardcodes the partitioning scheme ... boot partition is 8M big ... no space for an initrd [19:10] the question is really then... where does plymouth detect console and would it be better for it to look more aggressively for a non-serial console [19:11] it looks at the kernel cmdline [19:11] so console=ttymxc0,115200,8n1 console=tty1 [19:11] as soon as it detects console=tty[A-Z] it drops out of the splash [19:11] yerg [19:11] but there are two [19:11] doesnt matter [19:11] there is one of them serial [19:11] it recognizes that [19:13] there is a longstanding LP bug and an upstream bug about that [19:13] excellent [19:13] no solution though [19:13] something to read though isn't it [19:13] maybe we will fix it [19:14] heh, enjoy ;) [19:14] happy upstream discussing [19:17] forget discussion [19:18] why don't we just fix it and push a patch [19:18] they can discuss it all they like once we've shipped it [19:18] sure, but it wont be accepted [19:18] that is their mistake :D [19:18] since upstream opinion is that if you use a serial console you definitely dont want a splash [19:19] bah, splashes [19:21] upstream is amd64, real life is embedded systems where when the thing locks up you need serial :D [19:21] huh ? [19:21] if you don't watch splash and you have serial... why not add "nosplash" [19:21] you only need serail for bootloaders [19:22] and accessing terminals when your USB fails [19:22] or network is down for some reason [19:22] after the kernel is up there is no difference in architectures [19:22] there are plenty of rescue scenario :D [19:23] i agree that as developer you might want serial, for endusers its the most useless thing ever [19:23] here's another [19:23] you have Xen. You have it virtualized as a desktop. But Xen wants to have a serial terminal too for early boot messages... [19:23] (or would your motrher use a seria console to tinker with her laptop) [19:23] I want to see a splash over my RDP [19:23] *mother [19:23] no but Raquel and Bill might [19:24] why ? [19:24] they only do twitter and facebook [19:24] they are not low level devs but they are interested and I got like 5 calls this morning about poking around in terminals [19:24] any company with MBWA attitude :] [19:25] serial is a wart ... it shoud go away imho [19:25] I would rather something like Android Debug stuff got standardized [19:25] good if you have unstable kernels you develop, but thats about it [19:25] plug a USB cable in and hooray [19:25] nah [19:26] have framebuffer and input support in your bootloader ... [19:26] we do :) [19:26] but we're shipping U-Boot which sucks. [19:26] so i can reach the u-boot console without using a second computer ? [19:26] no not at all. [19:27] hi Martyn :) [19:27] see [19:27] thats what i mean [19:27] "our" bootloader is not U-Boot though. we just don't ship it yet. [19:27] MX53 is the target [19:27] hey there armin [19:27] * Martyn is in the last stages of packing for UDS [19:27] well, does your redboot give me that ? [19:27] did you ever see Pegasos? it was PPC and had an OpenFirmware, grab any PC PCI or AGP graphics card, get a framebuffer [19:27] USB input [19:27] They stuck the ARM LAMP optimization talk on Monday, damnit! [19:27] play midi tunes.. [19:28] boot from ATA, USB.. [19:28] or TFTP over network. it's nice. but the new technology is not ready yet :D [19:28] moving away from ppc gave us the chance to throw most of it away and do it properly [19:28] (with a view on virtualization and so) [19:31] ogra : When are you arriving in Orlando? [19:32] tomorrow evening [19:32] Okay, about the same time then.. Rob, Bob and I get in ~6:30pm [19:33] same for me [19:33] hmm anyone in Linaro here? [19:33] We're coming in via JetBlue .. share a cab? [19:33] i think we are already four [19:33] 'kay [19:33] Neko, go to #linaro [19:33] I am in there [19:34] right, they are likely all in the air [19:34] or preparing for traveling or just arriving [19:34] bad time ... [19:34] I will get Konstantinos to bring it upo [21:19] ogra_ac, around ??