[00:46] <dcordes> Anybody experienced bug 625591 in http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100829/maverick-preinstalled-netbook-armel+omap4.img.gz ?
[00:46] <ubot2> Launchpad bug 625591 in jasper-initramfs (Ubuntu) "[ARM] ubuntu-netbook defaults to 3D session even after "fix" by jasper-initramfs (affects: 1) (heat: 10)" [Medium,Incomplete] https://launchpad.net/bugs/625591
[04:10] <DanaG> Say, I really wish we could get those OMAP DSP accelerated codecs packaged. :(
[04:10] <DanaG> Or at least, have a packaged thing where you point it at the .bin file they give you, and it sets it up.
[04:10] <persia> I think some folks are working on that
[04:11] <persia> At least for omap3/omap4
[04:12] <DanaG> http://www.slashgear.com/texas-instruments-blaze-video-demo-1674291/
[04:13] <DanaG> It'd be an awesome thing to have: 1080p video encode/decode.
[04:13] <DanaG> Or even 720 would be nice.
[04:14] <persia> I heard 1080p was the target, but depends on all sorts of factors.
[04:14] <DanaG> Or heck, implementing va-api would be one way they could do it.
[04:14] <DanaG> That'd be the most useful for things such as gnash.
[04:15] <persia> Unfortunately, I can't find any work-in-progress for those immediately offhand.
[09:18] <hrw> morning
[10:54] <ogra> ndec, whats the magic to make the tablet display work ? (/me gets omapdss DISPC error: SYNC_LOST_DIGIT on boot atm when booting teh 2.6.34 ubuntu omap4 kernel)
[10:55] <ogra> (i'm likely wanting the 2.6.35 kernel with robs patches but we dont have a package for it yet)
[12:48] <rsalveti> ogra: you could try http://people.canonical.com/~rsalveti/maverick/kernel/linux-image-2.6.34-903-omap4_2.6.34-903.7rsalveti1_armel.deb
[12:48] <rsalveti> that's our current tree with the hdmi fixes
[12:49] <rsalveti> this is the deb I mainly use here
[12:49] <rsalveti> all fixes are included at our current 2.6.35 tree, but will be only for es2 and after beta
[12:50] <ogra> right
[12:50] <ogra> i'm focusing on es1 now
[12:51] <ogra> rsalveti, btw, a bug for the LED issue would be nice :) (and thanks a lot for the fix)
[12:51] <rsalveti> ogra: yep, this deb is for es1
[12:51] <ogra> oh, ok
[12:51] <ogra> well, still i cant play with the tablet until i have beta half way working :)
[12:52] <rsalveti> ogra: ok, I can create a bug for it
[12:52] <ogra> the good thing with the tablet is that our bootloader setup seems safe though
[12:52] <rsalveti> cool
[12:52] <rsalveti> ogra: so, today's image installs fine and boots fine, but the bar is still wrong
[12:53] <rsalveti> using the default gnome bar
[12:53] <rsalveti> shouldn't this be fixed already?
[12:53] <ogra> yes, i just uploaded the last bits for the fix
[12:53] <ogra> and the other bit hasnt been approved yet by ubuntu-release
[12:53] <ogra> i'll take care for it as soon as my upload shows up in the queu
[12:53] <ogra> e
[12:54]  * ogra twiddles thumbs waiting for it to appear
[12:55] <rsalveti> ogra: oh, nice
[12:55]  * ogra waits for the bot in #ubuntu-release to pick it up
[13:08] <ogra> NCommander, bug 626749
[13:08] <ubot2> Launchpad bug 626749 in flash-kernel (Ubuntu) "Generation of initramfs fails on OMAP4 when no 'Kernel' mtd partition exists, preventing configure/install. (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/626749
[13:08] <ogra> NCommander, your subarch spec seems to cause even more issues
[13:09] <ogra> NCommander, MTD should never be tried on omap4
[13:09] <ogra> no matter if flash-kernel.conf exists or not, that seems very wrong to me
[13:09] <persia> And named MTD partitions aren't reliable anyway.
[13:09] <ogra> they are on beagle
[13:09] <NCommander> ogra: argh. what-the-hell, it shouldn't be using MTD at all
[13:09] <NCommander> screw me
[13:09]  * NCommander sighs
[13:10] <ogra> but thats because the names are hardcoded in the kernel
[13:10] <persia> No they aren't.  MTD partitions are entirely fictional.
[13:10] <persia> There's nothing like a "partition table"
[13:10] <persia> That's a bug in the kernel :)
[13:10] <ogra> persia, there is a fake one in the beagle kernel
[13:10] <persia> Ugh.  That's too ugly for words.
[13:10] <ogra> as long as we control that we can be sure there are the right names
[13:11] <persia> We don't.
[13:11] <ogra> currently we do
[13:11] <persia> "control" and "free software" mix badly.
[13:11] <ogra> if people build their own kernels thats up to them
[13:11] <persia> How about if people upload their own kernels to Ubuntu?
[13:11] <ogra> if the naming changes in our kernel we can adjust
[13:12] <ogra> then we need to react
[13:12] <ogra> and i would expect us to get a bug+
[13:12] <persia> Better to have a design that works well with social norms, but if I got into a critique of armel kernels, I'd be here all night, so I'll let it rest :)
[13:12] <ogra> heh
[13:13] <ogra> well, maverick images dont use MTD at all
[13:13] <ogra> the MDT stuff is really only to make lucid->maverick upgrades not break
[13:13] <persia> I know.  I blame myself.  I never finished shaving that particular yak.
[13:13] <ogra> *MTD
[13:14]  * persia wants nice happy MTD support, and *will* get it, but has several precursors that get in the way
[13:15]  * ogra takes a break
[13:15] <ogra> (hoping the queue bot will have picked up my upload if i return ... 30min seems a bit long for it to pick up stuff)
[13:17] <persia> Some of the RMs actually check the queue directly once in a while :)
[14:51] <dcordes> persia: Thanks a gain for the recommendation to solve onboard issues upstream. They welcomed my recommendations a lot.
[15:43] <rsalveti> GrueMaster: do I need to add any different testing tag to the bug so you could easily track the "needs-testing" bugs?
[15:44] <rsalveti> for example, we got a package with possible fix, but needs testing to confirm
[15:44] <GrueMaster> Add a tag "verification-needed".
[15:44] <GrueMaster> And good morning.
[15:46] <sakoman_> rsalveti: any further u-boot issues?
[15:46] <rsalveti> sakoman_: nops :-)
[15:46] <rsalveti> didn't try with es2 yet
[15:46] <rsalveti> sakoman_: should it work?
[15:47] <rsalveti> GrueMaster: good morning :-)
[15:47] <sakoman_> rsalveti: I believe it should, but I don't have an OMAP4 ES2 to test with
[15:47] <rsalveti> sakoman_: ok, will test along the day
[15:47] <rsalveti> and let you know about it
[16:22] <ogra> ubuntu-netbook-efl-default-settings 0.6 (Accepted)
[16:22] <ogra> \o/
[16:22] <ogra> theer we go !
[16:22] <ogra> *there
[16:24] <devilhorns> w00t
[16:28] <rsalveti> nice!
[16:42] <dcordes> ogra: Could you elaborate what is ubuntu-netbook-efl-default-settings ?
[16:42] <dcordes> ogra: Is it an approach to cut the need of jasper writing configuration ?
[16:44] <dcordes> https://launchpad.net/ubuntu/maverick/+source/ubuntu-netbook-efl-default-settings/0.6
[16:47] <dcordes> Nice I have been wondering where all those settings are :)
[16:50] <mopdenacker> ogra: Hi! Do you know when we can expect your instructions to make our own pre-installed images? After the beta release?
[16:53] <dcordes> mopdenacker: for a specific device ?
[16:56] <ogra_cmpc> mopdenacker, i'll start on it during this week, beta looks ok so far so i should hve some time the next days to extract the build scripts into something for home use
[16:57] <mopdenacker> dcordes: I'm interested in generic instructions, but we will use them on Blaze and Panda.
[16:58] <dcordes> mopdenacker: for generic stuff I guess it will be best to use rootstock and put custom kernel etc
[16:58] <mopdenacker> ogra_cmpc: perfect, thank you very much! This will also help us to make the image work on eMMC storage, and to help you with the kernel flashing scripts.
[16:58] <ogra_cmpc> mopdenacker, a good first step is to get familiar with livecd-rootfs, the other scripts are just wrapping around the resulting image
[16:59] <dcordes> mopdenacker: I am also interested in such instructions though - because as of now I am unable to produce a fully functional image with rootstock. I am wondering how the daily autobuilds are produced.
[16:59] <mopdenacker> ogra_cmpc: right, this makes sense. We can parallelize.
[16:59] <ogra_cmpc> yeah
[17:02] <dcordes> ogra: So that howto of yours will cover how to manually create complete images like http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100830/maverick-preinstalled-netbook-armel+omap4.img.gz ?
[17:04] <ogra_cmpc> dcordes, well, you can set up a debian-cd cofiguration and have a livefs builer machine running livecd-rootfs already, i'm just extracting the related debian-cd scripts into a separate omap4 build script for mopdenacker
[17:05] <dcordes> ogra_cmpc: is the script available ?
[17:05] <ogra_cmpc> read above :)
[17:05] <dcordes> :)
[17:05] <ogra_cmpc> livecd-rootfs creates the filesystem image, debian-cd the partitioned one
[17:05] <ogra_cmpc> but you need powerful HW
[17:06] <ogra_cmpc> livecd-rootfs is all native
[17:06] <dcordes> script being 'separate omap4 builds cript'
[17:06] <ogra_cmpc> i will make that available, yes
[17:06] <ogra_cmpc> but it already is ... as a part of debian-cd
[17:07] <dcordes> That's the answer I was looking for. Thank you.
[17:09] <dcordes> I'm always a friend of transparency in such projects, that's why I was wondering.
[17:11] <GrueMaster> ogra_cmpc: I'm finally up-to-date with all of the daily images.  Anything I should know as I start whacking away?  XM is already booting second stage of first boot.
[17:11] <ogra> GrueMaster, only that the settings package fix just got accepted today so only tomorrows image will have a proper netbook session
[17:11] <ogra> beyond that, file bugs as you find them :)
[17:12] <GrueMaster> Ok.
[17:12] <dcordes> ogra_cmpc: Will you anounce the publication of the script / instructions somewhere ?
[17:12] <GrueMaster> dcordes: It will more than likely be part of the release notes.
[17:13] <ogra> dcordes, no, i'll put it on the wiki, its actually rather a personal favour i do for mopdenacker and really not targeted at anything else but omap4
[17:13] <dcordes> GrueMaster: Hello. I created bug 626055 on your proposal. Can you take a look and maybe confirm it if you find a minute ?
[17:13] <ubot2> Launchpad bug 626055 in ubiquity (Ubuntu) "oem-config: make on-screen keyboard available (affects: 1) (heat: 3442)" [Undecided,New] https://launchpad.net/bugs/626055
[17:13] <dcordes> ogra: Ah I get the idea :)
[17:14] <ogra> its not the job of oem-config to make a11y functionallity available
[17:14] <ogra> on the "normal" ubuntu images thats done by selecting assitive technologies at boot time
[17:14] <ogra> which then makes gdm spawn the necessary bits
[17:15] <dcordes> ogra: Can you elaborate selecting assitive technologies at boot time ?
[17:16] <ogra> on the initial screen you have on the normal ubuntu isos
[17:16] <GrueMaster> Actually, Colin Watson re-targeted the bug to ubiquity (parent source of oem-config).  Other than that, I can bump the importance and milestone, but there is enough info for the dev's to go on I think.  Thanks.
[17:16] <ogra> anyway ... off for the evening
[17:19] <dcordes> ogra: aha ok. But if you read the bug you will notice it is not about "normal" ubuntu images
[17:20] <dcordes> GrueMaster: No, thank you. I was just worried about it not being seen because of the undecided importance.
[17:22] <GrueMaster> First step is to file a bug.  Then the bug triagers can reset priorities, etc.
[17:29] <GrueMaster> dcordes: What kind of network bandwidth do you have?
[17:30] <dcordes> GrueMaster: Unfortunately my dormitory SDSL connection is rather slow as it's shared between many
[17:31] <dcordes> Downloading http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100830/maverick-preinstalled-netbook-armel+omap4.img.gz right now at ~30KB/s
[17:31] <GrueMaster> I was thinking that you could setup your desktop to mirror the armel packages from maverick and let it pull overnight when bandwidth is more readily available.  Then keeping it updated is trivial.
[17:32] <GrueMaster> Painful at first, but a lot of gain in the end.
[17:32] <dcordes> GrueMaster: That's an awesome idea. I can always take my laptop to the library and get ~5mbit download speed for such one time purposes
[17:33] <dcordes> GrueMaster: Do you know where I can find documentation on that ?
[17:44] <GrueMaster> Not offhand.  I had to learn the hard way, before I found a document doing a google search.  For your needs, apt-mirror would pull in a copy of everything by distro (lucid, maverick, etc) and pool (main, universe, multiverse, etc).  Once you have a copy, it can get updates very fast with little bandwidth.  You can then use approx to have your dev system pull packages from your local copy without modifying sources.list.
[17:45] <GrueMaster> I also use ubumirror, but it will pull down everything (and I do mean everything).
[17:47] <GrueMaster> My mirror which has everything to build complete images of Lucid & Maverick for armel is 135G.  But that includes universe & multiverse.  For base images & maverick only, just pull main.  Should be around 15-25G max.
[17:48] <dcordes> I think I will do that after my vacation. Then I will hopefully also have a laptop that has a battery :)
[17:48] <dcordes> ~in 2 weeks
[18:46] <GrueMaster> rsalveti: You around?  I'm getting an error on my XM.  BUG:  Soft Lockup - CPU#0 stuck for 61s! [alsa-utils:577].  Will deep dive unless it works for others (could be my hw).
[19:18] <rsalveti> GrueMaster: back now
[19:19] <GrueMaster> ok
[19:20] <rsalveti> GrueMaster: can you paste the full log?
[19:20] <rsalveti> GrueMaster: does it happen with latest image?
[19:21] <rsalveti> my xM is up for 4 hours already and didn't happen
[19:21] <rsalveti> but depends on the kind of activity you were doing
[19:21] <rsalveti> mine was just idle
[19:23] <GrueMaster> This was before oem-config came up, but after rootfs resize & reboot.
[19:23] <dcordes> What is the strategy about updating the ARM kernel packages ? Are you aiming for bleeding edge code to enable more features ? Stability ?
[19:25] <rsalveti> GrueMaster: hm, didn't see it, but can try again
[19:25] <rsalveti> GrueMaster: do you have any other message or just this one?
[19:26] <GrueMaster> Well, could be my hw.  Same sd moved to beagle boots through oem-config fine.
[19:26] <GrueMaster> Will finish oem-config and move back.  Better able to debug with a user account.
[19:26] <rsalveti> GrueMaster: possible also
[19:26] <rsalveti> sure
[19:29] <GrueMaster> hmmm.  no gdm on beagle.  possibly due to updated netbook-launcher-efl settings recently checked in?
[19:29] <rsalveti> GrueMaster: pre-installed image or by update?
[19:30] <rsalveti> with latest image I was able to install at my c4 with no problems
[19:30] <rsalveti> the latest netbook-launcher-efl settings just got to the archive
[21:08] <rsavoye> would 10.04 or 10.10 run on a Sharp NetWalker ? new toy...
[21:09] <rsalveti> hm, sharp netwalker...
[21:09] <rsavoye> portable build machine I hope
[21:09] <rsalveti> rsavoye: do you know the specs?
[21:09] <rsalveti> imx515
[21:10] <rsavoye> 800Mhz i.mx51, 4GB SSD, it comes with jaunty
[21:10] <GrueMaster> iirc, it was preloaded with Jaunty.  Would require some kernel tweaking to get it to run Lucid.
[21:10] <rsalveti> nice
[21:10] <rsalveti> yep, the kernel and bootloader is always the same mess
[21:11] <rsalveti> that's why linaro is up there now trying to fix most of these issues
[21:12] <kblin> right
[21:12] <rsavoye> on my SmartTop, I'm running Maverick user space on the older karmic kernel, so was hoping to do that with the netwalker
[21:12] <rsavoye> google says the custom kernel was done by Canonical :-)
[21:13] <kblin> rsavoye: ah, easy then. just buy the company and have them fix it for maverick then
[21:14] <rsavoye> kblin: I think it's being done anyway :-)
[21:14] <rsavoye> I just can't wait that long :-)
[21:14] <GrueMaster> rsavoye: You should be able to take the kernel it has and compare it with the stock jaunty kernel for imx51 and go forward.
[21:15] <rsavoye> yeah, I'm download the src now
[21:15] <rsavoye> on the SmartTop, I just changed the repos to maverick, upgraded, and it survived the process
[21:17] <rsavoye> ultimately, I was hoping to run unity
[21:22] <rsavoye> http://translate.google.com/translate?hl=en&sl=ja&u=http://d.hatena.ne.jp/fslasht/20100714&ei=jxJ8TKjxO839ngeC2pGdCw&sa=X&oi=translate&ct=result&resnum=8&ved=0CDgQ7gEwBzgK&prev=/search%3Fq%3Dnetwalker%2B%2Blucid%2Bupgrade%26start%3D10%26hl%3Den%26client%3Dfirefox-a%26sa%3DN%26rls%3Dorg.mozilla:en-US:official%26prmd%3Ddf
[21:22] <rsavoye> 10l04 on NetWalker supposedly
[21:30] <prpplague> just as  a reminder, i am trying to finish up on the hardware features for the bamboo board, feel free to post comments suggestions - http://www.elinux.org/Panda_Bamboo
[21:39] <GrueMaster> prpplague: If possible, you should post at least a rudamentory mockup case that has leds & button on it.  Doesn't need to be final, but it would help convey the idea.
[21:40] <prpplague> GrueMaster: hmm, ok, i'm not an artsy type, i'll see what i can do
[21:40] <prpplague> GrueMaster: my main concern was the actual hardware features
[21:40] <GrueMaster> Understood.
[21:47] <prpplague> ndec: i have an updated L24.9 branch for panda - http://gitorious.org/pandaboard/kernel-omap4/commits/L24.9
[21:47] <GrueMaster> Let me mess with the base image of yours and I'll see if I can come up with an "artitst rendition".
[21:47] <ndec> prpplague: hi
[21:47] <prpplague> GrueMaster: i'll try and take a picture of the board
[21:47] <ndec> prpplague: what's new?
[21:48] <prpplague> ndec: about 20 or 30 new grey hairs (which is most of the hair i have left)
[21:48] <ndec> prpplague: that doesn't sound too good...
[21:48]  * prpplague jokes with ndec 
[21:48] <prpplague> ndec: i've applied a bunch of fixes from robclark  the that branch
[21:49] <prpplague> ndec: support for the DVI displays and HDMI should be alot more robust
[21:49] <prpplague> ndec: you should be able to cherry-pick some for your kernel builds
[21:49] <ndec> prpplague: on our Dell DVI displays, we have noticed that the resolution picked at boot was not the best one (too small)
[21:50] <prpplague> ndec: even with robclark 's patches?
[21:50] <ndec> prpplague: and on 1 HDMI screen, only the top half of the screen was used
[21:50] <ndec> prpplague: no, without them. well with the ones from a few days back... should that be better now?
[21:51] <prpplague> ndec: yea robclark 's done alot of work cleaning up the hdmi/dvi support - http://gitorious.org/pandaboard/kernel-omap4/commits/L24.9
[21:51] <prpplague> ndec: we've tested a handful of displays that were known to be an issue
[21:51] <ndec> prpplague: ok. i will be working from home without panda tomorrow ;-) so sebjan will give this a try.
[21:51] <prpplague> ndec: any testing/feedback would be appreciated
[21:51] <ndec> prpplague: for sure...
[21:51] <prpplague> ndec: gotcha
[21:53] <prpplague> ndec: if you and sebjan have time, some feedback on the bamboo accessory board would be appreciated as well - http://www.elinux.org/Panda_Bamboo
[21:57] <robclark> ndec: the reduced vertical resolution is likely a symptom of framebuffer that is shrunk due to insufficient vram
[21:57] <robclark> in addition to omap.vram=... you also need to give vram=...
[21:58] <robclark> brb
[21:58] <ndec> robclark: that could be that... what's the min vram for 1080p?
[21:58]  * prpplague makes a note of that symptom
[21:58] <prpplague> ndec: min recommendation for the panda is to allocate 16MB
[21:58] <prpplague> ndec: but we normally test with 32MB since i have multiple FB's running
[22:18] <robclark> ndec: 8MB
[22:18] <ndec> robclark: thx.
[22:31] <persia> rsavoye, The .jp article you link talks about running lucid on a jaunty kernel on netwalker.
[22:32] <persia> ogra, The more common use case for enabling a11y with oem-config would be pre-installed machines where users did not have the option of enabling a11y earlier in the process (likely not a maverick thing)
[22:33] <persia> dcordes, The images are really built from livecd-rootfs and debian-cd for transparency: any one-off script produced is unlikely to either precisely match the infrastructure build instructions, or be kept up-to-date (although it may be useful as a one-off).
[22:33] <rsavoye> persia: I'm going to probably try it after making a backup
[22:36] <persia> rsavoye, OK.  You could also just prepare a live image on SD for testing: take a look at the recovery image to see how the kernel & filesystem must be placed/named, then construct an SD that doesn't install, but rather provides a live experience, then boot that with the double-mouse-button trick.
[22:36] <rsavoye> good idea
[22:37] <rsavoye> are there live images for ARM ?
[22:40] <GrueMaster> rsavoye: We have a live lucid image for imx51, but I make no promises it will work for your needs.
[22:41] <rsavoye> I found a 9.10 image for the i.MX51,
[22:41] <rsavoye> on my other iMX51 system I;m running a maverick user space on the karmic kernel and boot loader
[22:41] <persia> rsalveti, The live images published at cdimage.ubuntu.com are in a completely different format than those required by the bootloader on the NetWalker.
[22:41] <rsavoye> but I'll gladly try the lucid one just so we know :-)
[22:42] <persia> And the lucid Ubuntu imx51 kernel was never safe to run on the NetWalker.
[22:42] <rsavoye> maybe I'll stick to the karmic one
[22:42] <persia> That either.
[22:42] <persia> None of the Ubuntu kernels are safe to run on the Netwalker.
[22:42] <rsavoye> oh, bummer
[22:42] <persia> You can use a Sharp kernel or a Canonical kernel safely, but those are for Jaunty.
[22:43] <rsavoye> I'm compiling the jaunty araneo kernel now
[22:43] <persia> You can mix that with newer userspace, expecting some bugs (which is why I recommend a live environment to test first)
[22:43] <persia> Why recompile?  Binaries are available.
[22:43] <rsavoye> I like the live test idea too
[22:44] <rsavoye> when I screwed up my other imx51 it took a while to fix
[22:45] <rsavoye> binaries from where ? I didn't find any
[22:46] <persia> I always used the Canonical kernels, from http://netbook-remix.archive.canonical.com/updates/pool/public/l/linux-fsl-imx51/
[22:47] <persia> I believe the "araneo" kernels are for the clamshell, and the "sendai" kernels for the tablet.
[22:47] <rsavoye> I have the clamshell version
[22:47] <persia> But I've only used the "araneo" kernels myself, so I can't be sure.
[22:50] <persia> Alternately, if you grab the recovery image, the kernel on that ought to be fine for doing a test run against a newer rootfs.
[22:50] <rsavoye> downloading araneo19 tarball...
[23:08] <rsavoye> persia:  should I install one of the arfaneo debs on an x86 machine to make the live SD card
[23:09] <rsavoye> I wound up with the kernel source instead
[23:09] <persia> The tar.gz is the source :)
[23:10] <rsavoye> yeah, I noticed; _)
[23:10] <rsavoye> I already had that
[23:10] <persia> OK.  First, let me say that my Netwalker had an unfortunate accident involving dishwater, so this is from memory.
[23:10] <persia> I believe the procedure is as follows:
[23:10] <persia> 1) download the recovery SD image from sharp
[23:11] <persia> 2) put that on SD
[23:11] <persia> 3) remove the rootfs from that filesystem (inspect it if you like: it seems to contain some low-level tools to reinstall)
[23:12] <persia> 4) add a replacement rootfs (with the exact same name as the one you removed) to the SD
[23:12] <persia> 5) insert the hacked SD into the netwalker
[23:12] <persia> 6) hold down both mouse buttons and power up
[23:13] <rsavoye> so basically follow the debain directions ?
[23:13] <persia> I've not seed the Debian directions, but yeah, it's likely largely the same.
[23:13] <persia> The key bit being that you don't want to modify the ubifs until you're sure
[23:42] <persia> rsavoye, I've suddenly had a worry: you really want to inspect the rootfs you pull off the recovery image: you need to replace the one with the mini-installer, not the one with the jaunty image.
[23:42] <rsavoye> I'm still making the recovery.