[01:42] <lotuspsychje> good morning to all
[05:31] <marcoagpinto> Heya
[05:32] <marcoagpinto> the demon!
[06:05] <lordievader> Good morning
[06:09] <luna> hi
[06:13] <lordievader> Hey luna
[06:13] <lordievader> How are you doing?
[06:14] <luna> lordievader: alright
[07:42] <ducasse> good morning
[07:43] <luna> morning
[07:43] <EoflaOE> helllo
[07:44] <marcoagpinto> morning, guys
[07:44] <EoflaOE> good morning
[07:44] <lotuspsychje> hey luna EoflaOE
[07:44] <EoflaOE> lotuspsychje hello
[07:44] <marcoagpinto> I have been working on LanguageTool: https://github.com/languagetool-org/languagetool/commits/master
[07:44] <marcoagpinto> :)
[07:45] <EoflaOE> nice marcoagpinto.
[07:45] <EoflaOE> What is it?
[07:45] <OerHeks> kernel 5.0.0.23 update made me boot in recovery mode and use the dpkg fix option, both machines https://usn.ubuntu.com/4069-2/
[07:46] <marcoagpinto> EoflaOE: A grammar checker for LibreOffice, Firefox and others
[07:47] <EoflaOE> marcoagpinto: nice.
[07:47] <lotuspsychje> OerHeks: downloading & installing...gonna test right away
[07:47] <lotuspsychje> 300mb oof!
[07:47] <lotuspsychje> cross my fingers!
[07:49] <lordievader> Does that include modules?
[07:49] <EoflaOE> lotuspsychje welcome back
[07:49] <marcoagpinto> what?! A 300 MB update for the Kernal?
[07:49]  * lordievader just compiled 5.2.5: 14M for the kernel, 250M for the modules.
[07:49] <marcoagpinto> Kernel*
[07:53] <lotuspsychje> OerHeks: big troubles so it seems
[07:53] <lotuspsychje> reaching to desktop with crazy flickering
[07:53] <lotuspsychje> booting 4.18.0-24-generic works
[07:54] <lotuspsychje> is there a bug already?
[07:54] <OerHeks> nope
[07:54] <OerHeks> just boot recovery mode, use the dpk option to fix packages
[07:55] <OerHeks> c/dpkg
[07:55] <lotuspsychje> OerHeks: lets hope they on this already, got a lot of hwe customers
[07:55] <OerHeks> if this is your fix, we file a bugreport
[07:57] <lotuspsychje> ok lets try
[08:00] <EoflaOE> lotuspsychje: How's it going?
[08:01] <lotuspsychje> wich kernel you on OerHeks
[08:01] <OerHeks> Andy-HP:~$ uname -a
[08:01] <OerHeks> Linux Andy-HP 5.0.0-23-generic #24~18.04.1-Ubuntu SMP Mon Jul 29 16:12:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[08:01] <OerHeks> andy@Andy-HP:~$
[08:02] <lotuspsychje> kk
[08:03] <EoflaOE> hi OerHeks
[08:04] <OerHeks> yeah, i have some cruft that does not want to autoremove
[08:04] <OerHeks> https://paste.ubuntu.com/p/N2NZ7mmJ2M/
[08:05] <lotuspsychje> 5.0.0-23-generic booted after dpkg recoverymode, but backlight doesnt work anymore
[08:06] <lotuspsychje> Fn keys dont react
[08:06] <OerHeks> normal resolution?
[08:06] <lotuspsychje> yes
[08:06] <OerHeks> i had low resolution too, reboot fixed that
[08:07] <lotuspsychje> lets try another
[08:09] <EoflaOE> lotuspsychje: How's the backlight?
[08:09] <lotuspsychje> not good, reboot gives me flicker again
[08:10] <lotuspsychje> back to 4.18.-25
[08:10] <EoflaOE> lotuspsychje: OK.
[08:10] <lotuspsychje> OerHeks: i presume its backlight flickering issue for me
[08:10] <OerHeks> i checked first with live iso, nothing to fix with partitions
[08:11] <OerHeks> i guess your gpu dkms is not build ?
[08:11] <lotuspsychje> intel grafix
[08:13] <lotuspsychje> OerHeks: does the -release guys know about this yet?
[08:14] <OerHeks> your journalctl -b -1 from the previous boot # comes in handy now
[08:14] <OerHeks> i run the amd 5450
[08:18] <lotuspsychje> OerHeks: ok talked to them, if we file a bug, forward to #ubuntu-kernel
[08:19] <lotuspsychje> nothing known yet
[08:19] <lotuspsychje> i gota split in 10min
[08:30] <lotuspsychje> bbl OerHeks
[08:30] <EoflaOE> lotuspsychje: what is "bbl"?
[08:30] <lotuspsychje> OerHeks: informed apw in -kernel
[08:31] <lotuspsychje> be back later
[08:31] <EoflaOE> lotuspsychje: Thanks
[10:20] <tomreyn> moar details needed on your kernel issues, plz
[10:20] <BluesKaj> Hi folks
[10:39] <tomreyn> lotuspsychje and Oerheks: could you file a bug report if there's an issue with the 18.04 HWE image update to linux 5.x, please?
[10:39] <tomreyn> + anyone affected
[10:43] <tomreyn> that is an issue which goes beyond what is stated in the "ATTENTION" paragraph on https://usn.ubuntu.com/4069-2/
[10:43] <OerHeks> still determining what exactly happened
[10:44] <OerHeks> no linux-generic on this system
[10:45] <BluesKaj> odd, I'm running the 5.2.0-8-generic kernel here without any problems
[10:45] <OerHeks> this is specific 18.04.2 hwe kernel update to 5.0.0-23
[10:45] <BluesKaj> ok
[10:46] <tomreyn> i've been on hwe-edge for a while, so didn't run into this.
[10:46] <BluesKaj> and this is VB related too, so who knows what it could be
[10:46] <tomreyn> but i'm on 5.0.0-20 now, haven't booted into 5.0.0-23 yet.
[10:47] <tomreyn> maybe it's really just about the need to regenerate vbox modules.
[10:47] <BluesKaj> thta's why I avoid VMs, nothing but trouble IME
[10:49] <BluesKaj> I suspect some users run VMs because they can, not because they need them :-)
[10:50] <lordievader> Or you go for kvm/qemu. Most of the virtio drivers are pre-installed.
[10:50] <lordievader> No need to recompile modules or anything.
[10:51] <tomreyn> it's just a little less convenient if you're into mice and GUIs.
[10:52] <tomreyn> i thnk the vbox packages in ubuntu have a lot of issues. those from vbox.org work fine for me for the very most part.
[10:53] <tomreyn> but i don't do secure boot
[10:53] <lordievader> Mice and gui's work fine in kvm (with spice anyways).
[10:54] <tomreyn> yes, but not for setting VMs up. there are GUIs, but they're not as good.
[10:55] <lordievader> You mean like virt-manager?
[10:55] <tomreyn> yes, virt-manager, gnome-boxes
[10:56] <lordievader> Yeah, those tools could be better. Then again, I rarely use them.
[10:57] <tomreyn> desktop virtualization is a bit of a weird concept, i give you that ;)
[10:58] <lordievader> Erm... yes
[10:58] <BluesKaj> tomreyn, isn't secure boot meant for windows only?
[10:59] <tomreyn> BluesKaj: no
[10:59] <lordievader> No, Linux can do it too.
[11:00] <tomreyn> it's a uefi feature. any OS can (choose to) support it.
[11:00] <BluesKaj> I have it disabled , since i thought it was problematic
[11:01] <tomreyn> i think windows 10 required uefi and uefi secure boot support from 'windows 10 compatible' platforms.
[11:02] <tomreyn> so that was what pushed for mainboard producers to introduce support for it.
[11:03] <tomreyn> 'proper' secure boot support in ubuntu is still somewhat young. and it's generally not that easy to get right when there are changes.
[11:03] <BluesKaj> well, windows needs as much security as it can muster anyway :-)
[11:04] <tomreyn> "secure boot" is another terrible misnomer. a better name would have been "firmware authenticated boot".
[11:05] <tomreyn> and then your firmware is a big proprietary blob most of the time
[11:10] <EoflaOE> hello
[11:10] <BluesKaj> 'Morning EoflaOE
[11:10] <EoflaOE> Good morning BluesKaj
[12:58] <tomreyn> hmm, no issues for me going from 5.0.0-20 to 5.0.0-23
[13:36] <lotuspsychje> ok lets see whats going on here now..
[13:45] <lotuspsychje> from a -23 in recoverymode: https://paste.ubuntu.com/p/98jBCTpmhb/
[13:45] <EoflaOE> hi lotuspsychje
[13:48] <lotuspsychje> hey EoflaOE
[13:49] <lotuspsychje> im gonna try to file the bug against linux, from recoverymode here, as i cant access desktop with normal boot
[13:50] <EoflaOE> lotuspsychje: Thanks for making bug report and making Ubuntu better.
[13:57] <lotuspsychje> ok, this is whats happening to me: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe/+bug/1838644
[13:57] <lotuspsychje> OerHeks: ^
[13:58] <EoflaOE> lotuspsychje: Saw your bug report and commented. However I am not affected.
[14:00] <lotuspsychje> EoflaOE: its kind of you, but not sure this is very helpful to do in bugs, perhaps keep the space free for debugging more?
[14:00] <EoflaOE> lotuspsychje: OK.
[14:00] <lotuspsychje> lets test the nuc now..
[14:03] <lotus|NUC> cross fingers
[14:04] <lotus|NUC> nuc seems fine
[14:05] <lotus|NUC> lotuspsychje@NUC:~$ uname -a
[14:05] <lotus|NUC> Linux NUC 5.0.0-23-generic #24~18.04.1-Ubuntu SMP Mon Jul 29 16:12:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[14:05] <EoflaOE> Nice
[14:09] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838601
[14:23] <lotuspsychje> lets c what happens in wayland
[14:34] <lotuspsychje> been able to select wayland at gdm, but both gdm and wayland also flickering
[14:45] <tomreyn> the latest from #ubuntu-devel: <gaughen> Apologies all, the [18.04.3] point release is delayed. it will not happen today, there were issues found in kernel testing.
[14:47] <tomreyn> currently plans are to release on 2019-08-08, but this is pending confirmation.
[15:09] <EoflaOE> hello lotuspsychje
[15:12] <jink> Hellotuspsychje.
[15:12] <lotuspsychje> howdy
[15:12] <EoflaOE> hello jink and lotuspsychje
[15:22] <lotuspsychje> updated bug #1838644
[15:46] <TJ-> lotuspsychje: the i915 driver isn't loading according to the dmesg you've attached
[15:47] <lotuspsychje> TJ-: yes i know, as i can only boot into recoverymode
[15:47] <lotuspsychje> the flickering prevents me doing anything
[15:47] <lotuspsychje> no tty, no gdm, no desktop
[15:48] <lotuspsychje> both on xorg & wayland
[15:49] <TJ-> SSH?
[15:51] <lotuspsychje> or can i make startup command dmesg > dmesg.txt ?
[15:51] <TJ-> you can grab the last log when it flickered using "journalctl -k -b -1" or similar
[15:52] <TJ-> use "journalctl --list-boots" to find the correct "-1" to refer to a boot that flickered
[15:54] <lotuspsychje> hm only june boots there
[16:00] <lotuspsychje> TJ-: catched one: https://paste.ubuntu.com/p/bmsVjhmhSk/
[16:01] <TJ-> add it to the bug report, quote the last line which reveals the error
[16:02] <lotuspsychje> ok
[16:03] <lotuspsychje> added
[16:12] <lotuspsychje> food time first
[16:22] <tomreyn> https://01.org/linuxgraphics/documentation/how-report-bugs and several bug reports discussing "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun" errors suggest booting with    drm.debug=0x1e log_buf_len=4M    to get more debug output. apprently this error message is more of a symptom than a hint on the root cause.
[16:23] <tomreyn> * a *common* symptom
[16:27] <TJ-> tomreyn: correct, and that suggestion is a great way to capture the detail required to diagnose it
[16:28] <tomreyn> it's good to have someone around who actually *knows* such things :)
[16:29] <tomreyn> (i just copy and paste)
[16:34] <TJ-> the i915 driver is becoming like the iwlwifi driver... they're show-horning functionality for so many different chipsets into the single driver they're breaking it frquently
[16:49] <EoflaOE> lotuspsychje hi
[17:07] <tomreyn> yes, that's not healthy. we can handle multiple module names very well.
[17:09] <lotuspsychje> didnt hear any customers yet...
[17:10] <lotuspsychje> most of them are on bionic hwe
[17:31] <lotuspsychje> https://news.softpedia.com/news/canonical-releases-linux-5-0-kernel-hwe-security-update-for-ubuntu-18-04-2-lts-526921.shtml
[17:34] <tomreyn> lotuspsychje: maybe you can support them by providing more debugging info as discussed above (if you have time for this)
[17:35] <lotuspsychje> tomreyn: support who
[17:35] <tomreyn> lotuspsychje: "any customers"
[17:35] <tomreyn> as well as the devs looking into it, i guess
[17:36] <lotuspsychje> tomreyn: my customers are mostly novice ubuntu users, i chosen LTS and tweaked this way, they dont need to search much anymore
[17:37] <lotuspsychje> dont think they will comprehend what grub is
[17:38] <lotuspsychje> tomreyn: but the devs & bugs i always will support on lts :p
[17:39] <tomreyn> lotuspsychje: okay, what i mean to say is that *if* we can assume there is a somewhat generic issue with this kernel image which affects users of (probably specific generations of) intel GPUs then those users would benefit from someone affected and experienced enough to provide debug info to the developers so they can identify the root cause and craft a fix.
[17:40] <tomreyn> i don't mean to argue, though.
[17:40] <lotuspsychje> i know i know
[17:40] <tomreyn> :) ok
[17:41] <lotuspsychje> tomreyn: i filed the bug today, and co-operated with the dev handling, if thats what you mean
 https://01.org/linuxgraphics/documentation/how-report-bugs and several bug reports discussing "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun" errors suggest booting with    drm.debug=0x1e log_buf_len=4M    to get more debug output. apprently this error message is more of a symptom than a hint on the root cause.
