[05:46] hey guys, i have a netwinder with a strongarm processor, SA-110 ... do you think it would be possible to install Ubuntu on it ? [09:53] nexact: No, StrongARM is v4; Debian supports it though [09:54] lool, thanks for the grep suggestion, indeed my grep didnt work [09:55] (i dont know why it worked during my testing yesterday though) [09:56] in the live boot we are sitzing for 80sec at the bouncing progressbar btw ... the actual boot progress once usplash switched takes only 15sec though ... [09:57] ogra: it sounds like there's an issue in some component here [09:57] will be fine for installed systems, but i guess we need to release note the liveimage configuration phase, so people dont think their boot crashed [09:57] ogra: It would be interesting to see what is so much slower on imx51 [09:57] no, casper takes just long on SD [09:57] ogra: It looks like a bug somewhere [09:58] i dont think it is [09:58] casper was always slow [09:59] ogra: One thing I pondered was doing split SD + USB images for imx51; if you think it's only due to slowness of SD (which I find surprizing since it's random access) that might a path to explore? [09:59] its just that you dont see it working with quiet and splash set ... i wonder if we should drop quiet for the live boot [09:59] that gives you usplash but some text lines so you see it's moving on [09:59] how would we do USB images without redboot support ? [10:00] ogra: Well my idea was to split the images for various reasons [10:00] One was U-Boot [10:00] hmm [10:00] The other was the fact that the SD is used as boot media after install [10:00] * ogra doesnt really like that ised [10:00] *idea [10:00] So I had in mind that we'd ship a large USB image and a small SD live boot image which would become the SD boot media [10:01] Basically my issue is that we're focusing on SD because it's the only controllable scenario we found, but it's very limiting in terms of use cases, for instance it doesn't work when you dont have access to the DIP switches / boot SD [10:01] forcing people to download two images *and* making sure both are in sync all the time (at the user, not on cdimage) will be tricky [10:02] Precisely, but I dont think they need to be in sync [10:02] the kernel and initramfs are on the SD [10:02] What I had in mind was using softbootloader here, but sadly it's not ready / working on imx51 [10:02] ah [10:03] well, with softbootloader putting redboot into flash could be worked out [10:03] Anyway, I just had in mind to have more versatile images rather than a huge SD blob [10:04] something for karmic+1 [10:04] lets have a spec ;) [10:04] ogra: But the time it takes to get out of the initramfs is still worryingly slow [10:04] i would like to move to modular squashfs'es [10:04] ogra: I dont understand what would explain such a slowness really [10:04] its casper [10:04] ogra: You have a SD card reader on your laptop right? I wonder whether you could try booting from that and see how fast it is on x86 [10:05] its doing a ton of stuff to be as generic as possible [10:05] Still this is supposed to be a capable netbook base board [10:05] you cant compare my 2.5GHz laptop with 3G of ram with a babbage board [10:05] i didnt do any installs yet, its on my list for next week [10:05] but i'm 90% positive it will boot in 20-30 secs to a desktop [10:06] rather 20 than 30 ... [10:06] I can compare them, I actually do :) I see it was taking a minute in the initramfs which is more than 10 times than what it takes on x86 [10:06] the slowness is caspers ton of scripts ... we might only need half of them [10:07] but that needs some very special hacking i guess [10:08] hmm, which libc ends up in initramfs on armel would be intresting to research [10:08] we might win something by making sure it's the vfp one [10:09] It used to be and that used to be incorrect :) [10:09] It was fixed to not take the vfp one; we could take both though, but it's not worth changing that since we're dropping the vfp glibc soon [10:09] oh ? [10:09] yeah [10:10] indeed, since everything will be vfp [10:10] so lets see where that gets us speed wise ... and lets research how much it takes to limit the casper scripts ... [10:11] i.e. we definately dont need to run dpkg-rexonfigure xserver-xorg ... it takes ages and we have an empty xorg.conf anyway [10:11] thjen there is some gpg key generation that takes very long [10:11] no idea why we dont dump them in the livefs at livefs buildtime [10:12] (i think it's the archive keys, but i didnt look deep into it yet, i only see the messages at boot) [10:12] Wow yeah we really dont want to generate a gpg key on boot, what's that for?? [10:12] I dont find that in casper [10:12] configuring KDE should be made conditional as well, it takes a while too [10:13] as i said, i didnt reseaerch that yet [10:13] will do so next week, for now my focus was to hide that stuff :P [10:14] casper should get a general cleanup next cycle, like keybuk is doing with initramfs atm [10:14] it collected so much cruft [10:16] Begin: Adding live session user... takes nearly 10sec [10:17] Begin: Setting up console keyboard... takes long [10:17] Begin: Configuring X... does too [10:17] Begin: Regenerating SSL certificate... is the gpg stuff i guess [10:17] ah, no it isnt [10:18] http://paste.ubuntu.com/261856/ [10:18] gpgv: Can't check signature: timestamp conflict [10:18] there we go [10:20] keyboard and live session user are the longest parts [10:21] We're still hit with clock issues :-( [10:21] Begin: Set ubiquity favourite for UNR... [10:21] ogra: I wonder whether we should set the clock in a casper script on imx51 [10:21] tsk [10:22] why are all these scripts we dont need run on -desktop [10:22] Begin: Disabling unnecessary KDE services... [10:22] Well currently casper isn't aware of what it's booting [10:22] Begin: Disabling trackerd... (do we even still install tracker ??) [10:22] I guess we could change that though; I'd write this up on ubuntu-devel@ though [10:23] i'll do a detailed table of what takes how long in the boot next week ... [10:23] seems its really worth it [10:23] Yup [10:23] we definately still have a keyboard config prob [10:23] i think thats the longest part [10:24] I think I filed a bug about that [10:24] It needs to be looked into [10:24] i also dont understand why we need to generate en_US.UTF-8 on boot [10:24] its done in livecd-rootfs [10:24] what does casper need it for ? [10:26] oh, seems we dont do it in livecd-rootfs anymore [10:27] (we should though) [10:27] It's the default locale [10:27] was probably done to save some CD space [10:27] And we dont have a package with this locale pregenerated [10:27] yes, i know, and we used to call locale-gen in livecd-rootfs [10:28] so the locales were in the squashfs already [10:29] Oh right; I dont know about that change [10:29] ok, i stopwatched the user creation, its actually 13sec [10:30] Begin: Adding live session user... 10sec break ... Shadow passwords are now on. 3 sec break ... [10:30] Tss [10:33] # XXX - awful hack to stop xscreensaver locking the screen (#7150) [10:33] echo 'RUNNING_UNDER_GDM="yes"' >> /root/etc/environment [10:33] heh [10:34] i remember adding that in breezy [10:34] we dont ship xscreensaver since post dapper i think [10:35] * ogra looks at scripts/casper-bottom/10adduser [10:35] it also sets up a lot of kde3 stuff [10:38] well, lots to do next week :)