[01:41] <Zero_Chaos> so anyone here using a nexus7 and built a kernel natively? I'm wondering why initrd.img is always so huge that it can't fit
[01:48] <TheMuso> /c/c
[01:48] <TheMuso> Probably because you have extra stuff on your system that makes the initrd bigger when its generated.
[01:52] <Zero_Chaos> TheMuso: not really familiar with how ubuntu knows what to put in the initrd so no clue how to trim it. any ideas?
[01:57] <TheMuso> Zero_Chaos: Without knowing whats installed on your system, its hard to give specific advice. But you could check to see what packages are associated with the files in /usr/share/initramfs-tools/hooks. Those scripts are responsible for helping create the initrd, and adding extra bits to the initrd image. Someone else may have a better idea though.
[01:58] <Zero_Chaos> TheMuso: that sir is exactly what I needed to know. thanks
[01:58] <Zero_Chaos> TheMuso: stupid device is charging right now (killed the wifi so can't ssh to it and charge at once) but soon, soon I'll play with that
[01:59] <Zero_Chaos> TheMuso: note to other, when recompiling the kernel it seems bcmdhd doesn't work so hot anymore. seems to be missing it's nvram file
[02:00] <lilstevie> Zero_Chaos, you probably aren't using the correct config
[02:00] <lilstevie> extract it from /proc/config.gz of the ubuntu kernel to compare
[02:02] <Zero_Chaos> lilstevie: I did. I change it to a module from builtin.
[02:02] <Zero_Chaos> lilstevie: ALWAYS start from a working kconfig ;-)
[02:03] <lilstevie> forgive me I don't mean to accuse that was just some advice given :) point is the nvram file exists in lib/firmware so a new compile of the kernel will not change that
[02:05] <Zero_Chaos> lilstevie: yeah but it will cause failures if, for instance, the loader can't find the firmware when it's not builtin... which it was, and now isn't.
[02:06] <Zero_Chaos> lilstevie: and the caps was a stressing of a point not trying to show anger.
[02:06] <lilstevie> Zero_Chaos, the firmware isn't built in
[02:08] <Zero_Chaos> lilstevie: it was definately for the 4329, I can't double check the bcmdhd right now due to the aforementioned power failure
[02:09] <lilstevie> uh no, I can assure you the firmware does not get built in, and I do not know any bcm4329 devices that do either
[02:11] <Zero_Chaos> lilstevie: since I lack the ability to jump onto the device right now (it's not even in the same state as me) I'll smile and nod. but when my hands get home and plug it back into the network for me we can have it out ;-)
[02:11] <lilstevie> Zero_Chaos, I maintain a kernel for the tf201, which is bcm4329
[02:11] <lilstevie> it is modular
[02:12] <lilstevie> but even if it isn't, if the firmware is not at the specified location it will fail to load
[02:12] <Zero_Chaos> lilstevie: you we are working on completely different devices then? and the one I'm working on claims to have 6100 patches added to it... couldn't be any changes in there.
[02:13] <lilstevie> Zero_Chaos, also, if the firmware was built into the kernel they would not need to distribute it in linux-firmware-nexus7
[02:13] <Zero_Chaos> lilstevie: original kernel worked with wifi, I "zcat /proc/config.gz > /usr/src/linux/.config && make && make modules_install && make install" then some dance to flash the kernel on the dev and the wifi no worky. only change before make was making wifi module
[02:14] <lilstevie> Zero_Chaos, bcmdhd can be problematic when built as a module
[02:14] <lilstevie> just fyi
[02:14] <Zero_Chaos> lilstevie: really... because it's working just so well over here.
[02:14] <Zero_Chaos> lilstevie: any ideas how to make it work? dmesg was crying about missing nvram something or another (should be able to get real text in ~20 min)
[02:14] <lilstevie> can does not mean always
[02:15] <Zero_Chaos> lilstevie: it was sarcasm, it doesn't work at all
[02:15] <lilstevie> :p
[02:15] <lilstevie> bcmdhd doesn't work at all under ubuntu on the tf201
[02:16] <lilstevie> but works fine with android
[02:17] <Zero_Chaos> lilstevie: that's like saying bcmdhd doesn't work in gnome but works in kde. the only thing that affects the kernel wifi modules is the kernel.
[02:18] <lilstevie> actually not the case
[02:19] <lilstevie> there are those userspace libraries that differ between android and ubuntu
[02:20] <Zero_Chaos> lilstevie: and userspace libs affect the kernel wifi module how exactly?
[02:20] <lilstevie> I give up
[02:20] <lilstevie> seriously
[02:23] <Zero_Chaos> lilstevie: fine, leave me bored waiting for a device to hack on. :-)
[05:09] <Zero_Chaos> lilstevie: you still here
[05:09] <lilstevie> yes
   Broadcom 4329/30 wireless cards support
