=== ojn is now known as facilities === facilities is now known as ojn === _MrCurious is now known as MrCurious_ === Lopi is now known as Lopi|idle [02:10] Dr_Who: infinity, ogra_ and janimo can also help reviewing and sponsoring libjpeg-turbo if needed [02:11] rsalveti: good idea! [02:11] the FFe is mostly accepted already, as we got an ack from both skaet and slangasek at latest release meeting === Lopi|idle is now known as Lopi [04:53] wired internet its only letting me use wireless and when i go into a terminal and type in a command my eth0 does not show up [04:54] what can i type in my terminal to see if my ethernet port is working [04:55] what can i type in my terminal to see if my ethernet port is working === suihkulo1ki is now known as suihkulokki === chrisccoulson_ is now known as chrisccoulson === Quintasan_ is now known as Quintasan [12:55] GrueMaster: since you do a lot of testing, have you ever tried unplugging the sd card after boot? (of course when it's not mounted) [12:55] GrueMaster: or have you tried booting entirely off some other media, and when the system is up, have you tried inserting the sd card? [12:56] he did some stuff with that on netinstalls iirc [12:56] ok [12:56] and had funny results [12:56] same here [12:56] hrw opened a bug about sd being inacceisble if he removes/reinsert the sd card [12:56] well, wait until janimo's drop of the vfat mangling show up in the images [12:56] no no [12:56] though wait, you dont use preinstalled, right ? [12:57] i use preinstalled [12:57] how can you unplug the rootfs then ? [12:57] sheer force [12:57] yeah [12:57] or abuse of the images ! [12:57] becasue i moved averyrthing to usb [12:57] he doesnt use them in their intended environment ! [12:57] evil guy you :) [12:57] i use the sd card just for uImage&c [12:58] :) [12:58] well [12:58] i would recommend using a netinst for such setups [12:58] while it should indeed work to copy the rootfs to another device you never know what mistakes you make doing that [12:58] but i just found out, that if i boot from another media (no sd card inserted during boot) [12:58] the sd slot is dead! [12:58] complain to u-boot or x-loader i guess :) [12:58] it doesn't recognize any sd insert&c [12:59] uhm [12:59] smells very much like either of them [12:59] that's why i asked GrueMaster, i have to try with some older release [12:59] did you try with an older u-boot and x-loader ? [12:59] and on xm now [12:59] nope [12:59] just oneiric/panda for now [12:59] i bet a beer that it works fine with nattys [12:59] i already own you a beer BTW :) [13:00] you can win it back now ;) [13:00] asd :) [13:00] ok [13:00] *g* [13:00] coffee and then back testing older releases... [13:21] ogra_: its not uboot/xloader - kernel rather [13:21] system booted, replace card = bug [13:22] hrw, i think tobin said he doesnt see it when rolling back to an older MLO/u-boot binary [13:22] hrw: have you tried the same with beagle? [13:22] load kernel/initrd in uboot, 'bootm', replace card - bug [13:22] ppisati: would have to dig out old C3 beagle [13:22] hrw: no prob, i'll do that [13:22] hrw: another thing that i discovered is that: [13:23] 1) if you boot from another media (load everything in memory, remove sd card and bootm) [13:23] if you tru later to insert the sd card, the kernel doesn;'t recognize it [13:23] 2) enabling MMC_DEBUG i see what it seems "activity" on mmc [13:23] even when it's not mounted [13:23] i wonder if it's polling [13:23] the slot for some reason [13:23] * ogra_ thinks the kgeneral bug is that the kernel leaves to much initialization to x-loader [13:25] we ran into bad stuff using a different x-loader through that (the usbboot one) ... you cant use our kernel *at all* if you dont use MLO/u-boot (doesnt work with generic android bootimages for example because the majority of devices stays unintialized) [13:25] same would go for kexec [13:26] (using a binary kernel instead of u-boot.bin) === Jack87|Away is now known as Jack87 [13:57] ogra_, you were right, it is lz compressed. It worked for me before as I figured it out after much trial. But I forgot since :( [13:58] anyway, going forward [13:58] )win 21 [13:58] yeah, i remember banging my head against the same issue a while ago [13:58] I want every boring task on Earth be done by machines [13:58] which is most of them [13:59] heh [14:11] hello [15:16] ogra_, infinity, slangasek : would any of you be will to participate in the review of : http://revu.ubuntuwire.com/p/libjpeg-turbo ? Aiming for oneiric, universe, thanks! [15:28] hrw: it works on xm! === mayday_jay is now known as mayday_jay-work [15:28] cool [15:28] but I ahve pandas [15:29] :) [15:31] I just got my pandaboard booting [15:31] the 11.04 release wouldn't boot properly for me [15:50] ppisati: I see you are looking at the SD bug I mentioned a while back. Bug 844099 [15:50] Launchpad bug 844099 in linux-meta-ti-omap4 "System fails to acknowledge changing of SD when rootfs is on a different device." [Undecided,New] https://launchpad.net/bugs/844099 [15:55] ogra_: Reading the backscroll, what are you talking about on the usbboot not working? It works fine since rsalveti updated the aboot bootloader. [16:05] GrueMaster: never seen that bug, i was working on hrw bug (that is a duplicate of yours actually) [16:08] the world needs more arm [16:10] is the natty process the update manager? [16:11] brandini: ??? That last sentence made no sense. [16:23] GrueMaster: what is the natty process? [16:24] in what? [16:25] you mean update? [16:25] brandini: What exactly are you trying to do? [16:29] GrueMaster, i was referring to the need to fix it ... [16:30] ogra_: Fix what? It is already fixed. [16:30] pointing out that way to many things are in the bootloader while they should rather (or additionally) be initialized in the kernel [16:30] Oh. [16:30] yes, i wasnt referring to the fix/bug at all [16:31] just to the fact that it actually needed to happen [16:32] for example theoretically it should be possible to add a hex header to a vmlinuz that can do kexec and use that instead of u-boot/MLO to chainload a kernel [16:32] but with the existing design that will never be possible without at least involving MLO [16:33] (though i suspect many things u-boot initializes wont be done by the kernel either) [16:34] sigh, the images are still building [16:34] over 4h already [16:34] afaik, MLO/aboot just initiallizes the main memory and a few minor other bits (i2c bus). u-boot/kernel does the bulk. [16:35] well, wasnt the fix in the MLO code of aboot ? [16:35] now that didnt make sense [16:35] well, wasnt the fix in aboot ? [16:35] that is better :P [16:35] But I also thought u-boot turns off everything it needs just before context switch to kernel. [16:35] i dont think it does [16:36] The fix was in aboot to initialize i2c iirc. [16:36] yeah [16:43] GrueMaster: I'm doing an update to 11.04 using the update manager (which was a silly mistake) and I'm watching the process headless from remote trying to monitor when it finishes [16:44] Ah. I usually just run "sudo apt-get update;sudo apt-get dist-upgrade" to pull the updates. [16:44] dist upgrade on SD card on an XM ? [16:44] SD Card :( [16:44] oh, not a release->release one [16:44] Doing a full dist upgrade (Maverick->Natty) is a lesson in patience. [16:44] I'm stopping by microcenter on the way home to pick up a usb->mSata adapter [16:45] GrueMaster: it is :) [16:45] i thought you upgrade to oneiric, that would indeed be a waste of time [16:45] really? [16:45] yeah [16:45] 10.10 is better than 11.04? [16:45] shoot :) [16:45] No, doing a release upgrade is a waste of time. Faster to download a new image. [16:46] yeah [16:46] ok, that makes more sense [16:46] Doing an in-release update is however a good idea. Just time consuming. [16:46] do I have to do anything special to make the pandaboard boot off a usb device? [16:46] in-release is fine you just shouldnt try to do something else as well on the system :) [16:47] heh, yeah :) [16:47] the load is like 4 [16:47] on the ac100 i actually dedicate time to it when i dont work [16:47] If you want to use your existing image, you will need to do it on a different system. What I found works best is to attach both USB & SD to your desktop (not mounted) and use gparted to copy the rootfs partition. [16:48] Then you need to change the uuid of the rootfs partition on the SD and just reboot. [16:48] The panda will need the SD for boot partition. [16:49] ok, that makes perfect sense [16:49] why wouldnt you just copy qemu-system-statci, chroot and do the dist upgrade that way ? [16:49] oh, you meant copying the rootfs [16:49] You can also try our netinstall for oneiric. It will allow you to install to the usb drive directly with different filesystems (EXT4, btrfs, etc), use LVM, cryptfs, etc. [16:49] ogra_: this is my first time goofing with these types of boards... so beginners luck? [16:50] The gparted copy method is what I used to create a USB drive with Maverick, Natty, and Oneiric all on one USB drive. Makes SRU testing much easier. [16:51] I thought this would be a great platform to serve some web stuff up for monitoring and managing my solar/wind power stuff [16:51] Now that sounds like a fun idea. [16:51] it is [16:52] brandini, http://www.grawert.net:81/ [16:52] ;) [16:52] Not sure how well everything for that will run under Natty. I only did extensive server testing in Oneiric. [16:52] I've got the web application built in go (#golang) and it serves things up really nicely [16:52] though thats runing on an x86 celeron [16:52] (simply because i had no beagle back then) [16:52] hey, that's got solar/thermal :) [16:53] how hot do your panels get when you're running water behind them? [16:53] oh, it says right on it [16:53] * ogra_ has a web based room heating control system too, that actually runs off a beagle C4 [16:54] That's exactly what I'm fleshing out! [16:54] * brandini introduces himself to ogra_ [16:54] well, the panel bursted, i havent gotten a replacement yet (condesed water froze inside and blew up one element) [16:54] it can get up to 130°C [16:54] sheesh [16:54] using copper? [16:54] the panels are supposed to survive up to 220 [16:55] efficiency drops quickly === zyga is now known as zyga-afk [16:56] yeah, to be honest i would rather have half of the collector replaced by power generating panels [16:57] I just built a single wind generator using some PVC Pipe and I'm quite pleased with it [16:57] 3 19" blades and a 30V DC motor... really works nice [16:58] cool [16:58] where you from ogra_? [16:58] germany [16:59] I'm from the states in ohio [17:11] hey hey [17:11] :) [17:11] GrueMaster, maybe we need an alarm, loud and red and blinking [17:11] soo ...binary packages often have arch: any and arch: all components [17:11] ogra_, right [17:11] the any components usually get built nativelyy [17:12] the all components all get built by the x86 builder [17:12] now the x86 builders are waaaay faster than the armel ones [17:12] right [17:12] so rthey finish the package early ... and publish their stuff [17:13] arm simply doesnt have the new bits yet ... but the existing package has a versioned dep on the arch:all package (which was just updated by x86) [17:13] so you get uninstallable packages until armel has built [17:13] this is messy... [17:13] which in some cases can take a day more [17:13] but I got it now [17:13] right [17:14] and that prevents images from building [17:14] there are two ways around it ... [17:14] but you said there are no images since Aug 30th [17:14] fix soyuz to handle the packages right [17:14] or work around the whole issue by running a separate mirror (like linaro does) [17:14] we aim for the fix [17:15] ogra_, is there a bug for that? because if that's causing lack of images like this, it's kind of critical [17:15] and you might want to talk to the launchpad stakeholder in Ubuntu to have it fixed [17:15] i think there is a bug (NCommander should remember the number, i'm not subscribed so i dont have bugmail for it) [17:16] and its known since quite a while ... even in higher levels ;) [17:17] Ursinha, its been raised. https://bugs.launchpad.net/launchpad/+bug/34086 [17:17] Ubuntu bug 34086 in launchpad "removal of arch-all packages while there are arch-specific packages dependent on it results in uninstallable binaries" [Critical,Triaged] [17:17] Wow, that is very old. [17:17] indeed [17:18] but awesome that's already escalated :) [17:20] after... 5 years [17:21] rsalveti, better late than even later [17:21] :) [17:22] well, its a heavyweight ... pushing it uphill needs many people apparently :) [17:22] sure, just surprised it took so long [17:22] took 5 years to get the crowd together ;) [17:22] ogra_, hehe, it's escalated, and people are apparently wrapping up the derived distros feature (which took some time to get completed) [17:23] rsalveti, launchpad touches lots of aspects of ubuntu, it's hard to fix everything relevant in a reasonable time, I believe [17:24] yup, probably [17:24] but I also want the derived distro working properly ;-) [17:24] that reminds me I need to ping some folks at launchpad [17:27] GrueMaster, janimo, does mx5 need flash-kernel.conf ? [17:28] * Ursinha adds #ubuntu-arm to the list of channels-to-lurk-in [17:28] Aha. That's the problem. On mx5, boot.scr, and uI* is on the second partition. [17:29] yeah, that shoudl get a flash-kernel.conf then :) [17:29] so you can set it [17:30] but i wonder if the code uses it yet [17:30] Trying to run it after manually fixing flash-kernel.conf. [17:30] We'll see if oem-config still crashes. [17:30] yeah, that should tell === zyga-afk is now known as zyga [17:49] GrueMaster, I am working on that now [17:49] cool [17:50] ogra_, uboot is not on the vfat partition but kernel and initrd are so presumably needs some flash-kernel.conf [17:50] yeah [17:51] I wonder why resizing rootfs on mx5 is done in a blink [17:51] IIRc on omap it had a progess bar and took a while [17:52] and it didnt fail ? [17:52] maybe it doesn ot happen for some reason - bug to be hunted [17:52] ogra no error msg, just Done [17:52] It may not be resizing the correct partition. [17:52] It is suspicious probably does not happen [17:52] and your partition has the expected size ? [17:52] GrueMaster, ++ [17:52] will check after [17:53] still I;d expect e2fsresize to complain if you ask it to resize a vfat [17:53] GrueMaster, i bet i added a variable for that too ;) [17:53] janimo: Small card? [17:53] infinity, default mx5 [17:53] janimo: On my 1GB card, resize on my Panda is literally instant. [17:53] janimo, well, it would, in the jasper log [17:53] That was changed as part of the ext4 change. [17:53] resize is supposed to happen from 2g to 4g [17:54] init: mounted-proc main process (385) terminated with status 1 [17:54] mountall: Event failed [17:54] I wish I knew why these happen [17:54] no plymouth i guess [17:54] for the mountall bit [17:54] no idea about the upstart one [17:54] ogra_, when is the next round of respins? [17:55] and only for mx5 for now is omap done for b2 ? [17:55] janimo, well, if you ask GrueMaster i guess he doesnt want one :) [17:55] great, I agree [17:55] janimo, thats not how it works [17:55] if you upload jasper we need to re-test all jasper using images [17:55] at least up to the jasper part [17:56] yep. [17:56] ok, there is a new jasper needed for mx5 of course [17:56] we dont cherry pick arches for builds during milestones [17:56] yes [17:56] * ogra_ wasnt expecting todays images to be final actually [17:56] Although I am still pulling, so if a respin is required I am ok. [17:57] we also need to fix the missing slideshow still [17:57] post beta though [17:57] and the missing ti icon [17:57] ogra_, when are the jasper hooks executed? [17:57] for the mlabel copying [17:57] Do we have packages for the ti icon to install? [17:57] one in local-premount, one in local-bottom [17:58] GrueMaster, no, its a jasper thing, but the handling of the favorites completely changed, so it doesnt show anymore [17:58] GrueMaster, iirc persia had the bug assigned to move that into packages [17:59] I meant when you click on the icon, is there packages in the ppa? [17:59] it is there, you just dont see it :) [17:59] and no, there is no package atm [17:59] i'll add that by release time (if TI doesnt) [18:00] Yea! Fixing /etc/flash-kernel.conf fixed the oem-config crash. [18:00] awesome ! [18:00] And I have unity. [18:00] wow [18:00] This is on yesterday's image though. [18:00] Well, unity-2d. [18:01] And the install icon is still there. sigh. [18:02] ubiquity ? [18:02] well, oem-config didnt finish [18:03] did you actually see it removing packages ? [18:04] I wasn't paying attention. Too many monitors to see all the details on all systems. But I have seen this before. [18:05] interesting. When ubuntu-bug pops up to report a detected crash, it blanks the screen and asks for sudo access. [18:05] bug in gksudo i think [18:05] thats supposed to be transparent [18:05] (teh black bg you see) [18:06] poke mvo about it, i did it several times, he said he doesnt need a bug, it would go away anyway [18:06] if it didnt go away yet, he might want to know about it :) [18:09] It appears that the resize worked, but the system thinks the image is using 3.92G on my 4G SD. Will try again with a 16G SD later today. [18:09] weird [18:10] well ... [18:10] * ogra_ is off to find some dinner [18:10] Does it think there's free space anywhere? [18:10] Cause 4G cards aren't 4G... [18:14] No, it is a resize issue. du-sh / says it is only using 1.4G [18:16] df -h shows / as 1.5G with 1.4G used. Gparted shows mmcblk0p3 as 3.95G [18:17] jasper.log ? [18:17] n/a [18:19] Found it in /run. Tried to resize mmcblk0p2. Fail. [18:19] no further info ? [18:19] Right, because that partition number is hardcoded in jasper. [18:20] Of course, this is yesterday's image. Prior to jasper fix for ext4. [18:20] And p3 is the one you're using. [18:21] its not hardcoded [18:21] i wish i could have hardcoded it ... but certain people at linaro wanted to use jasper, so it has that weird detectuion code that parses root= for finding the disk [18:21] ROOTPART="${ROOTDEV}2" [18:21] ^-- That's not hardcoded? [18:22] hmm, that should be dreived from $DISK [18:23] ROOTDEV="/dev/${DISK}${SEP}" [18:23] and it is [18:23] Dude. [18:23] The 2. [18:24] The partition NUMBER is what's hadcoded. [18:24] hard* [18:24] yeah, sorry [18:24] And mx5 is using a different layout. [18:24] Kinda indicates structured fail. [18:24] Or, so I understand. [18:24] yeah, thats definitely a bug [18:24] the code should just parse root= [18:25] mx5 uses a non-fs part1 for u-boot, fat for part2 (kernel, initrd), and rootfs on part 3. [18:25] right === Ursinha is now known as Ursinha-lunch [18:25] but that doesnt need to be hardcoded at all given we set root= at image build time [18:25] Ironically, if there's a UUID in play, things work correctly later... [18:25] yes [18:25] But only partially correctly. [18:26] So, yeah, that whole mess needs a bit of a clean up. [18:26] a bit ? [18:26] I should have looked closer where I was in there for the FSTYPE thing. :/ [18:26] :) [18:26] it needs a rewrite [18:26] thats why we had discussions about it in dublin [18:29] This is where my comment on us getting bogged down in last weeks meeting applies. [18:29] yup [18:30] Well, I could fix most of this root-finding mess in jasper right now, but the diff might be a bit unpleasant for a freeze. [18:30] Not faulting anyone, just that we get tied up with long, difficult tasks, and the simple stuff falls through the cracks. [18:30] infinity, do it post beta [18:31] ogra_: Sure, this just means mx5 gets to be broken for beta. *shrug* [18:31] jasper is initial prototype code that happened to work right ... it was never intended to stay in production in that state for that long [18:31] infinity, just add a three liner that checks /proc/cpuinfo and resets the partition number then [18:32] another hack for a few days wont harm us ;) [18:32] Ew. [18:32] No. [18:32] I'm either going to fix it right, or postpone it. [18:32] The latter sounding like a better option. [18:32] well, postpone means no mx5 at all [18:32] Though, we can stage a fix now. [18:33] "at all"? [18:33] this is the critical milestone [18:33] Looks like it now fails due to fstab. [18:33] It's a community image, there's no quality requirement. [18:33] well [18:33] It's not like it was going to be on releases.ubuntu.com. [18:33] we produce it... [18:33] It'll always be on cdimage. [18:34] i actually have some quality requirement for the work i ship ... at least on the surface :) [18:34] infinity, point is that we agreed with the release team that images that arent ready by beta1 (actually) wont be releasable [18:34] I do too. I'm just saying that non-release images have no such requirement. [18:35] we talked kate into b2 [18:35] Yeah, so we don't "release" it. We weren't anyway. [18:35] Sort of my point. :P [18:35] if we dont make it i wont step up again for it [18:35] so we will miss [18:35] Wait. Okay, are we talking past each other, or... [18:35] Did you actually expect ac100/mx5 to be on releases.ubuntu.com? [18:35] we were supposed to release it (opposed to having a daily on cdimage that gets wiped with the first P build) [18:36] Where, y'know, half our images never go. [18:36] no [18:36] Oh, it can be "released" on cdimage. [18:36] That's a whole different quality criteria, though. [18:36] i expect the tested and QA^ approved release to be on cdimage in the r5eleases subdir of the respective image [18:36] And I think people get muddied up about that sometimes. [18:36] we only rarely have images on releases.u.c [18:37] all armel images but one live on cdimage [18:37] we had one release where we actually dumped them on r.u.c [18:37] anyway, moot point, do you see a fix thats not a horrid diff and that can work around it ? [18:38] Well, I'd have to see exactly where it's failing to come up with a "hack" instead of a fix. [18:38] irregardless of the current arguements regarding release, this image is fail. It actually is mucking up the partitions now to the point where it won't boot. [18:38] But... Does every preinstalled image have a sane root= on the command line? [18:38] up to now they did [18:38] And is it always a device? Or sometimes a UUID? [18:38] always a device (see jasper code) [18:39] jasper expects to not see a UUID [18:39] Well, the jasper code assumes it might not be a device. :P [18:39] (because it actually creates the UUID) [18:39] On first boot, it is a device. jasper rewrites boot.scr to use UUID. [18:39] right [18:39] if echo "$root" | grep -q '^UUID='; then [18:39] VOLID=$root [18:39] else [18:39] if echo $root| grep -q ^/;then [18:39] ROOTPART=$(basename $root) [18:39] fi [18:39] If it's never a UUID, that code's broken. [18:39] you look at the wrong script i think [18:40] Look at premount [18:41] there is UUID stuff, but thats unrelated to resize code [18:42] Right, well same ROOTDEV2 issues there. [18:42] And both can be solved with the same small amount of code. [18:42] right [18:42] then go for it [18:42] But the above that I pasted is also an issue. :P [18:42]