[17:45] <tomreyn> i'm suggesting to produce another log while booting with    drm.debug=0x1e log_buf_len=4M    !kernelparm
[17:45] <tomreyn> ...and to attach it to the bug report
[17:45] <lotuspsychje> ah gotya, missed that part sorry
[17:45] <tomreyn> no worries, i just didn't know whether you missed it or just had no time to spend on it. ;)
[17:46] <tomreyn> got to go, ttyl
[17:46] <lotuspsychje> enjoy
[18:03] <lotuspsychje> tomreyn TJ- updated bug #1838644
[18:08] <TJ-> lotuspsychje: did you get flickering when that log was captured?
[20:10] <lordcirth> PSA: linux-generic-hwe-18.04 got updated to 5.0 recently, and 5.0 kernels cause problems with ZFS.
[20:14] <lordcirth> Namely, significant performance drops, though it should be stable.
[20:19] <lordcirth> Though apparently there's a patch to reimplement the SIMD checksumming in the ZoL codebase, so that might be fixed already. Not sure what ZFS versions it's in
[22:09] <tomreyn> seven-eleven: new (read: unexperienced) ubuntu desktop and server users are more likely to install snaps rather than apt / debian packages anyways, so you might want to examine the 'trust model' of that rather
[22:15] <seven-eleven> tomreyn, yeah, im going to read upon snaps. i remember that snaps create a loopback device for each application, maybe that adds security too
[22:16] <tomreyn> read it again, you're remembering this wrong.
[22:17] <jeremy31> snaps are only as trustworthy as the source
[22:18] <tomreyn> and you can't really tell who the source is
[22:19] <sarnold> the apparmor policy and the seccomp policy provide security; the squashfs delivery system is just a delivery system though :)
[22:20] <sarnold> whether apparmor and seccomp policies in place provide sufficient security for your goals is still something you ought to decide after reading more about it
[22:21] <seven-eleven> gotcha, so the loopback is only to mount squashfs
[22:22] <sarnold> yeah
[22:23] <tomreyn> it's a loop mount (mount -o loop), not a loopback (network) device.
[22:25] <seven-eleven> mhm right
[22:32] <jeremy31_> How do you get an IPv6 address that ends with dead beef?
[22:34] <tomreyn> you request it from your nearest butchARIN
[22:35] <OerHeks> c0f:fee for me
[22:36] <tomreyn> 3 character hex costs extra, though
[22:36] <jeremy31_> My ISP doesn't even support IPv6 yet
[22:38] <tomreyn> :-/
[22:38] <tomreyn> i got a /64 at home