**** BEGIN LOGGING AT Fri Nov 23 02:59:59 2012 Nov 23 08:00:12 good morning Nov 23 09:06:36 sigh.... and now the touchscreen doesn't work :( Nov 23 11:11:53 hi... I'm trying to flash the rootfs.img image to my 32GB nexus 7... "fastboot flash userdata rootfs.img" fails with "error: cannot load..." Nov 23 11:12:03 any idea why that'd occur ? Nov 23 11:12:18 which rootfs.img is that ? Nov 23 11:12:20 the sha sums check out Nov 23 11:12:26 (where did you get it) Nov 23 11:12:28 it's the one that the installer downloads Nov 23 11:12:36 is it a 3G model ? Nov 23 11:12:47 no Nov 23 11:12:49 wifi Nov 23 11:12:55 I didn't know there was a 3d model lol Nov 23 11:13:03 http://hwe.ubuntu.com/uds-r/nexus7/32GB/rootfs.img Nov 23 11:13:07 well, bug 1079729 Nov 23 11:13:07 Launchpad bug 1079729 in ubuntu-nexus7 "Ubuntu uninstallable on 32GB 3G Nexus 7" [High,Confirmed] https://launchpad.net/bugs/1079729 Nov 23 11:13:21 ah Nov 23 11:13:25 not sure if all 32G models have the changed partitioning Nov 23 11:13:38 I have a 16GB model too Nov 23 11:13:47 I just figured that my experimental tablet should have more space Nov 23 11:14:15 thanks for the help :) Nov 23 11:14:29 the changed partitioning shouldn't affect *flashing* though Nov 23 11:14:39 there are some experimental raring images, the next build should have the install fix Nov 23 11:14:40 bootloader maps 'userdata' to the right partition Nov 23 11:14:47 yeah Nov 23 11:15:03 if the image is bigger than the partition ? Nov 23 11:15:12 that would surely affect flashing Nov 23 11:15:17 it shouldnt be Nov 23 11:15:33 it's quite unlikely the image is bigger than the biggest partition on the tablet ;) Nov 23 11:15:43 true ;P Nov 23 11:16:14 what is the exact error you get though? Nov 23 11:16:26 "error: cannot load..." doesn't tell much :P Nov 23 11:16:33 error: cannot load './rootfs.img' Nov 23 11:16:38 ^^^ exact error Nov 23 11:16:48 I am doing this on an ODROID-X Nov 23 11:16:55 that may make a difference Nov 23 11:17:09 that sounds more like the rootfs.img you are trying to flash is missing from the directory you run the command from... Nov 23 11:17:12 it flashed the bootloader fine Nov 23 11:17:30 I can assure you it's in the right directory Nov 23 11:17:41 and that the command is being executed in the right place Nov 23 11:17:45 * aquarat rechecks anyway Nov 23 11:17:59 yup Nov 23 11:18:17 so many people just get that stuff wrong, so better to verify, hehe Nov 23 11:18:29 of course Nov 23 11:18:34 I make stupid mistakes sometimes Nov 23 11:19:16 I can try giving fastboot an absolute path Nov 23 11:19:21 but as I said, the boot image flashed correctly Nov 23 11:20:10 nope, that doesn't work either Nov 23 11:21:04 the interesting thing is that it's exactly the error it gives if you do e.g. 'fastboot flash userdata nonexistant.img' Nov 23 11:22:12 I could try the normal installer again Nov 23 11:23:48 installer dies too Nov 23 11:24:13 is your disk full or some such ? Nov 23 11:24:27 disk has 578MB of space remaining Nov 23 11:24:55 what os are you using? Nov 23 11:25:03 linaro variant of ubuntu Nov 23 11:25:12 intended for the origenboard Nov 23 11:25:32 I should probably just try this on an x86 desktop Nov 23 11:25:45 * ogra_ doesnt think the installer was ever tested on arm Nov 23 11:25:59 it's not really the installer Nov 23 11:26:01 it's fastboot Nov 23 11:26:01 aquarat: does the user in question have read access to the file? Nov 23 11:26:03 no reason for it to fail though Nov 23 11:26:13 it gives the same, unhelpful error if it doesn't Nov 23 11:26:15 yes... sha256sum works on the file Nov 23 11:26:24 and I've chmodded it to 777 just in case Nov 23 11:26:42 funky Nov 23 11:26:44 pitty fastboot doesn't have a -vvvv Nov 23 11:26:54 not even a -v :) Nov 23 11:27:00 uh huh :( Nov 23 11:27:54 did you use the packaged fastboot from the archive/PPA ? Nov 23 11:28:18 er... I don't know... I just typed "fastboot" in the terminal and it responded Nov 23 11:28:22 i know for sure that i can flash my nexus fine from my raring chromebook Nov 23 11:28:49 using the fastboot package Nov 23 11:28:49 "android-tools-fastboot" Nov 23 11:28:52 yep Nov 23 11:28:54 is the package Nov 23 11:29:25 ah well... I'll try later from an x86 machine Nov 23 11:29:32 and let you know :) Nov 23 11:29:42 k Nov 23 11:39:39 does the touchscreen require any trick to work ? Nov 23 11:39:49 I mean to work with X Nov 23 11:40:18 the kernel driver reports events but it seems that X simply ignores them Nov 23 11:45:08 fmoreau, which image is that using? your debian one? Nov 23 11:47:07 lilstevie: yes. Nov 23 11:47:29 which hw? Nov 23 11:48:17 fmoreau, last I looked debian doesn't have all the multitouch enhancements that canonical have put into evdev Nov 23 11:48:34 fmoreau, you may have to use one of the multitouch libs available Nov 23 11:50:02 lilstevie: are those enhancements n7 specific or are they in their generic evdev driver? Nov 23 11:50:16 kulve, against the generic evdev driver Nov 23 11:50:24 lilstevie: multitouch ? but is that required to make the touchscreen work with "single" touch mode ? Nov 23 11:51:06 fmoreau: I noticed that my Xorg's evdev driver didn't understand the evdev from the kernel. I used mtev driver for X.Org and with that it worked in the multitouch mode Nov 23 11:51:12 fmoreau, I haven't looked closely at the n7 touch driver but 99% of these android devices touch screen drivers do not report in "single touch" mode only with multitouch protocol Nov 23 11:51:41 lilstevie: I see thanks for those hints. Nov 23 11:51:59 I would use mtev as kulve said Nov 23 11:52:09 kulve: hmm, I can give it a try thanks Nov 23 11:52:23 hmm. ubuntu's Xorg evdev driver requires libmtdev1 Nov 23 11:52:28 that is what I was using back with the SGT7" with 11.04 Nov 23 11:54:18 fmoreau, https://launchpad.net/ubuntu/raring/+source/ubuntu-defaults-nexus7/0.33 Nov 23 11:54:34 there is a rootfs/uusr/share/X11 dir in that package Nov 23 11:54:40 grab the content Nov 23 11:55:27 xorg recognizes the touchscreen as mouse without these files Nov 23 11:56:23 ogra-cb_: I already have that one: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/ubuntu-defaults-nexus7/raring-proposed/view/head:/rootfs/usr/share/X11/xorg.conf.d/21-nexus7-rotation.conf Nov 23 11:56:46 and looking at Xorg.log, it doesn't seem to be seen as a mouse Nov 23 11:57:08 see for example: http://pastebin.com/Z6RXmc8Y Nov 23 11:58:30 yeah, looks fine Nov 23 12:06:15 xnox, so i'm wondering ... spitting out three images for the nexus7 (8/16/32G) will eat a lot of space on cdimage ... if we would instead provide the raw tarball and call make_ext4fs from usb-creator we could save that Nov 23 12:07:09 but would lose oversized checking indeed (or would have to put it into usb-creator too) Nov 23 12:07:34 ogra-cb_: true. what about the bootimg? is it the same for all three? Nov 23 12:07:44 it can be, yeah Nov 23 12:07:51 ogra-cb_: with iso's we already do a bit of unpacking & shuffling around. Nov 23 12:08:31 it would indeed mean more instructions for manual installing people Nov 23 12:09:15 ogra-cb_: well, what I am hinting at is ship a flashable 8GB image, but make usb-creator repack it for 16 & 32. Nov 23 12:09:39 yeah, thats definitely doable as well Nov 23 12:09:56 8G will become pretty rare in the future Nov 23 12:13:27 well yeah, it's no longer available for sale Nov 23 12:13:44 there is now a model with 3G though =) Nov 23 12:13:51 i know Nov 23 12:13:56 just fixed a bug for it Nov 23 12:14:01 (different partitioning) Nov 23 12:14:15 nexus 4 is sold out =( Nov 23 12:14:29 it will return ... just be patient Nov 23 12:14:47 * ogra-cb_ would rather have a nexus 10 Nov 23 12:15:04 * Tassadar would rather have all of them Nov 23 12:15:29 heh Nov 23 12:15:56 well, the nexus 10 is essentially a chromebook in a different shell Nov 23 12:15:57 fmoreau: the latest upstream xorg evdev driver is using mtev and ubuntu has only one patch on top of that (use-sigsafe-logging.diff) so maybe you just need to upgrade your Xorg evdev driver? Nov 23 12:16:23 ogra-cb_: are we doing nexus10? Nov 23 12:16:30 so it should be reallly easy to get ubuntu running Nov 23 12:16:39 xnox, not to my knowledge Nov 23 12:16:50 hmm, I sent patch to kernel-team mailing list yesterday, but it did not show up in the mailing list archives Nov 23 12:16:56 I wonder where it went Oo Nov 23 12:17:05 kulve: yes. I'm just giving mtev a try to see if that fixes the issue. If so, I'll do what you suggested. Thanks ! Nov 23 12:17:28 but nobody stops a community image (apart from infinity who will cry about all the builds and only a single livefs builder) Nov 23 12:17:58 Tassadar, are you subscribed ? else it will get into moderation first Nov 23 12:18:07 oh, that I am not Nov 23 12:18:27 you should have gotten an answer mail telling you yours waits for moderation Nov 23 12:19:05 nothing like that Nov 23 12:19:29 spam filter catched it ? Nov 23 12:19:42 no, checked that Nov 23 12:20:44 well, probably ask in #ubuntu-kernel Nov 23 12:21:02 Can anyone decipher https://launchpadlibrarian.net/123744966/buildlog_ubuntu-raring-armhf.gmp_2%3A5.0.5%2Bdfsg-2ubuntu2_FAILEDTOBUILD.txt.gz for me? It's a new failure from what should have been an unrelated upload; it built three weeks or so ago. Nov 23 12:21:33 (It also failed on amd64 due to what appears to be a compiler configuration bug, but not one that seems likely to be related to ARM.) Nov 23 12:24:28 hmm, linker assembly issues, i guess that needs doko or infinity Nov 23 12:27:56 kulve: is the latest upstream evdev driver you were refering is 2.7.3 ? Nov 23 12:29:12 cjwatson, any hints on https://wiki.ubuntu.com/ARM/Thumb2PortingHowto ? Nov 23 12:30:07 o wonder if USE_THUMB=1 possibly means use thumb1 Nov 23 12:30:13 s/o/i/ Nov 23 12:30:24 wouldn't it have failed three weeks ago if it were a thumb issue? Nov 23 12:30:28 or am I missing something there? Nov 23 12:30:30 fmoreau: I just checked from the git browser, so the most fresh commit Nov 23 12:30:42 dunno, was it changed inbetwween ? Nov 23 12:30:46 * ogra-cb_ grabs the source Nov 23 12:31:01 it had USES_THUMB=1 then too Nov 23 12:31:14 ah, k Nov 23 12:31:17 I sponsored a patch from wookey, but not one that would have affected armhf Nov 23 12:31:31 there was a libc upload inbetween though, wasnt there ? Nov 23 12:32:18 three actually Nov 23 12:33:08 I guess I'm not sure what isn't ARMish about "str r1,[ r0 ]" Nov 23 12:33:10 nothing that looks related though Nov 23 12:33:45 ah, binutils got updated too Nov 23 12:33:56 on wed. Nov 23 12:34:40 "- arm, aarch64 and x32 updates." Nov 23 12:35:01 i guess its either a buildd hiccup or that upload Nov 23 12:36:55 * ogra-cb_ grumbles about the chromebook designers Nov 23 12:37:35 as shiny as having a normal key on the kbd for power ... putting it where the del key normally would be is really annoying Nov 23 12:37:57 s/power/power is/ Nov 23 12:39:05 ogra-cb_, heh the transformer keyboard has a lock key there, I ended up remapping the key at a driver level back to delete cause of accidental sleeps Nov 23 12:39:27 and at one stage there was a bug with sleeping, where it would not come back Nov 23 12:40:08 well, ubuntu sets [pwer to pop up a window by default, so at least i dont go to sleep twice an hour Nov 23 12:40:29 yeah that isn't too bad Nov 23 12:40:38 but i have to cancel the sutdown countdown all the time indeed Nov 23 12:40:47 heh Nov 23 12:41:06 there was never any hesitation with the sleep button, just off it went Nov 23 12:41:41 yeah, that one just calls pm-suspend Nov 23 12:41:59 you should be able to disable it in dconf-editor though Nov 23 12:42:17 was easier to just remap :p Nov 23 12:42:32 yeah, i dont thinnk i can easily remap power Nov 23 12:42:49 it will very likely stiill sent the power event Nov 23 12:43:02 yeah probably Nov 23 12:43:23 at least with the sleep button it is just a scan code Nov 23 12:44:15 and the driver doesn't even report most of them without changing them cause KEY_ASUSDEC_* scan codes do not line up with what evdev or any other sane driver will be expecting Nov 23 13:28:24 * ogra-cb_ hugs xnox Nov 23 13:28:38 ? Nov 23 13:28:48 plymouth :) Nov 23 13:28:57 oh, you wanted it for arm? Nov 23 13:29:44 well, i wanted to have the new version before going on to debug the nexus Nov 23 13:30:07 since thats supposed to have a bunch of fixes for console= handling Nov 23 13:30:08 * xnox just doesn't like the 300kB of text here http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt Nov 23 13:30:16 yeah Nov 23 13:30:28 i would have jumped on plymouth on monday Nov 23 13:30:37 if you hadnt done it ... Nov 23 13:30:38 yeah about the console= handling. I am not entirely convinced that our vt_handoff patches interfere with that or not. Nov 23 13:30:49 this week is simply nexus image build week for me Nov 23 13:31:13 well, if it still fails i'll do some tests Nov 23 13:31:25 i have high hopes it gets better though Nov 23 13:35:14 fmoreau: btw, I never got the fastboot flash -S working, so tell me if it works for you. Currently I'm creating 4GB file system but it has to have at most ~700MB of data on it or the flashing fails Nov 23 13:36:08 hmm.. I did try it only with the original fastboot. Maybe the Android MR1 updated also the fastboot? Nov 23 13:36:34 Is it bootable yet? I would try to make instalation zip for recoveries, like android ROMs do Nov 23 13:37:19 * xnox ponders if it matters whether or not the tablet is OTA updated to the latest (post nexus4) multi-user android 4.2 firmware update Nov 23 13:37:39 the bootloader was updated in 4.2 Nov 23 13:41:00 ogra-cb_: did you update the android side of nexus7 ever? Nov 23 13:48:28 * xnox lols over surface pricing Nov 23 13:48:50 * Tassadar lols over the actual free memory of 32gb surface Nov 23 13:50:02 kulve: do you mean that fastboot can load an image of 4Go if it's full of zero ? Nov 23 14:06:57 fmoreau: the file itself is smaller, but somehow the imag is still 4GB. I don't know the details, but make_ext4fs (iirc) makes it happen Nov 23 14:08:44 will try to use make_ext4fs then. Nov 23 14:09:42 kulve: the touchscreen is finally working :) well almost, because for some reason the Invert{X,Y} and swapAxes options are not working Nov 23 14:09:59 it's a bit buggy though, I can give you details later, when I have a keyboard instead of a phone :) Nov 23 14:10:29 fmoreau: which xorg driver? Nov 23 14:10:37 latest evdev Nov 23 14:10:43 as you suggested Nov 23 14:11:07 ok, great Nov 23 14:14:37 kulve: when you'll get a keyboard, please send the gory details so I can try to make it works eventually :) Nov 23 14:17:03 fmoreau: did you upgrade to android 4.2? Nov 23 14:17:36 for the kernel ? Nov 23 14:17:37 xnox, not beyond the upgrade i got directly at startup of the device Nov 23 14:17:57 fmoreau: for the fastboot Nov 23 14:18:32 ogra-cb_: ack. Nov 23 14:21:10 kulve: nope I'm still 4.1 Nov 23 14:22:16 well, maybe I'll try upgrading on sunday.. Nov 23 14:25:56 so does the existence of nexus 7 images mean that nux is fixed and i can remove the pinning? Nov 23 14:26:38 nope Nov 23 14:26:52 it just means that the images currently ship with a broken nux Nov 23 14:27:47 and the current one is still to big, only lucky people for which fastboot -S works can use it atm Nov 23 14:28:13 that part should change with the next build though, nux not yet Nov 23 14:34:25 ogra-cb_, what is the issue with -S exactly? Unknown bug? Nov 23 14:35:07 janimo, yeah Nov 23 14:35:25 you get a corrupt unmountable fs on the target disk Nov 23 14:35:46 i suspect some dicrepancy between the fastboot on the device and the PC Nov 23 14:35:56 *dis Nov 23 14:36:30 ogra-cb_, well the bootloader ROM versions are different across devices Nov 23 14:36:37 and some Android upgrades also change them Nov 23 14:36:55 right Nov 23 14:36:58 maybe we could find out if only certain versions have it Nov 23 14:37:42 Having an android style .zip upgrade tarball has its advantages I guess Nov 23 14:37:55 fastboot may not be as well tested Nov 23 14:37:56 yeah, probably Nov 23 14:38:14 well, we would still use fastboot for flashing the zip Nov 23 14:38:39 adb to the recovery Nov 23 14:38:55 but maybe neds rooting unless the zip is google's, I don't know Nov 23 14:39:08 you cant rely on the fact that all devices we'll support will have actual recovery available Nov 23 14:40:33 yeah, needs custom recovery to flash updates not-from-google Nov 23 14:40:43 which means unlocked bootloader Nov 23 14:40:58 well, we always need an unlicked bootloader Nov 23 14:41:03 heh Nov 23 14:41:06 *locked Nov 23 14:41:48 right, oem unlock is a given for our case Nov 23 14:42:33 but if you run into devices like i.e. the ac100 where an update makes recovery a no-op you are screwed relying on a recovery mode Nov 23 14:42:56 fastboot flash is simply wjat all oem unlocked devices know Nov 23 14:44:09 i think the grub/casper-lupin way is the way for the future though (13.10 and later), that should give us other compression abilities Nov 23 14:44:33 so then this issue wouldnt bite us anymore Nov 23 14:44:45 for 13.04 we should simply just keep the seed small Nov 23 14:46:04 can someone point me out the location of the fastboot repository ? Nov 23 14:46:47 I don't know if it's me but I'm always having hard time to figure out where the stuff are for android project... Nov 23 14:48:35 https://android.googlesource.com/platform/system/core/ Nov 23 14:48:37 its in here Nov 23 14:55:09 thanks Nov 23 14:56:02 sad... can't do a simple "make" to build fastboot. Nov 23 14:57:20 * Tassadar looks at 4 android repositories on his disk, each one to build just one small part Nov 23 14:57:23 yeah... Nov 23 14:58:38 :) Nov 23 15:04:47 just apt-get source the package, then replace the .c files as needed/wanted Nov 23 15:05:07 ogra-cb_, is this a new upstream? Nov 23 15:05:20 though i think we have the code from a very recent master checkout Nov 23 15:05:42 doko, what ? cjwatson's gmp FTBFS ? Nov 23 15:05:52 i doubt that Nov 23 15:12:49 diwic, did any of the pulse and alsa bits from the nexus7 defaults package into rating already ? Nov 23 15:12:59 *go into Nov 23 15:13:06 ogra-cb_, no Nov 23 15:13:27 k, good, since i didnt remove them from the package when i uploaded it Nov 23 15:14:00 if that stuff goes into regular packages, please let me know so i can clean up the default package Nov 23 15:18:36 ogra-cb_, ok, so far I think it's quite specific Nov 23 15:19:06 as the pandaboard stuff or the ac100 bits are Nov 23 15:19:25 we still ship their ucm files in the regular packages Nov 23 15:22:33 Yeah, I've always wondered why we do that, especially for x86... Nov 23 15:23:34 achiang, no news on the no-sound-before-s3 issue? Nov 23 15:23:42 fmoreau: make_ext4fs comes in a package android-tools-fsutils (take it from the ubuntu's repos). Then create the image like this: "sudo make_ext4fs -s -l 4G rootfs.img /path/to/roofs". For me it failed if I had the normal /dev files there, so my /dev is empty. But I also have the automount /dev option turned on in the kernel Nov 23 15:24:50 diwic: sorry, i didn't get a chance to escalate to nvidia yet. i will do that soon Nov 23 15:25:09 kulve: thanks. I'm actually facing the issue with /dev/. Nov 23 15:25:19 doko: of gmp? no, just a trivial patch Nov 23 15:25:20 was looking at the code of make_ext4fs Nov 23 15:26:24 fmoreau: is it option for you to turn the kernel option on? It stupid anyway to have some initial files there as tmpfs is probably mounted to /dev quite soon anyway Nov 23 15:26:38 +typofix Nov 23 15:28:25 kulve: are you talking about this option CONFIG_DEVTMPFS_MOUNT ? Nov 23 15:29:03 achiang, ack Nov 23 15:29:22 fmoreau: I think so. Nov 23 15:29:30 kulve: then it's already on Nov 23 15:30:07 then you should be just fine with empty /dev as the kernel will mount it right after it mounts the rootfs Nov 23 15:30:36 kulve: ok Nov 23 15:30:38 thanks Nov 23 15:31:45 DEVTMPFS_MOUNT: "Automount devtmpfs at /dev, after the kernel mounted the rootfs", yeah that's it Nov 23 15:32:46 cool Nov 23 15:33:25 but make_ext4fs should handle file devices... I'm wondering why it's failing. Nov 23 15:33:34 s/should// Nov 23 15:38:00 perhaps I'm running an old version of make_ext4fs but the source I'm looking at does handle special dev files. Nov 23 15:42:12 and I've no idea how to rebuild make_ext4fs... Nov 23 15:42:25 anyways I'm going to try to boot with an empty /dev Nov 23 15:45:27 kulve: works fine :) Nov 23 15:52:29 kulve: BTW, make_ext4fs is only used in order to create a ext4 fs without root permission or does it provide more ? Nov 23 16:13:42 fmoreau: "without root permission"? I've used it to create 4GB image that fits into the 700MB flashing limit. And I'm using 4GB without any particular reason. I think 13GB should be fine for 16GB n7 Nov 23 16:19:15 fmoreau: you mean why mkfs.ext4 isn't used? Nov 23 16:20:01 Tassadar: yes. But I think that the answer was given by kulve when he suggested to use '-s' switch Nov 23 16:21:58 kulve: doing : make_ext4fs -s -l 13G rootfs.ext4 rootfs => rootfs.ext4 794M Nov 23 16:22:04 it does not create normal ext4 image, but special "sparse" image Nov 23 16:25:15 Tassadar: does the "sparse" image need a special fasboot's option ? Nov 23 16:25:25 when flashing it. Nov 23 16:25:46 no, it is the format for fastbooot Nov 23 16:26:08 it cannot flash normal ext4 image I think Nov 23 16:26:44 as you can see, it is only as big as are the data in it Nov 23 16:26:59 Tassadar: well I'm flashing normal images. Nov 23 16:27:26 I don't think flasboot reads the content of the images actually Nov 23 16:28:37 Tassadar: but sparse image can't be mounted on the host Nov 23 16:29:30 exactly, that is why I think fastboot actually reads the image Nov 23 16:30:10 which value should I pass to fastboot with '-S' ? Nov 23 16:32:06 ogra-cb_ said 630M I think Nov 23 16:33:34 sudo fastboot flash -S600M userdata ../rootfs.ext4 Nov 23 16:33:34 Invalid sparse file format at header magi Nov 23 16:33:43 ... Nov 23 16:33:58 weird. Nov 23 16:34:17 maybe you have too old make_ext4fs..? Nov 23 16:35:35 no idea, and those tools have no version num :-/ Nov 23 16:47:37 infinity: around? To generate cloud ARM images for machines that need mkimage wrappers to netboot, I'm going to need to hardcode load addresses and mkimage calls into the image generation scripts. Which is horrible. What do you think about modifying flash-kernel to be able to produce images for named boards, but to stop short of "installing" them? Nov 23 16:48:19 Eg. "flash-kernel --write-uImage-only -o /where/I/want --machine '...' Nov 23 16:48:44 Looks like that'll need some surgery to flash-kernel though, and we'll want to sync with Debian on that Nov 23 16:51:45 fmoreau: for me all sizes to -S failed. Give the image that you can flash without -S with e.g. "-S 256M". It is then sent and flashed 256M at a time Nov 23 16:52:44 without -S you should be able to flash also normal ext4 images (less that 700M). -S understands only the sparse images Nov 23 16:53:30 I'll try to make -S work since I'd like to use all space available on the flash. Nov 23 16:53:46 my wild guess is that the fastboot in n7 doesn't understand the -S and flashes all pieces to the start of the partition and then the kernel can't mount it because in practice there is only the last piece of the image Nov 23 16:54:38 my wild try is to use all latest version (including the bootloader) and hope that it will work. Nov 23 16:54:48 fmoreau: I would first flash the android 4.2 and only then try with the -S. But I'm guessing that the new fastboot wouldn't work with -S either.. Nov 23 16:55:15 I would too like really much to get the -S working.. Nov 23 16:56:51 I'm going to try the new bootloader from 4.2 Nov 23 17:03:19 kulve: with bootloader v4.13, I also got this: "Invalid sparse file format at header magi Nov 23 17:03:19 " Nov 23 17:03:50 then Nov 23 17:03:53 sending sparse 'userdata' (443531 KB)... Nov 23 17:03:53 OKAY [ 61.174s] Nov 23 17:03:53 writing 'userdata'... Nov 23 17:03:53 FAILED (remote: (NotSupported)) Nov 23 17:04:03 that shouldn't happen if you give it the image created with make_ext4fs Nov 23 17:04:41 image created with "make_ext4fs -s -l 13G rootfs.ext4 rootfs" Nov 23 17:05:03 ohh wait Nov 23 17:05:24 443531 KB? Nov 23 17:05:25 :P Nov 23 17:07:47 the actual file size doesn't need to match the partition size Nov 23 17:08:33 yeah, but he says his image has 790MB Nov 23 17:11:09 ok this time the image has been flashed successfully but the kernel panic when mounting the rootfs. Nov 23 17:12:18 fmoreau: yeah, that happens when the -S doesn't work properly Nov 23 17:12:25 i.e. that's what I get always Nov 23 17:12:34 ok Nov 23 17:12:57 but sometimes it might work, so I'm going to try a couple of times. Nov 23 17:13:35 somebody claimed that it might work occasionally but I tried 10 times in a row without luck.. Nov 23 17:14:47 I'd like to try the latest version of fastboot but seems to be painfull to build. Nov 23 17:15:17 I doubt you can flash it Nov 23 17:15:49 fmoreau: what distro do you have? Nov 23 17:16:23 bricking the bootloader could brick the whole device Nov 23 17:16:44 it will brick the whole device Nov 23 17:17:04 it has already happened several times on XDA Nov 23 17:17:32 but he means "fastboot" as the program on PC, not the bootloader Nov 23 17:18:27 it won't let you flash a bl not signed by google anyways (N7 that is) Nov 23 17:18:32 I think the problem is that the fastboot on the device side doesn't understand getting the image in pieces. PC side is probaby working as expected Nov 23 17:19:10 that doesn't explain why it works on some devices though Nov 23 17:19:15 RaYmAn: I think you can just write whatever you want the if you get the linux running? Nov 23 17:20:08 well, technically speaking, yes, you can. However, tegra bootrom won't accept it because it's not signed/encrypted/checksummed in the right ways & places Nov 23 17:20:25 Tassadar: debian Nov 23 17:20:28 but you can't with flashboot (which incidentally does all the fancy signing/encryption/checksumming for you) Nov 23 17:20:33 *fastboot Nov 23 17:20:35 I can build it for you if you want Nov 23 17:20:39 yeah, so you can flash it but it won't be loaded anymore -> bricked Nov 23 17:21:13 bootloader sources are not public anyway, are they? Nov 23 17:21:37 I don't thinkg so Nov 23 17:22:08 that means we would not have anything to flash there anyway, so it does not really matter Nov 23 17:22:18 zeros? ;) Nov 23 17:22:56 point being, don't mess with the bootloaders just for fun.. Nov 23 17:24:19 then I'll try to generate a sparse image < 600 Mo, that should allow me to use a 10Go filesystem, shouldn't it ? Nov 23 17:24:42 yes Nov 23 17:24:54 good Nov 23 17:25:23 kulve: BTW could you drop some words about InvertX/InvertY that doesn't work with the touchscreen ? Nov 23 17:27:41 sorry, I didn't try the new evdev driver but the different xorg mtev driver and for that those options did work Nov 23 17:28:08 did you check the X.Org log if it says something about those options? Nov 23 17:39:36 rbasak: That was supposed to be the point of the flash-kernel rewrite (or, one of the points), where the database of machine-specific settings was meant to eventually be a seperate package so others could source it. That last bit never happened. :/ Nov 23 17:40:14 it will, at some point Nov 23 17:40:33 rbasak: I have no fundamental issues with this happening (either a broken out DB package, or f-k having a foreign creation mode as you suggest), but I also have very little interest in being involved in f-k work at all. :P Nov 23 17:42:24 all you want to skip is the actual writing to the device though Nov 23 17:42:48 i think adding such a function should be rather trivial Nov 23 17:46:58 OK, thanks all Nov 23 17:53:10 sfeole: how do you suggest we handle https://bugs.launchpad.net/ubuntu-nexus7/+bug/1082364 Nov 23 17:53:10 Launchpad bug 1082364 in ubuntu-nexus7 "android debugger bridge cant be install on ubuntu on nexus 7" [Undecided,New] Nov 23 17:54:57 cwayne: i did see that one, but put it aside for now, I think I may wait until monday when more of the staffers are back to work and question what to do about it Nov 23 17:55:22 cwayne: in the meantime I'm moving some bugs back to a "New" status, such as this one... https://bugs.launchpad.net/ubuntu-nexus7/+bug/1080789 Nov 23 17:55:22 Launchpad bug 1080789 in ubuntu-nexus7 "Corruption around mouse cursor when dragged, particularly around Dash, Indicators, window chrome" [Low,New] Nov 23 17:55:55 cwayne: even though we have confirmed it, I don't think anyone is working it. If it is a upstream issue with NVidia then it should be handled accordingly Nov 23 17:56:30 sfeole: no, leave them as confirmed Nov 23 17:56:33 we don't want any new bugs Nov 23 17:57:38 sfeole: Confirmed doesn't mean people are working on it, just that it's confirmed to be a bug. Moving back to new seems counter-intuitive. Nov 23 18:00:30 ogra-cb: http://hwe.ubuntu.com/uds-r/nexus7/ these are the images people (eg. at XDA) should use, or are the 13.04 images ready for use? Nov 23 18:00:55 cwayne: the email you forwarded to me this morning should adhere all bugs, not just bugs filed after the 21st. Nov 23 18:01:37 sfeole: yes, but they dont say to move them to new Nov 23 18:01:58 achiang: ^^ thoughts? Nov 23 18:02:18 sfeole: it's been confirmed as a bug == marked confirmed Nov 23 18:03:55 sfeole: i agree with the others, i do not think it should be new. i think that it should be confirmed. Nov 23 18:04:04 achiang: ack Nov 23 18:04:08 sfeole: for all tegra3 bugs, tag them with tegra3 and assign to me Nov 23 18:04:18 achiang: will do Nov 23 18:04:36 thanks Nov 23 18:10:37 cwayne: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1078696 Nov 23 18:10:38 Launchpad bug 1078696 in ubuntu-nexus7 "gksu does not accept sudo password" [Low,Confirmed] Nov 23 18:13:02 cwayne: Looks like you had the last word on the bug above , do you have any more insight on it? Nov 23 18:13:37 i was about to run through the whole process myself of trying to reproduce , etc... Nov 23 18:14:14 sfeole: all it needs is an assignee Nov 23 18:14:27 if its confirmed, just follow victor's rules for assigning, that's all you'll need to do Nov 23 18:15:51 thats what i was going to do. just checking with you if you wanted to add to it Nov 23 18:16:28 sfeole: i marked that adb one incomplete with a question Nov 23 18:16:33 sfeole: nope Nov 23 18:16:39 cwayne: ack and ok Nov 23 18:21:35 cwayne: did you assign it to the right sudip? Nov 23 18:21:48 cwayne: The last names look different Nov 23 18:22:12 Tassadar, 13.04 images are still to bigg and there is at least one nux bug that needs to be fixed Nov 23 18:22:23 sfeole: nope, i fixed it though Nov 23 18:22:24 thanks Nov 23 18:22:27 cwayne: no Nov 23 18:22:31 cwayne:oops np Nov 23 18:22:32 ;P Nov 23 18:22:45 brave people can indeed try http://cdimage.ubuntu.com/daily-preinstalled/current/ Nov 23 18:22:58 but seems we still need to lose some weight Nov 23 18:23:08 (still needs -S) Nov 23 18:23:17 weight is no problem, I don't wanna flash that with fastboot :) Nov 23 18:23:39 okay, are images on that address I linked daily-built, or are they still the same and updates are provided by apt-get upgrade? Nov 23 18:23:43 well, you need the configuration the initrd sets up during first boot Nov 23 18:24:03 so just using the img will leave you with a broken setup Nov 23 18:26:33 I think I can handle the instalation process well enough, I just need to think of the easiest way to actually put ubuntu to /sdcard Nov 23 18:27:07 I dont really wanna to provide pre-edited images, because I would have to keep them updated, so I am looking for a way to edit them in recovery Nov 23 18:27:21 that is why I wanna know if there images change or not Nov 23 18:28:12 well, depends on nux Nov 23 18:28:46 that and the oversizedness are the last bits keeping us from moving over Nov 23 18:29:24 * Tassadar is looking up what the "nux" is... Nov 23 18:29:48 libnux Nov 23 18:29:52 ah, opengl library Nov 23 18:30:06 renders the UI elements of unity Nov 23 18:30:11 and what about the 12.04 images? Nov 23 18:30:28 there nux has a fix in the PPA packages Nov 23 18:46:28 kulve: sorry, had to deconnect. Xorg.log reports the options set in the xorg.conf Nov 23 18:47:53 hm... I thought that I uploaded armsoc xserver to raring... Nov 23 18:48:39 ok, still in NEW queue Nov 23 18:48:43 hrw, NEW Nov 23 18:48:51 ah, you found already Nov 23 18:49:19 I will create set of crazy packages in meantime Nov 23 18:51:10 hi, I was wondering if someone could offer some advice on this armhf FTBFS : http://paste.ubuntu.com/1380127/ Nov 23 18:55:41 oh nvm, icecc/ccache issue I think ( still building if I remove ccache/icecc from PATH ) Nov 23 18:58:32 Hey all! I'm trying to install Ubuntu on a BeagleBone and have previously used Robert Nelson's script on an Ubuntu machine. But now I'm on a Mac and the setup_sdcard script is throwing an error. Any help is greatly appreciated. Nov 23 18:58:38 usage: mktemp [-d] [-q] [-t prefix] [-u] template ... Nov 23 20:03:44 ogra-cb: chromium-mali-opengles is now distributable - works as long as there is original ROOT-A partition ;D Nov 23 20:09:49 oh, nice ! Nov 23 20:10:24 http://git.juszkiewicz.com.pl/?p=package/chromebook/chromebook-opengles.git;a=summary Nov 23 20:10:36 https://launchpad.net/~hrw/+archive/my-own-packages/+packages will have it soon Nov 23 20:11:18 cool Nov 23 20:12:27 size of rootfs is limited only by the size of RAM, right? Nov 23 20:17:49 https://launchpad.net/~hrw/+archive/my-own-packages/+build/4007773 Nov 23 20:34:39 I hate packages which do not allow for "debuild -b;debuild -S" Nov 23 20:41:35 ogra-cb: would it be possible to add uboot/tegra? Nov 23 20:48:37 marvin24, ask jcrigby, he maintains all the u-boot packages Nov 23 20:49:21 (surely sending a patch for the linaro packaging git tree would speed it up :) Nov 23 20:50:40 ogra-cb: time to write blog post :) Nov 23 20:50:59 ogra-cb: users of quantal or raring will get x11 server, opengles and ucm profiles Nov 23 20:52:12 yeah Nov 23 20:53:29 ogra-cb: Alexander Graf (opensuse guy) has u-boot packed as kernel so even /boot/ kernels are closer Nov 23 20:53:50 but I was not able to properly ext2ls my partitions with it ;( Nov 23 20:54:07 use a small vfat then Nov 23 20:54:18 that's the idea Nov 23 20:54:36 KERN-A for chromium kernel, KERN-B for uboot, KERN-C for vfat Nov 23 20:55:52 16MB each so huge waste of space Nov 23 20:56:39 shouldn't uboot stay in its own partition? Nov 23 20:56:41 massive Nov 23 20:57:33 less than 300k here Nov 23 20:57:39 including ext4 support Nov 23 20:57:43 marvin24: boot scheme will be: exynos5-internal-bootloader - chromium uboot - chromium vboot - our uboot - kernel Nov 23 20:58:07 why? Nov 23 20:58:10 multiboot? Nov 23 20:58:11 Wow, that's not ugly at all... Nov 23 20:58:40 hrw, whats the reason to have uboot in that chain ? Nov 23 20:59:13 ogra-cb: that's just option to have normal not signed each time kernel in /boot Nov 23 20:59:15 * ogra-cb would prefer to just flash raw to the KERN-B partition Nov 23 20:59:35 oh, it needs to be signed ? Nov 23 20:59:42 * ogra-cb didnt know Nov 23 21:00:12 ogra-cb: tool and devkeys are provided so it is not so big problem Nov 23 21:00:29 but change cmdline == signing, change of kenrel == signing etc Nov 23 21:00:37 well, i'm not a fan of forcing kernel signing on people Nov 23 21:00:45 yeah Nov 23 21:00:48 * marvin24 is happy to still live in the old world Nov 23 21:00:55 annoying ... automatable though Nov 23 21:01:53 yep Nov 23 21:02:32 Signing buys you nothing if the private key is known, so I'm not sure why we'd bother. Nov 23 21:02:51 Chaining into a loader that lets you load unsigned kernels seems fine in that case. Nov 23 21:02:58 well, if the ROM code requires it there is hardly a way around it Nov 23 21:03:08 yeah Nov 23 21:03:25 forget about 10sec boots though :P Nov 23 21:03:49 uBoot chaining to another uBoot should be nearly instant. Nov 23 21:03:54 ogra-cb: vboot (part of chromium uboot) needs that. we can flash own uboot Nov 23 21:04:04 but brick risk ;( Nov 23 21:04:21 hrw: Nah, better off chaining than bricking. Nov 23 21:04:29 hrw: I assume we'd need to sign our uboot? Nov 23 21:04:31 ++ Nov 23 21:04:50 (Which we can easily do if we have the key and it's publicly-known, cause we can just slap it in the source package) Nov 23 21:04:51 hrw: well, once you have dev-mode ro firmware installed, you're back to zero brickrisk again ;) Nov 23 21:05:06 but yeah. Nov 23 21:05:18 infinity: yes, you need Nov 23 21:05:39 RaYmAn: I have mass market user firmware Nov 23 21:05:59 * ogra-cb has a TV and wanders off to it Nov 23 21:06:22 RaYmAn: but I can take dev firmware with exact steps Nov 23 21:06:30 I just flashed dev firmware on mine Nov 23 21:06:38 (ro firmware that is) Nov 23 21:07:30 it was surprisingly painless :) (and now I can presumably safely flash custom RW FW A and RW FW B) Nov 23 21:08:21 RaYmAn: delay at boot still present? Nov 23 21:08:55 hrw: no, you can remove that with gbb flags (well, make it be like, 1-2 seconds) Nov 23 21:09:27 the downside is that official chromeos updates will fail to start (because ro firmware keys are different - a good thing, but it requires a bit more effort to update then) Nov 23 21:10:39 RaYmAn: once we get everything working (maybe never) I can live without chromium os even Nov 23 21:11:33 The ncie thing is that you can just re-enable read-only after installing, so essentially your chromebook is in danger for ~5 minutes, and once that's done, you're just as safe as before (except now, you can sign recovery keys, firmwares etc yourself) Nov 23 21:12:32 RaYmAn: where I can find exact steps and images? Nov 23 21:13:07 hrw: yeah, you can't really, lol. I had to try and piece together things mostly through looking at scripts :/ Nov 23 21:13:42 RaYmAn: write a post about it. you will get your 5 minutes of glory Nov 23 21:13:55 i'm planning to try and done some sort of quick guide whenever I manage to get a custom u-boot in RW FW booting Nov 23 21:13:58 lol Nov 23 21:14:11 I can live without those 5 minutes just fine, but I'll do a quick writeup regardless ;) Nov 23 21:14:31 cool Nov 23 21:15:40 It *appears* that just taking out the screw closest to the usb 3 port disables the hardware write protect though - so if you fancy testing that, it would help a lot :P Nov 23 21:17:11 I know that Nov 23 21:17:15 it is public information Nov 23 21:17:18 ;d Nov 23 21:17:26 the public info says you have to take apart the full deive Nov 23 21:17:28 device Nov 23 21:17:29 :/ Nov 23 21:17:29 one screw works as SPI write protect Nov 23 21:17:38 sure, but this is an *Externally* available screw Nov 23 21:17:55 I was expecting it to be below the back cover Nov 23 21:18:04 http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook#TOC-Read-Only-SPI-Flash Nov 23 21:18:52 yeah, well. It's certainly not obvious that you don't need to take it fully apart ;) Nov 23 21:19:01 hm.. it was there.. Nov 23 21:19:09 (or rather, that you just need to remove one screw rather than the entire backside) Nov 23 21:21:51 hrw: anyways, primarily, it's just a matter of disabling ro and running the /usr/share/vboot/bin/make_dev_firmware.sh , then /usr/share/vboot/bin/set_gbb_flags.sh 0x31 (which means force_dev_boot_usb, disable fw rollback check and dev screen short delay) Nov 23 21:22:11 the make_dev_firmware.sh sets it to 0x30 by default, which means it leaves out the short delay setting Nov 23 21:22:38 force_dev_boot_usb == always boot from side SD? Nov 23 21:23:00 I dunno - it might prioritize it I guess Nov 23 21:23:21 I haven't checked the vboot source yet Nov 23 21:47:53 bye Nov 23 23:27:26 I got ubuntu running on my 32GB nexus 7 after I tried the installation on an x86 machine Nov 23 23:27:36 I think the problem was storage space rather than architectire Nov 23 23:27:41 *ure **** ENDING LOGGING AT Sat Nov 24 02:59:58 2012