[05:09] <Zero_Chaos> (/lib/firmware/fw_bcmdhd.bin) Firmware path
[05:10] <Zero_Chaos> (/lib/firmware/nvram.txt) NVRAM path
[05:10] <Zero_Chaos> it builds the firmware in
[05:10] <Zero_Chaos> happy birthday
[05:10] <Zero_Chaos> sorry it took so long
[05:10] <lilstevie> nope it doesn't
[05:10] <Zero_Chaos> lol
[05:10] <lilstevie> that is the reference paths to where it will find it in the filesystem when you boot
[05:10] <lilstevie> I dare you to remove those firmware files after the kernel is built
[05:10] <Zero_Chaos> dare huh?
[05:11] <lilstevie> :p
[05:11] <lilstevie> because I know it will be looking for those files in the filesystem
[05:11] <lilstevie> meaning boot after deleting them, you will have no wifi
[05:12] <Zero_Chaos> interesting challenge. I've never in my life seen a driver that allows you to set a random name for the firmware file.... but perhaps this is one like that
[05:13] <lilstevie> you are talking about a driver that is made for android, there is nothing sane about it
[05:13] <Zero_Chaos> I don't see a call to udev to pickup the firmware but I may just be missing it
[05:13] <Zero_Chaos> drivers are made for linux
[05:13] <Zero_Chaos> android is just a cute little gui
[05:14] <lilstevie> android is a userspace
[05:14] <Zero_Chaos> well yes and no, there is still a lot of linux like userspace
[05:14] <lilstevie> android doesn't even use libc, they use their own custom implementation
[05:14] <Zero_Chaos> yeah so does everything embedded, that doesn't mean it's not linux
[05:14] <lilstevie> but still, the driver is for android
[05:14] <Zero_Chaos> it's a userspace driver?
[05:14] <Zero_Chaos> why am I recompiling my kernel then?
[05:14] <lilstevie> as in, androids stupid custom libs, and filesystem layout
[05:15] <lilstevie> up until recently bcmdhd class drivers didn't work with network manager without patches
[05:15] <Zero_Chaos> yeah but nm sucks ;-)
[05:16] <lilstevie> no, in this case it is the driver that sucks
[05:16] <lilstevie> to android it is just an ethernet card interface
[05:16] <Zero_Chaos> well the driver isn't mac80211/nl80211/etc so it's no surprise
[05:17] <Zero_Chaos> yeah, that's why these things are so loved
[05:18] <Ethernin> freakin android is a mess
[05:18] <Zero_Chaos> android sucks like hell
[05:18] <Ethernin> why the hell can't they just make it full blown linux already/?!?!
[05:19] <Zero_Chaos> let's make a pwnphone android rom
[05:19] <Ethernin> and what the hell ever happened to ubuntu mobile anyway??
[05:19] <Ethernin> lol
[05:19] <Ethernin> have u seen um
[05:19] <Ethernin> fuck
[05:19] <Ethernin> what is it called
[05:19] <Ethernin> dsploit
[05:19] <Ethernin> that's it
[05:19] <Ethernin> pentesting android rom
[05:19] <Zero_Chaos> Ethernin: hey
[05:19] <Ethernin> course it does no wireless packet injection whatsoever
[05:19] <Zero_Chaos> Ethernin: dude, check what channel you are in
[05:20] <Ethernin> seriously though, does anyone here know what happened to ubuntu mobile?  are they working on releasing a ubuntu for phones?
[05:22] <lilstevie> fwiw Zero_Chaos I thought you may want a little more real evidence of my claims
[05:22] <lilstevie> module_param_string(firmware_path, firmware_path, MOD_PARAM_PATHLEN, 0660);
[05:22] <lilstevie> module_param_string(nvram_path, nvram_path, MOD_PARAM_PATHLEN, 0);
[05:22] <lilstevie>  /* load firmware and/or nvram values from the filesystem */
[05:22] <lilstevie> the last was meant to be first
[05:23] <Zero_Chaos> lilstevie: I guess it makes some sense though. considering it has to understand that messed up hierarchy in android and the slightly more sane standard linux one.
[05:23] <lilstevie> yes
[05:23] <lilstevie> that is the point
[05:24] <lilstevie> although the config you showed seems to have more than what it is meant to defined
[05:24] <lilstevie> bcmdhd is meant to only be the path to the folder
[05:24] <Zero_Chaos> lilstevie: it was what I pulled from /proc/config.gz
[05:24] <lilstevie> older versions (bcm4329 bcm4330) were full filename
[05:24] <lilstevie> I didn't say it wasn't
[05:24] <lilstevie> it will work all the same
[05:25] <Zero_Chaos> lilstevie: this is from a 3.1.10 kernel, not that old but not new
[05:25] <lilstevie> you missed what I said bcmdhd is new
[05:26] <lilstevie> prior to that it was bcm4329 or bcm4330
[05:26] <Zero_Chaos> lilstevie: oic, interesting
[05:26] <lilstevie> and I am aware about the kernel, this is the newest nvidia is working with at present
[05:26] <lilstevie> which is silly
[05:26] <lilstevie> but meh
[05:27] <Zero_Chaos> yeah, now I just need to hack it up to work with compat-drivers and then no care. :-)
[05:28] <Zero_Chaos> but that seems a lot harder than expected
[05:28] <Ethernin> lilstevie, have u tried recompiling the android kernel with usb wifi options?  / MAC80211 / CFG80211?
[05:28] <Zero_Chaos> Ethernin: we had the alfa working fine yesterday
[05:28] <Ethernin> just curious, i know source is kinda hard to come by as far as i know
[05:28] <Zero_Chaos> Ethernin: it is pretty much the same kernel
[05:29] <Ethernin> ya, the kernel on the android 4.whatever i was working on was something weird like 3.0.8
[05:29] <Ethernin> but ya
[05:29] <Zero_Chaos> Ethernin: considering this kernel is reasonable close to android's kernel, I'm pretty confident if I can make compat-wireless work for it I can do it on android
[05:30] <lilstevie> Ethernin, for the tf201 I do, I compile for most usb wireless devices
[05:31] <Ethernin> dank
[05:31] <Ethernin> well heck, after this nexus 7 ill have to get back to work turning the SG3 into the next pwnphone
[05:31] <Ethernin> at least until jolla comes out with the next N900
[05:31] <Ethernin> the motorolla atrix is not bad either
[05:32] <Ethernin> HTC one x+ is fast but no mircosd, and you can't take out the battery!
[05:33] <Zero_Chaos> Ethernin: moto droid4?
[05:33] <Zero_Chaos> :-)
[05:33] <Zero_Chaos> Ethernin: has a keyboard and good battery life. but it's a bit slow
[05:33] <Ethernin> !?!?
[05:33] <Ethernin> dual core?
[05:34] <Ethernin> ya but isn't it verizon only?
[05:34] <Zero_Chaos> I think not, but not really sure
[05:34] <Ethernin> i looked into droids for a while and pretty sure they're verizon only which is a major bummer
[07:59] <dholbach> good morning
[08:29] <davecheney> raring-29-nov-nexus-7 image is busted :(
[08:30] <davecheney> heroic video corruption once it struggles to the desktop
[08:56] <ogra_> davecheney, yes, known
[08:56] <ogra_> davecheney, thats the reason we are not making much noise about these images yet ;)
[08:57] <ogra_> davecheney, the more important fact is that you got through the installer and into the desktop, thanks for the feedback !
[08:58] <davecheney> ogra_: well, glad I could help
[08:59] <ogra_> i'll add the images to the channel topic once they are good enough for usage
[08:59] <ogra_> (and there will be blog posts etc)
[08:59] <davecheney> cool
[09:00] <davecheney> ogra_: turns out that I have two nexus 7's
[09:00] <ogra_> bug 1065638 btw
[09:00] <ubot2> Launchpad bug 1065638 in ubuntu-nexus7 "Unity panels don't display visuals" [Critical,In progress] https://launchpad.net/bugs/1065638
[09:00] <davecheney> so expect more bug reports
[09:00] <ogra_> yay, great !
[09:00] <davecheney> ogra_: u canonical ?
[09:00] <ogra_> yep
[09:00] <davecheney> me too
[09:01] <davecheney> oh fuck, i just quit onboard
[09:01] <lilstevie> ogra_, turns out that I have no problems with plymouth because I had FRAMEBUFFER=y in my initramfs-tools config
[09:01] <davecheney> trying to make it always on
[09:01] <ogra_> enable the "floating button" option
[09:01] <ogra_> always on will get in your way
[09:01] <lilstevie> ogra_, so yes, it does work with quantal as well
[09:01] <davecheney> yeah, i was trying, but I hit quit, instead of prefs
[09:02] <ogra_> lilstevie, yeah, my prob is that our bootimg cant be bigger than 8M and the wlan driver is compiled into the kernel ... which gives me a 4M vmlinuz
[09:02] <lilstevie> ogra_, yeah ouch
[09:02] <ogra_> setting FRAMEBUFFER pulls enough stuff in to make my initrd to big
[09:03] <lilstevie> ogra_, yeah, understood my initrd is 8MB on its own
[09:03] <ogra_> *envy*
[09:03] <ogra_> but your boot will be slower :P
[09:03] <lilstevie> ogra_, it is the trade off
[09:04] <lilstevie> ultimately I find that it is worth it
[09:04] <lilstevie> but that is my opinion
[09:04] <ogra_> instead of having to hack defaults ? yeah
[09:05] <ogra_> we have way to much useless stuff in our initrd
[09:05] <lilstevie> it isn't only that, from time to time I do find myself using android
[09:05] <lilstevie> which  is certainly much easier to manage
[09:06] <lilstevie> and size
[09:06] <lilstevie> for a very long time I was fighting size with the tf101
[09:06] <lilstevie> at one point I increased the size of LNX purely for the extra space required
[09:07] <ogra_> well, i like to stay with the device defaults where the bootloader defines the partitioning so people dont get issues rolling back to the original OS
[09:08] <lilstevie> yeah well that is what has happened this time
[09:08] <lilstevie> using lvm to tie partitions together means that it is just a wipe and restore with recovery away from stock
[09:08] <lilstevie> -rw-r--r--    1 root     root        7.9M Nov 30 05:39 initrd.img-3.1.10-1-transformer-tegra3
[09:08] <lilstevie> -rw-r--r--    1 root     root        3.5M Nov 16 10:13 vmlinuz-3.1.10-1-transformer-tegra3
[09:08] <lilstevie> wouldn't be possible before
[09:08] <lilstevie> :p
[09:11] <lilstevie> next step though is to trim down the kexec host kernel, I'm sure a lot of the unneeded cruft that is left in the kernel which would be used under normal boot conditions will be slowing boot down
[12:30] <ogra_> xnox, so how about using the compiz wallpaper plugin in ubiquity ?
[12:31] <xnox> ogra_: it already suppose to do it.
[12:31] <xnox> ogra_: but nothing shows up =(
[12:32] <ogra_> oh, i only saw the decoration plugin on your commandline
[12:32] <xnox> ogra_: there is --background as well.
[12:32]  * xnox is not sure if it needs a plugin or just that command line option though
[12:32] <xnox> (or whatever it is --background-img?!)
[12:32] <ogra_>  wm_cmd = ['compiz', '--sm-disable', '--fast-filter', 'decor']
[12:32] <ogra_> thats what i see in the merge request, did you change it ?
[12:33] <ogra_> oh
[12:33]  * ogra_ missed wm_cmd.extend(['--bg-image', background_image])
[12:33] <ogra_> ignore me :P
[12:38] <hrw>  /ignore ogra_
[12:40]  * xnox likes hrw
[13:24] <dholbach> I'm not sure if my last message actually made it here....
 ogra_, is "update-manager -c -d" supposed to work on the nexus7? :)
