tsimonq2 | yay 4.4 is out! | 00:39 |
---|---|---|
=== jhenke_ is now known as jhenke | ||
=== henrix_ is now known as henrix | ||
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 | 11:42 |
cristian_c | jsalisbury: hi | 13:45 |
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:54 |
xnox | would you please review them for sensibility and shepperd it past the nagging bot =) | 17:55 |
apw | xnox, are those causing issue, or just making you unhappy | 17:56 |
xnox | apw, the VIRTIO_BLK and VIRTIO_NET are failing to boot the cloud images. | 17:57 |
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:58 |
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? | 17:59 |
apw | xnox, ubuntu essentially does not boot without an initrd anyhow | 18:00 |
apw | right ? | 18:00 |
xnox | so virtio_blk ends up in -extra | 18:01 |
xnox | which is odd | 18:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
apw | xnox, oh goody we have it half right, sigh ^2 | 18:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
xnox | i only see virtio_scsi.ko and virtio_net.ko in the installer =/ | 18:17 |
xnox | sigh, i guess block-modules is not included in the d-i. | 18:18 |
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:19 |
xnox | le sigh. | 18:20 |
xnox | so block-modules needs to be added to like ppc64el, armhf, arm64, s390x | 18:20 |
* 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:22 |
rtg | apw, yeah, probably. lemme go back in my local log. I can find the last 4.3 tip | 18:23 |
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:27 |
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:28 |
rtg | apw, pushed | 18:29 |
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:30 |
xnox | rtg, cool thanks. Well work with apw as to what you want to make things consistent and which way around. | 18:31 |
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:32 |
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:33 |
xnox | thanks =) | 18:35 |
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:09 |
xnox | given that any disk-image can be trivially exported into a VM and booted. | 19:10 |
apw | xnox, right we likley would want them in every initrd, not in the kernel though as they don't go away then | 19:12 |
xnox | right. | 19:13 |
* xnox ponders where/how initramfs decides to include virtio_net or not. | 19:13 | |
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:14 |
xnox | failing to grep for it. | 19:15 |
xnox | apw, yeah, we are good. we default to most, and that does "copy_modules_dir kernel/drivers/block" copy all the things. | 19:21 |
xnox | and kernel/drivers/net | 19:22 |
xnox | so turning virtio_blk|_net into modules should be a fairly safe and uneventful. | 19:22 |
xnox | still need to check that all the relevant d-i's have block-modules and that's about it. | 19:23 |
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:28 |
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:29 |
cking | rtg yep | 19:38 |
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 | 21:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!