=== Nisstyre-laptop is now known as Nisstyre === Sarvatt is now known as Sarvatt_ === Logan_ is now known as Guest912 === Guest27218 is now known as Logan_ === Logan_ is now known as Guest54086 [02:53] hello ,I want to boot the panadboard using the ubuntu core 12.04 by nfs , what should I to set for the boot.scr ? [04:20] Good morning [05:27] hm, do we still have a powerpc porter box somewhere? [05:27] pitti: hello [05:32] pitti: davis [05:33] Which seems to not love the world [05:33] StevenK: that's what I thought, but it seems broken [05:33] * pitti is using partch.debian.org === Noskcaj10 is now known as Noskcaj [06:19] didrocks, good morning :) [06:20] hey tvoss_, how are you? [06:20] didrocks, pretty good :) you? [06:20] tvoss_: I'm fine, thanks! Quite a little bit of backlog though :) [06:21] didrocks, ah okay :) I have a question for you: do you have an eta when Mir/system comp will land in universe? [06:22] tvoss_: see #ubuntu-mir, let's not get the discussion in two channels :) [06:22] didrocks, yup, thx :) my bad [06:22] no worry ;) [06:23] Daviey, ping [07:10] Noskcaj: hey [07:11] Daviey, i sent you a PM yesterday, did you see it? === smb` is now known as smb === echevemaster is now known as echevemaster_afk [07:30] good morning [07:34] dholbach, hey, wie gehts? [07:36] hey seb128 - sehr gut - et toi? comment ça va? [07:36] dholbach, ça va bien merci ;-) [07:36] :) [07:37] Noskcaj: Yes, I'll have a better answer for you latr. [07:37] +e [07:43] mvo: hey, how are you? [07:43] mvo: I already handled https://code.launchpad.net/~seb128/sessioninstaller/handle-parsing-errors/+merge/168970, including the tighter except: === 13WAAK4RM is now known as tvoss [08:35] pitti: hi, thanks! yeah, I nocticed after I answered, was on vac for a couple of days and worked on the mail sequentially :) [08:36] mvo, hey! thanks for the review anyway ;-) I hope you enjoyed your vac days! [08:41] seb128: I did, it was very nice, thanks! [08:42] hey mvo [08:43] hey dholbach! [08:44] * pitti sends some water bubbles to dholbach [08:44] * dholbach hugs pitti === gusch_ is now known as gusch [09:23] memtest86+ fails to upgrade for me, in an ubuntu-cloud image launched under lxc, due to calling update-grub2 unconditionally, which fails in ubuntu-cloud image under lxc. [09:24] memtest86+ seems to have a mariod of upgrade/install bugs on launchpad due to failing at the update-grub2 call. Should it have "|| true" added? [09:26] xnox: because the update-grub2 command doesn't exist, or does it fail? [09:26] if it doesn't exist, a [ -x ] test sounds more appropriate to me [09:27] pitti: there is already a -x test, it's just that lxc container has grub2 package install, /boot/ mounted&present (from the ubuntu cloud preinst image), yet lxc container cannot successfully run update-grub2, as it fails to identify boot device. [09:27] and well, one doesn't actually boot lxc containers with grub. [09:28] I guess memtest postinst should check if it's in a container/lxc and do nothing with grub even if that's present. [09:28] wouldn't that logic be better placed in update-grub then? [09:28] otherwise we'd have to fix a lot of packages in the same way? [09:30] pitti: yeah. It looks like there is a generic command "running_in_container" command already which can be recycled. [09:31] /bin/running-in-container shipped by upstart, perfect. [10:05] xnox: The right fix is to add [ -e /boot/grub/grub.cfg ] [10:05] Though actually a running-in-container test is fine too [10:05] /etc/kernel/postinst.d/zz-update-grub has both [10:06] cjwatson: /boot/grub/grub.cfg is present in ubuntu-cloud images, which are then booted as an lxc container =( [10:06] cjwatson: http://launchpadlibrarian.net/142639886/memtest86%2B_4.20-1.1ubuntu4_4.20-1.1ubuntu5.diff.gz [10:07] Yeah, that occurred to me afterwards [10:07] Just make the logic match /etc/kernel/postinst.d/zz-update-grub [10:08] i think it matches now, despite using different syntax for the same thing. [10:17] Looks like it, thanks [10:18] Hey, just reported a bug in launchpad and the status was changed to "incomplete" so I provided more info as asked, should I now change the status back to "New" ? [10:18] That's reasonable [10:19] ok, thanks === ckpringle_ is now known as ckpringle [10:58] Daviey: could you please approve my post to the ubuntu-server list? [10:58] and whitelist my address? :) [11:05] mvo_: ping [11:16] ev: ack === MacSlow is now known as MacSlow|lunch [11:20] mpt: briefly going back to the crash reports for Firefox and Chrome discussion, I forgot that I wrote this a while back: https://wiki.ubuntu.com/ErrorTracker/BreakpadApplicationSupport [11:21] so we're not without some work on this, albeit small === greyback is now known as greyback|lunch [12:01] ev, huh, I didn't know they used the same crash reporting system [12:01] yeah, we considered breakpad, but you need to link the world against it === MacSlow|lunch is now known as MacSlow === greyback|lunch is now known as greyback === mmrazik_ is now known as mmrazik === mmrazik is now known as mmrazik|afk [13:12] zyga: sorry, busy day today, could you send me a quick mail? I gtg to a meeting in some minutes [13:13] mvo_: sure, thanks [13:33] stgraber: FYI, this could remotely affect LXC: http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html [13:36] pitti: soounds like it won't make things much worse. As it currently is, it's almost impossible to run systemd in a container. Some Fedora users have been trying for months, sent a dozen patches to LXC but all of it is just trying to workaround silly limitations put in place by systemd (like it refusing to start getty on pts devices or indeed messing with cgroups in a way it shouldn't) [13:38] stgraber: yeah, I rather meant the upcoming changes to the kernel side of cgroups [13:38] the bit about assigning resources to users may indeed be problematic (assuming that's done in logind and not systemd), though that's something we need to deal with at some point anyway if we want unprivileged containers [13:38] ah yeah, we're aware of the upcoming kernel changes, hallyn has been following those discussions for a while now [13:38] stgraber: ah, good; nevermind them [13:39] stgraber: yeah we'll need to update lxc to use 'cgroup.procs' instead of 'tasks' soon [13:40] kenvandine, seb128, didrocks (and anyone else :-) ): would you please endorse me? https://wiki.ubuntu.com/AlbertoMardegan/CoreDeveloperApplication [13:40] mardy, hey, sure! [13:40] pitti: oh, you too :-) ^ [13:41] mardy: hey, will do :) === wedgwood_away is now known as wedgwood [13:43] oh, so where was that magical UDD page about "what did I sponsor for X?" [13:43] mardy: ^ if you happen to have a list, I'd appreciate :) [13:43] (back in 30) [13:44] mardy, will do === lfaraone_ is now known as lfaraone === mmrazik|afk is now known as mmrazik [13:47] pitti, kenvandine, seb128, didrocks: I renamed the page to https://wiki.ubuntu.com/AlbertoMardegan/ContributingDeveloperApplication [13:47] mardy: making more sense, thanks! [13:47] mardy, great ;-) [13:47] pitti: there's a couple of links here: https://wiki.ubuntu.com/AlbertoMardegan/ContributingDeveloperApplication#Examples_of_my_work_.2BAC8_Things_I.27m_proud_of [13:54] pitti: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi === kentbout is now known as kentb [14:35] mardy: hm, seems I didn't actually sponsor anything from you? [14:35] Laney: thanks [14:36] thank the awesomebar! [14:36] * Laney hands out "Firefox by default" buttons [14:37] make it work usable on arm [14:37] then we can talk [14:41] Laney: +1 :) [14:57] pitti: I corrected my application wiki: I'm actually applying as contributor, not core-dev anymore [15:05] arges: just fyi, we do need the previous 14.9 changelog entry and need to debuild -v1.0+noroms-0ubuntu14.8 to build the qemu precise package - but i'll do that. [15:06] hallyn: oh ok, let me know if you need anything from me then [15:16] arges: pushed to precise-proposed with http://people.canonical.com/~serge/qemu-kvm.debdiff as the debdiff [15:17] arges: (now we just need an SRU admin to accept it) [15:18] hallyn: thanks [15:19] Laney: I'm not Australian, but I support chromium by default! [15:19] np :) [15:25] Riddell: hey, are you monitoring the libical transition? you started it and it seems to be stuck in proposed for quite a few days [15:25] Riddell: as you bump the build-deps on it, this makes some of our components like indicator-datetime stalled [15:25] sil2100: ^ [15:26] didrocks: hmm yes, that's on my todo for today [15:26] Riddell: could you poke me once that's pushed further? [15:26] Since I'd like to unblock indicator-datetime then [15:26] thanks Riddell for looking at it :) [15:30] sil2100: bug 1191792 is the remaining blocker for the ibus transition, I worked around openchange's build problem [15:30] bug 1191792 in kmymoney (Ubuntu) "kmymoney fails to build on saucy" [High,New] https://launchpad.net/bugs/1191792 === mmrazik is now known as mmrazik|afk [15:36] jbicha, "ibus transition"? [15:36] s/ibus/ical [15:37] too many i's [15:37] k [15:42] sil2100: the indicator-datetime failure doesn't have anything to do with libical [15:44] Riddell: the indicator-datetime failure I have been encoutering while trying to get my branch merger in did have, since it was failing because of: Depends: libical-dev (>= 1.0) but 0.48-2 is to be installed. [15:48] jbicha: hmm new libaqbanking probably the culprit there [15:48] sil2100: you need to enable -proposed to get 1.0 installed === dholbach_ is now known as dholbach [15:50] Riddell: we know that, but mergers do not have -proposed, and the CI team has some reasons for why it cannot be enabled there [15:50] Riddell: but I merged that in manually already [15:50] Riddell: yes I believe so [15:50] Since this way we can unblock everything, as libical can move from -propose to saucy now that indicator-datetime will be re-built [15:52] sil2100: That's going to be "interesting" in the case of transitions [15:52] Your CI team is probably wrong :) [15:56] We've been hearing that a lot lately ;) [16:01] (Speaking as the person who manages proposed->release migration) [16:15] jbicha, btw, uploaded new deja-dup with your g-c-c panel name fix [16:16] mterry: cool, thanks :) [16:18] \msg Laney ping [16:18] ops.... sorry [16:20] andyrock: you can just ask your questions in the channel, you probably don't need to privmsg people [16:21] the secret world of privmsg! [16:22] Laney, hey good morning/afternoon/evening [16:22] i still can reproduce https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1182307 [16:22] Launchpad bug 1182307 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_type_check_instance()" [Medium,Fix released] [16:22] can you file a new bug? [16:23] I would say if you have the fixed package it's more likely to be a different one with similar symptoms [16:25] Laney, sure [16:25] andyrock: From the commandline: apport-bug /var/crash/_usr_bin_nautilus. [16:27] brb === andyrock_ is now known as andyrock [16:33] Do we know what version of qemu is going in saucy yet, and/or is there a packaged version around somewhere? (not according to packages.ubuntu.com) [16:34] ok ignore me - packages.ubuntu.com is playing up. The answer is 1.5.0 === v2azkk is now known as trickyj [17:05] jbicha: got kmymoney compiling, all the fault of something called gwenhywfar [17:06] we should have more Celtic-language-family package names [17:06] sounds ominous enough [17:06] I was going to go with WelshOS [17:06] (IIRC that one is the Welsh for "Guinevere") [17:07] * slangasek nods [17:11] Riddell: while looking around for a fix, I noticed that Fedora backported about 15 patches to fix various issues [17:11] you can grab the src rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=421621 if you're interested [17:18] Daviey, slangasek, cjwatson can I get some SRU love on the precise unity upload https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=unity [17:21] Laney, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1191883 [17:21] Launchpad bug 1191883 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_type_check_instance()" [Undecided,New] [17:23] * andyrock had some issues with apport [17:25] sil2100: so new indicator-datetime will be going in? [17:26] chiluk: yep, I can have a look this afternoon [17:26] awesome thanks. [17:27] barry: fyi, the python2.7 SRU for bug #1058884 is currently stalled out because there's an existing SRU in -proposed that needs sorted (bug #1088771 failed verification); maybe you can help get that un-stuck? [17:27] bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [High,In progress] https://launchpad.net/bugs/1058884 [17:27] bug 1088771 in python-defaults (Ubuntu Precise) "dangling symlink /usr/lib/pkgconfig/python2.pc" [Low,Triaged] https://launchpad.net/bugs/1088771 [17:27] slangasek: sure, i can take a look [17:30] cjwatson, stgraber: ok... correction, the parted in the recovery image does *not* recognize the partiton table correctly :P [17:30] GNU Parted 1.8.8.1.179-aef3 [17:30] I'm working on the necessary backports in any case [17:31] well, this is the parted from the android build ;) [17:31] one wonders why it's there at all if it's in such a dire state [17:31] Yeah, but presumably it would help to have a working parted somewhere [17:31] generally speaking! [17:32] Adding http://paste.ubuntu.com/5774631/ seems to do the trick === francisco is now known as Guest20683 [17:42] cjwatson, if a software migrated from qt4 (where is was available on ppc) to qt5 (where it's not), is deleting the ppc binary from the old version the right thing to do to unblock the proposed->archive migration? [17:43] seb128: Probably, yes, but check its rdepends [17:43] cjwatson, https://launchpad.net/ubuntu/+source/signon-ui/0.15daily13.06.12-0ubuntu1 is the source [17:44] hum, that's going to make the ppc desktop quite unhappy I guess [17:44] kenvandine, ^ [17:44] :/ [17:45] you think we have users of unity on PPC ? [17:45] no [17:45] * ogra_ would expect them to use lubuntu or so [17:45] without unity, signon-ui won't get used [17:45] since we only show the signon panel on unity [17:45] the issue is that it will likely make the desktop not installable on ppc [17:46] not sure how to deal with it [17:46] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber [17:46] out of starting rebuilding stuff without uoa on ppc [17:47] but if we are sure that there are no unity users, why doe we bother to make it installable ? [17:47] The rdepends stack is fairly large, but is it possible that it just makes some unity scopes and account plugins uninstallable (indeed those would need to be removed too)? [17:48] It *looks* that way to me [17:48] * JanC wonders how often PPC is still used? [17:48] The side discussion is unlikely to be productive here [17:48] surely there are quite some server users [17:48] it looks like empathy and shotwell are the real problems [17:48] cjwatson, can we just delete the binary and see what happens and fix fallouts later (or wait to see if anyone care enough to fix those)? [17:48] slangasek: i cannot reproduce lp: #1167177 in a chroot. what am i missing? [17:48] Launchpad bug 1167177 in python-defaults (Ubuntu Precise) "package python-dev 2.7.3-0ubuntu2 failed to install/upgrade: tentative de remplacement de « /usr/lib/pkgconfig/python2.pc », qui appartient aussi au paquet python2.7 2.7.3-0ubuntu3.1" [High,Triaged] https://launchpad.net/bugs/1167177 [17:48] empathy and shotwell depend on libsignon-glib1 [17:48] seb128: Please don't, that makes proposed-migration more fragile [17:49] which depends on signond, which depends on signon-ui [17:49] shrug [17:49] barry: "luck" in the unpack ordering in your local test? [17:49] barry: you may want to dpkg -i /path/to/python-dev.deb explicitly [17:49] we just had the discussion about how we can make empathy not depend on it last week [17:49] kenvandine, not sure how to deal with it, out of starting rebuilding stuff without uoa on ppc [17:49] seb128: Its constraint is that the total *number* of uninstallables not decrease - so every extra uninstallable in the archive gives it more wiggle room, and not in a good way [17:49] which was "not easily" [17:50] slangasek: could be. let me try that [17:50] same for shotwell [17:50] kenvandine, well I guess we can stop enabling uoa for those on ppc [17:50] empathy's involvement here seems to be a Recommends [17:50] Ah, Build-Depends [17:50] not really [17:50] internally it's private lib links to it [17:50] and is hard to unravel :/ [17:51] No, it's a build-depends leading to signond which only Recommends: signon-ui [17:51] oh [17:51] right [17:51] shotwell doesn't seem to show up in the Depends stack [17:51] then that shouldn't break [17:51] same for shotwell [17:52] shotwell depends on libsignon-glib1, which depends on signond which recommends signon-ui [17:52] As I say, there's a certain amount to unravel here and I'd like us to remove some subset that keeps things consistent (and preferably that won't reappear next rebuild) [17:52] But it doesn't seem intractable [17:52] and since the whole thing came up due to ubuntu touch testing, note that ubuntu touch images build with --no-install-recommends still ... [17:53] (just as a side comment wrt recommends) [17:53] Riddell: it should, but... jenkins is preparing for a shut down [17:53] So I'll take care of that tomorrow [17:55] kenvandine, going to be fun dropping those... [17:56] on that note, need to go for dinner [17:56] bbiab [18:01] libsignon-glib1 doesn't need to depend on signond though, so empathy & shotwell should be fine if signon-ui is the only thing that's broken [18:01] slangasek: okay, forcing the order allowed me to reproduce the problem, and the proposed fix look right. should i apply this to a new version of python-defaults 2.7.3-0ubuntu2.1 and get the one in proposed bounced, or prepare a -0ubuntu2.2? [18:05] barry: python2.7/2.7.3-0ubuntu3.2 is the version already in -proposed; you can reupload python2.7/2.7.3-0ubuntu3.3 with both fixes - and in that case, please make sure to build the source package with a -v option pointing to the last version in precise-updates [18:06] * barry nods [18:14] slangasek: actually, the fix is in python-defaults, but i understand what you mean :) [18:14] barry: ah right :) [18:14] slangasek: uploaded [18:18] barry: ta === alexbligh1 is now known as alexbligh [18:34] andyrock: ta [18:34] yw [18:37] cjwatson: so, parted also isn't happy with the N7 partition table... completely different behavior though :) [18:37] Error: /dev/block/mmcblk0: unrecognised disk label [18:42] cjwatson: where should I start with this? [18:43] Jan 7 00:49:56 ubuntu-phablet kernel: [ 3.495050] Primary GPT is invalid, using alternate GPT. [18:51] cjwatson: doh... heh, I fixed the gpt thing this morning too ;) [18:53] psusi: any thoughts on my new parted issue (above)? :) [18:54] slangasek: parted does not complain about this but the kernel does? [18:55] psusi: the opposite; the kernel is "happy" with the alternate GPT, parted doesn't read it at all [18:55] slangasek: and this is with the proposed fix it looks like cjwatson just uploaded a few minutes ago? [18:55] psusi: yep - different device [18:55] different crazy-wrong partition table [18:55] slangasek: you seem to have pasted a kernel error message? [18:57] psusi: well, I wouldn't call it an error, but a warning [18:58] slangasek: right... so the kernel is saying the primary is corrupt, and it's using the backup... does parted agree with this assessment? [18:58] psusi: http://paste.ubuntu.com/5774883/ [18:58] psusi: no, parted says 'Error: /dev/block/mmcblk0: unrecognised disk label [18:58] ' [18:59] slangasek: which version of parted? the one cjwatson just uploaded to fix the nonstandard gpt size issue? [19:00] psusi: yes [19:00] 2.3-13ubuntu2 [19:00] slangasek: did it fix the problem with the other system? [19:00] psusi: actually haven't tested that one yet... let me do that now [19:00] slangasek: and how about gdisk? [19:01] psusi: http://paste.ubuntu.com/5774895/ [19:04] psusi: so... the /kernel/ likes it this time, but nothing else does :) [19:05] slangasek: looks like the kernel doesn't bother checking the version number [19:06] slangasek: so it looks like your primary is corrupt, and the backup has the wrong version number, which the kernel fails to notice [19:08] psusi: so, what's the correct solution here? Should parted be bug-for-bug compatible with Linux? Should there be some tool I can use to "repair" the alternate GPT/ [19:08] slangasek: did the new version at least fix the problem with the first machine? [19:08] psusi: note that this device is the Nexus 7, which I'm told is notorious for being bricked if one fiddles with the partitioning... I suspect that writing to the primary GPT might be a bad idea :) [19:09] you may be able to use gdisk to repair it, or you might just have to hex edit it by hand... linux probably should be fixed to check the version number [19:09] psusi: yep, new parted works fine on the other device (N4) [19:09] I thought mmc devices had their own low level partition scheme? [19:10] psusi: I'm wary of "fixing" the kernel because I suspect the firmware's partition support (fastboot) of being a house of cards that may explode if I touch anything I shouldn't [19:10] rsalveti: ^^ what do you think of the above? (N7 GPT is invalid from parted's perspective, and barely passes the kernel) [19:10] last time I tried fiddling around on my android phone, it looks like mmc has its own low level partition table, and there is no msdos or gpt [19:11] mmc is just a storage medium, and the particular partition table used is implementation-dependent [19:11] so far, the Nexus devices seem to be GPT [19:11] I'm pretty sure when I looked at the kernel mmc code, it had its own low level partition table that all mmc devices must have [19:17] psusi: well, the N4 was the device with the other non-checksumming GPT, and it was also /dev/mmcblk0 [19:17] psusi: what you describe sounds like mtd, which some android device use, but AFAIK not the Nexus ones we're looking at [19:18] slangasek: it also looks like this new device has no protective MBR? can you confirm that with fdisk? [19:18] ahh, right, mtd is what I was thinking... [19:19] psusi: fdisk also bombs out spectacularly, yes [19:19] Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel [19:19] pitti: should we turn on apport opening bugs on Launchpad now? [19:19] slangasek: then the kernel shouldn't be recognizing it either [19:19] I'll leave you two to the parted investigation, since I'm mostly meant to be childcaring now :) [19:21] unless... there's a kernel command line " [19:21] "gpt" option to force it to use gpt without a valid protective mbr [19:21] but the mbr is required by the efi standard, which says you shall not treat it as gpt without it [19:22] how is EFI relevant on ARM? [19:22] because EFI is the standard that defines GPT [19:22] We do already bend that rule for Apple, of course ... [19:22] (In a fairly evil way, but still) [19:23] why is that? [19:23] psusi: well, let's see. 'gpt gpt_sector=30535679' [19:23] Because Apple bent it before us and we had to play along in order to work there [19:23] They have a legacy MBR rather than a protective MBR [19:24] legacy or hybrid? no type ee or ef? [19:24] See gptsync.patch [19:24] No time to explain now [19:24] right; similar issues apply here, I need to be able to work with the partition tables that come on the device, waving the text of a standard at my phone isn't going to help me read/edit the partitions [19:24] I might mean hybrid, I forget which adjectives settled down into meaning which things [19:28] slangasek: say, if you don't want to mess with the goofy partitions this device comes with, why do you care about what parted thinks about it? [19:28] slangasek: hm, that's kind of unexpected [19:28] just flashed my n10, let me check that as well [19:29] psusi: I want to repartition the device; I want to do so in a way that won't brick the device in the process, by, say, writing to a new location that the firmware is doing something funky with [19:31] slangasek: it seems that they have patched their kernel to handle some funky stuff... I'd start by seeing what they patched in block/partitions/gpt.c [19:32] ah, the pain [19:32] ok [19:32] hehe [19:34] err, it's efi.c, not gpt.c [19:36] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=history;f=fs/partitions/efi.c;h=30546cc8d03faa14f9fc0e05df307e24db006371;hb=grouper [19:36] not seeing any weird patching in there [19:38] slangasek: might be interesting to dd the table to a USB stick and try it on a standard Ubuntu machine, see what a clean kernel thinks of it [19:39] hmm, possibly. [19:39] how do I find the table? :P [19:39] gpt_sector=30535679 - how does that translate to a dd command? [19:40] looks like sectors are 512 bytes [19:40] 0-indexed? [19:41] hmm, that'd mean the table is pretty much at the end of the flash then? [19:41] that's why I said they seem to have patched their kernel... because I don't see any gpt_sector kernel argument [19:42] slangasek: dd if=/dev/mmcblk0 of=gpt.img bs=1K count=32 seek=30535679 ? [19:42] hmm * 512 [19:42] psusi: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=commit;h=2311e2e994b86a4d9592ba9cc63e9d877fe270f6 [19:43] stgraber: in fact, total disk size is 30535680 sectors [19:44] slangasek: hmm, so that'd be 512 bytes for the table? sounds rather short. How big is that flash 16GB? [19:44] Disk /dev/block/mmcblk0: 15.6 GB, 15634268160 bytes [19:45] slangasek: the header is one sector... it describes how long the table itself is, which normally is 128 bytes x 128 entries, but the other device you had only had 9 entries [19:45] so if the header is 1 sector, where does it put the table? :) [19:46] because it claims to be reading it from the last sector on the device [19:46] slangasek: immediately following for the primary, and preceeding for the backup [19:46] psusi: confirmed that we have this kernel in the grouper kernel but it's not an upstream patch and likely isn't in our desktop kernel [19:46] psusi: "preceding" -hah [19:46] ok [19:46] slangasek: nexus 10: http://paste.ubuntu.com/5775036/ [19:47] slangasek: so in your case it should be the 3 sectors leading up to the last one, then the last one itself is the backup header [19:47] rsalveti: well, that's nice enough :) [19:47] kind of odd that it passes the kernel override argument and points it to the last sector, which is where the backup is suppoed to be anyhow [19:48] psusi: yeah, beats me :) [19:48] though it is also weird that the device doesn't seem to have a primary [19:48] rsalveti: wow, that one looks valid, nice and short, that's a change ;) [19:48] stgraber: :-) [19:49] hmm, so does adb handle sparse files? :P [19:49] slangasek: that may explain why some people bricked their device while messing with gpt. Some editors may be able to see the backup table, load that, do the change and then write the master table, possibly overwriting part of the bootloader in the process [19:49] right [19:50] yes, that's exactly my concern [19:50] dd if=/dev/block/mmcblk0 of=gpt.img bs=512 count=4 skip=30535676 [19:50] slangasek: dd count=4 if=/dev/mmcblk0 | xxd? [19:51] psusi: http://paste.ubuntu.com/5775052/ [19:53] $ sudo kpartx -lv /tmp/gpt-full.img [19:53] $ [19:53] so... a stock kernel doesn't seem to like it very much? [19:53] what's gpt-full.img? [19:54] stgraber: reconstituted sparse image from 'adb pull /data/gpt.img && dd if=gpt.img of=gpt-full.img bs=512 count=4 seek=30535676' [19:55] slangasek: it looks like the stock kernel will do the same thing since the backup is actually at the end of the disk ( you did say that right? ), and it doesn't bother checking the version number [19:56] psusi: it is at the end of the disk; still, kpartx doesn't do anything useful with such an image, but maybe that's kpartx's fault [19:57] it may also be checking the version and rejecting it because of that being wrong [19:59] psusi, stgraber: so I definitely see an android patch on fs/partition/efi.c: StrawberryMountain:~/ubuntu-saucy$ git log fs/partitions/efi.c [19:59] 2311e2e994b86a4d9592ba9cc63e9d877fe270f6, fs: partitions: efi: Add force_gpt_sector parameter [19:59] * slangasek eyes the pasting [19:59] at any rate, this device appears to be a hack job where they have something else ( boot loader? ) at the start of the disk, and rely on a mal-formed backup gpt at the end... there's just no clean way to deal with this [20:00] psusi: so you would consider a parted option to "only write the table back where you found it" to be uncleas? [20:00] unclean [20:00] yes... that and you still have the problem of the version number being wrong [20:02] slangasek: so I'm starting to wonder if we wouldn't get more reliable results if we were to ship a copy of the original and new partition table in the recovery image for each device where we support re-partitioning. That way we would basically just checksum the existing one, if it matches the backup we have, we dd the new one and do the opposite to restore. [20:03] slangasek: that'd give us way more insurance that we won't screw things up and would allow for possibly pretty weird hand-hacked table to be put in place without relying on heavily patched tools [20:04] that sounds like a good idea [20:04] psusi: I'd be willing to try binary patching the alternate GPT here to fix the version, if you could guide me through that; but that still leaves the problem of being able to adjust the partition tables without corrupting the bootloader.. which maybe stgraber's idea solves, yes [20:05] stgraber: well, I wasn't expecting "heavily patched", I was expecting "let's address these incompatibilities upstream" [20:05] safer all around.. the way if you brick your device you can deal with it, and users only get a partition table that has been tested and known to work [20:07] for that matter, you could just say to hell with partitioning and use a loopback file ;) [20:07] that's our plan for the devices we don't have a custom partition table for [20:07] for the 4 devices we fully support, we'd prefer to avoid the performance and power impact of loop mount though [20:08] (power impact is ~5%, performance is a bit random but appears to be at least 10%) [20:08] loopback file - doesn't provide read-only control at the lowest level, doesn't let us leverage the space on the system partition, has a silly performance penalty [20:10] psusi: so how can I fix the version number here (or where should I read about the table layout to figure this out for myself)? [20:12] slangasek: efi.h defines it in the kernel sources.. 64bit signalture followed by a 32 bit version number that should be 0x00010000, but I don't think changing it is what you want to do... parted will still overwrite the primary copy [20:13] though if yuo're just trying to hack this up and then restore the original contents at the start, that should work [20:14] psusi: well, we have several devices to be supported and I don't want to have to *generate* the binary deltas for the whole table by hand [20:15] yea... so for that purposes, dding a value of 0x0001 to offset 8 may get it going, then you just have to throw out the primary and put back the original contents there, and change the 1 back to a zero later [20:16] * slangasek nods [20:16] err... endienneess probably makes it the other way around [20:16] damn liliputians [20:17] mm? [20:17] so 0x00000100 instead? [20:18] should be whatever 0x00010000 is in little endien format [20:19] upper word is major revision, lower word is minor [20:19] ok [20:20] slangasek: http://paste.ubuntu.com/5775132/ for galaxy nexus [20:21] rsalveti: ok, thanks. Can you get these to me as binary dumps of the partition tables? (First 512k of the disk on each, to be safe) [20:22] slangasek: sure [20:25] fortunately, the partition layouts are reasonably similar in all cases and let us grow the system partition without moving anything besides cache and userdata [20:25] psusi: so the other reason I wanted to use parted for this was to be able to shrink+move the userdata partition... instead of having to reformat it. [20:28] slangasek: you mean using resize2fs + my recent parted patches that ubuntu isn't yet carrying to resize the partition? [20:34] psusi: hmm, are there patches not yet in Ubuntu for this? I thought parted already had good support for resize/move :) === _salem` is now known as _salem [20:35] slangasek: no, which is why upstream killed the functions entirely ;) [20:35] heh [20:35] it only really worked on fat and hfs [20:36] slangasek: so much for that [20:36] but I have some patches I'm still trying to get applied to add a resizepart command so you can at least manually run resize2fs to resize the filesystem and parted to resize the partition [20:37] psusi: note that we also need to be able to move the partition for this to be any good... is /that/ supported? [20:38] it was removed upstream as well, but I think is still supported in our version [20:38] ok [20:38] well [20:38] that still means we would need a parted that can deal with this partition table [20:38] of course, that just amounts to a dd [20:39] except that, I hope, it can deal with the case where the partition moves back by a distance less than the new partition size [20:39]