[00:39] <tsimonq2> yay 4.4 is out!
=== jhenke_ is now known as jhenke
=== henrix_ is now known as henrix
[11:42] <xnox> i have dual screen monitor setup with classy dvi & vga connectors.
[11:42] <xnox> my vga screen this morning is 1024x768, instead of the expected 1920x1080
[11:42] <xnox> on wily
[13:45] <cristian_c> jsalisbury: hi
[17:54] <xnox> apw, hi! i have more kernel config requests. Imho _KVM _VIRTIO_* should be set to =y, on s390x, if not throughout. See bug 1532886 
[17:54] <ubot5> bug 1532886 in linux (Ubuntu) "s390x kernels are inconsistent for cloud stuff" [Undecided,New] https://launchpad.net/bugs/1532886
[17:55] <xnox> would you please review them for sensibility and shepperd it past the nagging bot =)
[17:56] <apw> xnox, are those causing issue, or just making you unhappy
[17:57] <xnox> apw, the VIRTIO_BLK and VIRTIO_NET are failing to boot the cloud images.
[17:58] <apw> xnox, but presumably that is because they are missing from the initrd or something, as much as not being =y
[17:58] <xnox> sure.
[17:58] <xnox> all i have is virtio_scsi.ko because of ./config.common.ubuntu:CONFIG_SCSI_VIRTIO=m
[17:59] <apw> as it seems more logical for them to all be =m rather
[17:59] <xnox> apw, no... cause then one requires to have initrd, and cannot do direct kernel boot, no?
[18:00] <apw> xnox, ubuntu essentially does not boot without an initrd anyhow
[18:00] <apw> right ?
[18:01] <xnox> so virtio_blk ends up in -extra
[18:01] <xnox> which is odd
[18:02] <apw> well that is likely all wrong
[18:02] <apw> likely because it has been =y so noone noticed it wasn't being pulled up to -image
[18:03] <xnox> apw, and do we have any history into why they are =y?
[18:03] <xnox> and in per-arch rather than in config.common.ubuntu?
[18:03] <xnox> surely things that are the same on all arches, let's say pre-recent ports should have migrated into config.common.ubuntu?
[18:03] <apw> "it doesn't work mumble mumble" without, and i think s390x came with it =m and we thought to use that to find out why
[18:04] <rtg> apw, debian.master/config/s390x/config.common.s390x:CONFIG_VIRTIO_BLK=m
[18:04] <rtg> debian.master/config/s390x/config.common.s390x:CONFIG_VIRTIO_NET=m
[18:04] <rtg> those are wrong IMHO
[18:04] <rtg> or at least inconsistent
[18:04] <xnox> rtg, see full bug report -> bug 1532886 i have CONFIG_KVM there too, and ZLIB_DEFLATE
[18:04] <ubot5> bug 1532886 in linux (Ubuntu) "s390x kernels are inconsistent for cloud stuff" [Undecided,Confirmed] https://launchpad.net/bugs/1532886
[18:04] <apw> rtg, they are inconsistant, but there is no obvious reason tehy _have_ to be =m which is what we discussing
[18:04] <apw> =y even
[18:05] <rtg> right
[18:05] <apw> we have a lot of stuff which is =y because in 2.6.32 they wern't loadable, and we've not come back to them
[18:05] <xnox> apw, well back in the day we had normal and virtual kernel images. and normal had it as a module, and virtual had it as =y no?
[18:05] <xnox> and then we merged all kernel flavours to one (or some such)
[18:06] <apw> xnox, i don't thikn it is as clear as that sounds, but some of that occured
[18:06] <xnox> and at that point i guess CONFIG_VIRTIO_* did =m -> =y
[18:06] <apw> it did that becuase it didn't autoload, in the old days
[18:06] <apw> but, it may well do so now
[18:06] <apw> i think debian is all =m and happy, so 
[18:06] <xnox> however, it seems that the current cloud-image building machinery doesn't have -extra image installed, and subsequently initramfs-update doesn't include virtio-blk (automagically or needs to be forced)
[18:07] <apw> xnox, right so for sure that not being in linux-imageis _wrong_
[18:07] <rtg> xnox, that is definitely a bug
[18:07] <xnox> oh, lack of autoloading *sigh* those were the good old days =)
[18:08] <xnox> i can check that it can autoload, with d-i on s390x on a virtual machine.
[18:08] <xnox> becase udebs are packaged right and have virtio-blk, and in a qemu vm they should autoload....
[18:08] <xnox> let me check that.
[18:11] <apw> xnox, oh goody we have it half right, sigh ^2
[18:12] <xnox> or rather "for once .udebs are on the ball =)"
[18:12] <apw> rtg, heh and we might want to upload a 4.3 now :/
[18:12] <rtg> apw, great :(
[18:13] <apw> rtg, luckily i have the previous master-next should it come to it
[18:13] <mamarley> Xenial will eventually be getting 4.4, won't it?
[18:14] <apw> mamarley, yep, "soon" waiting on some dkms fallout to be resolved as much as anything
[18:14] <rtg> apw, why don't you go ahead anf force push xenial master-next. I've updated unstable
[18:15] <apw> mamarley, and inded we had just decided we wen't going need a v4.3 again
[18:15] <mamarley> Oh, stuff like graphics drivers failing to compile?
[18:16] <xnox> apw, virtio_net appears to be auto-loaded
[18:16] <apw> xnox, that is enocouraging
[18:16] <apw> xnox, so i'd say lets get that fixed in teh inclusion list if that fixes you
[18:17] <xnox> i only see virtio_scsi.ko and virtio_net.ko in the installer =/
[18:18] <xnox> sigh, i guess block-modules is not included in the d-i.
[18:19] <xnox> and well, it's a must really.
[18:19] <xnox> because then none of the d-i/server installer will install inside a virtual machine =(
[18:19] <xnox> on some arches....
[18:19] <xnox> build/pkg-lists/cdrom/powerpc.cfg:block-modules-${kernel:Version}
[18:19] <xnox> build/pkg-lists/hd-media/amd64.cfg:block-modules-${kernel:Version}
[18:19] <xnox> build/pkg-lists/hd-media/i386.cfg:block-modules-${kernel:Version}
[18:19] <xnox> build/pkg-lists/hd-media/powerpc.cfg:block-modules-${kernel:Version}
[18:20] <xnox> le sigh.
[18:20] <xnox> so block-modules needs to be added to like ppc64el, armhf, arm64, s390x
[18:22]  * xnox ponders which d-i builts are used for qemu installs
[18:22] <apw> rtg, ok the tip i have was last changed on the 24 dec, do you recall doing anything since then to it ?
[18:23] <rtg> apw, yeah, probably. lemme go back in my local log. I can find the last 4.3 tip
[18:27] <apw> rtg, the source uploader has:
[18:27] <apw> commit e0e8e4a3f07e4f489fae0fcbbade29ef4102d04f
[18:27] <apw> Author: Tim Gardner <tim.gardner@canonical.com>
[18:27] <apw> Date:   Tue Jan 5 07:35:27 2016 -0700
[18:27] <apw>     UBUNTU: [Config] CONFIG_ZONE_DEVICE=y for amd64
[18:28] <rtg> apw, yep, that is what my log shows as well
[18:28] <rtg> I'll reset master-next
[18:28] <apw> ok good enough thanks
[18:29] <rtg> apw, pushed
[18:30] <rtg> xnox, apw, I'll catch up on bug #1532886 after I get some lunch
[18:30] <ubot5> bug 1532886 in linux (Ubuntu) "s390x kernels are inconsistent for cloud stuff" [Undecided,Confirmed] https://launchpad.net/bugs/1532886
[18:31] <xnox> rtg, cool thanks. Well work with apw as to what you want to make things consistent and which way around.
[18:32] <rtg> xnox, well, if we make VIRTIO_BLOCK and _NET consistent, i.e., =y, then no other changes are needed.
[18:32] <xnox> sure.
[18:33] <xnox> but i thought that apw wants to make them all =m and make sure they land in -image, rather than in -extra
[18:33] <xnox> whichever =) as long as cloudimages still build and are bootable =)
[18:33] <apw> rtg, prolly the expedient way forward and i will add a card to get that looked at by someone
[18:35] <xnox> thanks =)
[19:09] <xnox> apw, rebuilt s390x d-i in a ppa, with block-modules. virtion_blk & _net autoload correctly for me. However, I'm struggling to figure out if there is any initramfs that we want to /not/ have those modules.
[19:10] <xnox> given that any disk-image can be trivially exported into a VM and booted.
[19:12] <apw> xnox, right we likley would want them in every initrd, not in the kernel though as they don't go away then
[19:13] <xnox> right.
[19:13]  * xnox ponders where/how initramfs decides to include virtio_net or not.
[19:14] <apw> xnox, it is likley on my list of "always include this if it exists"
[19:14] <apw> it has quite an extensive list of that
[19:15] <xnox> failing to grep for it.
[19:21] <xnox> apw, yeah, we are good. we default to most, and that does "copy_modules_dir kernel/drivers/block" copy all the things.
[19:22] <xnox> and kernel/drivers/net
[19:22] <xnox> so turning virtio_blk|_net into modules should be a fairly safe and uneventful.
[19:23] <xnox> still need to check that all the relevant d-i's have block-modules and that's about it.
[19:28] <hallyn> apw: sforshee: async ping on bug 1531747, any ideas on how we should fix it?
[19:28] <ubot5> bug 1531747 in linux (Ubuntu Xenial) "overlay: mkdir fails if directory exists in lowerdir in a user namespace" [High,Triaged] https://launchpad.net/bugs/1531747
[19:28] <rtg> cking, was there an upstream update for the 'rhashtable: Fix walker list corruption' revert ?
[19:29] <rtg> cking, nm, just saw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1526811/comments/4
[19:29] <ubot5> Launchpad bug 1526811 in linux (Ubuntu Xenial) "SRU: walker list corruption while being intensively stressed" [High,Fix committed]
[19:38] <cking> rtg yep
[21:21] <sque> skoe, Hi, are you here? I am interested in your work on bug #1525554
[21:21] <ubot5> bug 1525554 in linux (Ubuntu) "[HP ProBook 470 G3, Intel Skylake HDMI, Digital Out, HDMI] No sound at all" [Medium,Incomplete] https://launchpad.net/bugs/1525554