[13:25] <dholbach>  it presents me with the option to upgrade "your up-to-date, but there's 13.04" and if I click on "update..." it just exits
[13:26] <dholbach> I could just go into /etc/apt/sources.list and dist-upgrade manually, but I thought I'd check the more obvious solution first
[14:21] <ogra_> dholbach, sure, that should work
[14:22] <ogra_> (update-manager)
[14:25] <ogra_> suihkulokki, *all* image/rootfs builder tools should export FLASH_KERNEL_SKIP=true, then flash-kernel will DTRT
[14:26] <ogra_> just make sure to export it somewhere in your live-build config
[14:27] <suihkulokki> sounds greek to me :P
[14:27] <infinity> No, that's markos.
[14:27] <ogra_> hah
[14:27] <suihkulokki> ogra_: you mean the bug is in linaro-media-create that should set FLASH_KERNEL_SKIP=true
[14:27] <ogra_> suihkulokki, exactly
[14:28] <ogra_> that will prevent flash-kernel from trying to flash/write to a bootloader partition
[14:28] <suihkulokki> ok, I'll poke people to do that
[14:28] <ogra_> thx
[14:28] <infinity> How did we end up needing this hack with 3.0, when 2.x was fine in chroots?
[14:28] <ogra_> 2.0 had that too
[14:28] <infinity> Was it in our livecd-rootfs configs back then?
[14:29] <infinity> Maybe I just don't remember. :P
[14:29]  * suihkulokki unsure which one to hate more - flash-kernel or linaro-media-create
[14:29] <infinity> Oh, even livecd.sh had it.
[14:29] <infinity> Alright.
[14:29] <infinity> It's always sucked. :P
[14:30] <ogra_> right
[14:30] <infinity> Althought, we don't suppress anymore, we now dpkg-divert.
[14:30] <ogra_> originally added on 2011-01-26
[14:37] <dholbach> ogra_, it doesn't, but I talked to mvo about it -- nux/unity should land early next week according to didrocks
[14:38] <dholbach> ogra_, they're still working on some test-suite issues
[14:38] <ogra_> i hope so
[14:38] <dholbach> yes, me too
[14:38] <ogra_> i really want to make the alpha1 date with the images
[14:42] <infinity> ogra_: Ubuntu's not doing alphas anyway...
[14:42] <infinity> ogra_: Welcome to raring. :)
[14:43] <ogra_> infinity, i know, but that was my point in time i have set as target for having working images
[14:44] <ogra_> i still like to use milestones for scheduling ;)
[14:44] <infinity> Fair enough.
[14:44] <infinity> I say they should work yesterday.
[14:44]  * infinity waits.
[14:44] <infinity> DO THEY WORK YET?!
[14:44] <ogra_> they do
[14:44] <ogra_> since last week
[14:44] <ogra_> the desktop doesnt
[14:44] <infinity> Who needs that?
[14:44] <ogra_> heh
[14:44] <infinity> Commandline tablets are all the rage.
[15:26] <achiang> dholbach: hi, what time is the meeting today? :)
[15:28] <dholbach> achiang, half an hour?
[15:28] <dholbach> achiang, what's on the agenda?
[15:28] <dholbach> achiang, I'll announce it on the @ubuntudev channels
[15:28] <achiang> dholbach: i think we can do general q&a and also general discussion re: memory leaks
[15:28] <achiang> dholbach: have you read my latest blog entry?
[15:29] <dholbach> yes, I shared it through @ubuntudev too :)
[15:29] <achiang> heh, ok
[15:29] <achiang> kyleN_: ^^
[15:30] <kyleN_> ack
[15:40] <dumby88> RK2918
[15:44] <dholbach> does anyone have their nexus7 on raring already? was onboard deinstalled for you during the installation too?
[15:44] <dholbach> err, upgrade
[15:49] <dholbach> ogra_, can you please reupload onboard into the nexus7 ppa?
[15:49] <dholbach> so it picks up the new python
[15:50] <dholbach> right now it's uninstallable
[15:50] <dholbach> into the raring ppa pocket
[15:53] <dholbach> or maybe upload it straight to the archive :)
[15:58] <dholbach> ^ or anyone else in ~ubuntu-nexus7 really
[15:59] <dholbach> I assume a changelog-only upload, maybe for virtkey too (have to check) will do it
[16:00] <ogra_> why is there an onboard at all in the PPA ?!?
[16:00]  * ogra_ doesnt knwo who uploaded that
[16:00] <ogra_> i have no issues with onboard on the raring images
[16:05] <dholbach> ogra_, you did
[16:05] <dholbach> ah no
[16:05] <dholbach> sorry
[16:06] <dholbach> ssweeny
[16:06] <dholbach> https://launchpad.net/~ubuntu-nexus7/+archive/ppa
[16:07] <ssweeny> I uploaded it at the behest of the onboard devs
[16:13] <ssweeny> dholbach, what's the issue with onboard and python? was there an update?
[16:13] <dholbach> no, but it can not be installed in raring
[16:13] <dholbach> because it wants python << 3.3
[16:13] <dholbach> a simple rebuild should do it
[16:13] <ssweeny> in raring people should be using the archive version i would think
[16:14] <ogra_> why ... the version in raring should outsmart the one in the PPA
[16:14] <dholbach> but maybe we should just get the new version into the archive
[16:14] <ssweeny> unless upstream hasn't released yet...
[16:14] <dholbach> ssweeny: the version in the ppa is higher
[16:14] <ogra_> ouch
[16:14] <ssweeny> ah, hm
[16:14] <dholbach> 0.99~tr1071-0nexus7.1 vs 0.98.2-0ubuntu1
[16:14] <ssweeny> so the version in the PPA is a snapshot of an upcoming release
[16:14] <dholbach> are we in touch with upstream?
[16:15] <ssweeny> i was lead to believe that the release was coming soon and that it would go straight into raring
[16:15] <dholbach> nothing in the sponsoring queue
[16:15] <ssweeny> the snapshot has a fix for the performance issue with the ambiance theme
[16:16] <dholbach> ok, shall I mail upstream and CC you?
[16:16] <ssweeny> that would be great
[16:16] <dholbach> alright
[16:16] <dholbach> will do
[16:19] <dholbach> done
[16:21] <ssweeny> great, thanks dholbach
[16:21] <dholbach> anytime
[17:13] <bootidsa> Anyone here from meetingology today ?
[18:37] <philhug> is anyone familiar with the odroid-x2 or -u2?
[18:43] <Quinto68> hi someone has pcre package for arm?
[18:43] <Quinto68> i have this error
[18:43] <Quinto68> error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
[19:20] <Quinto68> hi someone has pcre package for arm?
[19:20] <Quinto68> error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory i have this error
[19:27] <lardman|home> Is there any thought to provide dual booting ability for the Nexus 7?
[19:27]  * lardman|home looks at the installer script
[19:27] <lardman|home> Ah, I seem to remember someone mentioning that this is often asked.... :)
[19:29]  * Tassadar throws http://forum.xda-developers.com/showthread.php?t=2011403 at lardman|home
[19:31] <lardman|home> this potentially looks to be a better bet: http://forum.xda-developers.com/showthread.php?p=34853595
[19:31] <lardman|home> place the Ubuntu kernel in the recovery partition, etc.
[19:32] <Tassadar> and both android and ubuntu to /data at once?
[19:32] <lardman|home> yeah I'm wondering quite what the deal is there
[19:32] <lardman|home> then again the link you pasted my have changed since I looked at it yesterday
[19:33] <Tassadar> I am not saying that it does not work, just that it is _kinda_ dirty
[19:33] <lardman|home> would be good to repartition and then install Ubuntu to its own one (as I have a 32GB device)
[19:33] <Tassadar> I don't think that's really an option
[19:35] <lardman|home> Tassadar: I wasn't so keen on the multiboot method of copying boot partition everytime
[19:35] <[mbm]> haven't looked at the existing solutions, but it should be pretty easy to create a /data/ubuntu; android will ignore that and the ubuntu initrd would need to be altered slightly to use it as a root
[19:35] <[mbm]> I don't think repartitioning is an option given that I don't see an actual partition table
[19:36] <lardman|home> there are the wonderful pit files iirc
[19:36] <lardman|home> though yeah, sounds quite messy
[19:36] <Tassadar> lardman|home: me neither, but kexec-hardboot compatibility is already in the ubuntu-nexus7 kernel, just waiting for it to actually get to the devices
[19:37] <lardman|home> if one uses chroot then presumably the Android data won't be available?
[19:37] <lardman|home> s/chroot/whatever method to change the location of root
[19:37] <[mbm]> depends on the chroot
[19:38] <[mbm]> one fun trick is pivot_root
[19:38]  * lardman|home tries to remember the difference
[19:38] <[mbm]> which technically only works on mount points
[19:38] <[mbm]> pivot_root differs from chroot in that it's global, not just sub processes
[19:39] <[mbm]> also it places the pervious root directory as a subdirectory of the new root
[19:39] <lardman|home> I had to do that on the Galaxy Tab kernel to move from initrd to rootfs to boot Mer, but can't remember for the life of me now what the diff was
[19:39] <lardman|home> ah yes, that sounds familiar
[19:39] <[mbm]> so a common thing might be: mount /dev/root /target; pivot_root /target /initrd; umount /initrd
[19:39] <Tassadar> I wanted to modify ubuntu as little as possible, so I just move the android to /media/*something* and then move in the ubuntu files :/
[19:40] <[mbm]> normally you can't specify an argument to pivot_root that isn't a mount point
[19:40] <[mbm]> which would make something like /media/ubuntu or /data/ubuntu annoying
[19:40] <[mbm]> the workaround is amazingly simple though
[19:41] <[mbm]> mount --bind /data/ubuntu /data/ubuntu
[19:41] <[mbm]> and magically it's a mount point suitable for use with pivot_root
[19:42] <Tassadar> would be great to get something like that into ubuntu)
[19:42] <lardman|home> +1
[19:42] <[mbm]> yeah, I want to see a nice dual boot solution
[19:43] <[mbm]> bootloader is a different story
[19:43] <Tassadar> also, mounting .img as root would be great, if that's even possible
[19:43] <[mbm]> yep, that's easy
[19:43] <Tassadar> do tell
[19:44] <[mbm]> mount -o loop root.img /target; pivot_root /target /initrd; umount initrd
[19:44] <[mbm]> as in, recompile the ubuntu kernel so that the initrd mounts the correct root device
[19:45] <[mbm]> part I'm trying to figure out is if there's a better way to handle bootup than booting into a linux kernel which provides a kexec boot menu
[19:45] <lardman|home> normal vs recovery partitions?
[19:46] <Tassadar> then you don't even have the boot menu
[19:46] <lardman|home> or you want to leave the recovery partition functionality?
[19:46] <[mbm]> yeah, could put the ubuntu kernel on the recovery partition but then you lsoe access to recovery
[19:46] <[mbm]> would be nice if there was a 3rd partition and entry on the existing boot menu
[19:47] <Tassadar> would be nice if the bootloader was open-source)
[19:47] <lardman|home> :)
[19:47] <[mbm]> yeah, that's the problem
[19:47] <Tassadar> ...and we had nvflash, so that we could not brick it)
[19:48] <[mbm]> frmo what I can tell the hardware is technically locked, and it's simply that unlocking tells the bootloader to ignore signature checks
[19:49] <Tassadar> well, it is nvidia, so...
[19:49] <lardman|home> Is the loss of the recovery partition such a problem - people installing this are going to be used to flashing things I'd expect
[19:49] <[mbm]> not 100% certain on that first part though, don't know if nvflash is all that's needed or if the hardware does a signature check on the botloader
[19:50] <[mbm]> yeah, but it's more of an annoyance thing; if I'm dual booting and I get an ota update to android, it'll download to the /cache partition and then reboot into recovery with the /cache/recovery/command set to automatically apply it
[19:51] <Tassadar> lardman|home: I don't really see the point in using recovery partition once the kexec-hardboot is there
[19:51] <lardman|home> ah, I didn't realise that was how it worked
[19:51] <lardman|home> Tassadar: sure
[19:51] <[mbm]> Tassadar: I know what kexec is, but what's the "hardboot" part?
[19:52] <Tassadar> on most android devices, normal kexec just freezes
[19:52] <Tassadar> due to drivers not properly initializing, probably
[19:52] <[mbm]> well yeah, arm kexec has traditionally been a bit dodgy
[19:52] <Tassadar> so "kexec-hardboot" patch was made, which does full hw restart of the device between the boot
[19:52] <Tassadar> basically "fastboot boot" without the fastboot
[19:53] <Tassadar> gimme a second, I'll find a link to the original patch...
[19:53] <[mbm]> that's interesting; any idea how it manages to avoid going into the bootloader after resetting everything?
[19:53]  * [mbm] grabs some lunch (bbl)
[19:54] <Tassadar> kexec -e saves some info to RAM (some location where it does not get overwritten on reboot), then reboots normaly
[19:55] <Tassadar> the same kernel checks for that info in early state of boot (in the decompressor), and if it is there, it decompresses the kernel from RAM
[19:55] <Tassadar> ...that is how I understand it
[19:56] <Tassadar> http://forum.xda-developers.com/showthread.php?t=1266827 here is the original patch
[19:57] <lardman|home> thanks
[19:58] <Tassadar> the con is that it needs 2 small patches in the "guest" kernel, the one which is being booted with kexec
[19:59] <lardman|home> So the plan would be to place the Ubuntu kernel in the boot partition and need to patch the Android kernel?
[20:00] <Tassadar> both kernels must be patches
[20:01] <Tassadar> *patched
[20:01] <lardman|home> sure, but which is booted?
[20:01] <lardman|home> (first)
[20:02] <Tassadar> I would recommend the android kernel, since it does not get updated so often and can be easily patched.
[20:03] <lardman|home> fine, that makes sense, and presumably one would be able to perform a binary patch on the kernel from Android userspace?
[20:03] <Tassadar> wau
[20:03] <Tassadar> you just want to make it difficult :D
[20:03] <lardman|home> to avoid needing to flash a new kernel whenever an update occurs
[20:08] <lardman|home> re this post, any ideas on what the Ubuntu image does on first boot that might break something if it's in the recovery partition: http://forum.xda-developers.com/showthread.php?t=1266827
[20:09]  * lardman|home goes to look at the image now it's downloaded
[20:09] <Tassadar> well it flashes boot image
[20:10] <Tassadar> which it also does on every kernel/initrd update
[20:10] <Tassadar> so you have to disable that
[20:11] <lardman|home> Not the updater script that runs on the desktop, the image running on the device flashes the boot image too>
[20:11] <lardman|home> ?
[20:11] <lardman|home> s/updater/installer
[20:11] <Tassadar> yes
[20:12] <Tassadar> 12.10 removes the tarball-installer image
[20:12] <Tassadar> and 13.04 will change kernel cmdline during installation
[20:12] <Tassadar> *tarball-installer package
[20:13] <lardman|home> and it can't know where the running kernel is located I guess?
[20:13] <Tassadar> no
[20:14] <lardman|home> ok, well at least that explains the need that chap had to reflash the Android kernel
[20:16] <lardman|home> Is the move to using kexec imminent, or is it worth just hacking together a dual boot setup for the time being?
[20:16] <Tassadar> I dunno where the kernel with patches gets to repositories, so...
[20:17] <Tassadar> *when..ohmygodineedsomesleep
[20:17] <lardman|home> :) I was just trying to parse that correctly
[20:22]  * [mbm] reads over the kexec threads
[20:23] <[mbm]> guessing that the stock recovery kernel isn't patched for hardboot support?
[20:23] <Tassadar> nope
[20:23] <[mbm]> :/
[20:24] <[mbm]> was hoping it would be as easy as replacing recovery with a kexec menu and then using kexec-hardboot to switch between ubuntu and recovery
[20:25] <[mbm]> though there's also the pesky problem of /system/etc/install-recovery.sh which takes the existing "boot" kernel, applies a patch and writes it to recovery
[20:25] <[mbm]> stupid script gets installed by an ota and run every subsequent boot
[20:28] <Tassadar> anyway, heres CM10 kernel with applied kexec-harboot patch: https://github.com/Tasssadar/android_kernel_asus_grouper/commits/kexec-clean
[20:28] <Tassadar> I even submitted it for review to cyanogenmod, hope it get's there
[22:12] <marvin24> ogra_: can we create some nvidia-tegra-dev package with headers needed to compile the gstreamer plugins?
[22:13] <marvin24> I don't want to copy them into the source, because I feal they belong to the drivers package
[22:15] <marvin24> ogra-cb_: ^^^
[22:23] <marvin24> basicly these ones (without the OMX_*) https://gitorious.org/nvtegra-gst/gstomx/trees/master/nv_headers
[23:18] <mjrosenb> ooompf
[23:19] <mjrosenb> I installed ubuntu on my chromebook using the absurd script that repartitons the disk, and fetches a bunch of tarballs
[23:19] <mjrosenb> and its kernel wasn't compiled by ubuntu, was it?
[23:19] <mjrosenb> I bet it just stole cros' kernel
[23:19] <mjrosenb> which explains why I can't install perf on it :/