[00:05] no, still freezes [00:05] I think there is something wrong with "void machine_kexec()", because normal kexec does not even reboot the device [00:07] did you have a look at the patches [00:07] yes, on tf2, RaYmAn removed several calls from that method, because they caused tegra3 to freeze [00:07] there was one to remove an extra flush_cache_all() [00:07] *tf201 [00:07] https://github.com/EnJens/kernel_tf201_stock/commit/6e5043854b55a8552d35d56ed9de414d095cd4d6 [00:08] yes, I removed those [00:08] the outer_inv_all too? [00:08] yes [00:08] spam printks through there [00:09] thats what we did to figure out exactly where it froze [00:09] klog does not get disabled somewhere there? [00:09] afaik it isn't until the very last step [00:09] oh my god) [00:09] I have already done that, but thought klog just gets disabled [00:10] but I don't really remember where was the last printk, have to try that again) [00:11] the other thing you can do is write to a specific register to force a reboot, move it up one spot each time it works until it fails === keithzg_ is now known as keithzg [00:14] last printk which gets into klog is before cpu_proc_fin(); [00:16] hm [00:16] well, let's try to comment it out I guess) [00:49] chm [00:49] no change, still freezes [00:50] maybe it does not even boot anything [00:51] the ramdisk console is not touched, there is still output from the kernel in which I did the kexec -e in there [01:04] tassadar_, pastebin machine_kexec? [01:05] http://pastebin.com/Zea4zUsp [01:07] and the last thing you get is exec8? [01:08] well I would expect that anyway [01:09] that's right [01:13] odd [01:13] if you get to that point it should just work [01:13] I just looked through the code [01:13] Im gonna try to mess with --mem-min [01:14] yeah [01:14] mem-min was a pain from memory [01:14] actually [01:14] does it require any other parametrs? [01:14] from memory I had similar results until I came across where I am [01:14] like ramdisk or something [01:14] um [01:15] well I have it doing commandline zimage ramdisk mem-min [01:15] then kexec -e [01:15] there is no command line in nexus 7's boot image anyway [01:15] cause it is bootloader set [01:15] but that isn't the point [01:16] with the atags patch you need to set it [01:16] even if your --commandline=`cat /proc/cmdline` [01:24] now it rebooted [01:25] yeaaah [01:25] it works! [01:25] it just does not have initrd [01:25] so it reboots [01:25] I'll put one there [01:27] ./kexec --load-hardboot ./zImage --command-line="$(cat /proc/cmdline)" --mem-min=0xA0000000 --initrd=./rd.img [01:27] nice, thank you :) [01:27] shell@android:/ $ cat /proc/version [01:27] Linux version 3.1.10kexec4test-gba0df58-dirty (tassadar@nymeria) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #18 SMP PREEMPT Thu Nov 22 01:01:55 CET 2012 [01:29] there we go [01:31] * lilstevie goes back to trying to write his boot manager [01:32] one last thing - it uses kernel from recovery, right? [01:34] uh? what? [01:34] https://github.com/EnJens/kernel_tf201_stock/commit/e443f15cd73232b78827dc108c1d2ffbd5bc1fb1#L8R1546 [01:36] that must be some left over from the original code, you cannot boot to recovery from kernel space (requires some userspace stuff first) [01:37] but it all depends on what kernel you put in boot, [01:37] kernel in boot must always have these patches, the one which is kexecd' does not, correct? [01:37] I put the kexec kernel in boot because I want to go directly to the boot menu, not have to get to recovery to select [01:38] huh [01:38] the patches to the decompressor and the patches to do the hardboot kexec are all intertwined [01:38] so both must be patched, well, that is not good :/ [01:39] oh wait I see what you mean [01:39] yes, you require 2 patches to the kexec guest kernel [01:40] the decompressor optimization patch (otherwise boots take anywhere from 30seconds to 10 minutes) and the atags patch, otherwise the guest kernel just ends up with the initrd and cmdline of the kexec host kernel [01:40] RaYmAn did say that way back when you started looking === doko_ is now known as doko [01:41] Hello everyone [01:42] I'm trying to install ubuntu server on my pogoplug pro. Is anyone familiar with it? [01:44] pogoplug pro is armv6, ubuntu does not support armv6 processors [01:47] Would debian do it then? [01:47] maybe [01:48] I saw something on the archlinux wiki which makes commenting on that rather difficult to know [01:50] rafase282, there does appear to be a third party project that got debian running on it though, just google around [01:53] yeah I'm googling it around, I'm not a fan of archlinux I prefer ubuntu but i was told it does not support arm6 === zz_chihchun is now known as chihchun [02:01] hm, I should go to bed, it's 3am here [02:01] so, thanks for help and good night === chihchun is now known as zz_chihchun === zz_chihchun is now known as chihchun [07:40] good morning [08:00] hi all. I'm trying to use the kernel shipped by the ubuntu-n7-installer but with my own chroot (debian based). So far I've got a login prompt but the wifi connection failed. I can see from NM's log "unable to read permanent MAC address..." which seems suspicious. Could anybody give me an hint to make the wifi work ? [08:15] fmoreau, you need the wifi firmware [08:17] lilstevie: well I already took from ubuntu rootfs the /lib/firmware directory [08:17] and the modules? [08:17] sure [08:17] the driver seems to load fine but it fails to read the permanent MAC address [08:25] lilstevie: do you know where I can find the kernel source code ? [08:27] google [08:38] fmoreau: The linux-nexus7 source package or, as lilstevie says, Google. [09:26] fmoreau, you need /etc/nvram.txt too [09:26] Which is the most awfully generic name ever. [09:27] or /lib/firmware/nvram.txt, not sure where it lives atm [09:27] Why is that named that? :P [09:27] ask broadcom [09:27] ogra_: Is there a hardcoded reference to that in the binary blobs? :/ [09:27] not sure, might be that you can just change it in the module code [09:28] If so, that might be pleasant. [09:28] i nerver really bothered beyond getting the wlan to work :) [09:28] ogra_: thanks a lot for your usefull suggestion, we'll try it in a couple of minutes. [09:28] s/we/I [09:29] ogra_: Say, if you have any dev boards to sacrifice, can you break one in half and do a dance around it for me? [09:29] heh [09:29] what did you do that deserves this ? [09:29] ogra_: Or some sort of voodoo to promise eglibc will build on the second try, cause I'm not doing another upload just to disable one intermittently-sad testcase. >:( [09:29] Stupid Pandas. [09:30] oh man [09:30] The test passed on the previous 4 uploads, and passed here, so I can only hope it passes on give-back of the current upload. [09:31] Cause there's no reason it should be regressing other than "a Panda was having a bad day". [09:31] as usual [09:31] its really time they get replaced [09:31] andale board? [09:31] Though, I guess I shouldn't be too surprised that a test called "tst-cpuclock2" occasionally fails on an SoC that does aggressive frequency scaling to avoid exploding. [09:31] where do we stand wrt highbank buildds ? [09:32] ogra_: Supply issues. [09:32] any changes? [09:32] ah [09:32] hrw: We really don't want to replace dev boards with dev boards, we're trying to get real server kit that's actually manageable. [09:33] hrw: Besides, replacing dev boards we actively support with ones we don't isn't clever either. That essentially jacks up the cost of the endeavor by the salary of half a kernel engineer for a year or two. [09:33] infinity: sure, but when those will be finally somewhere else then in news articles... [09:34] Also, this particular issue wouldn't be better on andale, or any other dev board. [09:34] we should just go with arm64 in qemu :P [09:34] All ARM SoCs aggressively frequency scale to avoid overheating. [09:34] The solution is to glue heatsinks to them. :P [09:34] ogra_: qemu can't do arm64. [09:34] it will at some point :) [09:34] I heard rumours that panda5 will come with DIY heatsink set [09:34] lol [09:35] infinity: not all, just the fast ones :P [09:35] suihkulokki: Okay, fair. All the ones I'd use as buildds. :) [09:35] and info: "if you run TI kernel, it will work. if mainline then put heatsink until we merge whole PM stuff" [09:35] hrw: Yeah, the 4460 has similar caveats (but didn't come with a heatsink) [09:36] hrw: Still, people using these boards at 100% load (like buildds) should put heatsinks on, or you're not actually getting full clock all the time. [09:36] after playing with Archos tablet (with 4430 and 512MB ram) I prefer to avoid omap4 line [09:36] Maybe I should mail a bag of heatsinks to London and have someone glue one on each Panda. [09:37] you think they dont have heatsinks in the UK ? [09:37] or are canadian ones just colder ? [09:37] ogra_: I think we don't have a datacenter engineer to go shopping and faff about, so the more work I do in advance, the easier it is to convince a sysadmin to wander down and stick them on. :P [09:38] heh, k [09:38] (Plus, for just about anything except teabags, shopping in North America and shipping it to the UK is always cheaper than shopping in the UK) [09:39] not always [09:39] Well, no. Not always. But very often. [09:39] Probably not for 5$ crap heatsinks. [09:40] Unless one shipped by boat. [09:40] Or heatsink mule. [09:40] "Why are those heatsinks in a condom?" [09:41] uuuh [09:41] I really didn't want to imagine that [09:42] :P [09:42] ogra_: Drug mules? Condoms full of heroin in various body cavities? Nevermind. :P [09:45] * ogra_ shudders ... now i regret that i just uploaded the microSD content of my mx6 for you :P [09:45] ogra_: Are you imagining jagged heatsinks in uncomfy places? [09:45] hmm, well, "am still uploading" .... i shoudl upgrade to more than 2Mbit [09:46] i'm trying not to [09:46] lalalala [09:47] and yes, pandas fit a heatsink fine: https://plus.google.com/101339419642360856354/posts/FUzUk5U4kJe [09:51] infinity, http://people.canonical.com/~ogra/mx6/mmcblk0p1.img needs to be dd'ed to the start of the micro SD, http://people.canonical.com/~ogra/mx6/mmcblk0p2.tgz needs to go onto a vfat partition in the card, http://people.canonical.com/~ogra/mx6/ubuntu-precise-imx6-sabre-77f462e.tar.gz is a snapshot of the source tree from kernel.ubuntu.com [09:56] ogra_: Cool. And it boots from the micro or the big slot? [09:58] ogra_ ping [09:59] I am trying to assign https://bugs.launchpad.net/ubuntu-nexus7/+bug/1065644 to someone relevant, is this something foundations should be looking at? [09:59] Launchpad bug 1065644 in ubuntu-nexus7 "plymouth causes a hard reset of the nexus" [Critical,Confirmed] [09:59] infinity, that is a horrible mental picture [09:59] :/ [09:59] lilstevie: You're welcome. [10:00] I think I am going to go afk for a little bit [10:00] to vomit [10:00] :p [10:02] victorp, take me [10:02] ogra-cb__, ? do you mean pick me? [10:02] infinity, micro [10:02] I think I may join lilstevie... [10:02] victorp, err, yes [10:02] lol [10:03] that is a scary though [10:03] t [10:05] ogra-cb__, do you get this bug in your system at all? I dont [10:05] https://bugs.launchpad.net/ubuntu-nexus7/+bug/884041 [10:05] Launchpad bug 884041 in ubuntu-nexus7 "Screen brightness not adjusted when switching from AC to battery" [High,Confirmed] [10:05] as in, it does dim [10:06] it didnt dim for me i think [10:06] ogra_: unfortunatly I already have nvram.txt because its located in /lib/firmware which I have copied earlier .. [10:06] my device is currently slightly borked due to running raring [10:07] so its hard to compare [10:10] fmoreau, well, i would actually rather blame userspace anyway, what are you using to manage the device ? [10:12] ogra-cb__: network-manager. The thing is that the error seems to be related to the driver which can't read the MAC address (that's what suggest the error from the kernel logs) [10:14] that message is normal i think [10:14] infinity, http://paste.ubuntu.com/1376788/ does that look sane (i know i'll mess it up again so please look twice :) ) [10:16] ogra-cb__: I can read this for example : dhd_preinit_ioctls: can't get MAC address, error=-5 [10:24] ogra-cb__: Should do, but please group it with the other ubuntu-preinstalled instead of hiding lubuntu in the middle. :P [10:26] k, i'll move it one up [10:32] ogra-cb__: do you think it could be related to wpasupplicant which is version 0.7.3 in my rootfs wherease version 1.0 on ubuntu one ? [10:33] yeah, something liek that [10:33] ok [10:33] will try to update that package [10:33] if you copied kernel, modules and firmware, there shouldnt be any reason that the kernel side doesnt work [10:34] ogra-cb__: that's what I'm thinking to [10:34] +o [10:34] but since the driver showed some errors... I was tempted to think that the driver was the culprit [10:34] well, i remember seeing some MAC related warnings [10:35] my device is currently unbootable and i'm waiting for a nnew image [10:35] once i booted that i'll check dmesg [10:35] thanks :) [10:36] but actually I dumped the dmesg after booting the ubuntu image [10:36] and there're much less errors than what I'm getting [10:36] hmm, k [10:36] this one is an example: dhd_preinit_ioctls: can't get MAC address, error=-5 [10:44] ogra-cb__: BTW can the userspace be in armv7l whereas the kernel is build in armv7hl ? [10:44] fmoreau: yes, because there is no "armhf" kernel the kernel is the same for amrel and armhf [10:45] should theoretically work [10:46] ok thanks both === chihchun is now known as zz_chihchun [11:10] ogra-cb: same after updating wpasupplicant :( [11:11] ogra-cb: do you think that could be related to initrd ? I actually don't use it. [11:12] not really [11:12] the wlan driver is builtin iirc [11:12] so onlz having the firmware in the right place counts [12:45] can't flashboot dump the 'userdata' partition so I can retrieve some dumped files on my host ? [12:47] sadly it only works in one direction [12:47] there aare the nandroid backup tools [12:48] ogra@nexus7:~$ cat /var/log/installer/media-info [12:48] Ubuntu Raring Ringtail (development branch) - armhf (20121122-11:16) [12:48] ogra@nexus7:~$ [12:48] yay [12:48] * ogra-cb makes a checkmark on bug 1080747 [12:48] Launchpad bug 1080747 in livecd-rootfs (Ubuntu Raring) "Set a build stamp for pre-installed images" [Medium,Fix released] https://launchpad.net/bugs/1080747 [12:50] ogra-cb: sad that could be really usefull sometimes [12:56] yes, i would love to eb abe to create a backup during installlation that you can play back to the device [13:02] ogra-cb: do you know which wpa_supplicant's driver should I use ? [13:08] wext I guess [13:13] ogra-cb, are the drivers in the nvidia-tegra3 package the original r16 ones, or the r16.2 ones? [13:17] ogra-cb: where can I find the source package of wpa_supplicant used on the ubuntu image ? [13:23] ogra-cb, are the raring images installable and usable? I just saw they are on cdimage :) [13:24] fmoreau, apt-get source wpasupplicant or do you want something else? [13:25] I'd like to retrieve it from the web instead. [13:25] http://packages.ubuntu.com/fr/raring/wpasupplicant [13:32] fmoreau, I usually look at LP for that for example https://launchpad.net/ubuntu/+source/wpasupplicant [13:32] there you have links to all versions [13:32] lilstevie, something inbetween, i got them as pre-release weeks before they showed up on developer.nvidia.com [13:33] ogra-cb, ah ok [13:33] janimo, kind of ... still weeding out some bugs with the traball installer and the default settings are still missing (you need a kbd/mouse atm) [13:33] janimo, and it only works for people that can use -S with fastboot [13:34] (doesnt work on all devices) [13:34] janimo, beyond that yes, i just did an install [13:35] (using http://cdimage.ubuntu.com/daily-preinstalled/current/) [13:36] janimo, daily builds are running at 13:32 UTC every day now ... next image should show up at 15:30 UTC or so [13:36] (if i didnt mess it up at least) [13:45] sigh, so using resize2fs on the nexus rootfs makes the sys tem go into a reboot loop [13:46] even when i onlz resize my slightly to small 6G rootfs [13:46] (adding a few MB) [13:46] sad [13:59] ogra-cb: the cmdline in boot.img is "root=/dev/mmcblk0p9 ro console=tty1 fbcon=rotate:1 quiet" but I don't think it's the one which is passed during normal boot (once the installation is finished, is it ? [14:00] fmoreau, it is, but the bootloader prefixes it with some hardcoded stuff [14:01] oh I see [14:06] janimo, ogra-cb: any chance to build an ac100 kernel? [14:06] marvin24_, I can't today [14:06] marvin24_, new code in the branch? [14:06] janimo: not today ... [14:06] I updated to 16r2 [14:07] which fixed the console problem [14:07] marvin24_, well not today but sometimes soon I guess :) [14:07] but introduced a different one ;-) [14:07] janimo: many thanks! [14:07] I wish someone else maintained that kernel in ubuntu I have not been using that device for a long time [14:08] janimo: I would if I had more time [14:08] compiling a kernel isn't the problem [14:08] marvin24_, I understand :) [14:08] uploading is a mess [14:08] or building a package out of it [14:08] grrr [14:08] marvin24_, uploading when it comes to getting upload access? [14:08] no, I mean packaging [14:08] marvin24_, well it is a mess I agree [14:09] I surely could upload it to the project page [14:09] maybe I can setup some scripts to make it easier locally [14:09] marvin24_, at least for getting testers that too would be great [14:09] I keep planning on making an autobuilder of debs for ac100 [14:09] yeah, weekend isn't far away anymore [14:09] but not quite making it :( [14:10] marvin24_, I documented the steps used for the nexus7 kernel which I based on the ac100 one here: [14:10] https://wiki.ubuntu.com/Nexus7/Kernel?action=show&redirect=Nexus7%2FKernelBuild#Building_the_kernel [14:10] it is at least some start, and exactly what I use [14:11] more or less the same as you'd find on the ubuntu or linaro wiki pages [14:11] which it is inspired from [14:11] but it is only for tinkering to make a local deb not the full packaging ritual for ubuntu [14:11] so it is something you probably already know and do anyway [14:12] a different solution would be to add support for both machines in the same kernel [14:12] but I need to check if this would work [14:12] both tegra2 and tegra3 is not really doable in 3.1 eight? [14:13] right [14:13] it's possible in mainline kernel [14:13] but you may be right on 3.1 [14:13] too many IS_TEGRA2x_SOC defines [14:13] I know, that is why I keep hoping we get 3.8 for ac100 in 13.04 :) [14:13] just clone my branch ;-) [14:14] I can also setup some patches against 3.8 [14:14] marvin24_, how close are we to have it working? [14:14] to make display light up [14:14] janimo: we managed to get kexec working on nexus7 last night, is there a chance to add hardboot patches to ubuntu's kernel? [14:14] marvin24_, if you can make ac100 work on 3.8 we get maintenance almost for free [14:14] janimo: only display (backlight and tegra drm) [14:14] and not have to carry a diverging package [14:14] eh, wrong, tegra-drm was merged to 3.8 [14:14] so only backlight left [14:15] well, does it work with the binary drivers is the question [14:15] tassadar_, I am not familiar with what hardboot is? If you get a set of patches it will definitely be at least looked at and considered :) [14:15] janimo: it may not be until 3.9 or 3.10 before this will have a change to get merged [14:15] any none else notices that vger.kernel.org stopped to deliver mails? [14:15] marvin24_, if it works it does not need to be mainlined, we could carry it in ubuntu. But at least have a kernel based on 3.8 as the rest of Ubuntu will [14:16] ok, will try to create a patchset [14:16] marvin24_, that would be awesome [14:16] as long as it supports what 3.1 does I see no reason not to move to 3.8 as well [14:16] ogra-cb: whatever you are seeing on arm (desktop background/ubiquity not appearing for ages) I see in the VM as well. [14:17] same for nexus7 btw but noone has yet looked at porting those changes forward [14:17] xnox, there was aa bug i saw passing by [14:17] kexec-hardboot - normal kexec does not work on some (most?) android devices because of the drivers, so this patch does the same thing as kexec, but with full device reboot [14:17] janimo: well, given that 3.1 broke suspend, we'll be at the same feature level ;) [14:17] not a prio in the current setup, where we just wanted a working device [14:17] marvin24_, ;) [14:17] marvin24_, well, there are no issues on the nexus with suspend atm [14:18] tassadar_, as I said I am not familiar with kexec at all. The ubuntu-kernel team and its mailing list would be a much better place to bring this up [14:18] ogra-cb: yeah, it must be related to nvec code then [14:18] I don't know how nexus7 suspends though [14:18] or at least as a bug with optional patches filed against the linux-nexus7 package [14:25] libO and TB dropped from all armhf images for now [14:25] that shoudll give us a properly sized image === rsalveti_ is now known as rsalveti [14:44] ogra-cb, can the daily images for the nexus7 be used? [14:48] brendand, only manually atm only on devices that can handle oversized images (fastboot -S) and you need a kbd and mouse atm [14:48] (most of that should be fixed on monday) [14:48] ogra-cb, do i have one that can handle oversized images? [14:48] ogra-cb, keyboard - check, mouse - check [14:49] no idea, we're not sure which ones can and which cant [14:49] i haven an 8G one that definitely can [14:49] *have [14:49] waht model do you have ? [14:49] i think the *g ones didnt have issues with it [14:50] 8G [14:50] Bug 1079729 has a manual step by step guide [14:50] Launchpad bug 1079729 in ubuntu-nexus7 "Ubuntu uninstallable on 32GB 3G Nexus 7" [High,Confirmed] https://launchpad.net/bugs/1079729 [14:51] (you need -S 630M for the flash userdata call) [14:52] ogra-cb, i got mine at UDS [14:53] ogra-cb, if i try, what's the worst that can happen? [14:54] ogra-cb, mine is 16GB [14:55] ogra-cb: hi! what kernel will you be using for 13.04 for omap? are you still planning to have a ti-omap4 branch? [14:56] ndec_, that question better goes to ppisati, i know he wanted to ask robclark for feedback about necessary patches to make PVR work first [14:57] well for PVR only, it's very much possible to use mainline or close to it. [14:57] brendand, it wouldnt fail to find the rootfs and not boot (indeed you can always reflash) [14:57] problems come with h/w video decode and power management... [14:57] ah [14:57] ppisati, ^^^ [14:58] ndec_, what will you stay on ? or is omap4 dead anyway ? [14:58] hehe [14:58] ogra-cb, yeah, should be a matter of 3 or 4 patches to get pvr... I have a pvr branch on my github tree which was a quick/dirty/rush rebase of pvr stuff onto one of my working branches for 3.7.. [14:59] right, i'm not super concerned about video playback, but PM sounds serious [14:59] well.. and PM is much more unlikely to come from mainline soon. [14:59] after all its up to ppisati though [14:59] you can always do mechanical PM (ie. a heatsink) :-P [15:00] hard to distribute heatsinks inside images though [15:00] :) [15:00] true [15:00] active power management with a fridge [15:00] heh [15:00] heheh [15:22] robclark: can you point me to these pvr patches for mainline? [15:22] ndec_: about pm, i'll try to pick all the dvfs stuff and see how much it is [15:23] ndec_: besides, there;s one thing that i never understood [15:23] ndec_: mainline doesn't have DVFS, bu omap2plus work on omap4/panda [15:23] ndec_: shouldn't it melt then? [15:24] not with a heatsink :) [15:24] ppisati, look at https://github.com/robclark/kernel-omap4/commits/pvr at the 2nd thru 5th commits [15:24] ppisati, it probably runs but just not at highest clock speeds [15:25] robclark: ok, i'll do [15:25] and is there a dvfs branch somewhere? [15:26] not sure about dvfs.. I guess there are various branches with different implementations over the years.. I'm not a PM expert, but I guess it somehow ties up in common clock framework and other changes happening upstream so rebasing from an old kernel version might not be so straightforward.. [15:30] ppisati: no there is no dvfs branch that can be easily picked up. [15:31] and don't be confused we have cpufreq support... so you can actually change the CPU freq... but that doesn't change the 'voltage'. [15:31] so in effect, it's DFS, not DVFS ;-) [15:31] and no changing the voltate means that you don't impact the PM... [15:39] is there a limit on the size of the image that fastboot can upload on the N7 ? [15:39] it seems that image > 700Mo make fastboot to be stuck [15:41] ndec_: but correct me if i'm mistaken, when you say that the main problem with mainline is PM, you mean the lack of DVFS, right? [15:42] not just DVFS... thermal management, clock gating, OFF mode... [15:43] and do you have some topic branches for these? [15:43] because, we picked 3.8 for R and i need to collect all the pieces [15:44] even if it's not for 3.8, at least knowing what to pick is enough [15:44] i'll do the rest [16:07] fmoreau, yes, the limit is somewhere between 680 and 700M [16:08] ogra-cb: hmm is there a workaround to upload a bigger file ? [16:08] you can use the -S option when flashing [16:08] but its not very reliable [16:13] what does -S mean ? can't see a description for it in --help ... [16:13] ogra-cb: fwiw, as far as I know, the reason for the limit is that it stores it temporarily on the staging partition - so the limit is the size of that (usually roughly the same as the system partition) [16:14] ah, i always thought it uses a tmpfs [16:30] hmm, should I use the kernel-team mailing list to send patch for nexus 7 kernel? I mean isn't there like arm or nexus7 mailing list? [16:31] no [16:32] nexus is just another ubuntu device, ubuntu-devel, ubuntu-desktop and the kernel list should be used [16:33] okay [16:43] ogra-cb, will fastboot hang if i can't install the raring daily? [16:44] yes [16:44] you need to use -S [16:44] A question. Has anyone here tried to use a usb DVB-t reciever with an arm system? [16:45]