**** BEGIN LOGGING AT Sat May 21 02:59:58 2011 May 21 10:21:47 ogra_, So, I got a Dynabook AZ: Do we have a wiki page for putting Ubuntu on it? May 21 10:22:06 not yet May 21 10:22:20 its a bit scattered atm May 21 10:22:56 Well, I don't mind fixing that: please point me at some good places. May 21 10:23:07 I'll try for something like the Archos 10.1 or Nokia N900 pages. May 21 10:23:27 first of all its hard to get the flash tool, nvidia shot down their linux supoport May 21 10:23:27 * persia should probably do a page for the Netwalker, but keeps being discouraged by the impossible-to-upstream kernel May 21 10:23:37 Is there a mirror somewhere? May 21 10:24:03 not that i know of, let me put it somewhere for you May 21 10:24:32 Is it licensed in a way that it can be distributed (like stuck on people.ubuntu.com or something)? May 21 10:25:50 i dont think so :( May 21 10:26:29 http://www.grawert.net/nvflash.tgz May 21 10:27:08 i havent written an installer script yet or some such, so itzs a bit more complex than it should be May 21 10:27:10 Received. May 21 10:27:37 removed :) May 21 10:27:53 natty images are at http://people.canonical.com/~ogra/tegra/2.6.37/ May 21 10:28:08 pull the two img files and the non SD tarball May 21 10:28:33 I want SD and non-SD image files? May 21 10:28:57 ah, well, just pull the SD one May 21 10:29:21 the first boot to copy over the rootfs to internal mmc needs to happen from SD May 21 10:29:24 So, SD image file, non-SD tarball? May 21 10:29:27 i plan to script all that May 21 10:29:31 right May 21 10:36:40 persia, once you have the files, untar nvflash ... attach a mini usb cable to the dynabook, hold down ctrl+esc to get into flash mode May 21 10:36:58 (teh backlight stays off, power LED is on ) May 21 10:37:21 go to the nvflash dir ... May 21 10:38:37 sudo LD_LIBRARY_PATH=. ./nvflash --bl ./fastboot.bin --download 6 May 21 10:39:20 if you want to do backups before: sudo LD_LIBRARY_PATH=. ./nvflash --bl ./fastboot.bin --read 5 tegra_partition_6.bin --go May 21 10:39:29 eerr May 21 10:39:34 that should be read 6 indeed May 21 10:39:35 OK. That will be a bit: I'm still doing the first-time-charge thing to train the battery (and expect to do that for at least a few hours) May 21 10:39:44 k May 21 10:40:00 then i'll go back to gardening :) May 21 10:40:22 Once I replace partition 6, should it just boot? May 21 10:40:58 you need to change /boot/bootimg.cfg to the right root= and run sudo flash-kernel May 21 10:41:17 Now I'm confused. May 21 10:41:21 you want to format mmcblk0p7 May 21 10:41:34 part 6 only contains kernel and initrd May 21 10:41:37 So, I have a never-booted device. I replace the .img file with the one you distribute. May 21 10:41:49 Then I boot into that initrd, and run flash-kernel? May 21 10:41:52 the SD image by default looks at the first part on an SD card May 21 10:42:51 you unpack the tarball to that sd ... copy the tarball into it too ... set a root pw or remove the passwd bit from /etc/shadow, boot into the SD and foarmat/untar the rootfs to mmcblk0p7 May 21 10:43:11 as i said, i plan to script all that in an initrd script May 21 10:43:19 currently its all manual May 21 10:43:30 OK. What filesystems do I want for the SD and mmcblk0p7> May 21 10:43:32 i would recommend ext4 btw May 21 10:43:38 snap :) May 21 10:43:59 SD doesnt matter, you throw it away once you have installed to mmc May 21 10:44:17 So, to recap: May 21 10:44:30 my scripted version will essentially do the same i will do for the build cluster May 21 10:44:33 1) nvflash partition 6 with the new kernel/initrd May 21 10:44:42 right May 21 10:44:50 2) untar tarball onto SD and copy tarball into SD May 21 10:44:58 * ogra_ nods May 21 10:45:09 3) boot device holding Ctrl+Esc, which launches environment on SD. May 21 10:45:14 no May 21 10:45:19 that would have been 0 May 21 10:45:30 4) In that environment, untar rootfs into mmcblk0p7 May 21 10:45:35 the device needs to be in flash mode before nvflash May 21 10:45:42 Ah, OK. May 21 10:45:53 So, 3) boot device normally, launching environment from SD. May 21 10:45:58 yeah May 21 10:46:09 5) In that environment, run flash-kernel May 21 10:46:13 no May 21 10:46:16 6) shut down, remove SD, reboot May 21 10:46:44 3) modify /etc/shadow on the SD, *then* boot device normally, launching environment from SD. May 21 10:47:02 there is no user :) May 21 10:47:10 so allow root to log in May 21 10:49:05 OK. And 4,5,6? May 21 10:49:23 4) In that environment, untar rootfs into mmcblk0p7 May 21 10:49:41 5) In that environment, run flash-kernel after modifying the cfg file May 21 10:49:50 reboot ... May 21 10:50:15 What do you need to do to the cfg file? May 21 10:50:45 point root= to mmcblk0p7 May 21 10:50:55 oh, wait May 21 10:50:58 you dont :) May 21 10:51:04 thats only on the SD tarball May 21 10:51:13 your cfg should be fine OOTB May 21 10:51:32 so just flash-kernel May 21 10:51:57 Ah, good. I'll let you know how it goes (and put up the wiki page). May 21 10:51:59 Thanks. May 21 10:52:18 i'll have the script ready by beginning of the week May 21 10:52:45 then it should only be: flash part 6 ... copy tarball onto SD card ... boot May 21 10:53:45 In my ideal vision of the world, at that point you'd be in a ubiquity environment, with partman preseeded to use mmcblk0p7 for / May 21 10:53:59 that would mean live image May 21 10:54:04 Yes. May 21 10:54:35 so also 2min untarring vs cp / (surely about 30min) May 21 10:55:20 If there is that much time discrepancy, we're doing something wrong. May 21 10:55:40 Given a compressed archive of files, we should select the fastest way of delivering it to disk. May 21 10:55:44 well, ubiquity copies the uncompressed filesystem May 21 10:56:05 which by nature takes more time than just untarring May 21 10:56:13 Right, which is naively correct, but may not actually be correct. May 21 10:56:27 I've heard lots of complaints that ubiquity was slow: this may be part of the issue. May 21 10:56:41 well, invent squashcat May 21 10:56:43 ;) May 21 10:57:14 squashcat > May 21 10:57:42 No need: you've just invented it: the rest is an implementation detail. May 21 10:57:48 lol May 21 10:57:53 detail, right May 21 10:58:44 Do you happen to know *why* cp is slower than tar? Is it filesystem consistency checking? May 21 10:59:03 cp operates without compression May 21 10:59:21 it just copies from the loop mounted / May 21 11:00:29 anyway, let me go back to gardening ... i'll be back May 21 11:00:47 No worries. It's just theory at this point anyway :) May 21 11:01:20 * persia adds to the list of things to do one day running time and strace (separately) on cp, tar, and rsync delivery of files May 21 14:28:25 ogra_, Obviously MMC performance changes things, but results for image-mount -> HD on amd64 for natty-desktop i386 squashfs supports your assertion: http://paste.ubuntu.com/611065/ May 21 14:30:03 I'm not sure what happened with "real" times: I suspect something took advantage of the "idle" state during the rsync run: prior attempts showed it to be more "real" similar to cp (although the other numbers don't seem to have been affected as much) May 21 14:42:13 ogra_, On another note, nvflash doesn't seem to work for me :) **** ENDING LOGGING AT Sun May 22 02:59:58 2011