[07:27] <tjaalton> huh, not even 14.04.1 server image works
[07:27] <tjaalton> tried on another machine too, same thing
[07:27] <tjaalton> no kbd
[07:30] <tjaalton> that one has ps2 ports too, and at least the installer isn't hung
[07:30] <tjaalton> dmesg shows that the usb device is attached, but doesn't work
[07:38] <tjaalton> smb: I see you've worked on a similar issue in the past, looks like usb keyboards can't be used with server installer and I've verified it with trusty, wily & xenial, on two different machines (legacy/hp microserver, uefi/intel sdp)
[07:39] <tjaalton> desktop installer works fine
[07:39] <tjaalton> guess noone tests real hw anymore :P
[07:40] <smb> tjaalton, well also if you do preseed-ed net installs its no issue either. Do you at least have some more details about what combination of usb host / device this is?
[07:41] <smb> Cause the initial problem should be fixed (which was a missing hid driver for usb2)
[07:47] <tjaalton> smb: gen8 microserver, certified with precise :)
[07:48] <tjaalton> though the intel sdp is skylake, so the usb controller might not be supported on trusty, although the installer does boot from it..
[07:48] <smb> tjaalton, That is a lot of information that is not helpful. :-P
[07:48] <tjaalton> http://www.ubuntu.com/certification/hardware/201306-13791/
[07:48] <tjaalton> better? :)
[07:50] <tjaalton> debian jessie b2 installs fine fwiw
[07:51] <smb> tjaalton, Maybe. Just generally this seems to be an issue that a certain part of the usb drivers is not compiled into the kernel. But then there can be any combination of usb-1-2-3 on either side
[07:53] <tjaalton> ok, what do you want? I can get info from the intel machine more easily as it has a ps2 port that works
[07:54] <tjaalton> but the machine needs to be booted with it attached to work, it seems
[07:55] <tjaalton> ps2 kbd i mean
[07:55] <smb> tjaalton, thats at least something... You said desktop install is ok. So if you  can open a new bug about this. I think ubuntu-bug linux will gather lsusb and lsmod. So any info that helps to figure out what driver chain is running when it works
[07:56] <smb> tjaalton, Yeah, I would not think ps2 is made for hotplug... or was made
[07:57] <tjaalton> I've opened bug 1559692
[07:57] <ubot5> bug 1559692 in linux (Ubuntu) "server image has no keyboard, desktop image works" [Undecided,Incomplete] https://launchpad.net/bugs/1559692
[07:58] <tjaalton> but it has no logs yet
[07:58] <tjaalton> so if I boot working xenial on it and attach logs from it, that would be enough?
[08:01] <smb> tjaalton, if xenial is the target that you want to get fixed. Because upstream sometimes renames modules. In the end it could be required to open multiple reports (at least per hw). But I would probably start with one thing and then decide after we figured that one
[08:05] <tjaalton> i just want to get the machine installed so I can put my data on it :)
[08:05] <tjaalton> but yeah xenial is the main target
[08:08] <smb> tjaalton, So I added the question to the bug report as well. Basically the desktop installer has access to all modules while the server (d-i) installer needs proper declaration of what is an input module. 
[08:11] <tjaalton> i'm on the server installer with working network and ssh client, dmesg/lspci/lsusb collected
[08:11] <tjaalton> is that helpful?
[08:12] <smb> tjaalton, not that much as in that case the module likely is missing as otherwise you would have a keyboard
[08:12] <tjaalton> ok
[08:15] <smb> tjaalton, So not sure why but in the bug report you say 14.04 desktop is working. Is a 16.04 desktop working, too or not working as the server installer?
[08:16] <tjaalton> both desktop images work
[08:19] <smb> ah ok, so that is at least a better comparison than 16.04 server against 14.04 desktop. At least it can rule out it not being supported by the kernel in general as both 16.04 server and desktop use the same kernel then.
[08:26] <tjaalton> did a quick sanity test with 12.04.2 where it indeed works
[08:35] <tjaalton> smb: one thing I noticed is that input-modules doesn't have hid-lenovo
[08:35] <tjaalton> i have a usb thinkpad kbd which happens to be the only usb keyboard I have. precise installer had only hid-generic loaded though
[08:35] <tjaalton> and usbhid of course
[08:38] <smb> tjaalton, Hm. Might be that at some point there was special support ... I don't know from the top of my head whether that would automatically mean the generic driver will ignore it
[08:38] <apw> when we add a special driver we disable the generic one explicitly iirc
[08:39] <smb> Ah ok, that then might explain it
[08:39] <smb> apw, and morning
[08:39] <tjaalton> so, make sure all the special ones get added in input-modules?
[08:40] <apw> smb, moin
[08:40] <smb> That would be a result... and I can imagine that is easily forgotten
[08:40] <apw> tjaalton, that might well be a sane position to take, though it is early and i have not had my second cup of tea
[08:40] <tjaalton> :)
[08:42] <smb> apw, Maybe hwe should remind is if they require us to add new fancy keyboard drivers... :-P
[08:42] <apw> heh ... i am liking that
[08:42] <apw> tjaalton, does your keyboard have a trackpoint ?
[08:43] <tjaalton> apw: yep
[08:43] <tjaalton> (love it)
[08:43] <apw> ok i suspect that is the reason the driver was added then
[08:43] <smb> The problem is that not every hid driver is a keyboard... I think there is something like hid-joystick as well. Fancy but useless for a server install
[08:43] <tjaalton> right, special keyboards then :)
[08:45] <smb> tjaalton, So I guess you used the same keyboard in both (machine) cases. So likely we go and add hid-lenovo as a first step which you can then verify when things hit the image
[08:46] <tjaalton> smb: yeah
[08:46] <apw> tjaalton, now how to test that that is sufficient.  are you able to get that driver on and loaded to confirm that is sufficient in the d-i installer
[08:47] <smb> hm... might be possible to do that on the one that has ps2
[08:47] <tjaalton> by rebuilding the installer I guess
[08:48] <smb> tjaalton, could you not attach ps2 on that one server (plus usb), then load the hid module using the ps2 keyboard and check whether that makes the usb one working?
[08:49] <tjaalton> not attach ps2? means I have no kbd
[08:49] <smb> apw, though... do modules that are not in any d-i udeb be available in the d-i installer at all
[08:49] <tjaalton> don't think so
[08:49] <smb> tjaalton, no, I mean attach both
[08:49] <tjaalton> ah
[08:49] <apw> no, but they are available on any normal install for putting on a usb stick etc
[08:49] <apw> so not impossible
[08:50] <apw> tjaalton, i wonder if you could test this in VM, by passing that device to it
[08:50] <tjaalton> just needs copying to the right place and modprobe?
[08:50] <apw> or just copying in, and remove readd keyboard
[08:50] <apw> smb, can we do usb passthru to vms, i feel we can
[08:51] <smb> apw, in theory
[08:51] <tjaalton> problem is that my main desktop has the same kbd :)
[08:51] <tjaalton> same model
[08:52] <smb> It would be possible to attach two... thought highly confusing as well
[08:54] <smb> tjaalton,  but yeah I think have ps2+usb attached on server boot, do basic net setup with ps2, copy hid-lenovo (same kernel version) from some other place and insmod it. Then try usb (maybe with a unlug + replug)
[08:58] <tjaalton> smb: yep, that did the trick
[08:58] <tjaalton> didn't need to replug even
[08:59] <smb> tjaalton, ok cool. Yeah that was more just in case. :) So can you please add us that info to the bug report? We are forgetful about stuff only on irc
[09:00] <tjaalton> sure :)
[09:49] <tjaalton> smb: updated, marked as triaged
[09:50] <smb> tjaalton, ack thanks
[12:35] <caribou> apw: xnox: any reason why the linux-crashdump metapackage is gone AWOL on s390x ?
[12:35] <apw> caribou, that would be my fault i am sure
[12:35] <apw> caribou, can you file me a bug pls, and i will wack it
[12:35] <caribou> apw: sure
[12:35] <apw> i would imagine it is less awol and more "never existed", a lot of those packages have hand manage lists on them
[12:37] <caribou> apw: lp: #1560015
[12:37] <ubot5> Launchpad bug 1560015 in linux (Ubuntu) "linux-crashdump meta-package is missing on s390x architecture" [Undecided,New] https://launchpad.net/bugs/1560015
[12:37] <caribou> apw: no, I used it two weeks ago afaik
[12:37] <apw> caribou, ... really ?
[12:37] <caribou> apw: think so but I'd have to check xnox's instance
[12:38] <caribou> apw: let me check
[12:38] <apw> caribou, not as far as i can see ...
[12:38] <apw> not since vivid !
[12:39] <caribou> apw: true;
[12:39] <apw> caribou, is there any architecture we build for which does not support crashdump ?
[12:40] <caribou> apw: arm64
[12:40] <caribou> apw: kexec support is still under dev there
[12:40] <apw> caribou, ok, so the list should be "all arches - arm64" then after i am done fixing it
[12:41] <caribou> apw: yep
[12:41] <apw> caribou, which it is not if i just add s390x ... _sigh_
[12:45] <apw> caribou, fix-committed ...
[12:48] <caribou> apw: thanks!
[12:49] <apw> caribou, likely the next upload is when beta freeze lift
[13:15]  * ogasawara waves to ben_r 
[13:16]  * ben_r waves back :)
[13:16] <ben_r> Good morning :)
[13:16] <apw> ben_r, yo ... you should have said hello
[13:17] <ben_r> That also, however, I am sure it is morning there ;)
[13:17] <apw> ben_r, i am sure it is not :)
[13:18] <ben_r> apw: fair enough :)
[14:49] <lamont> jsalisbury: updated that bug for you.  what I missed in the update is that if 4.4.0-9+fix is good, then we have a new bug and should vacate 1543683 :)
[14:52] <jsalisbury> lamont, I'll build you the kernel with the new fix and without 237ed86c reverted.  Maybe it is an interaction between the two, that would make it easier to fix.
[14:53] <lamont> verily
[14:54] <lamont> jsalisbury: in other news, if you have the wherewithall to bring me up to speed on taking $RANDOMCOMMIT and turning that kernel tree into a built kernel, I'd be able to do all the bisecting myself
[14:54] <lamont> when I bisect to somewhere with no debian/ directory, I get lost...
[14:55] <jsalisbury> lamont, I use the 'mainline-build-one' script from kteam-tools: git://kernel.ubuntu.com/ubuntu/kteam-tools.git
[14:55] <lamont> jsalisbury: PERFECT!
[14:55] <jsalisbury> lamont, it does the checkout of debian and debian.master
[14:56] <lamont> it was one of those "I KNOW THERE'S A SCRIPT somewhere!!"
[14:56] <lamont> kind of things
[14:56] <jsalisbury> lamont, its in : ~kteam-tools/mainline-build
[14:58] <lamont> ta.  I'll let you build this next kernel, and then I'll update with answers and run with it
[14:58]  * lamont will be distracted by $REALJOB for a bit this morning
[14:58] <jsalisbury> lamont, :-)
[15:00] <lamont> jsalisbury: oh hey, and what is this magic commit hash that we're calling "the fix", just for my clarity
[15:01] <lamont> as in, what do I need to cherrypick onto the bisect branch each test?
[15:01] <jsalisbury> lamont, gotcha, one second
[15:02]  * lamont will catch scrollback in a bit
[15:04] <jsalisbury> lamont, this is the SHA1 in mainline:
[15:04] <jsalisbury> lamont, this is the SHA1 in mainline:
[15:04] <jsalisbury> 8d409cb drm/i915: Fix hpd live status bits for g4x
[15:04] <jsalisbury> lamont, this is the SHA1 in Xenial:
[15:04] <jsalisbury> 7a5c500 drm/i915: Fix hpd live status bits for g4x
[15:30] <lamont> ta
=== alkisg_away is now known as alkisg
[23:17] <lamont> jsalisbury: we have a WINNER.... bug updated.
[23:18] <lamont> and since it's not bisecting, I'm going to let you provide me with a kernel that does what you think we need next.
[23:18] <lamont> s/bisecting/a matter for bisecting/
[23:20] <jsalisbury> lamont, ack, thanks for testing.  I'll build you another kernel shortly.
[23:20] <lamont> I'm about to bail, will test in the morning.