| veebers | Hi all, would anyone be able to take a look at this bug?: https://bugs.launchpad.net/bugs/1085767 | 00:55 |
|---|---|---|
| ubot2 | Launchpad bug 1085767 in ubiquity (Ubuntu) "Installer boot halts and hangs (netboot + nfs)" [Undecided,New] | 00:55 |
| veebers | or at least what/if there is any other details that I can provide to make it more useful? | 01:24 |
| FourDollars | cjwatson: I may find the root cause of https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1087653 . | 09:34 |
| ubot2 | Launchpad bug 1087653 in OEM Priority Project "grub2-signed doesn't support removable drive." [High,New] | 09:34 |
| FourDollars | cjwatson: grub2-signed will only read (hd1,msdos1)/EFI/ubuntu/grub.cfg but not (hd1,msdos1)/EFI/BOOT/grub.cfg . | 09:35 |
| cjwatson | FourDollars: grubx64.efi reads from /EFI/ubuntu/; gcdx64.efi reads from /EFI/BOOT/ | 09:36 |
| cjwatson | they're intentionally configured differently per the UEFI specification | 09:36 |
| cjwatson | so grub-install --removable probably needs to remember to use gcdx64.efi | 09:36 |
| cjwatson | I've reassigned the bug to grub2 accordingly | 09:36 |
| FourDollars | cjwatson: Yes. That is why `grub-install --removable` doesn't work for me. | 09:38 |
| FourDollars | cjwatson: I finally understand the difference between gcdx64.efi and grubx64.efi. | 09:38 |
| cjwatson | there are a couple of other differences in the module set available, but they aren't relevant here | 09:39 |
| FourDollars | cjwatson: BTW, `grub-install --removable` of precise-proposed will not create /EFI/BOOT/grub.cfg automatically. Is it normal? | 09:43 |
| cjwatson | You're the first person to test --removable on UEFI SB | 09:45 |
| cjwatson | So in general it's not a surprise (and not a regression) if it's broken | 09:45 |
| FourDollars | I know. Because I need this function. XD | 09:45 |
| cjwatson | Sure, just saying, expect it to be broken right now because nobody has previously cared | 09:46 |
| FourDollars | Do you remember I have asked the same question in one UDS seesion? | 09:46 |
| cjwatson | I'm afraid I have trouble remembering everything from UDS, sorry - I'm not saying I won't fix it, just that asking "is it normal" doesn't make sense | 09:47 |
| FourDollars | Not mind. | 09:48 |
| cjwatson | Ah, now, I do see a mistake in my backport here | 09:48 |
| cjwatson | Which could be the cause of stgraber's trouble as well | 09:54 |
| cjwatson | FourDollars: Try applying http://paste.ubuntu.com/1422879/ to /usr/sbin/grub-install | 09:59 |
| FourDollars | cjwatson: Will grubx64.efi read /EFI/BOOT/grub.cfg ? I just put a /EFI/BOOT/grub.cfg and it doesn't work. | 10:01 |
| cjwatson | No, it will not | 10:01 |
| cjwatson | But if you apply the patch I gave, grub-install will use gcdx64.efi instead | 10:01 |
| cjwatson | (with --removable) | 10:02 |
| FourDollars | cjwatson: I see. | 10:02 |
| FourDollars | cjwatson: Is http://paste.ubuntu.com/1422879/ used for grub2 of precise-proposed? | 10:03 |
| cjwatson | Yes | 10:04 |
| FourDollars | cjwatson: I have manually copied gcdx64.efi to /EFI/BOOT/grubx64.efi. | 10:04 |
| FourDollars | cjwatson: Will gcdx64.efi read any grub.cfg by default? | 10:05 |
| FourDollars | OK. Let me try you patch first. | 10:07 |
| FourDollars | s/you/your/ | 10:07 |
| gema | xnox: ping | 10:11 |
| gema | xnox: bug 1087630 needs some attention, are you aware of it? | 10:11 |
| ubot2 | Launchpad bug 1087630 in ubuntu-meta (Ubuntu) "server minimal virtual installations are bloated" [High,Confirmed] https://launchpad.net/bugs/1087630 | 10:11 |
| gema | xnox: if this not important, I'd like to know so that we can demote these tests out of smoke testing | 10:12 |
| xnox | gema: I have seen being pinged about this bug. But it's not for me to fix, it will probably need seed changes. | 10:13 |
| xnox | gema: I have a point to bring about smoke testing. | 10:13 |
| gema | xnox: so who should be fixing this? | 10:13 |
| gema | xnox: good, go ahead | 10:13 |
| infinity | Do was actually want to hard-cap the installation size so strictly? | 10:13 |
| xnox | gema: I would think server product owner would be the one interested in fixing this. | 10:13 |
| gema | infinity: I don't know, we were asked to add this last cycle, it may not be so important anymore? | 10:13 |
| xnox | gema: I think static analysis should not block other testing. | 10:14 |
| xnox | gema: e.g. I have noticed that Wubi check was removed from iso static pre-test, because on initial raring images wubi was not present yet. | 10:14 |
| infinity | Bah, and cdimage has already dropped the old manifests, I wanted to see if it was new packages being added, or just packages growing. | 10:14 |
| gema | xnox: this one in particular is not static analysis | 10:14 |
| xnox | gema: the wubi check then blocked testing of downstream projects. | 10:15 |
| xnox | gema: does the server minimal install test block downstream testing of i386 server? | 10:15 |
| gema | xnox: yes, because we run static analysis on the default job that kicks everything else | 10:15 |
| infinity | Ahh, the buildd has a few more. Handy. | 10:15 |
| gema | xnox: nope, this is a job that kicks of on a minimal VM and ubuntu doesn't really fit, it is a minimal configuration type of test | 10:15 |
| xnox | gema: which is not fully correct, since the server cdimage is good, does complete the install, abeit oversized. | 10:16 |
| cjwatson | FourDollars: With my patch, grub-install --removable should create /EFI/BOOT/grub.cfg and gcdx64.efi should read it. Please don't copy anything else around manually - you will just make it harder to diagnose your system. | 10:16 |
| xnox | gema: ah, ok then. | 10:16 |
| FourDollars | cjwatson: Roger that. | 10:16 |
| gema | xnox: ok, so we may need the release team's help defining what is smoke and that is not, and what are blocking factors for downstream testing | 10:16 |
| cjwatson | gema: This is absolutely a matter for the server team | 10:16 |
| gema | cjwatson: ack, will talk to them | 10:16 |
| xnox | gema: from a developers perspective (/me is not release team) I want to attempt as many tests as possible & see the output from as many as possible. | 10:17 |
| cjwatson | While we can help with matters that turn out to be installer bugs, IIRC last time I investigated most of this was not | 10:17 |
| cjwatson | And the question of what limits should exist on a product is up to the product team in question | 10:17 |
| gema | cjwatson: understood | 10:17 |
| cjwatson | But yeah, I agree with xnox, this isn't an "image is hosed, don't try anything more" issue | 10:18 |
| infinity | gema: As for what's on the CD, (literally) nothing changed in the window the bug refers to. | 10:18 |
| cjwatson | There was an old bug on this which I don't think has been closed | 10:18 |
| cjwatson | So it's probably a dup | 10:18 |
| xnox | gema: I am ok seeing that for example 8 tests against server ISO have "total install size fail", yet it still boots & installs in all 8 server test cases (for example) | 10:18 |
| cjwatson | Ah, one of the two old bugs was wontfixed | 10:19 |
| infinity | 64309655a78512e0ed4f2533dcc2ade0 livecd.ubuntu-server-20121208-amd64.manifest | 10:19 |
| gema | xnox: I think we need to explain what smoke is actually testing and then have a discussion on what are the blocking factores | 10:19 |
| infinity | 64309655a78512e0ed4f2533dcc2ade0 livecd.ubuntu-server-20121209-amd64.manifest | 10:19 |
| cjwatson | gema: bug 1028453, bug 1053770 | 10:19 |
| ubot2 | Launchpad bug 1028453 in livecd-rootfs (Ubuntu) "Quantal Ubuntu Server minimal install oversized" [High,Fix released] https://launchpad.net/bugs/1028453 | 10:19 |
| ubot2 | Launchpad bug 1053770 in ubuntu-docs (Ubuntu Quantal) "ubuntu-server install takes up too much space" [High,Fix released] https://launchpad.net/bugs/1053770 | 10:19 |
| cjwatson | ^- history | 10:19 |
| xnox | gema: yeah. | 10:19 |
| infinity | gema: ^-- The package set on the CDs was actually identical between the two stated dates. | 10:19 |
| infinity | gema: So, whatever broke was post-install (in the server tasks, I'd assume) | 10:20 |
| infinity | gema: ie: retrying the test with 20121208 should show the same issue, so clearly not the ISO's fault. | 10:20 |
| infinity | gema: I thought the original stated go/no-go smoke-test was going to be just "boot/install/reboot", nothing fancy. | 10:21 |
| gema | infinity: that's what it will be, this is smoke testing post publishing the images | 10:21 |
| xnox | infinity: jenkins tells me 20121206 was the last good, and we started to be over the size since then. | 10:21 |
| xnox | infinity: https://jenkins.qa.ubuntu.com/view/Raring/view/Smoke%20Testing/job/raring-server-i386-smoke-minimal-virtual/buildTimeTrend | 10:21 |
| infinity | gema: Oh, if this is post-publish, that's different. xnox implied this was a "stop-ship" somehow. | 10:22 |
| gema | infinity: nah, we are not doing the stop-ship one yet | 10:22 |
| gema | infinity: we agreed we'd do that after Xmas | 10:22 |
| infinity | xnox: I'm looking at amd64, not i386. | 10:22 |
| infinity | gema: Right, hence my confusion, though. I don't actually care what tests are run (the more, the merrier) for post-ship regression testing. | 10:22 |
| gema | infinity: I think xnox means that if static validation doesn't pass, the way we have configured the jobs right now, no other jobs will run | 10:22 |
| gema | infinity: and he doesn't know if everything else works | 10:23 |
| infinity | gema: It's a matter of finding the right people who care about the tests (so, yes, the server team for install size) | 10:23 |
| xnox | infinity: amd64 was also 20121206 last good. | 10:23 |
| gema | cool | 10:23 |
| infinity | gema: Ahh, yeah. Having jobs block other jobs is unclever (unless the blocking job is "this hoses your whole VM so nothing else can run") | 10:23 |
| infinity | xnox: Then the bug lies. :P | 10:23 |
| cjwatson | I remember earlier versions of this bug as being annoying with the rls-mgr reports.qa pages | 10:24 |
| infinity | xnox: Even then, the only changes in the manifest are a version bump of libglib2.0-0 and sed. | 10:24 |
| xnox | infinity: well amd64 has no jenkins test results for 07,08 (probably not triggered due to dependency =( ) | 10:24 |
| cjwatson | Because ubuntu-meta was assigned to foundations by default (which isn't unreasonable), but there didn't seem to be a way for us to say "er, no, this is a server team thing" | 10:24 |
| cjwatson | Short of an artificial and probably wrong package reassignment | 10:24 |
| infinity | Assigning bugs works. :P | 10:25 |
| cjwatson | It didn't use to | 10:25 |
| cjwatson | I mean, you saw the assignee, but it was still in the foundations section | 10:25 |
| infinity | Right, that's a fundamental issue with the scrapey bot, though. | 10:25 |
| infinity | I'm not sure asking people to misuse Malone to work around the scraper is the right approach. | 10:26 |
| cjwatson | Well, indeed, that's what I'm saying | 10:26 |
| cjwatson | It was annoying because the scraper results were in general useful and people were looking at them, but we had to keep saying "no, that one isn't our bug, stop nagging us about it" | 10:26 |
| cjwatson | And I suspect the server team kept forgetting about it because it wasn't in their section | 10:27 |
| infinity | Anyhow. The insatiably curious guy in me kinda wants to know why the install size went up. | 10:27 |
| infinity | The rest of me doesn't care and, yes, it's a server team issue. :P | 10:27 |
| * gema goes talk to the server guys | 10:27 | |
| xnox | Daviey: how big should the server install size should be? | 10:27 |
| xnox | ^^^^ | 10:27 |
| xnox | gema: no need to go =) Daviey idles here ;-) | 10:27 |
| infinity | gema: Now, on the other hand, if the install size of ALL images goes up dramatically in the same window, that's likely something we (foundations/installer/cdimage/something) might care to have a quick glance at. | 10:28 |
| infinity | gema: Not something to fail on, per se, but something we can tick off as a "yeah, we meant to do that". | 10:28 |
| xnox | gema: do we have statistics on the offline desktop install size? | 10:28 |
| xnox | or e.g. size of core. | 10:29 |
| gema | xnox: no | 10:29 |
| gema | xnox: but we could gather them | 10:29 |
| xnox | (although core will probably not tell us much) | 10:29 |
| xnox | gema: that would be useful. E.g. jenkins plotted graph =) | 10:29 |
| gema | xnox: if you guys can define what kind of sizes you care about, we can have utah taking some measurements on every install | 10:29 |
| gema | Daviey: jamespage is on the case | 10:30 |
| xnox | gema: well it looks like in foundations we care more about the trends and up/down big jumps rather than X bytes. | 10:30 |
| Daviey | thanks | 10:30 |
| gema | xnox: I have been aiming to collect stats from installed images for a while, but I don't know what are the right indicators | 10:31 |
| gema | xnox: so if you could define them, we can start collecting them and start plotting them mid cycle or so? | 10:31 |
| gema | xnox: this would be queued after bootspeed and power consumption graphs :) | 10:31 |
| gema | xnox: but there's nothing stopping us from collecting the data already | 10:32 |
| xnox | gema: I see. Adding an item for me to file a bug with definitions that are stable and useful. | 10:32 |
| gema | xnox: thanks | 10:32 |
| gema | xnox: we will add another reporting area to smoke testing for trends and stick the graphs there | 10:38 |
| cjwatson | FourDollars: Any luck? If it improves things it might be worth me uploading that to precise-proposed ... | 10:39 |
| FourDollars | cjwatson: Not yet. I just generate the Debian packages. | 10:40 |
| cjwatson | FourDollars: Oh, my patch was one that you could just apply in place | 10:49 |
| cjwatson | Should be like 400 times faster | 10:49 |
| cjwatson | FourDollars: The correct patch for the packaging is a bit different since it would want to modify the patch system instead ... | 10:49 |
| cjwatson | 'sudo patch /usr/sbin/grub-install <the-patch-file' | 10:50 |
| FourDollars | cjwatson: It seems to use the (hd1,gpt2)/boot/grub/grub.cfg on HDD but not (hd1,msdos1)/boot/grub/grub.cfg on USB drive. | 10:50 |
| cjwatson | At this point it is not at all clear to me what you've done because you apparently aren't following my directions ... | 10:50 |
| cjwatson | So I'll have to ask you for full debug logs at every step | 10:51 |
| FourDollars | cjwatson: I use quilt to add your patch on grub2/precise-proposed. | 10:51 |
| cjwatson | That wasn't what I asked you to do | 10:51 |
| cjwatson | (debug logs: add the --debug option to grub-install, post result on paste.ubuntu.com) | 10:52 |
| FourDollars | OK. Let me try. | 10:52 |
| cjwatson | I appreciate your testing effort but you really need to follow my directions to the letter; remember that from my point of view I am trying to come up with a mental model of what your computer is doing by asking you to do specific things to it, and when you do different things from what I asked it makes it harder for me to come up with that model | 10:53 |
| FourDollars | Roger that. | 10:53 |
| FourDollars | cjwatson: http://paste.ubuntu.com/1422959/ | 10:55 |
| cjwatson | FourDollars: could I also have the full command line you used there, please? | 10:57 |
| cjwatson | just to make sure | 10:57 |
| FourDollars | cjwatson: sudo grub-install --debug --removable --uefi-secure-boot --root-directory /media/UsbStick /dev/sdb1 | 10:58 |
| cjwatson | So I *think* that using --root-directory is wrong | 10:59 |
| cjwatson | But I'm investigating | 10:59 |
| FourDollars | :) | 11:00 |
| cjwatson | Hmm, maybe that's a red herring | 11:01 |
| cjwatson | Oh, hmm, I see. So one of the problems with signed UEFI images is that there's no way to stuff a bootstrap configuration file into them, because that would be inside the signed region | 11:02 |
| cjwatson | Which means that they have to work everything out from context at boot time | 11:02 |
| cjwatson | The way that gcdx64.efi does this is to assume that it's on an Ubuntu installation image, and to look for a device that has /.disk/info on it | 11:03 |
| cjwatson | (Contents don't matter) | 11:03 |
| FourDollars | `mkdir /.disk && touch /.disk/info`? | 11:03 |
| cjwatson | Right, that's a necessary step, at least for now. However, there's one other thing I'm wondering about | 11:04 |
| FourDollars | Let me try. | 11:04 |
| cjwatson | At the moment, do either /media/UsbStick/boot/grub/grub.cfg or /media/UsbStick/boot/grub/x86_64-efi/grub.cfg exist? | 11:04 |
| FourDollars | cjwatson: Only /media/UsbStick/boot/grub/grub.cfg that I copied from my own system. | 11:06 |
| cjwatson | Hmm | 11:07 |
| cjwatson | So that's a problem too - let me try to work this out | 11:07 |
| FourDollars | cjwatson: After I touch .disk/info, it is back to the initial state of that bug. It can not show GRUB menu. | 11:07 |
| cjwatson | Sure, because (as I was trying to say) the embedded config file sources /boot/grub/x86_64-efi/grub.cfg | 11:08 |
| FourDollars | Oh~ I see. | 11:08 |
| cjwatson | I'm not sure this is the right answer, but just as a test, could you please create /media/UsbStick/boot/grub/x86_64-efi/grub.cfg with these contents: | 11:08 |
| cjwatson | source $prefix/grub.cfg | 11:09 |
| FourDollars | OK. Let me try it. | 11:09 |
| cjwatson | (This may actually be leakage from the different /boot/grub/ arrangement in 2.00 that I failed to correct when backporting all this to 1.99, hence my comment that it may not really be the right answer) | 11:11 |
| FourDollars | cjwatson: Yes. It works but the GRUB menu looks weird. | 11:11 |
| cjwatson | Progress | 11:13 |
| FourDollars | It looks like https://plus.google.com/111702816719386284707/posts/WDVNeumLwGP | 11:15 |
| cjwatson | OK, that's either a missing font or a missing locale | 11:16 |
| xnox | do you have /media/UsbStick/boot/grub/unicode.pf2 ? | 11:18 |
| FourDollars | OK, that should be fine because the grub.cfg is copied directly from my system. | 11:18 |
| cjwatson | Yeah, you need to copy unicode.pf2 in. In 1.99, this was handled only by the package postinst | 11:19 |
| xnox | (or is it /boot/grub/fonts/unicode.pf2 i have it in both locations on my system....) | 11:19 |
| cjwatson | You should find it in /usr/share/grub/ | 11:19 |
| cjwatson | xnox: /boot/grub/unicode.pf2 in 1.99 | 11:19 |
| xnox | ack. | 11:19 |
| cjwatson | So the grub.cfg copied from your system is probably making assumptions about the path to the font which don't hold when it's running with a different $root/$prefix | 11:20 |
| FourDollars | I think so. | 11:20 |
| FourDollars | I works now after I copy /usr/share/grub/unicode.pf2 into /media/UsbStick/boot/grub and modify /media/UsbStick/boot/grub/grub.cfg . | 11:22 |
| cjwatson | Excellent | 11:22 |
| cjwatson | So, going back to the /boot/grub/x86_64-efi/grub.cfg thing - that path is in fact used by installer images, which are the most important use case for gcdx64.efi | 11:22 |
| cjwatson | What I can do, though (it'll take a new grub2-signed upload to precise, but not otherwise hard), is to have gcdx64.efi try to read $prefix/x86_64-efi/grub.cfg and fall back to $prefix/grub.cfg if it's missing | 11:23 |
| FourDollars | Good. :) | 11:25 |
| * FourDollars looks forward the new grub2 in precise-proposed. :P | 11:26 | |
| cjwatson | Preparing it now | 11:29 |
| * FourDollars is away from keyboard. | 11:30 | |
| cjwatson | Thanks for the testing work | 11:31 |
| cjwatson | Uploaded to precise-proposed, pending SRU team review | 11:34 |
| FourDollars | np. I am glad to help. | 12:01 |
| psivaa | xnox: cjwatson: is there any update about the fix for bug 1080701 | 12:34 |
| ubot2` | Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed] https://launchpad.net/bugs/1080701 | 12:34 |
| psivaa | iirc xnox was going to look into that :) | 12:34 |
| xnox | psivaa: no update yet. Didn't get to it yet. Reached EOD on friday, but will look into it today. | 12:36 |
| psivaa | xnox: ok, thank you | 12:37 |
| infinity | cjwatson: Does ubiquity explicity (re)install the kernel, despite it already existing in the live image? | 15:18 |
| infinity | cjwatson: Seems to be set to auto in the squashfs, but after a fresh install, it's manual, so I'm assuming yes. | 15:18 |
| xnox | infinity: yes. | 15:20 |
| xnox | infinity: we also run update-initramfs to rebuild initramfs. | 15:20 |
| infinity | Yes, the latter is perfectly fine. | 15:20 |
| infinity | if name.startswith('linux-image-2.'): | 15:21 |
| xnox | infinity: what abut the former? cause trouble with kernel auto removal? | 15:21 |
| infinity | ^-- That's not outdated code... | 15:21 |
| cjwatson | scripts/check-kernels is more relevant | 15:21 |
| cjwatson | Heh, yeah, might be worth fixing traverse_for_kernel | 15:22 |
| cjwatson | So I think perhaps scripts/check-kernel should just append to /var/lib/ubiquity/apt-installed for already-installed kernels rather than doing the full apt-install thing | 15:23 |
| cjwatson | In general I think apt-install is right to do an explicit apt-get install, because other things it's asked for might be vulnerable to autoremoval otherwise | 15:23 |
| cjwatson | But it obviously doesn't make sense for individual kernel packages | 15:24 |
| cjwatson | We should just make sure that the top-level metapackages aren't autoremoved | 15:24 |
| infinity | Yeah. The whole traversal thing here feels wrong. | 15:25 |
| infinity | I can't sort out WHY it would want to drill down and install the "real" package instead of the meta. | 15:25 |
| infinity | Though there must have been a reason. | 15:25 |
| === bdmurray_ is now known as bdmurray | ||
| xnox | psivaa: i think i can now reproduce the hang. | 17:00 |
| psivaa | xnox: thanks, that's good :) | 17:09 |
| xnox | psivaa: yeah... | 17:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!