[00:40] <sadmac> Keybuk: could you explain how TEST_ALLOC_FAIL is supposed to work?
[00:51] <sadmac> never mind
[11:19] <ion_> Offtopic, but anyhoo: i wrote a jQuery plugin: http://johan.kiviniemi.name/blag/extservice-jquery-plugin/


[03:05] <MrCurious> 3 minutes and i can take another try at making a bootable ubuntu stick
[07:44] <kapinter> Hi! Is there a way to start ubuntu-arm on pandabox with console login? Without gui?
[09:00] <doko> is janimo online today?
[09:15] <Captain386> So, I had a question regarding an ubuntu install that I was doing on a beagleboard. I followed the instructions posted here: https://wiki.ubuntu.com/ARM/OmapNetbook and successfully installed the OS on my beagle. The problem is, I can't log in. It goes straight to a login screen without setting up any user info. If someone could provide an explanation/help I would greatly appreciate it.
[10:46] <plasmasolutions> Hi guys...I'm on a beagleboard-xm with my beloved ubuntu but can't manage to get the gles2 SGX demos to run properly...has anyone a hint in which direction I should have a look?
[10:47] <plasmasolutions> the gles1 demos are running without a problem
[11:02] <plasmasolutions> anyone?
[11:06] <ogra_> infinity, why are you still awake ?
[11:12] <plasmasolutions> I just solved it ... was using the wrong drivers 2.0 in contrast to 5.0...so solved
[12:12] <olive> hello
[12:13] <olive> what's the correct way to build omap4 ubuntu kernel ?
[12:13] <olive> I used this : http://seabright.co.nz/2011/03/29/building-the-ubuntu-pandaboard-kernel/
[12:13] <olive> but, how to install the kernel ?
[12:14] <olive> seems have to copy some files (uImage, zImage ?) in /boot, right ?
[12:17] <ogra_> well, you surely also want the modules
[12:17] <olive> oh. yes :)
[12:17] <ogra_> and you need to create an initrd
[12:17] <ogra_> for which you need to boot the panda
[12:18] <olive> yeah. do you have a link to help me ?
[12:18] <ogra_> just copy the files in place, boot the board with an existing kernel and run update-initramf for the kernel version
[12:19] <ogra_> *update-initramfs
[12:19] <olive> update-initramfs needs arguments ?
[12:20] <ogra_> yes, see the manpage
[12:21] <olive> update-initramfs -c -k the_name_of_my_kernel ?
[12:21] <olive> in previous example, seems to be "uImage", right ?
[12:21] <ogra_> copy zImage into /boot (as vmlinuz-${your version}, copy uImage into the vfat partition, then roll a tarball with the cross built modules and copy that into the rootfs
[12:22] <olive> I'll try
[12:22] <ogra_> then you boot and run: sudo update-initramfs -c -k ${your kernel version} && sudo flash-kernel
[12:23] <olive> okay! thanks. :)
[12:25] <ogra_> btw, there should be howtos about cross building a package instead of doing a raw build, that would make your life easier (you would just need to dpkg -i it)
[12:48] <olive> ogra_: oh wait, my kernel _is_ cross builded
[12:49] <olive> built* (sorry, don't speak english very well :/)
[14:44] <infinity> ogra_: What made you think I was awake? :P
[15:36] <ogra_> infinity, dircproxy messing up logging i think
[15:42] <infinity> ogra_: Fair enough. :)
[15:44] <ogra_> infinity, so i was a) wondering wheer to put my code in live-build and b) how to use a chrooted command, nothing in live-build/auto/build does that and i wonder why
[15:45] <ogra_> is the chroot around until live-build/auto/clean is called or is it wiped earlier already ?
[15:46] <infinity> ogra_: It's around until it's cleaned, which is pretty much "forever" from the POV of auto/build.
[15:47] <ogra_> so everything i put below the tarring in live-build/auto/build will be in the chroot but not affect the tarball content, right ?
[15:47] <infinity> Right.
[15:47] <infinity> It's actually even more vile than that, the chroot exists twice.
[15:48] <ogra_> well, i need the one that has /dev, /proc and /sys
[15:48] <infinity> chroot/* is the one installed to, then it's copied to binary/boot/filesystem.dir, and tarred from there.
[15:48] <ogra_> i dont think both have that mounted
[15:48] <infinity> Neither will have that mounted by the time the tarball is created.  Hrm.  Fair point.
[15:49] <ogra_> i need to update the initrd so i will need that
[15:49] <ogra_> but i can do that from my code if needed
[15:50] <infinity> Yeah, I'm looking to see if there's a "right way" we can do it that doesn't reinvent wheels.
[15:50] <ogra_> there is likely an lb command
[15:51] <ogra_> but with that quality of documentation nobody can expect we use it :P
[15:51] <infinity> You'd think.  Looks like it's broken into several.
[15:55] <infinity> I'm not convinced that we ever have a fully-populated /dev, BTW.
[15:56] <ogra_> well, i'm not sure what update-initramfs needs actually, but i think /dev needs to be popuzlated a bit at least
[15:57] <ogra_> doesnt lb have an initrd command that cares for all that ?
[15:57] <ogra_> one would think such a thing should exist :)
[15:57] <infinity> But "lb chroot_devpts install ${*}" and "lb chroot_proc install ${*}" and "lb chroot_sysfs install ${*}" should get you dev/pts proc and sys.
[15:57] <ogra_> heh, great, thats not much different to a mount line for each
[15:58] <ogra_> and i bet i need an lb unmount command too for each :P
[15:58] <infinity> Not really, no. :P
[15:58] <infinity> Clean kills them all, but you could use a remove line explicitely too.
[15:58] <ogra_> heh
[15:58] <ogra_> so i guess by looking at the other code i want:
[15:59] <ogra_> Chroot chroot blah ....
[15:59] <ogra_> to exec my commands
[15:59] <infinity> Unfortunately, it looks like the update-initamfs stuff isn't abstracted out, and just happens in chroot_hacks. :/
[15:59] <ogra_> fun
[16:00] <infinity> But again, it's just one command.
[16:00] <ogra_> the more i hack on live-build the less i like it
[16:00] <ogra_> its not like it improves *anything*
[16:00] <ogra_> beyond being maintained in debian
[16:01] <infinity> Part of that is our fault for being too slow to release livecd-rootfs.  I tried. :/
[16:01] <infinity> But by the time we got it released as free software, this other project was well underway.
[16:02] <ogra_> well, i was pointed to http://people.debian.org/~jak/mkrootfs-doc.pdf today
[16:02] <ogra_> looks like a saner approach than live-build
[16:17] <infinity> ogra_: Oh, and I found out why my ac100 was sad.
[16:17] <infinity> ogra_: The total abootimg size was definitely larger than the 8M partition allotted for it.
[16:18] <infinity> ogra_: flash-kernel probably needs a sanity check of target_partition versus image before it just mindlessly tries to dd 11MB to an 8MB partition. :/
[16:19] <infinity> (And this is going to be a recurring problem... Those image files will be large)
[16:19] <infinity> I only got mine down by switching to MODULES=dep in initramfs.conf... Which will only help for a while until that becomes too big too.
[16:26] <ogra_> infinity, no problem since the installer creates a proper bootimg.cfg that definaes the max size
[16:26] <ogra_> seems yours didnt have that
[16:27] <ogra_> infinity, MODULES=dep is set by the installer too
[16:28] <infinity> Ahh, I guess I need to fix my bootimg.  I just used one you gave me. :P
[16:28] <infinity> bootimg.cfg, even.
[16:28] <ogra_> well, i likely gave you one i use
[16:28] <ogra_> which definitely defines 8M as max size
[16:28] <infinity> Well, then it doesn't work as expected. :P
[16:28] <ogra_> bootsize = 0x800000
[16:28] <infinity> Cause it happily creates an unbootable system instead of erroring out or something.
[16:29] <ogra_> weird, it should definitely error
[16:29] <ogra_> iirc there is also a check_size call in flash-kernel that actually double checks
[16:30] <infinity> Weird.
[16:30] <infinity> I'll have to look at that later.
[16:30] <infinity> My tuits aren't particularly round right now.
[16:30] <ogra_>                                 abootimg --create $TMPIMAGE -f /boot/bootimg.cfg -k $kfile \
[16:30] <ogra_>                                         -r $ifile >/dev/null 2>&1 || return 1
[16:30] <ogra_>                                 imagesize=$(wc -c "$TMPIMAGE" | awk '{print $1}')
[16:30] <ogra_>                                 check_size "Bootimage" $imagesize $AC_SIZE
[16:31] <ogra_> AC_SIZE is defined as: $(abootimg -i $dev |grep "image size"|cut -d ' ' -f5)
[16:32] <ogra_> which is quite ugly
[16:33] <infinity> Well, now that I know it's *supposed* to work, I'll look into it a bit later and see why mine appears not to.
[16:33] <ogra_> probably the abootimg output changed
[16:34] <infinity> I still think that, even if it DTRT, it'll blow up "soon" when kernel+MODULES=dep ends up over 8M. :P
[16:34] <ogra_> well, i cant do much more than MODULES=dep adn diverting plymouth
[16:34] <infinity> We need to shove a chainloader in that 8M partition and jump to our real kernel.  grub on ac100, plox.
[16:34] <ogra_> which should get you an initrd below 2M
[16:35] <ogra_> i wrote all that already ... using kexecf
[16:35] <ogra_> as initrd shellscript menu ...
[16:35] <ogra_> NCommander, picked that up and created mukluk from that idea
[16:35] <ogra_> but the unstable state of kexec made us never use it
[16:35]  * NCommander runs and hides
[16:36] <ogra_> and controversial discussions sbout grub or UEFI etc
[16:36] <ogra_> *about
[16:36]  * infinity nods.
[16:36] <infinity> I was being partially facetious.  I see little point in retrofitting fancy boot loading options for an EOL product.
[16:37] <ogra_> hmm, so why are my mouse clicks not recognized anymore and why does my unity launcher hang around in front of all windows
[16:37]  * ogra_ cant change channels in xchat
[16:37] <infinity> Because you haven't switched to Xubuntu yet.
[16:37] <ogra_> lol
[16:37] <ogra_> ni, i'm unity-2d fan
[16:38] <ogra_> s/ni/no
[16:38] <ogra_> and xubuntu would have that prob too i guess, i think its metacity acting up
[16:38] <infinity> I use unity on my netbooks, but I have fundamental disagreements with it on my hi-res 4x3 laptop screen.
[16:38] <infinity> xubuntu doesn't use metacity...
[16:39] <ogra_> ah, indeed, there is that xfce WM
[16:39] <infinity> Took me less than half an hour to make my xfce look shockingly identical to my old GNOME2 setup, so I'm happy.
[16:40] <ogra_> aha, it was the panel ...
[16:40] <infinity> Anyhow.  Less idle chatter, more working.
[16:40] <ogra_> i guess i should update ... i'm on pre-A3 ...
[16:43] <infinity> Maybe I need bacon, then more work.
[18:25] <RoAkSoAx> howdy guys
[18:25] <RoAkSoAx> I'm trying to get a pandaboard
[18:25] <RoAkSoAx> to netboot
[18:25] <RoAkSoAx> however, it seems that it doesn't even turn on
[18:25] <RoAkSoAx> or something
[18:26] <RoAkSoAx> as I can't see any output connected though minicom
[18:39] <renswind> dose some one have problem with installing the img file of ubuntu on the panda? my is installing but when the installation is finished and want to reboot it just loop the installation on it again,,, im using Natty Narwhal 11.04 img to install it...
[19:04] <armin76> RoAkSoAx: guess you don't mean you're trying to boot it without an sd card :)
[19:07] <RoAkSoAx> armin76: lol of course not
[19:07] <RoAkSoAx> armin76: but I got further this time, still no minicom output though
[19:07] <RoAkSoAx> armin76: but at least I know the swtich detects a link with the connected network cable
[22:13] <Captain386> Does anyone know the username and password to login when using the natty image?
[23:03] <rsalveti> RoAkSoAx: were you able to at least see the x-loader/u-boot messages?
[23:04] <rsalveti> RoAkSoAx: otherwise could be the wrong first partition format
[23:04] <rsalveti> RoAkSoAx: if you want to test your pandaboard I'd suggest you the latest linaro nano image: https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation
[23:05] <rsalveti> grab the lt-panda hwpack and the nano image
[23:05] <rsalveti> that should be enough for you to test the board, have proper console output and such
[23:06] <rsalveti> http://releases.linaro.org/platform/linaro-n/nano/11.07/
[23:12] <RoAkSoAx> rsalveti: yes I was, It seems it was due to the partitoins
[23:12] <RoAkSoAx> rsalveti: but managed to get the SD card partitioned correctly
[23:12] <rsalveti> RoAkSoAx: cool, great
[23:12] <RoAkSoAx> ;)