[02:10] <rsalveti> Dr_Who: infinity, ogra_ and janimo can also help reviewing and sponsoring libjpeg-turbo if needed
[02:11] <Dr_Who> rsalveti: good idea!
[02:11] <rsalveti> the FFe is mostly accepted already, as we got an ack from both skaet and slangasek at latest release meeting
[04:53] <doad>  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] <doad> what can i type in my terminal to see if my ethernet port is working
[04:55] <doad> what can i type in my terminal to see if my ethernet port is working
[12:55] <ppisati> 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] <ppisati> 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] <ogra_> he did some stuff with that on netinstalls iirc
[12:56] <ppisati> ok
[12:56] <ogra_> and had funny results
[12:56] <ppisati> same here
[12:56] <ppisati> hrw opened a bug about sd being inacceisble if he removes/reinsert the sd card
[12:56] <ogra_> well, wait until janimo's drop of the vfat mangling show up in the images
[12:56] <ppisati> no no
[12:56] <ogra_> though wait, you dont use preinstalled, right ?
[12:57] <ppisati> i use preinstalled
[12:57] <ogra_> how can you unplug the rootfs then ?
[12:57] <janimo> sheer force
[12:57] <ogra_> yeah
[12:57] <ogra_> or abuse of the images !
[12:57] <ppisati> becasue i moved averyrthing to usb
[12:57] <ogra_> he doesnt use them in their intended environment !
[12:57] <ogra_> evil guy you :)
[12:57] <ppisati> i use the sd card just for uImage&c
[12:58] <ppisati> :)
[12:58] <ppisati> well
[12:58] <ogra_> i would recommend using a netinst for such setups
[12:58] <ogra_> while it should indeed work to copy the rootfs to another device you never know what mistakes you make doing that
[12:58] <ppisati> but i just found out, that if i boot from another media (no sd card inserted during boot)
[12:58] <ppisati> the sd slot is dead!
[12:58] <ogra_> complain to u-boot or x-loader i guess :)
[12:58] <ppisati> it doesn't recognize any sd insert&c
[12:59] <ppisati> uhm
[12:59] <ogra_> smells very much like either of them
[12:59] <ppisati> that's why i asked GrueMaster, i have to try with some older release
[12:59] <ogra_> did you try with an older u-boot and x-loader ?
[12:59] <ppisati> and on xm now
[12:59] <ppisati> nope
[12:59] <ppisati> just oneiric/panda for now
[12:59] <ogra_> i bet a beer that it works fine with nattys
[12:59] <ppisati> i already own you a beer BTW :)
[13:00] <ogra_> you can win it back now ;)
[13:00] <ppisati> asd :)
[13:00] <ppisati> ok
[13:00] <ogra_> *g*
[13:00] <ppisati> coffee and then back testing older releases...
[13:21] <hrw> ogra_: its not uboot/xloader - kernel rather
[13:21] <hrw> system booted, replace card = bug
[13:22] <ogra_> hrw, i think tobin said he doesnt see it when rolling back to an older MLO/u-boot binary
[13:22] <ppisati> hrw: have you tried the same with beagle?
[13:22] <hrw> load kernel/initrd in uboot, 'bootm', replace card - bug
[13:22] <hrw> ppisati: would have to dig out old C3 beagle
[13:22] <ppisati> hrw: no prob, i'll do that
[13:22] <ppisati> hrw: another thing that i discovered is that:
[13:23] <ppisati> 1) if you boot from another media (load everything in memory, remove sd card and bootm)
[13:23] <ppisati> if you tru later to insert the sd card, the kernel doesn;'t recognize it
[13:23] <ppisati> 2) enabling MMC_DEBUG i see what it seems "activity" on mmc
[13:23] <ppisati> even when it's not mounted
[13:23] <ppisati> i wonder if it's polling
[13:23] <ppisati> 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] <ogra_> 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] <ogra_> same would go for kexec
[13:26] <ogra_> (using a binary kernel instead of u-boot.bin)
[13:57] <janimo> 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] <janimo> anyway, going forward
[13:58] <wookey> )win 21
[13:58] <ogra_> yeah, i remember banging my head against the same issue a while ago
[13:58] <janimo> I want every boring task on Earth be done by machines
[13:58] <janimo> which is most of them
[13:59] <ogra_> heh
[14:11] <brandini> hello
[15:16] <tgall_foo> 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] <ppisati> hrw: it works on xm!
[15:28] <hrw> cool
[15:28] <hrw> but I ahve pandas
[15:29] <ppisati> :)
[15:31] <brandini> I just got my pandaboard booting
[15:31] <brandini> the 11.04 release wouldn't boot properly for me
[15:50] <GrueMaster> ppisati: I see you are looking at the SD bug I mentioned a while back.  Bug 844099
[15:50] <ubot2> 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] <GrueMaster> 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] <ppisati> GrueMaster: never seen that bug, i was working on hrw bug (that is a duplicate of yours actually)
[16:08] <brandini> the world needs more arm
[16:10] <brandini> is the natty process the update manager?
[16:11] <GrueMaster> brandini: ???  That last sentence made no sense.
[16:23] <brandini> GrueMaster: what is the natty process?
[16:24] <gildean> in what?
[16:25] <gildean> you mean update?
[16:25] <GrueMaster> brandini: What exactly are you trying to do?
[16:29] <ogra_> GrueMaster, i was referring to the need to fix it ...
[16:30] <GrueMaster> ogra_: Fix what?  It is already fixed.
[16:30] <ogra_> pointing out that way to many things are in the bootloader while they should rather (or additionally) be initialized in the kernel
[16:30] <GrueMaster> Oh.
[16:30] <ogra_> yes, i wasnt referring to the fix/bug at all
[16:31] <ogra_> just to the fact that it actually needed to happen
[16:32] <ogra_> 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] <ogra_> but with the existing design that will never be possible without at least involving MLO
[16:33] <ogra_> (though i suspect many things u-boot initializes wont be done by the kernel either)
[16:34] <ogra_> sigh, the images are still building
[16:34] <ogra_> over 4h already
[16:34] <GrueMaster> afaik, MLO/aboot just initiallizes the main memory and a few minor other bits (i2c bus).  u-boot/kernel does the bulk.
[16:35] <ogra_> well, wasnt the fix in the MLO code of aboot ?
[16:35] <ogra_> now that didnt make sense
[16:35] <ogra_> well, wasnt the fix in  aboot ?
[16:35] <ogra_> that is better :P
[16:35] <GrueMaster> But I also thought u-boot turns off everything it needs just before context switch to kernel.
[16:35] <ogra_> i dont think it does
[16:36] <GrueMaster> The fix was in aboot to initialize i2c iirc.
[16:36] <ogra_> yeah
[16:43] <brandini> 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] <GrueMaster> Ah.  I usually just run "sudo apt-get update;sudo apt-get dist-upgrade" to pull the updates.
[16:44] <ogra_> dist upgrade on SD card on an XM ?
[16:44] <brandini> SD Card :(
[16:44] <ogra_> oh, not a release->release one
[16:44] <GrueMaster> Doing a full dist upgrade (Maverick->Natty) is a lesson in patience.
[16:44] <brandini> I'm stopping by microcenter on the way home to pick up a usb->mSata adapter
[16:45] <brandini> GrueMaster: it is :)
[16:45] <ogra_> i thought you upgrade to oneiric, that would indeed be a waste of time
[16:45] <brandini> really?
[16:45] <ogra_> yeah
[16:45] <brandini> 10.10 is better than 11.04?
[16:45] <brandini> shoot :)
[16:45] <GrueMaster> No, doing a release upgrade is a waste of time.  Faster to download a new image.
[16:46] <brandini> yeah
[16:46] <brandini> ok, that makes more sense
[16:46] <GrueMaster> Doing an in-release update is however a good idea.  Just time consuming.
[16:46] <brandini> do I have to do anything special to make the pandaboard boot off a usb device?
[16:46] <ogra_> in-release is fine you just shouldnt try to do something else as well on the system :)
[16:47] <brandini> heh, yeah :)
[16:47] <brandini> the load is like 4
[16:47] <ogra_> on the ac100 i actually dedicate time to it when i dont work
[16:47] <GrueMaster> 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] <GrueMaster> Then you need to change the uuid of the rootfs partition on the SD and just reboot.
[16:48] <GrueMaster> The panda will need the SD for boot partition.
[16:49] <brandini> ok, that makes perfect sense
[16:49] <ogra_> why wouldnt you just copy qemu-system-statci, chroot and do the dist upgrade that way ?
[16:49] <ogra_> oh, you meant copying the rootfs
[16:49] <GrueMaster> 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] <brandini> ogra_: this is my first time goofing with these types of boards... so beginners luck?
[16:50] <GrueMaster> 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] <brandini> 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] <GrueMaster> Now that sounds like a fun idea.
[16:51] <brandini> it is
[16:52] <ogra_> brandini, http://www.grawert.net:81/
[16:52] <ogra_> ;)
[16:52] <GrueMaster> Not sure how well everything for that will run under Natty.  I only did extensive server testing in Oneiric.
[16:52] <brandini> I've got the web application built in go (#golang) and it serves things up really nicely
[16:52] <ogra_> though thats runing on an x86 celeron
[16:52] <ogra_> (simply because i had no beagle back then)
[16:52] <brandini> hey, that's got solar/thermal :)
[16:53] <brandini> how hot do your panels get when you're running water behind them?
[16:53] <brandini> 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] <brandini> That's exactly what I'm fleshing out!
[16:54]  * brandini introduces himself to ogra_ 
[16:54] <ogra_> well, the panel bursted, i havent gotten a replacement yet (condesed water froze inside and blew up one element)
[16:54] <ogra_> it can get up to 130°C
[16:54] <brandini> sheesh
[16:54] <brandini> using copper?
[16:54] <ogra_> the panels are supposed to survive up to 220
[16:55] <brandini> efficiency drops quickly
[16:56] <ogra_> yeah, to be honest i would rather have half of the collector replaced by power generating panels
[16:57] <brandini> I just built a single wind generator using some PVC Pipe and I'm quite pleased with it
[16:57] <brandini> 3 19" blades and a 30V DC motor... really works nice
[16:58] <ogra_> cool
[16:58] <brandini> where you from ogra_?
[16:58] <ogra_> germany
[16:59] <brandini> I'm from the states in ohio
[17:11] <ogra_> hey hey
[17:11] <Ursinha> :)
[17:11] <Ursinha> GrueMaster, maybe we need an alarm, loud and red and blinking
[17:11] <ogra_> soo ...binary  packages often have arch: any and arch: all components
[17:11] <Ursinha> ogra_, right
[17:11] <ogra_> the any components usually get built nativelyy
[17:12] <ogra_> the all components all get built by the x86 builder
[17:12] <ogra_> now the x86 builders are waaaay faster than the armel ones
[17:12] <Ursinha> right
[17:12] <ogra_> so rthey finish the package early ... and publish their stuff
[17:13] <ogra_> 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] <ogra_> so you get uninstallable packages until armel has built
[17:13] <Ursinha> this is messy...
[17:13] <ogra_> which in some cases can take a day more
[17:13] <Ursinha> but I got it now
[17:13] <Ursinha> right
[17:14] <ogra_> and that prevents images from building
[17:14] <ogra_> there are two ways around it ...
[17:14] <Ursinha> but you said there are no images since Aug 30th
[17:14] <ogra_> fix soyuz to handle the packages right
[17:14] <ogra_> or work around the whole issue by running a separate mirror (like linaro does)
[17:14] <ogra_> we aim for the fix
[17:15] <Ursinha> ogra_, is there a bug for that? because if that's causing lack of images like this, it's kind of critical
[17:15] <Ursinha> and you might want to talk to the launchpad stakeholder in Ubuntu to have it fixed
[17:15] <ogra_> i think there is a bug  (NCommander should remember the number, i'm not subscribed so i dont have bugmail for it)
[17:16] <ogra_> and its known since quite a while ... even in higher levels ;)
[17:17] <skaet> Ursinha, its been raised.  https://bugs.launchpad.net/launchpad/+bug/34086
[17:17] <ubot2> 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] <GrueMaster> Wow, that is very old.
[17:17] <Ursinha> indeed
[17:18] <Ursinha> but awesome that's already escalated :)
[17:20] <rsalveti> after... 5 years
[17:21] <Ursinha> rsalveti, better late than even later
[17:21] <Ursinha> :)
[17:22] <ogra_> well, its a heavyweight ... pushing it uphill needs many people apparently :)
[17:22] <rsalveti> sure, just surprised it took so long
[17:22] <ogra_> took 5 years to get the crowd together ;)
[17:22] <Ursinha> ogra_, hehe, it's escalated, and people are apparently wrapping up the derived distros feature (which took some time to get completed)
[17:23] <Ursinha> rsalveti, launchpad touches lots of aspects of ubuntu, it's hard to fix everything relevant in a reasonable time, I believe
[17:24] <rsalveti> yup, probably
[17:24] <rsalveti> but I also want the derived distro working properly ;-)
[17:24] <rsalveti> that reminds me I need to ping some folks at launchpad
[17:27] <ogra_> GrueMaster, janimo,  does mx5 need flash-kernel.conf ?
[17:28]  * Ursinha adds #ubuntu-arm to the list of channels-to-lurk-in
[17:28] <GrueMaster> Aha.  That's the problem.  On mx5, boot.scr, and uI* is on the second partition.
[17:29] <ogra_> yeah, that shoudl get a flash-kernel.conf then :)
[17:29] <ogra_> so you can set it
[17:30] <ogra_> but i wonder if the code uses it yet
[17:30] <GrueMaster> Trying to run it after manually fixing flash-kernel.conf.
[17:30] <GrueMaster> We'll see if oem-config still crashes.
[17:30] <ogra_> yeah, that should tell
[17:49] <janimo> GrueMaster, I am working on that now
[17:49] <GrueMaster> cool
[17:50] <janimo> ogra_, uboot is not on the vfat partition but kernel and initrd are so presumably needs some flash-kernel.conf
[17:50] <ogra_> yeah
[17:51] <janimo> I wonder why resizing rootfs on mx5 is done in a blink
[17:51] <janimo> IIRc on omap it had a progess bar and took a while
[17:52] <ogra_> and it didnt fail ?
[17:52] <janimo> maybe it doesn ot happen for some reason - bug to be hunted
[17:52] <janimo> ogra no error msg, just Done
[17:52] <GrueMaster> It may not be resizing the correct partition.
[17:52] <janimo> It is suspicious probably does not happen
[17:52] <ogra_> and your partition has the expected size ?
[17:52] <ogra_> GrueMaster, ++
[17:52] <janimo> will check after
[17:53] <janimo> still I;d expect e2fsresize to complain if you ask it to resize a vfat
[17:53] <ogra_> GrueMaster, i bet i added a variable for that too ;)
[17:53] <infinity> janimo: Small card?
[17:53] <janimo> infinity, default mx5
[17:53] <infinity> janimo: On my 1GB card, resize on my Panda is literally instant.
[17:53] <ogra_> janimo, well, it would, in the jasper log
[17:53] <GrueMaster> That was changed as part of the ext4 change.
[17:53] <janimo> resize is supposed to happen from 2g to 4g
[17:54] <janimo> init: mounted-proc main process (385) terminated with status 1
[17:54] <janimo> mountall: Event failed
[17:54] <janimo> I wish I knew why these happen
[17:54] <ogra_> no plymouth i guess
[17:54] <ogra_> for the mountall bit
[17:54] <ogra_> no idea about the upstart one
[17:54] <janimo> ogra_, when is the next round of respins?
[17:55] <janimo> and only for mx5 for now is omap done for b2 ?
[17:55] <ogra_> janimo, well, if you ask GrueMaster i guess he doesnt want one :)
[17:55] <janimo> great, I agree
[17:55] <ogra_> janimo, thats not how it works
[17:55] <ogra_> if you upload jasper we need to re-test all jasper using images
[17:55] <ogra_> at least up to the jasper part
[17:56] <GrueMaster> yep.
[17:56] <janimo> ok, there is a new jasper needed for mx5 of course
[17:56] <ogra_> we dont cherry pick arches for builds during milestones
[17:56] <ogra_> yes
[17:56]  * ogra_ wasnt expecting todays images to be final actually
[17:56] <GrueMaster> Although I am still pulling, so if a respin is required I am ok.
[17:57] <ogra_> we also need to fix the missing slideshow still
[17:57] <ogra_> post beta though
[17:57] <ogra_> and the missing ti icon
[17:57] <janimo> ogra_, when are the jasper hooks executed?
[17:57] <janimo> for the mlabel copying
[17:57] <GrueMaster> Do we have packages for the ti icon to install?
[17:57] <ogra_> one in local-premount, one in local-bottom
[17:58] <ogra_> GrueMaster, no, its a jasper thing, but the handling of the favorites completely changed, so it doesnt show anymore
[17:58] <ogra_> GrueMaster, iirc persia had the bug assigned to move that into packages
[17:59] <GrueMaster> I meant when you click on the icon, is there packages in the ppa?
[17:59] <ogra_> it is there, you just dont see it :)
[17:59] <ogra_> and no, there is no package atm
[17:59] <ogra_> i'll add that by release time (if TI doesnt)
[18:00] <GrueMaster> Yea!  Fixing /etc/flash-kernel.conf fixed the oem-config crash.
[18:00] <ogra_> awesome !
[18:00] <GrueMaster> And I have unity.
[18:00] <ogra_> wow
[18:00] <GrueMaster> This is on yesterday's image though.
[18:00] <GrueMaster> Well, unity-2d.
[18:01] <GrueMaster> And the install icon is still there.  sigh.
[18:02] <ogra_> ubiquity ?
[18:02] <ogra_> well, oem-config didnt finish
[18:03] <ogra_> did you actually see it removing packages ?
[18:04] <GrueMaster> I wasn't paying attention.  Too many monitors to see all the details on all systems.  But I have seen this before.
[18:05] <GrueMaster> interesting.  When ubuntu-bug pops up to report a detected crash, it blanks the screen and asks for sudo access.
[18:05] <ogra_> bug in gksudo i think
[18:05] <ogra_> thats supposed to be transparent
[18:05] <ogra_> (teh black bg you see)
[18:06] <ogra_> poke mvo about it, i did it several times, he said he doesnt need a bug, it would go away anyway
[18:06] <ogra_> if it didnt go away yet, he might want to know about it :)
[18:09] <GrueMaster> 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] <ogra_> weird
[18:10] <ogra_> well ...
[18:10]  * ogra_ is off to find some dinner
[18:10] <infinity> Does it think there's free space anywhere?
[18:10] <infinity> Cause 4G cards aren't 4G...
[18:14] <GrueMaster> No, it is a resize issue. du-sh / says it is only using 1.4G
[18:16] <GrueMaster> df -h shows / as 1.5G with 1.4G used.  Gparted shows mmcblk0p3 as 3.95G
[18:17] <ogra_> jasper.log ?
[18:17] <GrueMaster> n/a
[18:19] <GrueMaster> Found it in /run.  Tried to resize mmcblk0p2.  Fail.
[18:19] <ogra_> no further info ?
[18:19] <infinity> Right, because that partition number is hardcoded in jasper.
[18:20] <GrueMaster> Of course, this is yesterday's image.  Prior to jasper fix for ext4.
[18:20] <infinity> And p3 is the one you're using.
[18:21] <ogra_> its not hardcoded
[18:21] <ogra_> 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] <infinity> ROOTPART="${ROOTDEV}2"
[18:21] <infinity> ^-- That's not hardcoded?
[18:22] <ogra_> hmm, that should be dreived from $DISK
[18:23] <ogra_> ROOTDEV="/dev/${DISK}${SEP}"
[18:23] <ogra_> and it is
[18:23] <infinity> Dude.
[18:23] <infinity> The 2.
[18:24] <infinity> The partition NUMBER is what's hadcoded.
[18:24] <infinity> hard*
[18:24] <ogra_> yeah, sorry
[18:24] <infinity> And mx5 is using a different layout.
[18:24] <GrueMaster> Kinda indicates structured fail.
[18:24] <infinity> Or, so I understand.
[18:24] <ogra_> yeah, thats definitely a bug
[18:24] <ogra_> the code should just parse root=
[18:25] <GrueMaster> mx5 uses a non-fs part1 for u-boot, fat for part2 (kernel, initrd), and rootfs on part 3.
[18:25] <ogra_> right
[18:25] <ogra_> but that doesnt need to be hardcoded at all given we set root= at image build time
[18:25] <infinity> Ironically, if there's a UUID in play, things work correctly later...
[18:25] <ogra_> yes
[18:25] <infinity> But only partially correctly.
[18:26] <infinity> So, yeah, that whole mess needs a bit of a clean up.
[18:26] <ogra_> a bit ?
[18:26] <infinity> I should have looked closer where I was in there for the FSTYPE thing. :/
[18:26] <ogra_> :)
[18:26] <ogra_> it needs a rewrite
[18:26] <ogra_> thats why we had discussions about it in dublin
[18:29] <GrueMaster> This is where my comment on us getting bogged down in last weeks meeting applies.
[18:29] <ogra_> yup
[18:30] <infinity> 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] <GrueMaster> Not faulting anyone, just that we get tied up with long, difficult tasks, and the simple stuff falls through the cracks.
[18:30] <ogra_> infinity, do it post beta
[18:31] <infinity> ogra_: Sure, this just means mx5 gets to be broken for beta.  *shrug*
[18:31] <ogra_> 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] <ogra_> infinity, just add a three liner that checks /proc/cpuinfo and resets the partition number then
[18:32] <ogra_> another hack for a few days wont harm us ;)
[18:32] <infinity> Ew.
[18:32] <infinity> No.
[18:32] <infinity> I'm either going to fix it right, or postpone it.
[18:32] <infinity> The latter sounding like a better option.
[18:32] <ogra_> well, postpone means no mx5 at all
[18:32] <infinity> Though, we can stage a fix now.
[18:33] <infinity> "at all"?
[18:33] <ogra_> this is the critical milestone
[18:33] <GrueMaster> Looks like it now fails due to fstab.
[18:33] <infinity> It's a community image, there's no quality requirement.
[18:33] <ogra_> well
[18:33] <infinity> It's not like it was going to be on releases.ubuntu.com.
[18:33] <ogra_> we produce it...
[18:33] <infinity> It'll always be on cdimage.
[18:34] <ogra_> i actually have some quality requirement for the work i ship ... at least on the surface :)
[18:34] <ogra_> infinity, point is that we agreed with the release team that images that arent ready by beta1 (actually) wont be releasable
[18:34] <infinity> I do too.  I'm just saying that non-release images have no such requirement.
[18:35] <ogra_> we talked kate into b2
[18:35] <infinity> Yeah, so we don't "release" it.  We weren't anyway.
[18:35] <infinity> Sort of my point. :P
[18:35] <ogra_> if we dont make it i wont step up again for it
[18:35] <ogra_> so we will miss
[18:35] <infinity> Wait.  Okay, are we talking past each other, or...
[18:35] <infinity> Did you actually expect ac100/mx5 to be on releases.ubuntu.com?
[18:35] <ogra_> we were supposed to release it (opposed to having a daily on cdimage that gets wiped with the first P build)
[18:36] <infinity> Where, y'know, half our images never go.
[18:36] <ogra_> no
[18:36] <infinity> Oh, it can be "released" on cdimage.
[18:36] <infinity> That's a whole different quality criteria, though.
[18:36] <ogra_> i expect the tested and QA^ approved release to be on cdimage in the r5eleases subdir of the respective image
[18:36] <infinity> And I think people get muddied up about that sometimes.
[18:36] <ogra_> we only rarely have images on releases.u.c
[18:37] <ogra_> all armel images but one live on cdimage
[18:37] <ogra_> we had one release where we actually dumped them on r.u.c
[18:37] <ogra_> anyway, moot point, do you see a fix thats not a horrid diff and that can work around it ?
[18:38] <infinity> Well, I'd have to see exactly where it's failing to come up with a "hack" instead of a fix.
[18:38] <GrueMaster> 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] <infinity> But... Does every preinstalled image have a sane root= on the command line?
[18:38] <ogra_> up to now they did
[18:38] <infinity> And is it always a device?  Or sometimes a UUID?
[18:38] <ogra_> always a device (see jasper code)
[18:39] <ogra_> jasper expects to not see a UUID
[18:39] <infinity> Well, the jasper code assumes it might not be a device. :P
[18:39] <ogra_> (because it actually creates the UUID)
[18:39] <GrueMaster> On first boot, it is a device.  jasper rewrites boot.scr to use UUID.
[18:39] <ogra_> right
[18:39] <infinity> if echo "$root" | grep -q '^UUID='; then
[18:39] <infinity>     VOLID=$root
[18:39] <infinity> else
[18:39] <infinity>     if echo $root| grep -q ^/;then
[18:39] <infinity>         ROOTPART=$(basename $root)
[18:39] <infinity>     fi
[18:39] <infinity> If it's never a UUID, that code's broken.
[18:39] <ogra_> you look at the wrong script i think
[18:40] <GrueMaster> Look at premount
[18:41] <ogra_> there is UUID stuff, but thats unrelated to resize code
[18:42] <infinity> Right, well same ROOTDEV2 issues there.
[18:42] <infinity> And both can be solved with the same small amount of code.
[18:42] <ogra_> right
[18:42] <ogra_> then go for it
[18:42] <infinity> But the above that I pasted is also an issue. :P
[18:42] <infinity> It'll be writing the fstab incorrectly on mx5.
[18:42] <ogra_> janimo needs an upload anyway
[18:42] <infinity> So.
[18:42] <infinity> Yeah.
[18:42] <infinity> I'll get on this in 30ish minutes, I'm starving. :)
[18:42]  * ogra_ finishes his dinner
[18:42] <janimo> infinity, I'll upload my changes now
[18:43] <ogra_> janimo, wait
[18:43] <infinity> janimo: Or just commit them, if you don't need an upload/rebuild cycle.
[18:43] <ogra_> just commit them so we can get along with one upload
[18:43] <janimo> ogra_, not uploading just committing
[18:43] <janimo> sure
[18:43] <ogra_> ah
[18:43] <infinity> janimo: (And I suspect rebuilding is useless to you without fixing the rootdev stuff)
[18:43] <ogra_> well, we have a good set for testing atm (beyond mx5 indeed)
[18:44] <GrueMaster> janimo: Looks good.  Should fix all of our problems.
[18:44] <janimo> I changed rootpart , uboot_part and boot.scr contents for mx5
[18:44] <janimo> GrueMaster, what was the flash-config change about?
[18:44] <ogra_> oh, rootpart too ?
[18:45] <janimo> I tried with my changes in a modified initrd and it still crashed at the end albeit differently. When I came back to the screen it had restarted ubiquity
[18:45] <janimo> just like I saw it done for omap previously
[18:45] <janimo> but var/crash is empty this time so some joy
[18:46] <janimo> ogra_, well rootpart to be part 3 and vfat part 2
[18:46] <ogra_> yes
[18:46] <janimo> as they were hardcoded to 1 and 2 for omap
[18:46] <ogra_> but see above
[18:46] <ogra_> infinity just wanted to start working on a general fix for that
[18:46] <janimo> no problem
[18:46] <ogra_> oh, geez ! i'm sooo proud !
[18:47] <janimo> general fix being?
[18:47] <GrueMaster> janimo: I manually changed /etc/flash-kernel.conf to show UBOOT=/dev/mmcblk0p2.
[18:47] <ogra_> (its my cats first bday today and he just brought me his first mouse)
[18:47] <janimo> I had a version that autodetected vfat/root using sfdisk
[18:47] <GrueMaster> Your jasper mods should fix this automatically.
[18:47] <janimo> ogra_, cats do not know the customs. Unclear about who needs a present
[18:47] <ogra_> janimo, well, talk to infinity so you guys dont duplicate work then
[18:47] <janimo> GrueMaster, good
[18:47] <ogra_> haha
[18:48] <janimo> ogra_, I did not do the smartsfdisk based approach so I introduce as little new code as possible
[18:48] <janimo> even if it looked better
[18:48] <ogra_> he still doesnt get that he can eat his toy though
[18:48] <janimo> no need for grepping cpuinfo for instance
[18:48] <ogra_> how do you know you are on mx5 ?
[18:49] <janimo> has MX53 in the hardware line
[18:49] <janimo> oh you mean without cpuinfo
[18:49] <ogra_> you just said you dont look at cpuinfo
[18:49] <ogra_> yeah
[18:49] <janimo> well for the partitions just look at where sfdisk finds vfat and linux
[18:49] <janimo> and operate on those devices
[18:49] <ogra_> yeah, that at least works for all images with vfat
[18:49] <janimo> but for the boot.scr content subarch is still needed
[18:50] <janimo> so not entirely streamlined without special casings
[18:51] <ogra_> well, that sounds like you already implemented what adam planned to
[18:51] <janimo> GrueMaster, but my fixes to jasper need testing with omap just in case I blundered something
[18:51] <ogra_> or at least something similar
[18:51] <GrueMaster> Someone going to upload this and trigger a respin, or do I call mx5 a cosmic failure?
[18:51] <ogra_> not yet :)
[18:52] <janimo> ogra_, similar, not very elegant, for the same reasons - freeze being close
[18:52] <ogra_> yeah
[18:52] <janimo> ogra_, I still need to add the mlabel thingie
[18:52] <GrueMaster> That can wait post-beta
[18:52] <janimo> so when is that hook/ copy_exec executed?
[18:52] <janimo> GrueMaster, fine by me
[18:53] <ogra_> yeah
[18:53] <ogra_> leave that for post muilestone
[18:53] <ogra_> janimo, during update-initramfs
[18:54] <ogra_> call update-initramfs -v ;)
[18:54] <ogra_> that shows you every copy_exec it does
[18:54] <janimo> ogra_, ah so after install
[18:54] <ogra_> including the list of libs
[18:54] <ogra_> we call update-initramfs several times during the build too
[18:55] <ogra_> well, once at least, more depends on the image type
[19:02] <infinity> janimo: We already know rootpart from root=, the sfdisk thing feels like overkill.
[19:02] <janimo> infinity, ok
[19:02] <janimo> but vfat needs to be detected too
[19:03] <janimo> anyway, for now the case with MX53 works
[19:03] <infinity> Is that in another commit? (the vfat thing)
[19:03]  * janimo tries again with logging to the screen
[19:03] <janimo> infinity, I commited all I have
[19:03] <janimo> UBOOT_PART
[19:03] <janimo> 2 or 3 commits I think
[19:04] <infinity> Ahh, that's not autodetected, though, just hardcoded for the subarch.  Check.
[19:04] <GrueMaster> Should be on rev 165 now.
[19:05] <infinity> Yeah.
[19:05] <GrueMaster> er, 167
[19:05] <infinity> 165..167 are his changes. :P
[19:05] <infinity> But yeah.  I just understood the mentioning of "have to detect vfat" as meaning he'd done so. :)
[19:06] <ogra_> well, if its sufficient to get mx5 through
[19:06] <infinity> Sec.
[19:06] <GrueMaster> So, I still need to know if we are respinning with this.
[19:06] <infinity> We will.
[19:06] <ogra_> yep
[19:07] <GrueMaster> We'll have to respin server and kubuntu/kubuntu-mobile as well.  All images except netboot & core.
[19:07] <infinity> However, if we're sure that we'll always have a correct root=/dev/blah, then we can scrap that whole bit in _setup.
[19:07] <infinity> ROOTPART="${ROOTDEV}2"
[19:07] <infinity> #iMX53 has rootfs on part 3
[19:07] <infinity> grep MX53 /proc/cpuinfo >/dev/null && ROOTPART="${ROOTDEV}"3
[19:07] <ogra_> well, we control what goes into the images
[19:07] <infinity> ^-- Unnecessary because of:
[19:07] <infinity> if echo "$root" | grep -q '^UUID='; then
[19:07] <infinity>     VOLID=$root
[19:07] <infinity> else
[19:07] <infinity>     if echo $root| grep -q ^/;then
[19:07] <infinity>         ROOTPART=$(basename $root)
[19:08] <ogra_> we could as well make jasper read /etc/subarch and wipe it afterwards
[19:08] <GrueMaster> where is that?
[19:08] <ogra_> adding a full AI to have disk detection seems overkill
[19:08] <infinity> jasper_setup
[19:09] <GrueMaster> No, the /etc/subarch part.
[19:09] <infinity> Nowhere.
[19:09] <infinity> He was saying we could create it.
[19:09] <ogra_> right
[19:09] <GrueMaster> So another added failure point.  Lets not.
[19:09] <ogra_> to remove all subarch detection code
[19:10] <infinity> Yeah, not worth it for now.
[19:10] <ogra_> well, its 20 lines of subarch detection by parsing /proc/cupinfo ... vs SUBARCH=$(cat /etc/subarch)
[19:10] <ogra_> heh, no, surely not for now
[19:10] <ogra_> i'm just thinking aloud
[19:10] <infinity> janimo: If your changes work, they seem low impact for now, I just hate committing hacks unless we also commit to fix them later. :/
[19:11] <ogra_> infinity, well, jasper is a lost case ... somewhat
[19:11] <GrueMaster> The right thing to do is to make jasper detect the correct partitions.  This way, it will work with other platforms and also with linaro images on existing platforms.
[19:11] <infinity> ogra_: Indeed.
[19:11] <ogra_> it is a hack consisting of hacks
[19:11] <infinity> GrueMaster: Well, yes.
[19:12] <ogra_> GrueMaster, linaro has no interest in using or helping with jasper
[19:12] <ogra_> they pretty clearly told me so
[19:12] <GrueMaster> Only because it breaks their current model.
[19:12] <ogra_> they had no model when jasper stzarted
[19:12] <GrueMaster> They have a master partition on P1.
[19:12] <janimo> also because they presumable wish to keep their sanity
[19:12] <ogra_> and asac worked quite hard to try to convince people
[19:13] <janimo> GrueMaster, for mx5 I copied their part layout
[19:13] <janimo> or uboot would not work
[19:13] <ogra_> janimo, jasper isnt a bad thing ... its just that we are still using the proof of concept prototype
[19:13] <GrueMaster> I wonder if the same layout could be used for omap/omap4.
[19:13] <infinity> Well, jasper shouldn't exist.
[19:13] <janimo> ogra_, the idea is not bad, but the hacks and the maintainability are
[19:14] <infinity> The growroot concept should be rolled back into ubiquity, and we'd be done with it.
[19:14] <ogra_> infinity, what would do the resizing then ?
[19:14] <infinity> That's the only thing it does different from ubiquity.  It resizes in place instead of copying.
[19:14] <infinity> Other than that, we WANT ubiquity.
[19:14] <ogra_> why would we
[19:15] <ogra_> we *use* ubiquity
[19:15] <infinity> Why wouldn't we?
[19:15] <ogra_> we only dont use the partman bits
[19:15] <ogra_> and pkgsel
[19:15] <infinity> Sure, but if it was all in one place, you could use one installer to install in-place OR to another drive.
[19:15] <GrueMaster> This debate really should be brought up at UDS.  Too late for major changes now.
[19:15] <infinity> And yes, not helpful now.
[19:15] <ogra_> haha
[19:15] <infinity> janimo: If your hacks DTRT, upload.
[19:16] <ogra_> infinity, fix the copying speed and i'll happily be with you on live images
[19:16] <infinity> ogra_: The current way to install to external drives on a Panda are either netboot (that's fine), or install with jasper and then cp -a to another partition.  That second case is just wrong. :P
[19:16]  * GrueMaster toddles off to play with the netinstall images while waiting for respins.
[19:17] <ogra_> preinstalled images mainly exist because the linaro guysw complained to me it takes to long to install
[19:17] <ogra_> that was way before they started to do their own
[19:17] <infinity> ogra_: And this has nothing to do with copying speed.  I'm saying the growroot (install in-place) option should be added to d-i proper.
[19:17] <ogra_> actually its all amitkÄs fault !
[19:17] <infinity> ogra_: So you could EITHER copy, OR do the in-place thing we do now.
[19:17] <ogra_> hmm
[19:17] <ogra_> yeah, that sounds sane
[19:17] <janimo> infinity, I am still testing a bit the fs resize
[19:18] <infinity> janimo: Mmkay.
[19:18] <GrueMaster> infinity: Growroot needs to happen before the rootfs is mounted. EXT4 doesn't allow grow while mounted.
[19:18] <ogra_> i think it does
[19:18] <ogra_> ext3 doesnt
[19:18] <infinity> janimo: It's not how I would have solved it, but it's definitely low-impact your way, and I'd rather push something in and have working images than rewrite things right now, so...
[19:18] <ogra_> and i think its a lot faster when mounted
[19:18] <GrueMaster> No, I tested it during my EXT4 testing.
[19:18] <janimo> infinity, out of curiosity how would you have done it?
[19:19] <GrueMaster> It actually produces an error.  Even when mounted RO.
[19:19] <infinity> janimo: Well, as above, I'd remove some redundant code, I'd use root= instead of sfdisk, I'd remove more redundant code... And more...
[19:19] <ogra_> janimo, i guess a udeb that brings that functionallity (using parted or partman)
[19:19] <infinity> janimo: But my changes have a regression potential if things don't work exactly as I'm told they do. :P
[19:19] <infinity> janimo: Yours should Just Work, for now.
[19:20] <ogra_> which then can be used by d-i and ubiquity/oem-config
[19:20] <janimo> infinity, ah indeed. Seeing I removed some code for the VFAT formatting because it was the right thing, introduced a regression (label) I thought I resist the urge to clean up things
[19:20] <ogra_> janimo, just look at the jasper buglist, 90% of jasper wouldnt exist anymore if they were all fixed
[19:21] <ogra_> it would mainly boild down to growroot
[19:22] <ogra_> u-boot setup shoudl be done by flash-kernel-installer buit that needs a re-write to accept being run in non d-i envs
[19:22] <ogra_> and all the other setup bits should go elsewhere too
[19:22] <ogra_> we have a re-occuring jasper rewrite spec since we have preinstalled
[19:22]  * ogra_ looks at infinity ...
[19:22] <infinity> Heh.
[19:23] <ogra_> we should wprobabls have a jasper slaying spec this time :)
[19:23] <ogra_> *probably
[19:23] <infinity> I'm inclined to agree.
[19:23] <ogra_> add it to the spec page ;)
[19:23] <ogra_> and dont let me implement it ... you might end up with jasper-ng :P
[19:24] <infinity> Chris Jones shouldn't be near installers.
[19:24] <infinity> We'd end up with multiple installer windows.
[19:24] <ogra_> heh
[19:25] <janimo> ogra_, I remember, I took the notes at the meeting and filed most of those bugs in Dublin
[19:26]  * ogra_ has a slight prob with chris' nick since it took him quite a while to make out that the guy who asked about "angie" from canonical IS actually meant chris :)
[19:26] <janimo> infinity, ogra, uploaded jasper
[19:26] <ogra_> janimo, yeah, they are still there :D
[19:27] <janimo> ogra_, closed the VFAT reformat one
[19:27] <ogra_> heh, cool
[19:28] <ogra_> i think you own a WI from my plate as well (or was it infinity) for the ext4 changes in jasper
[19:28] <ogra_> (i'll make sure to re-assign when i close it)
[19:31] <infinity> janimo: Accepted.
[19:31] <janimo> infinity, thanks
[19:33]  * ogra_ calls it a day 
[19:33] <infinity> 'Night.
[19:33] <brandini> night
[19:34] <brandini> ogra_: I hope you don't mind I shared that link with my wife because I wanted to share what I'm trying to accomplish
[19:34] <janimo> ogra_, bye
[19:35] <janimo> hmm, resize does not happen apparently. mount fails and the script quits
[19:35] <janimo> mount: can't read '/etc/fstab': No such file or directory
[19:35] <janimo> triggered by mount ${ROOTPART} /root >>${LOG} 2>&1 apparently
[19:36] <infinity> Is that you stepping through manually, or?
[19:37] <infinity> Cause at that point, on "proper" install media, /etc/fstab exists (albeit empty), and mount should be fine.
[19:37] <janimo> infinity, no, running yesteday's image patched with a modified initrd to test my jasper changes
[19:37] <janimo> I'll wait for proper images could be an artifact of something I did
[19:38] <janimo> anyway resize is the last step in that file
[19:38] <janimo> so the rootfs stays at 2G
[19:38] <janimo> maybe that is why it crashes, no space for installed packages
[19:38] <janimo> I test it on the mx53
[19:39] <GrueMaster> janimo: yesterday's image worked for me once I modified /etc/flash-kernel.conf.
[19:39] <janimo> GrueMaster, resized ext3 even?
[19:40] <GrueMaster> May be something with the ext4 stuff.
[19:40] <janimo> maybe because ARM boards love you
[19:40] <janimo> you are much closer to them than I am
[19:40] <infinity> It can't have resized correctly.
[19:40] <GrueMaster> It didn't resize properly (rewrote the partitions but that was it).
[19:40] <janimo> you cultivate a proper relationship with them
[19:40] <janimo> ok
[19:40] <janimo> so part resize is good, fs resize not
[19:40] <GrueMaster> Yea, I'm all touchy feely with them.
[19:41] <GrueMaster> This was yesterday's image prior to ext4 changes and everything else.
[19:42] <infinity> Yeah, partition resizing would have always worked, because it just expanded "the Linux partition", it didn't use numbers.
[19:43] <infinity> That would fail pretty entertainingly if anyone tried to use jasper in an image with multiple partitions.
[19:44] <infinity> Thankfully, no one would do such a thing. :P
[19:47] <amitk> ogra_: hehe :) I still think anybody thinking of installing ubuntu on ARM devices needs some introduction to the real world :-p
[19:48] <amitk> ogra_: (as opposed to pre-installed images, that is)
[19:53] <infinity> amitk: Well, depends on how you define "ARM devices" too.
[19:54] <infinity> amitk: I think most of the madness we do with flash is, well, madness.
[19:54] <infinity> amitk: But with devices that can actually use external storage, things (finally) change a bit.
[19:54] <brandini> flash?
[19:55] <infinity> brandini: Flash, SD, MMC, nvram, whatever you want to call it.  "slow, unreliable storage that belongs in watches, not desktop computers".
[19:59] <brandini> :)
[19:59] <brandini> the choice to rely/depend on that for booting seems odd to me
[19:59] <amitk> infinity: right, and when I complained a year ago, the only HW we had access to had flash storage and slow usb storage. Over one year later, we still don't have enough devices/boards in Linaro that can do SATA
[20:02] <brandini> so I'm going to start updating openbsd's armish arch to support the pandaboard
[20:02] <brandini> and the deeper I dig the more I wonder what I've gotten myself into
[20:03] <infinity> brandini: Pain.
[20:03] <brandini> Sure seems like it
[20:03] <brandini> the current install guide for openbsd doesn't start actually talking about the install until about half way through the document
[20:47] <GrueMaster> infinity: Ouch (from the builders status page):  armel 	18 	283 jobs (22 hours)
[20:48] <infinity> GrueMaster: That't the rebuild test.  And a huge improvement over when it said "12 weeks".
[20:48] <GrueMaster> ah
[21:14] <GrueMaster> infinity: Has the jasper update been published and accepted?  No sense respinning without it.
[21:15] <infinity> GrueMaster: Yes.
[21:16] <GrueMaster> ok.  I knew we were waiting on ubiquity.  Wanted to make sure jasper was also updated.
[21:16] <infinity> Yeah, jasper builds in a matter of seconds. ;)
[21:16] <GrueMaster> Doesn't necessarily mean it is accepted during a freeze.
[21:16] <infinity> (I accpted it)
[21:17] <GrueMaster> Ah.
[21:17] <infinity> 13:31 < infinity> janimo: Accepted.
[21:17] <infinity> 13:31 < janimo> infinity, thanks
[21:18] <GrueMaster> I was monitoring #u-release.  Thought it would get an honorable mention there.
[21:18] <GrueMaster> But no matter.
[21:19] <infinity> Nah, I reviewed it and slipped it under the radar somewhat intentionally.
[21:19] <infinity> Not that it's a "secret" (obviously), just didn't feel the need for fuss, since we were waiting on ubiquity. ;)
[21:20] <GrueMaster> No problem.  I just wanted to make sure.  When I'm not keeping everyone on their toes, things slip by (like daily builds).
[23:29] <brandini> Ok, I've procured my external usb enclosure
[23:30] <brandini> it's shiny and black, but that wasn't part of the instructions :)
[23:31] <infinity> brandini: Still seems important.
[23:31] <brandini> it is
[23:31] <brandini> man, I'm kinda bummed that I'm going to power off my pandaboard half way through this update from 10.10 to 11.04
[23:31] <brandini> :(
[23:50] <brandini> is there something different I need to do when I install the 11.04 preinstalled image to a CF and SSD?
[23:53] <GrueMaster> With that image, you just dd to the SD card same as 10.10 and boot.  After going through the oem-config and getting to a working image (before installing updates), shut down.  Then you can transfer the rootfs to the USB drive using your desktop system.
[23:55] <brandini> ok
[23:55] <brandini> I should use 11.04 release or daily?
[23:56] <GrueMaster> If you want to start with Oneiric (11.10) on your USB drive, you can do a netboot install directly to it, but it takes a little bit of working.
[23:58] <brandini> would I always have to netboot or just for the install?
[23:58] <GrueMaster> Essentially, there is a bug in the netboot install that fails to repartition the SD properly for normal booting.  But it is easy to work around.  See bug 806751 for info.
[23:58] <ubot2> Launchpad bug 806751 in debian-installer "Boot partition on SD is too small on omap/omap4" [Medium,New] https://launchpad.net/bugs/806751
[23:58] <GrueMaster> Just the install.
[23:59] <GrueMaster> This will pull the latest packages.  Once the system is installed, you can just pull updates as normal.