[12:20] ogra_, you really should change that 30min estimation to 5min in the tarball unpacking message :) [12:21] * janimo is installing today's ac100 image === hrw is now known as hrw- [12:22] janimo, heh, ok === hrw- is now known as hrw [12:23] getting into X in the installer is noticably slower than in precise [12:23] at one poits it's at console login as if no X is gonna start [12:23] the initrd somewhat takes longer [12:23] ubiquity-dm was always slow though [12:23] this was after starting userland on root, not sure it was the initrd [12:23] lightdm is fine [12:24] X seemed slow to paint [12:24] well, the time it takes from booting to the fsck messages [12:24] thats significantly longer ... [12:24] and i fear on all arches [12:25] getting to fsck took longer a bit, but then another 2 min until X [12:25] installer enocuntered unrecoverable error :( [12:25] * janimo checks logs [12:26] I wish there was a way of logging in/starting a shell to debug when this installer crashes [12:27] 'a desktop session will be run so that you may investigate' but that too crashes [12:30] wow, my install worked fine OOTB here [12:30] which image did you use ? todays ? [12:30] ogra_, today's yes [12:35] weird [12:35] no installer issues at all here [12:36] the screen doesnt wake up properly after DPMS kicked in though [12:36] (just noticed) === awafaa_ is now known as awafaa [12:48] janimo, bug 1026577 ? [12:48] Launchpad bug 1026577 in ubiquity "ubiquity crashed with TypeError in _execute_child(): Can't convert 'list' object to str implicitly" [Critical,Fix released] https://launchpad.net/bugs/1026577 [12:48] even though i didnt see it here, it is obviously in these images) [12:49] ah, no, ubi-partman [12:49] ignore me [12:58] ogra_, how hacky/hard would it be to provide a login shell before the install is complete? Ubuntu has a live desktop with ubuntu user where you can look around at will [12:58] pretty hackish and hard [12:59] (and really nothing i want to invest time in) [12:59] ogra_, what caused the crash last time was trying to use wifi, let's see what happens this time when I skip that [12:59] weird, worked all fine here [12:59] ogra_, I agree then, if there is time to invest it should be towards unifying with the ubuntu live installer [13:00] I kept pushing connect and it did not [13:00] the only issue i currently see is DPMS and plymouth [13:00] if I connected from the NM icon in the panel it worked [13:00] but then crashed [13:00] weird [13:00] the page doesnt automatically move forward after it connected [13:00] oh now it went ahead did not even ask about wifi [13:00] but the button changes [13:00] ogra_: that's a tegrafb bug [13:01] switch to X and back may help [13:01] janimo, is that a freshly unpacked tarball or just the failed install rebooted [13:01] ogra_, failed install rebooted [13:01] if its the failed one, debconf definitely keeps your input [13:01] so thats normal ... [13:02] ok, now it installs [13:02] still a bug but maybe it's in the logs somewhere [13:02] marvin24, thx, it does indeed [13:02] yeah [13:02] might be HW though [13:02] the nv guy seems to have given upon the console problems as it seem [13:02] I got no reply from him for a few days [13:03] * ogra_ just built an lzma compressed kernel ... curious if that will work [13:03] marvin24, do you know of any source for a README or HOWTO what needs to be switched on in the kernel to make the binary driver work ? [13:04] i suspect our kernel still doesnt have everything needed and would like to find out if its a config prob [13:05] nv added a lot of options, yes [13:05] I guess some tegra_defconfig should be sufficient [13:05] is that documented anywhere ? [13:05] hmm, k [13:05] arch/arm/configs/... [13:05] ogra_, maybe getting the kernel image from the L4T package and seeing what config it has enabled would help? [13:05] janimo, i would, if i could :) [13:06] is there a new l4t release? [13:06] nvidia downloads are completely shut down since the hack [13:06] marvin24, only R15 final [13:06] marvin24, L4T 15 final of a week or so ago [13:06] i think you know about it [13:06] lilstevie, said the actual download links still work, just the site frontend/logins is stopped [13:06] we already have it in quantal, but x fails [13:06] it's just that we don't know the link URLs :) [13:07] janimo, well, doesnt help if i want to lok for a readme [13:07] i know the url [13:07] ogra_, if there's a kernel image in the URL that may have configs already [13:07] but the README contained doesnt talk about kernels at all [13:07] which we can compare with ours [13:07] ogra_: I have most of the documentation on hand [13:07] what is it about the kernel that you are interested in [13:07] yes, it might be in the softfloat package [13:08] yeah [13:08] itttt is [13:08] but I also have the documentation package that is just the docs [13:08] lilstevie, on ac100 lightdm gots in a crash loop ... killing lightdm and running startx gets me a desktop but as soon as i click something it crashes [13:08] *goes [13:08] quantal only? [13:08] yep [13:09] ABI12 [13:09] ogra_: so we are left with tegra_android_defconfig [13:09] hm [13:09] marvin24, hmm, android doesnt use the xerver, do they ? [13:09] well as far as the docs say as long as you are using l4t-r15-rc tag it should be fine [13:09] no, but that's the only tegra2 config I found [13:10] is our kernel at that tag ? [13:10] as of r15 they rolled the DC code to be a common base [13:11] ogra_: no, we are further in the future ;-) [13:12] rel-15r7 [13:12] (branch) === satellit-arm is now known as satellit [13:12] tegra-15r7.1-android-4.0 [13:12] tag [13:13] marvin24, lilstevie actually with the last update we are at origin/l4t/l4t-r15 [13:14] I rebased on what I learned was very latest and recommended with L4T drivers by nvidia [13:14] janimo: so you stepped back? [13:14] marvin24, is that back?? [13:14] rel15r7 is 4 weeks old [13:14] l4t/l4t-r15 is 7 weeks old [13:14] I hate nvidia tag/branch naming scheme [13:15] http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git [13:15] janimo: yes, this is very confusing [13:15] marvin24, so 15r7 is the one that goes with L4T final? [13:15] I think they have different l4t and android branches [13:15] they seem to maintain these things in parallel and not talk to eachother [13:15] I thought from the most recent discussion with lilstevie that the branch I used was [13:15] janimo: technically no [13:15] oh well [13:16] l4t and android may have different branches, yes [13:16] I used the android one because it seemed to me that it has more fixes [13:16] I tried avoiding the android branch for that reason [13:16] by that reason being - it goes with L4T [13:16] no idea what the diffs are [13:16] works fine here ... [13:17] marvin24, this branch of yours is newer that what we had last week in ubuntu? [13:17] I haven't seen the new hdmi stuff in the newer rel-15r7 code from android [13:17] mine is based on tegra-15r7.1-android-4.0 [13:18] while you seem to have used tegra-l4t-r15-rc [13:23] ogra_, so ac100 install finished just as usual the first thing it does is crashes and invokes apport [13:30] lol [13:30] well, if you had a ubiquity crash there is a core dump in /var/crash on first start [13:30] apport just picks that up [13:44] WOW !!!!!! === ahs3` is now known as ahs3 [13:44] building the kernel lzma compressed saves 1MB ! [13:45] if that actually works, i could leave plymouth ion the initrd and drop all the ugly diversion hackery [13:45] and it does ! [13:46] ogra_: I have been building my kernel lzma'd for a while now for size reasons [13:46] lilstevie, right, it was never clear if the ac100 fastboot can handle that [13:47] kernel decompresses the initrd [13:47] i had mixed results in the past (though testing initrds, not kernels) [13:47] well the kernel decompressor code does it [13:47] fastboot only has the 2MB limit [13:47] so you may have ran into this problem [13:47] i had initrds failing with the old kernels when trying out other methods than gzip [13:47] (2.6.29 etc) [13:48] you need to select the decompressor in the kernel config [13:48] for the initrd it just needs to be enabled [13:48] older kernels didn't support so many (only gz and bz2 I think) [13:49] and we always had lzma available as inbitrd compression method [13:49] even in the kernels where iot didnt work [13:50] lilstevie, do you use any special cmdline options on your tablets to work with the r15 driver ? [13:50] vram or something alike [13:52] no more than usual [13:52] hmm, k [13:52] http://paste.ubuntu.com/1100098 [13:52] vmalloc=128M video=tegrafb [13:52] do you use these normally ? [13:53] but that is what the bootloader passes up [13:53] yes [13:53] almost the entire commandline is from the bootloader [13:54] i assume that doesnt fix the DPMS issues i see here "no_console_suspend=1" ... [13:56] DPMS issues? [13:56] i need to switch to console after waking up from DPMS to get X back [13:57] els i end up with a black screen [13:57] oh [13:57] no I don't have that [13:58] in fact switching to any tty means I don't come back :/ [13:58] ah [13:59] janimo, oh, i get a crash massage as well, seems its plymouthd [13:59] but I wake from DPMS fine [14:04] ogra_, no coming back from suspend either here, can't seem to switch to any VT [14:07] yep [14:16] ogra_, my initial ubi crash was indeed due to failing to connect NM, which crashed before that [14:16] so this is clearly a bug unrelated to ac100 installer [14:18] yeah [14:19] unfortunately not enough info in the coredump [14:19] * ogra_ is more intrested in the plyouth segfaults though [14:20] though it seems that my diversions are so good that i cant properly revert them :( [15:59] marvin24, I was just about to tell you to skip moving the framebuffer as it causes the toshiba logo to scroll uglily up [15:59] but I see you have a change already there [16:00] would be good to skip it even if not using uboot for above aesthetic issue [16:00] uglily eh ? [16:00] :) [16:00] well, it does not scroll smoothly enough [16:00] ++ btw [16:00] either we fix that or remove the scroll :) [16:00] yeah, it shouldnt move at all [16:00] it didnt in the past [16:01] it's a new change in 3.1 kernels only, needed for nvidia devboards apparently, but maybe not at all for us [16:01] yeah [16:23] howdy! is there some "official" ubuntu arm kernel git tree? like what goes into the omap4 images? [16:55] janimo: I don't know why they did it [16:55] maybe to see the bootloader output [16:56] I can disable it [16:56] and re-enable when we have u-boot *and* some bl framebuffer addresss [16:58] marvin24, probably disabling it completely makes sense for us indeed === zyga is now known as zyga-afk [18:02] * janimo is wondering how hard it is reflashing the ac100 to have the original layout where it had an SOS partition [18:02] debugging kernels would be easier that way [18:05] janimo: Mine still has an SOS partition. I guess you could clone mine? [18:05] infinity, I even had the full factory dump of the ssd on my disk, but the process itself seemed convoluted [18:06] involving lots of nvflash calls [18:06] Everything involves lots of nvflash calls... [18:06] or hadn editing of some files [18:06] yes, but this with weired argas thatn usual [18:06] of course it may have just been the regular Ncommander fearmongering at work and all is easy-peasy [18:08] * janimo just remembers that ad-ridden wiki where the process was confusingly written down [18:08] also ramconsole is great, that prompted me to think of having it available easily on the ac100 [18:09] infinity, also I'd probably need the exact model I have for the factory images [18:10] infinity, which is the easiest out of the archive solution for creating arm rootfs from c86? Anything better than deprecated rootstock? [18:10] but higher level than debootstrap [18:12] I don't seem to see an easy (as in linaro-media-create) tool for saying make an armhf root tarball corresponding to xubuntu-desktop optionally including other packages or kernel packages [18:12] janimo: live-build, though we have no nice wrappers to make it brain-dead. [18:13] infinity, oh does it do cross-builds too? [18:13] It can. I've not tested it much, but I know Linaro uses it. [18:13] hmm, I should probably ask them what they use to create the l-m-c tarballs [18:14] Then again, you can just untar ubuntu-core, toss in /usr/bin/qemu-arm-static, and tailor it yourself quickly too. :P [18:14] yes, the qemu + taylor it yourself bits what I hate [18:14] :) [18:15] I wonder if I am such a niche person with uncommon needs when I keep complaining about our build tools in general :) [18:18] janimo: Well, what you want can be done with live-build, I just don't find it "easy" to quickly tailor up something non-standard. [18:18] janimo: But, then again, I don't think any tool is easier than "chroot in and make it how you want it". Scripting that it only worth it if you do the same thing over and over. [18:18] s/it only/is only/ [18:18] infinity, well not very non-standard mind you, getting a xubuntu-desktop is quite a common use case I'd say [18:19] Well, then you also said "optionally including other packages". ;) [18:19] But, anything that isn't a base image set is "custom" in my mind. [18:19] infinity, well what I did today was a chroot indeed, via mk-sbuild just because that seems a nice enough wrapper that handles cross arch without me knowing what the hell is exactly going on behind the scenes [18:20] the whole debootstrap --foreign and 2 stages stuff is not something I want to learn about right now [18:20] The only problem with mk-sbuild is that it does a few schroot-specific things to your chroot, plus adding some buildd cruft you don't need. [18:20] Otherwise, yeah, that works. [18:20] (But you could have started with core, which would save you from the --foreign business) [18:20] infinity, well yes, extra packages is custom but well within what an apt call can do and common enough to warrant a tool. But yes, I am whining [18:21] I suppose I just don't see how "chroot foo/ apt-get -y install xubuntu-desktop^" is any harder than trying to convince a tool to do that for you. [18:21] as always, I would be content with good docs if tools are lacking, but somehow those too are non-existent, too dense or hard to find [18:22] infinity, the cross-build part is where I am lost as I never did that [18:22] and having read of xapt, dpkg-cross and a few other tools that in my mind overlap in functionality I got non-the-wiser [18:23] There's no cross involved in the above. [18:23] Just emulation. [18:23] Which is also how live-build and higher level tools work. [18:23] infinity, where does qemu-arm-static get involved? [18:23] And mk-sbuild, for that matter. [18:23] janimo: You just copy it into the chroot to /usr/bin [18:23] yes, I saw ps whosing qemu while running mk-sbuild [18:24] hmm, and then everything just gets ran by it? [18:24] * janimo must try [18:24] So, "untar core chroot/ && cp /usr/bin/qemu-arm-static chroot/usr/bin/ && chroot chroot su -" [18:25] janimo: If you install qemu-user-static on the host, binfmt_misc gets magically configured to throw all your non-native binaries at emulators. [18:25] janimo: So, as long as your current root has the emulator, you win. [18:25] yes, it has it, let's see [18:25] (since interpreters are found by path, whether it's an emulator, ld.so, /bin/sh, etc) [18:28] infinity, ok, running now in the chroot. I needed to create and chroot into it as sudo since it would not untar /dev nodes otherwise [18:29] janimo: Well, yes. The above assumed you were root. === k1l_ is now known as k1l