[07:12] <alkisg> apw: the school reported that your kernel didn't boot either
[07:12] <alkisg> It sounds like a different issue
[10:07] <alkisg> I'm currently at one of the affected schools where that "immediately reboots" issue happens, with xenial-hwe
[10:08] <alkisg> I tried terminal-output=console in grub, removing quiet splash, adding debug... I can't get anything at all, it reboots 2 secs after loading kernel/initramfs
[10:08] <alkisg> I have the exact same hardware at my office, and the problem doesn't happen there with the same kernel
[10:09] <alkisg> Any suggestions to try would be most welcome :)
[10:09] <alkisg> (or even test kernels)
[10:14] <alkisg> apw: is that new kernel respin that you did yesteray (for all, not the one just for me) available somewhere, e.g. in -proposed, to test with that one?
[10:15] <apw> alkisg, that is horribel symptoms to work with, if you have the same h/w and nothing
[10:15] <apw> alkisg, i wonder what cpu microcode it hsa installed
[10:16] <apw> alkisg, should be hitting -proposed "now", you can find the builds that will move in the CKT PPA though you need to take great care getting kernels from there to make sure they are consistent
[10:16] <apw> alkisg, ie you cannot sensibly add that PPA to apt
[10:16] <apw> alkisg, also they are not signed in there if efi secure boot is a thing you care about
[10:18] <alkisg> apw, one difference that I just thought of, is that schools have i386 while in the office I have amd64 installation
[10:18] <alkisg> office intel-microcode: 3.20170707.1~ubuntu16.04.0
[10:19] <apw> that is old microcode so not likely that
[10:19] <alkisg> school => same one
[10:19] <apw> alkisg, and this is 4.13 on xenial right ?
[10:19] <alkisg> (it's xenial with hwe and fully updated)
[10:19] <alkisg> Right
[10:20] <alkisg> Let me see if I can make sense of the ckt ppa.. 
[10:21] <alkisg> Ah, another difference is that I'm using uefi, they're booting with legacy (exact same hardware, batch purchase)
[10:21]  * alkisg tests 4.13.0-29.32~16.04.1  from the ppa...
[10:22] <alkisg> https://launchpad.net/~canonical-kernel-security-team/+archive/ubuntu/ppa/+build/14230584
[10:28] <alkisg> apw, that had the same symptoms, "reboot in 2 secs after loading initramfs, without displaying anything at all in the screen"
[10:30] <alkisg> I'll try to download the 64bit kernel that I have at work, and boot the 32bit userspace with the 64bit hwe kernel, and see if that makes it better...
[10:38] <alkisg> apw: I tried the kernel from the PPA. The i386 kernel reboots. The amd64 kernel (on the same i386 installation) BOOTS correctly.
[10:39] <alkisg> So the problem that my schools report (about 10 so far) happens only on i386 architecture.
[10:39] <apw> alkisg, hrm, ok ... thinking
[10:39] <alkisg> The good thing is that I'll probably be able to reproduce it at the office now that I know the problem is i386 vs amd64
[10:40] <apw> it is a shame one cannot install a 32bit kernel in 64bit for testing
[10:40] <alkisg> It doesn't happen with VMs though; my i386 virtualbox VM boots fine
[10:41] <alkisg> It does show some pagefault something, which it didn't show in the past, but it continues fine
[10:47]  * apw tries to get some testing done on this, hrm
[10:49] <apw> alkisg, i wish we had a 64bit kernel for use in 32bit installs, it is hard to see how it would not be a sensible option to take always
[10:49] <Caribou> Hi, any reason why the linux-meta pkg has a higher rev in Artful-proposed than in Bionic ?
[10:49] <Caribou> linux-meta | 4.13.0.25.26   | bionic           | source
[10:49] <Caribou>  linux-meta | 4.13.0.29.31   | artful-proposed  | source
[10:49] <apw> Caribou, because bionic is lagging against -proposed currently
[10:50] <apw> that has been respun so many times, we would be making people sad if it was updated so very often
[10:50] <Caribou> apw: :-)
[10:51] <Caribou> apw: just trying to fix lp: 1743537 that I just created
[10:52] <Caribou> nothing urgent but I just fumbled over it
[11:01] <alkisg> apw: sorry, I tried to run my 32bit virtualbox installation and it crashed my amd64 host. Twice. :)
[11:01] <alkisg> I haven't seen anything you might have written after the last time I wrote something
[11:01] <apw> just saying i would get some testing done, and see if we can see it here
[11:02] <apw> and musing that it would be nice to have a 64bit kernel for 32bit userspace
[11:02] <alkisg> I *thought* I tested my 32bit VM, but maybe I hadn't fully updated then, not sure. For now, and AFAIK, the 32bit kernel doesn't boot anywhere, even in VMs
[11:02] <apw> as that would likely always be a better idea
[11:03] <alkisg> OK, thanks for everything, I'm leaving the school now, I'll be online later.
[11:03] <apw> alkisg, ack thanks, will let you know what we find here
[12:06] <alkisg> apw, at home now, same setup as the office. New "find": when I boot my 64bit host with 4.13, and I try to launch my 32bit virtualbox VM, the HOST hangs
[12:06] <alkisg> When I boot the host with 4.10, it works fine
[12:06] <alkisg> I'll try removing intel-microcode, to see if that's to blame
[12:07] <apw> alkisg, hrm, ok thanks will get that on the to-investigate list
[12:08] <alkisg> I'll continue reporting new finds here; hopefully that's something helpful and not annoying :)
[12:10] <apw> yep
[12:13] <alkisg> I reverted intel-microcode to 3.20151106.1, it didn't help
[12:13] <alkisg> I'll try to find the latest *pre-spectre* 4.13 kernel to see if it happened there as well
[12:30] <alkisg> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.16/ has the same issue
[12:46] <alkisg> I have a better description of this issue: with 4.13 and 64bit installations, when starting virtualbox clients, the HOST crashes with this: https://snag.gy/HkOoeK.jpg
[12:46] <alkisg> Starting the same client with kvm works fine. This issue may be unrelated to the other one that I reported previously, that "4.13 reboots in 2 secs in 32bit clients". I'll investigate more.
[12:54] <thresh> how would I go about applying a patch on top of apt-get source'd kernel?
[12:55] <thresh> would `cat foo.patch | patch -pN;  dpkg-buildpackage -us -uc` work?
[12:57] <apw> thresh, might do indeed
[12:57] <apw> with a -b to say binaries
[16:08] <jsalisbury> alkisg, would it be possible for you to open bugs in launchpad for the issues you are seeing?  That will help us keep track of all the data and investigate more efficiently.  
[16:09] <alkisg> jsalisbury: of course, I just wanted to be able to reproduce it locally in my office first, so that I'm able to give proper feedback, without relying on remote teachers
[16:09] <alkisg> jsalisbury: the vbox issue is filed in https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1736116, so we can ignore it
[16:09] <jsalisbury> alkisg, great, thanks!
[16:09] <alkisg> Thank you too
[19:01] <tkamppeter> Hi
[19:02] <tkamppeter> I have a problem with a USB printer. When I unplug it, it does not correctly unregistered from systemd.
[19:03] <tkamppeter> "systemctl list-units" still shows
[19:03] <tkamppeter> sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d1.device                                     loaded active plugged   Deskjet_2540_series
[19:03] <tkamppeter> after unplugging.
[19:03] <tkamppeter> xnox told me that it is a kernel problem.
[22:50] <TimStarling> jsalisbury: regarding https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742602
[22:50] <TimStarling> 4.14rc1 works, which I think just leaves 12600 commits to choose from?
[22:51] <TimStarling> so bisection would take about 14 iterations, right?
[22:52] <TimStarling> and each iteration would require recompiling?
[23:02] <TimStarling> I'll just say it on LP