=== sagaci is now known as jpickett [08:34] I have a lot of identical machines. They have multiple NIC's (different chips and different drivers). 19 times out of 20, they come up with the 10G one being eth0 and the 1G one being eth1, but 1 time out of 20, it's the other way around. What are my best options for handling this? Can I specify a order in which the drivers get to initialise? [08:47] I'm thinking there must be something I'm overlooking. How does netcfg/choose_interface make sense with nondeterministic NIC naming? [09:20] cjwatson: I'm staring at biosdevname for a bit. I think I see a bug, but I'm a bit confused how this is supposed to work. [09:20] cjwatson: Some of biosdevname's magic is in a base-install.d hook, but how does the udeb get installed to begin with? [09:22] cjwatson: Anyway, the bug is that the base-installer.d hook doesn't actually allow you to prevent biosdevname from getting installed. [09:22] cjwatson: For each word in /proc/cmdline, it'll call "apt-install biosdevname". [09:22] cjwatson: Except if the word is "biosdevname=0" [09:31] cjwatson: Ah, it's included in d-i's base set. === zequence_ is now known as zequence [11:02] soren: Oh, wow, that's a horrible bug, nice catch. Could you file that, since I'm pretty sure I'll want to backport a fix for 12.04.3? [11:03] soren: As far as netcfg goes, you can tell it to pick an interface by mac address, which hooks into the syslinux mechanism for telling userspace what mac address it was pxe-booted from; does that help? [11:11] cjwatson: Not really. [11:11] cjwatson: I want the 10G nic. [11:12] cjwatson: If I could force that driver to load first, I'd be golden. [11:12] cjwatson: biosdevname may do the trick, though. [11:12] cjwatson: Sure, I'll file that bug. [11:15] bug 1134227 [11:15] Launchpad bug 1134227 in biosdevname (Ubuntu) "biosdevname always gets installed" [Undecided,New] https://launchpad.net/bugs/1134227 [11:16] Truth be told I don't know if it actually always does get installed (I haven't actually ever installed anything newer than precise from scratch), but looking at that code, it would be. [11:16] The logic is broken for sure. [11:16] You're almost certainly correct. I don't feel the need to verify. [11:17] Oh, indeed, since precise didn't have that same code it doesn't have that bug. [11:17] But having a bug doesn't hurt anyway :) [11:18] So you could try installing with biosdevname=1 (or quantal, which has that by default) and see if you get non-eth* names for the NICs. [11:18] cjwatson: I have that queued up for testing later today or tomorrow. [11:19] cjwatson: If that works for these systems, I'm probably in good shape. I guess I'm just surprised this hasn't been more of a problem for others in the past. [11:19] Well, it was one of the motivations for biosdevname [11:20] True. [11:20] Well, /me -> lunch [11:20] Thanks! [12:14] In the latest design proposal we want to show light bulbs (orange or dark dots) to indicate how many plugin pages there are & how many are done in the progress section. [12:14] this means that "expander with the skip button and terminal" are in the way. [12:15] I'm thinking to move those into a notebook page which one can switch to with "Ctrl-u" (aka which is typically used in web-browsers as show html source of the page) [12:15] and also display "details" url link in the bottom right corner, if one is running in ubiquity debug mode. [12:16] (although details url link may be redundant) [12:16] thoughts? [12:20] How about making the descriptive text only take up part of the horizontal width, and putting the light bulbs at the right alongside it, or similar? [12:20] Or, we could hide the expander until the point where the light bulbs stop being useful (since they're no longer relevant once you've answered all the questions) [12:21] So you answer all the questions and then the light bulbs are replaced by the progress widget etc. [12:21] ok. [12:21] Ctrl-u: this kind of thing is acceptable if and only if it's discoverable, IMO, which seems a bit tricky? [12:22] I'd never guess Ctrl-u even with the analogy with web browsers. Ubiquity looks nothing much like a web browser so that's not a key combination I'd expect to work. [12:22] So I'd still prefer something visible if possible. [12:22] (x) (x) (o) (o) => (line1: expander/text \n line2: [=======>] progress bar) => (ubuntu one pictograms + legal notice URL) => nothing. [12:22] cjwatson: ok. [12:23] * xnox should make new visuals public. [12:23] Maybe in debug mode the expander etc. could always be visible? [12:23] It's genuinely useful when working on the installer [12:24] true. currently one cannot get to it from the very first screen though. [12:24] which does already print activity. [12:26] there is also bug 1074375 [12:26] Launchpad bug 1074375 in ubiquity (Ubuntu) "Progress text looks needlessly geeky" [Medium,Confirmed] https://launchpad.net/bugs/1074375 [12:26] which makes a good point that it's too discoverable for uninitiated. [12:40] xnox: I don't mind it being more discreet as long as people who know they want progress information can get hold of it [12:41] Matthew's suggestion for modifying the presentation seems reasonable though ... it's certainly not meant to look editable [12:49] xnox: U1> Looks pretty good; I don't have any fundamental objections. My one suggestion is that I think it could be a little clearer that you don't have to do this in order to complete installation. [12:50] I realise we probably have business reasons to encourage people in the direction of a U1 login by default, but "Log in later" really does imply that you're going to *need* to do this at some point [12:50] cjwatson: each and every screen has "Do it later" or "Skip to finish installation" (not sure what's the latest final string). Apart from dead-end pages (e.g. moving to legal notice page / futher details, have only a back button) [12:50] I think it could use some explanatory text. [12:51] ok. [12:51] "do it later" may be true in the future, once users will be able to on-the-fly purchase media & apps directly from the dash in an approx. one click fashion. [12:52] It still won't be mandatory [12:52] sure. [12:53] I'm all for encouraging people to use our services - I just think that if the services are actually compelling then we shouldn't need to make deceptive implications in the installer about whether they're mandatory or optional :) [12:53] And IME people respond better to honesty [12:54] Anyway, it should just be a minor tweak from here [12:54] I like the new final / reboot screen with a big logo a lot =))) === kentb-out is now known as kentb === kentb is now known as kentb-afk [16:46] cjwatson: Was your d-i upload premature, given that linux-signed was in NEW? [16:46] cjwatson: Or does d-i not actually use the kernel-signed-image udeb? [16:48] It does. I didn't notice [16:48] I see no mention of the udeb in the build log, just the if vmlinuz*signed shell snippet. [16:48] Was trying to clear bug 1134123 [16:48] Launchpad bug 1134123 in Ubuntu CD Images "Raring server installations fail with kernel mismatch with 20130227 images" [Critical,In progress] https://launchpad.net/bugs/1134123 [16:48] It's in build/pkg-lists/kernel [16:48] May not mention it if it's missing [16:49] Possibly not, yeah. [16:49] Oh well, I'll just no-change rebuild it after the next publisher run hits disk. [16:50] Ta [16:50] Could you respin server once that's landed? [16:50] And close that bug above [16:50] Cando. [16:50] Assuming you'll be around a bit later than me [16:50] I'm here all day. [16:59] cjwatson: Though, I'm curious why there was a mismatch that needed fixing at all. [17:00] cjwatson: Given that -8- was happily stuck in proposed, waiting on d-i... [17:00] Yeah, not totally sure and I didn't really investigate [17:01] Feb 27 07:18:05 main-menu[1735]: DEBUG: resolver (libc6-udeb): package doesn't exist (ignored) [17:01] That seems unexpected, or is it really not on the CD? [17:03] Should be in the initrd IIRC [17:03] Library reduction and all [17:03] Oh, right, so that's just the resolver being unhelpfully verbose when what it really should say is "already installed, skipping" or nothing at all. [17:04] I guess anna/udpkg don't have a status DB to check such things against? I've never really looked into the architecture. [17:04] They do but I think libc6-udeb is still a weird special case or something [17:04] I tend not to care unless something's actively breaking :) [17:05] A good philosophy. [17:05] There is certainly a /var/lib/dpkg/status in the d-i env though === ogra_ is now known as ogra === kentb-afk is now known as kentb [20:24] cjwatson: was it you who mentioned problems with the tftp client in grub2? [20:25] cjwatson: I got an action item from last UDS to test PXE boot with UEFI/SecureBoot and IPv6. I just did a test with IPv4 and grub2 loads fine, grabbing all its modules and the config, but fails to grab the kernel/initrd with some kind of network error [20:26] poking from the shell, I can see it has the IP, DNS and routes right, but the tftp part is somehow failing [20:26] * stgraber checks that the grub image is the latest one from raring [20:29] cjwatson: "error: couldn't send network packet." [20:31] oh, actually, all commands give me that error, not only those that obviously need to fetch stuff from the network. (lsmod gives me the same error for example) [22:14] stgraber: Steve reported to me that those exist [22:15] stgraber: If you can get me instructions for constructing a reproduction case in kvm/OVMF, I expect I can fix it from that [22:21] cjwatson: will be tricky with OVMF as IIRC we don't have network support built into the firmware we have in the archive [22:22] Or even any reproduction case that doesn't involve an excessively complex network - if I can start it from the EFI shell on a test machine maybe? [22:22] Something that I can iterate on [22:23] (Bearing in mind I don't really have EFI netbooting infrastructure at the moment in general, though I could bring it up in principle) [22:23] I was hoping for OVMF since that's easier, but you make a good point ;-) [22:23] hmm, I wonder if booting the same binaries from a usb stick would be enough. I'll have to test that. [22:24] I have two EFI test machines at the moment; neither is SB-capable though [22:24] So if it needs SB I'd need to build specialised OVMF or something [22:25] I think Steve indicated it was a general problem on UEFI though [22:25] nope, I wan't testing with SB, just plain UEFI using a tftp with the result of grub-mknetdir [22:25] Ah, good; if that works with booting from USB then I could probably take it from there [22:55] cjwatson: hmm, can't seem to get grub to load any of its modules from usb when using the tftp .efi binary [22:55] either that or I'm failling to setup the fs layout for it to find them [22:56] (grub complains of unset root variable, but as far as I can tell, it doesn't have the gpt module so even if I set it, it won't work) [22:56] so all I'm getting is the recovery prompt which isn't terribly useful :( [23:09] I just did a fresh install of ubuntu and now all I get is the grub recovery prompt [23:10] 12.10 amd64, I didn't change any of the partition settings, it's supposed to dual boot with windows 8 [23:13] it's a moderately old desktop, the first disk is mbr, the second is gpt, first has windows 8 and grub, the second has ubuntu === kentb is now known as kentb-out