[00:13]  * infinity cleans out component-mismatches.
[00:14] <infinity> ... and wonders why nvidia-settings-updates wants to drop from restricted to multiverse.
[00:15]  * infinity fixes the seeds.
[00:16] <slangasek> where was it seeded before?
[00:17] <infinity> Nowhere, I suspect it was previously a depends/recommends of something.
[00:18] <infinity> Since it's been in restricted for a couple of releases, and one would expect us to have noticed by now if germinate didn't love it.
[00:18] <slangasek> nvidia-settings* themselves seem to be the only relevant packages uploaded today
[00:20] <infinity> Maybe having them conflict with each other is what developed the demotion hatred?
[00:20] <slangasek> huh, did I really just crash this machine by trying to feed it a fat partition over PXE?
[00:20] <infinity> But seeding it explicitly should fix that, since an explicit seeding of experimental seems to have stuck.
[00:21] <xnox> remember the bug with ubiquity "preferring" usb-drive for grub install? now there is recipocal bug filed, with internal drive being the preference now *sigh* bug 1066173
[00:21] <ubot2> Launchpad bug 1066173 in ubiquity "whole disk install puts grub in wrong place" [Undecided,New] https://launchpad.net/bugs/1066173
[00:22]  * xnox wants to sleep...
[00:23] <slangasek> are we sure that's a bug, and not by design?
[00:24] <xnox> cjwatson should look at it =) he is the master of picking the right grub device ;-)
[00:24] <xnox> slangasek: I can see an argument going for "by design"
[00:25] <slangasek> well, the one thing that's obviously sketchy there is installing to the internal MBR but referencing the external disk for boot/grub
[00:25] <xnox> slangasek: yeah, we used to have a bug of reverse ;-)
[00:26] <xnox> imho the mbr of the disk which has /boot should be the "right" grub destination, regardless of how the machine was booted.
[00:27] <slangasek> that's probably reasonable
[00:30] <ScottK> I can report that yesterday's bmcwl problem is solved.  It installs from the live media, works right away, and installs/works with the installed system too.
[00:30] <ScottK> wgrant: Thanks.
[00:31] <xnox> fair enough. good night everyone =)
[00:37] <doko_> slangasek, infinity: I assume the armel buildd issue is solved?
[00:37] <skaet> ScottK,  good to know.  thanks.
[00:40] <infinity> doko_: "The armel buildd issue" being?
[00:40] <doko_> <ScottK> Could we have another armel builder or so.  What we have isn't keeping up.
[00:40] <doko_> <slangasek> infinity, doko: ^^ if one of you can make magic happen?
[00:41] <infinity> doko_: Oh, well, I see no queue, so yes. :)
[00:41] <infinity> We get to rebalance sanely soon anyway, the armhf rebuild is finally almost done.
[00:41] <doko_> nd just 371 armhf builds left
[00:43] <phillw> Hi, anyone else getting disconnects from the ether pad?
[00:46] <infinity> Only for the last year or so.
[00:49] <skaet> phillw,  when you go to the page,  hit refresh before typing.  That usually avoids most of the silliness.
[00:50] <skaet> (only most,  not all)
=== ScottK2 is now known as ScottK
=== LordOfTime is now known as TheLordOfTime
[02:38] <TheLordOfTime> official Q release date decided yet, or no?
[02:39] <TheLordOfTime> i know this month, i am seeking a specific day ;P
[02:46] <skaet> TheLordOfTime, October 18th.   schedule for this cycle is: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
[02:48]  * skaet --> EOD
[02:49] <slangasek> skaet: 'night!
[02:50] <skaet> good night slangasek,  thanks for keeping it sorted this afternoon.  :)
[03:45] <infinity> cjwatson: FYI, I'm uploading quantal chroot tarballs with bootstrapping disabled for release, will re-enable in r-series chroots if/when we need it.
[04:42] <plars> yay, panda lives!
[04:42] <plars> but looks really funny without the slideshow :)
[04:43] <plars> I am slightly worried about this "fix" though, of just killing the slides
=== Guest72551 is now known as maxb\
=== maxb\ is now known as maxb
[08:35] <jibel> xnox, I'm still get bug 1065502 with ubiquity 2.12.11
[08:35] <ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman (dup-of: 1065034)" [Undecided,Confirmed] https://launchpad.net/bugs/1065502
[08:35] <ubot2> Launchpad bug 1065034 in ubiquity "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Fix released] https://launchpad.net/bugs/1065034
=== tkamppeter_ is now known as tkamppeter
[09:13] <stgraber> slangasek: not too jetlagged actually though I've been busy with some social stuff ;)
[09:14] <stgraber> anyway, I tested the new shim yesterday and my laptop booted without the error message from the firmware, so the shim looks good
[09:14] <stgraber> I think I saw a couple of messages from grub though (non-blocking) relating to secureboot (looked like some grub modules that wouldn't load because of secureboot)
[09:14] <stgraber> I'll try and grab an updated server image later today and see if I can boot that one
[09:37] <ogra_> damned
[09:37] <ogra_> seems the slideshow hangs on ac100 as well :/
[09:54]  * ogra_ updates the pad for the above upload and related re-spin
[10:16] <knome> why aren't flavors visible in http://status.ubuntu.com/ubuntu-quantal/ ?
=== doko_ is now known as doko
[13:06] <skaet> knome,  should be showing back up on next refresh of status.ubuntu.com.    Turns out to be a "feature" that marking them complete removes from display.  :P
[13:07] <knome> skaet, heh, right. thanks. :)
[13:16]  * smartboyhw is surpised....
[13:16] <smartboyhw> There are 3 days left in the current cycle. That means that in order to complete all the work 198.00 workitems must be completed per day.
[13:16] <smartboyhw> 198 workitems PER day?
[13:21] <skaet> smartboyhw,  it illustrates that teams aren't as good about managing the workitems as they need to be thats all.   Note it doesn't mean they must be completed,  if its clear they aren't going to happen they should be postponed, and then it would show up ok, from status perspective.
[13:21] <skaet> (although,  not from the original intent of what was wanted to be done :/ )
[13:21]  * smartboyhw is waiting for status.ubuntu.com to be updated to see the progress for the Ubuntu Studio blueprints:D
[13:22] <doko> this boy doesn't sound that smart
[13:22] <smartboyhw> doko, is it a personal attack/assualt?
[13:25] <skaet> smartboyhw, http://status.ubuntu.com/ubuntu-quantal/group/topic-quantal-flavor-ubuntustudio.html - the info is still there, not just linked from the to page until the next update happens.
[13:25] <smartboyhw> thx skaet
[13:25] <skaet> UbuntuStudio is in pretty good shape.    Its clear what's been postponed.
[13:25] <skaet> (so can be used for planning for UDS-R ;) )
[13:26] <smartboyhw> skaet, actually that page is not updated at all
[13:26]  * skaet looks at it closely,  and realizes,  yeah.
[13:26] <smartboyhw> skaet, last update time is 7th Oct, while in this past 6 days we changed quite a lot of workitems...Anyway to request a refresh
[13:26] <smartboyhw> ?
[13:26] <skaet> it should be updated on that next run.
[13:26] <smartboyhw> yeah
[13:27] <skaet> however the data on it generally indicates it is basically complete from a status point of view,  not that much left unsorted.
[13:28] <smartboyhw> :)
[14:02] <skaet> slangasek, cjwatson - around?
[14:11] <smartboyhw> skaet, ha after the update of that page Ubuntu Studio got 100% YEAH!
[14:11] <skaet> :)
[14:12] <smartboyhw> First actually to reach 100% sounds like we did follow skaet's instructions very well:D
[14:12] <skaet> Thank you.  :D
[14:13] <smartboyhw> :D
[14:34] <skaet> morning summary:   testing in progress.   Some bugs need further investigation/discussion.   latest knowledge is on the pad.
[14:35]  * skaet --> saturday errands,  bbl
[14:45] <smartboyhw> skaet, not sure if this is a blocker
[14:46] <smartboyhw> I don't think so but
[14:46] <smartboyhw> Bug 1066302
[14:46] <ubot2> Launchpad bug 1066302 in ubiquity "'update this installer' link on the welcome page shows no response to a mouse click" [Undecided,New] https://launchpad.net/bugs/1066302
[15:55] <ScottK> I tried out the chromium in quantal-proposed and it seems fine.  If there's a Lubuntu respin, I'd copy it over.
[15:57] <ScottK> Sine the rebuild is done on armhf, having more than one working armel builder would be nice.
[16:04] <xnox> i am confused about bug 1066302 was the installer update been enabled on the mirror?
[16:04] <ubot2> Launchpad bug 1066302 in ubiquity "'update this installer' link on the welcome page shows no response to a mouse click" [Undecided,New] https://launchpad.net/bugs/1066302
[16:05] <xnox> jibel: if you are still seeing that /tmp/ mounting bug or similar please file a new bug with logs. And I'l look into that.
[17:09] <hggdh> humpf. On my panda setup, desktop installation does not show up until I ctrl-alt-f1/ctrl-alt/f7
[17:10] <hggdh> not critical, but perhaps we should release-note it
[17:10] <hggdh> skaet: ^ I will open a bug on it as soon as the install is done, want to grab dmesg and install logs
[17:17] <xnox> hggdh: i'm sure we have seen that bug already.... please search for it first.
[17:17] <xnox> me & ogra were discussing it yesterday.
[17:18] <hggdh> xnox: will do, thanks.
[17:48] <hggdh> xnox: yes, bug 1065902. I will tag on the ISO test result
[17:48] <ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
[17:51] <slangasek> stgraber: cool - does the server image boot for you now too?
[17:51] <xnox> hggdh: thanks =)
[17:51] <slangasek> skaet: ish
[17:53] <slangasek> ogra_: so the livecd-rootfs change only impacts the ac100 image?
[18:32] <slangasek> hggdh: for bugs you think should be release-noted, don't hesitate to mark them on the ubuntu-release-notes project directly (done now for bug #1065902)
[18:32] <ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
[18:41] <hggdh> slangasek: will do; I tend to be careful on that ;-)
[18:43] <slangasek> hggdh: if by "careful" you mean "reluctant to do so", it's far better for us to have it visible that you think it should be release-noted... we can always wontfix if we disagree ;)
[18:44] <hggdh> heh. Indeed, it would be more like "reluctant to do without additional confirmation". But I will be more, ah, careless in the future
[19:08] <stgraber> slangasek: testing now
=== yofel_ is now known as yofel
[19:17] <infinity> cjwatson: Oh wow, it was passing -lc?  That would explain it.
[19:18] <infinity> And pypy failed after 2 days, 3 hours, 4 minutes, 58.8 seconds.  Sadness.
[19:18] <plars> hggdh: heya, have you tried server on arm?
[19:19] <plars> hggdh: I'm trying to double-check now, but I think there might be an issue now with encrypted partitions
[19:19] <plars> hggdh: now that the keyboard works for server installs, we can get to this, and it looked like keyboard doesn't work for entering the password
[19:20] <plars> hggdh: installation about to finish up here
[19:20] <stgraber> need to find another usb key, that fancy usb3 ssd won't show up in my "bios"...
[19:20] <plars> hmm, yeah no keyboard
[19:21] <stgraber> cjwatson: I got some secure boot errors from grub at boot time now. I'll send you a photo
[19:21] <stgraber> (first checking that I'm up to date)
[19:22] <plars> infinity: any ideas on this? Is it possibly a missing module or something in the uinitrd?
[19:22] <infinity> plars: I'm confused.  That seems to boil down to "now that the keyboard works, the keyboard doesn't work"?
[19:23] <plars> infinity: well, the keyboard works during install now (previously I could only do installs over serial)
[19:23] <plars> infinity: so I can get it installed, and if I do a normal guided partitioning, everything is fine
[19:23] <infinity> stgraber: Wait, is there some assumption that current server should work for you, while the previous didn't?
[19:24] <plars> infinity: but if I select lvm+crypt then when it reboots and asks for the passphrase to unlock the disk, I cannot enter anything
[19:24] <stgraber> infinity: where previous is from a few days ago, yes
[19:24] <stgraber> infinity: basically hoping that new shim + grub will let me boot it
[19:24] <infinity> stgraber: That seems unlikely, given that d-i wasn't rebuilt, and server's boot bits come from d-i...
[19:25] <stgraber> hmm, indeed...
[19:25] <stgraber> slangasek: ^
[19:25] <infinity> plars: Oh, I see.  Post-install, no keyboard in the initrd.  Hrm.  I'm not sure why that would be different on ARM than x86, unless the keyboard bits are all built in to the x86 kernels.
[19:25] <stgraber> cjwatson, slangasek: http://www.stgraber.org/download/2012-10-13_21-18-56_512.jpg
[19:25] <stgraber> cjwatson, slangasek: btw, I don't actually have to press a key, there appears to be a 15-30s timeout
[19:26] <plars> infinity: likely config madness, keyboard didn't work on server installs until just recently, so even different between arm desktop and arm server
[19:26] <stgraber> cjwatson, slangasek: (that's on my installed system with up to date grub2 and shim)
[19:26] <stgraber> good news is, I'm not getting the access denied message from the firmware though :)
[19:27] <infinity> plars: Yeah, but I know the reason for that, since I fixed it. :P
[19:27] <infinity> plars: (It wasn't kernel configs, it was the d-i initrd)
[19:27] <plars> infinity: right, sorry
[19:28] <plars> infinity: but back to my original question... do you have some idea why the keyboard would work during the installer, and post install on non-encrypted installs, but not at this point?
[19:28] <infinity> plars: Yes, no keyboard modules in the initrd.  But I'm trying to sort out why.
[19:29] <plars> I do see a message on the screen right before it asks for the password: cryptsetup evms_activate is not available
[19:29] <plars> but I suspect that's unrelated
[19:29] <infinity> plars: (The installer includes them explicitly, that was the bug I fixed earlier, and you don't NEED a keyboard in the initrd when you're not running crypt, so you didn't notice the lack of keyboard)
[19:29] <infinity> plars: What's the bug # for this?
[19:30] <plars> infinity: haven't filed it yet, doing that now.  Just put it in linux-ti-omap4?
[19:30] <infinity> plars: No, initramfs-tools, probably.
[19:31] <infinity> plars: The kernel is fine (though, I suppose we could "fix" it by building in the USB-HID stack, that seems heavy-handed and unnecessary).
[19:33]  * infinity was pretty sure none of that was built in for x86 either, though, and is now a bit curious...
[19:33] <stgraber> infinity: the new server image actually boots fine, so looks like the new shim and grub made their way there somehow
[19:34] <infinity> stgraber: Curious, maybe it doesn't use the d-i cdrom bits, like it used to.
[19:34] <plars> infinity: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1066376
[19:34] <ubot2> Launchpad bug 1066376 in initramfs-tools "keyboard doesn't work to enter password with panda and encrypted partitions" [Undecided,New]
[19:34] <infinity> So, yeah.  USB HID stuff is modular on x86 too...
[19:34] <infinity> plars: Can you confirm that this work on x86 with a USB keyboard?
[19:35] <infinity> plars: Let me amend that.  Can you confirm this works on x86 with a USB keyboard and no BIOS USB->PCAT compat emulation? :P
[19:35] <infinity> plars: (Cause it really shouldn't)
[19:35] <plars> infinity: it worked in a VM with x86, haven't tried on hardware but it's probably pretending to be a usb keyboard
[19:35] <plars> infinity: I can try it though, of course
[19:35] <infinity> plars: I suspect that the VM is actually giving you an AT or PS/2 keyboard.
[19:35] <hggdh> plars: I have not yet started with encrypted disk on arm server, it is the next
[19:35] <infinity> plars: And most people's BIOSes also do "early boot keyboard emulation" which, again, is giving you a fake AT/PS2 keyboard.
[19:36] <infinity> plars: With that option off, this should fail hard on x86 too.
[19:36] <stgraber> infinity: so the shim's md5 on the media matches mine so it's clearly up to date, grub's doesn't, so I guess I have something slightly more recent on mine (or something...)
[19:36] <hggdh> plars: whole disk encryption, or justg home?
[19:37]  * infinity ponders how best to sort this keyboard mess... Adding the whole USB-HID stack to every initrd seems like some crazy bloat.
[19:37] <infinity> hggdh: Whole disk.
[19:37] <plars> hggdh: whole disk
[19:37] <infinity> hggdh: And I'm sure you'll have the same problem.
[19:37] <infinity> hggdh: I'm more curious for confirmation that it's also broken on x86 without BIOS keyboard emulation (which it should be).
[19:40] <hggdh> on it now on ARM, will try later on AMD64
[19:40] <infinity> This probably only *looks* like an ARM-specific bug because ARM doesn't ever provide you with fake keyboards, while PCs unhelpfully usually do, and sometimes don't. :P
[19:40] <infinity> hggdh: Kay.  Assuming your amd64 machine has a BIOS option to disable keyboard emulation (might be called "early USB keyboard support" or similar), that's what needs to be off.
[19:41] <hggdh> infinity: I will check
[19:41] <infinity> And if it's a laptop, all bets are off, cause laptops refuse to let you disable the internal keyboard, for sanity reasons.
[19:41] <infinity> (Though, you can still test with an external USB keyboard and emulation off)
[19:42] <infinity> Anyhow.  I need to pack and be on a plane, but I have a good handle on what the bug *is*, not so much a good plan as to where/how it should be fixed right now.
[19:42] <infinity> I'll think about it while I'm bored in the air. :P
[19:42] <plars> infinity: have a good flight, and thanks
[19:44] <infinity> Hrm.  The input-modules udeb is only 70k.  So, that leads me to believe I could add everything in that to the initrd and only grow it by, well, 70k.
[19:44] <infinity> That might not be awful.
[19:45] <infinity> And maybe worth doing universally, since I hear people like having keyboards in their initrds.  Though, I'd still prefer to believe that most omap4/server users would use serial consoles...
[19:45] <infinity> plars: I assume this all works smashingly if you do it via serial instead?
[19:46] <plars> infinity: it used to, but I haven't tried yet with this image
[19:47] <infinity> plars: Right, well.  Please file the bug on initramfs-tools, assign it to me, and mention some of the above (It works in the installer's initrd, it works after a full boot (so, post-initrd), but doesn't work for crypted root (so, in the post-installed initrd))
[19:47] <infinity> plars / hggdh: And if one of you can confirm that an x86 machine without BIOS emulation suffers the same issue, I'll just fix it universally, if not, I'll make it ARM-specific for minimal impact.
[19:48] <infinity> plars: Oh, and once filed, throw it in the pad in the "consideration" section, so people bug me about it (or, so I can bug myself). :P
[19:48] <plars> infinity: will do, thanks
[19:49] <infinity> stgraber: Well, regardless of which bits come from where, we'll want one last d-i respin before one last image respin, once the grub/shim stuff's definitely settled, I think.
[19:49] <infinity> stgraber: If you want to make a note of that so we don't forget, that would be snazzy.
[19:52] <stgraber> infinity: I'll make a not locally and put it on the pad once it's all setup for release
[19:52] <stgraber> *note
[20:03] <hggdh> crap. Just locked myself out of the amd64
[20:04] <plars> hggdh: ?
[20:04] <hggdh> infinity: the only option I have on my system is "disable USB emulation"
[20:04] <infinity> hggdh: That's likely the one.
[20:04] <infinity> hggdh: If changing that makes it so you can no longer, for instance, fiddle with GRUB boot menus, that's what we want.
[20:04] <hggdh> plars: I disabled USB emulation, now the keyboard does not work anymore. On anything (will try reboot, and F2)
[20:05] <hggdh> infinity: I cannot even login to the system
[20:05] <infinity> hggdh: Oh?  Once a system boots completely, the USB-HID stuff should be loaded.
[20:05] <infinity> hggdh: Maybe your system is extra special. :P
[20:06] <hggdh> infinity: it is a Dell, so yes, it is special ;-)
[20:07] <hggdh> but BIOS setup works. Since this system had a Quantal B2, I will reboot on it, and grab dmesg via SSH
[20:09] <hggdh> infinity: this might be related to the issue
[20:09] <infinity> Well, if it doesn't work without BIOS emulation even post-boot, that's an entirely different bug/problem than the ARM one I was hoping to verify, and likely the answer is just "don't do that on that BIOS, then".
[20:10] <infinity> Cause the Panda keyboard work fine post-boot, just not in early boot.
[20:10] <infinity> s/work/works/
[20:11] <plars> I just double checked, and if I enable serial console in the preEnv on panda, I can enter the password just fine
[20:11] <infinity> plars: Right, that's expected.
[20:11] <plars> yeah, but I said I'd check
[20:11] <infinity> plars: And a fair workaround/recommendation, if I can't fix this before release.
[20:11] <plars> yeah
[20:11] <infinity> Since, well.  A "server" with a keyboard is wrong anyway. :P
[20:12] <plars> well, for panda at least
[20:12] <infinity> For anything with workable serial or ethernet management, really.
[20:12] <infinity> So, anything other than a whitebox PC that needs a KVM cause it's crap.
[20:13] <hggdh> oh, another bug -- on the install, when you get to the selection ((install Ubuntu server, Multiple servers installs with MAAS, etc), select "Boot from first hard disk" -- and you are thrown back into the "select language", and then to the install menu
[20:13] <infinity> That entry probably just shouldn't be there.
[20:14] <hggdh> well it has been there for quite a long time
[20:14] <infinity> (You're still talking ARM?)
[20:14] <infinity> If x86, then yeah, that's a bug that it doesn't work.
[20:14] <hggdh> nope, AMD64 install, server
[20:14] <infinity> Oh!
[20:14] <infinity> Yeah, that's a bug.
[20:14] <infinity> Please file.
[20:14] <hggdh> I am oppening one against D-I
[20:15] <infinity> Possible cdimage, but d-i works for now, especially if you note it in the pad so we can hunt it.
[20:15] <infinity> s/possible/possibly/
[20:16] <infinity> Oh, wait.  To be sure, this is on a system where there's something bootable on the first hard disk?
[20:16] <infinity> Like, it's not trying to chain out and failing, is it?
[20:16] <infinity> Cause if the system wouldn't boot anything without install media, there's nothing for us to chain into and boot for that option.
[20:17] <infinity> Which should/would produce the sort of "loop back to the menu" behaviour.
[20:17]  * infinity packs more.
[20:17] <hggdh> infinity: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1066387
[20:17] <ubot2> Launchpad bug 1066387 in debian-installer "D-I install menu, select "Boot from first hard disk" and it goes back to Language selection" [Critical,New]
[20:19] <hggdh> in the pad now
[20:20] <infinity> hggdh: Did you see the above?  Is/was there actually something bootable installed?
[20:20] <infinity> hggdh: (ie: without the boot media in the drive/port, does it boot an OS?)
[20:21] <hggdh> infinity: this system has B2 installed
[20:21] <infinity> Alright.  They, yeah, sounds like a real bug.
[20:21] <slangasek> infinity: what now?  d-i absolutely was rebuilt after the latest shim upload
[20:21] <infinity> slangasek: After the last shim, not after the last grub2.
[20:21] <infinity> slangasek: And yeah, I guess stgraber's bug was shim-related, which explains why his bug went away.
[20:22] <infinity> slangasek: But we still probably need a rebuild for grub2-signed, too.
[20:22] <hggdh> infinity: and I just confirmed it does have an installed system
[20:22] <slangasek> infinity: mm; we ought to be rebuilding d-i to use the current grub, was that the issue you spotted the other night with grub2-signed landing much later than expected?
[20:22] <slangasek> but yes, it was shim that we changed for stgraber, not grub2
[20:23] <infinity> slangasek: No, this was a new grub2, a day after that non-issue.
[20:23] <slangasek> ok
[20:23] <infinity> slangasek: When you respun the world yesterday afternoon.
[20:23] <slangasek> right
[20:24]  * slangasek double-checks the grub changelog to refresh his memory
[20:24] <infinity> Maybe I'll just do a d-i bump right now with a hope/dream that it'll be the last.
[20:24] <infinity> And then future cdimage builds will just pick it up without thinking.
[20:25] <slangasek> stgraber: are those errors when booting the image, or after install?
[20:25] <slangasek> (the insmod errors)
[20:25] <infinity> I have a sneaking suspicion there may still be a last-minute ti-omap4 revert or something, but I've lost t context on where Paolo is at with debugging recent oddities.
[20:25] <infinity> Cause, well, weekend.
[20:26] <slangasek> infinity: I would fully expect the USB-HID stack to be in the initrd and am surprised it's not
[20:27] <infinity> slangasek: Alright, then we should just fix that.
[20:27] <slangasek> infinity: so as for d-i, there's no reason to think grub and shim aren't already settled by this point; if a d-i upload and image respin is needed, we should do that ASAP
[20:28] <infinity> slangasek: d-i's up.
[20:28] <slangasek> "up"?
[20:28] <plars> infinity: hmm, if I disable legacy support for usb, then I just end up at the grub menu with no keyboard control
[20:28] <plars> infinity: but it looks like it's moot now
[20:28] <infinity> slangasek: As in, uploaded.
[20:28] <slangasek> and already accepted?  or still waiting to hit the queue?
[20:29] <infinity> slangasek: It'll hit the queue in 45s.
[20:29] <slangasek> ok
[20:30]  * infinity eyeballs his ~/build/initramfs-tools directory and notes that it's nothing but Debian uploads.
[20:31] <slangasek> infinity: although, note that fixing the module-loading errors in grub that stgraber just posted requires a new round of grub2
[20:31] <infinity> slangasek: Hahaha.
[20:31] <slangasek> cjwatson: do you think loadenv and keystatus are safe to add to the SB images?  (and while we're at it, what about tftp?)
[20:31] <infinity> slangasek: Well, just leave that d-i in the queue, then.  Or reject it and wait.
[20:32] <slangasek> infinity: so let's just leave that d-i sitting in the queue for the moment, yeah
[20:32] <infinity> slangasek: Reject it, so no one's tempted to accept it and get all excited about respins.
[20:32] <slangasek> done
[20:32] <slangasek> stgraber: did the server image install successfully for you under SB, too?
[20:33] <infinity> slangasek: Wouldn't tftp in grub provide a simple bypass?  signed-grub->tftp->new-bootloader->chain to whatever?
[20:34] <infinity> Unless it would check that whatever it got from tftp was also signed before loading it.
[20:34] <slangasek> infinity: tftp only implements a filesystem interface, it doesn't let you bypass the security checks on module loading or chaining
[20:34] <infinity> Ahh.
[20:34] <infinity> Kay.
[20:34] <slangasek> but it does mean you suddenly have a network filesystem in your signed image, which is a potential source of bugs, and RH/Fedora are currently *not* including this in their SB images :)(
[20:34] <plars> hmm, but I can still enter the password with legacy support disabled
[20:35] <infinity> plars: "The password"?
[20:35] <infinity> plars: You mean for a crypted root?
[20:35] <plars> infinity: yes
[20:35] <infinity> plars: Alright, then this may only be ARM that's missing those modules in the initrd.  Add this debugging bit to the bug for me?
[20:35] <plars> in both cases, usbhid is loaded after boot
[20:35] <infinity> plars: I'll mangle this first thing Monday.
[20:35] <plars> ok
[20:36] <slangasek> infinity: but basically we have no UEFI netboot support at present, and I'm trying to get that all sorted.  If you're not doing SecureBoot you can just drop the kernel and initrd in your memdisk, cook a custom grub.cfg, and go from there; but if you need SB, grub needs a way to access a kernel and initrd that are *not* included in the image
[20:36] <infinity> (Though, *why* ARM would be missing those modules and not x86, I dunno... Not a lot of arch-specific stuff in initramfs-tools)
[20:37] <slangasek> stgraber: if you have the time, I would appreciate a bug on grub2 with that screenshot, asking for keystatus+loadenv to be added to the UEFI images
[20:37] <infinity> slangasek: Is doing this from the bootloader the expected way to do netboot on UEFI, or is this just a hackish workaround until we can build UEFI netboot images to complement the current PXE ones?
[20:38] <infinity> slangasek: (Seems odd to me to ask one's bootloader to implement a network filesystem)
[20:39] <slangasek> infinity: it's all debatable
[20:39] <slangasek> infinity: regardless, I'm concerned about having SB-enabled grub support loading the kernel from the network, because that's how cobbler needs it to work
[20:39] <slangasek> but I also have no idea if UEFI firmware is going to support the shim model
[20:40] <slangasek> if it *can't*, then maybe making this work with signed images distributed from the archive doesn't actually matter
[20:40] <slangasek> but I still don't want cobbler to have to work by implementing "here's a monolithic image containing all the possible kernel and initrds that you might want to boot, download this all at once and enjoy"
[20:46] <infinity> plars: Can you give me the initrd from that affected system?
[20:47] <plars> infinity: sure thing, I'll attach it
[20:48] <infinity> plars: And lsmod from the running system.
[21:02] <skaet> thanks hggdh
[21:04] <infinity> plars: And dmesg from the system too.
[21:08] <slangasek> xnox, jibel: is there a new critical ubiquity/partman bug report in our future?
[21:24] <hggdh> plars: you have abug for the usb keyboard not working on arm?
[21:27] <ScottK> Someone should let Mark know that he's already made the milestone of too late to update all the tools to know about the new release name, so he can announce it anytime now.
[21:42] <skaet> ScottK, done.
[21:56] <stgraber> slangasek: (replying in order of backlog). The errors are showing up on my installed system. I don't think they were showing up when booting from media, though I booted from media in debug mode, so they might have gone unnoticed in the rest of the log messages flying by
[21:57] <stgraber> slangasek: I didn't install the server build as I don't have enough USB disks around to both boot and install on USB (and don't quite want to wipe my laptop). I just checked that d-i started fine and then rebooted
[21:58] <stgraber> slangasek: I'll file a grub2 bug now
[22:02] <stgraber> slangasek: bug 1066399
[22:02] <ubot2> Launchpad bug 1066399 in grub2 "grub2 fails to insmod keystatus and loadenv when running with secureboot" [Undecided,New] https://launchpad.net/bugs/1066399
[22:03] <stgraber> you may want to target/milestone if you think this should be fixed for release. It seems release notable to me as the machine boots fine and doesn't require any user interaction (though the error seems to indicate otherwise)
[22:04] <stgraber> if you think this should be fixed, let me know once you have a signed grub2 around and I'll reboot to check the fix
[22:08] <skaet> stgraber, have set it up with Release Notes project targetted to quantal so we don't forget it, at any rate
[22:13] <stgraber> skaet: ok
[22:14] <stgraber> I guess it'll end up depending on how much we care about the first boot experience on those systems
[22:15] <stgraber> if we want it perfect, then we'll need the change (grub2 + grub2-signed) and respin the images, otherwise, a zero-day SRU will fix it post-install
[22:16]  * skaet nods
[22:16] <stgraber> oh, though I guess there's also the thing where it's likely that those errors will also show up whenever you boot the install media, so potentially more than just a one time thing for those using live medias pretty often
[22:17] <stgraber> (but the intersection of people using live media extensively, on non-persistent storage and on systems with secure boot enabled, will likely be pretty small for 12.10 ;))
[22:17] <skaet> will wait for slangasek's opinion, at any rate - its irritating, but not a real blocker.
[22:18] <skaet> agree about the user pool forecast,  and scope of risk.    :)
[23:09] <infinity> stgraber: We need to respin d-i and images for the previous grub2 upload anyway, so it's more a question of "do we want to make these grub changes", not "do we want to re-spin images".
[23:09] <infinity> stgraber: And I think slangasek was mulling that over before deciding when to unreject my d-i upload.
[23:54] <doko> lovely, traded two arm build failures for an amd64 one