20:03:08 <DavidWHodgins> #startmeeting
20:03:08 <Inigo_Montoya> Meeting started Thu Jan  4 20:03:08 2018 UTC.  The chair is DavidWHodgins. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:08 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:03:19 <DavidWHodgins> #chair lewyssmith Benmc
20:03:19 <Inigo_Montoya> Current chairs: Benmc DavidWHodgins lewyssmith
20:03:24 <DavidWHodgins> #topic * Who's new? - If you are then come and say hello.
20:03:42 <DavidWHodgins> So, anyone here who hasn't been to a qa team irc meeting before?
20:03:54 <Benmc> no new hand raised
20:04:05 <DavidWHodgins> #topic * 4.14.10 kernel updates
20:04:20 <DavidWHodgins> Anyone have any problems with it so far?
20:04:42 <tarazed_> Not here.  I shall run a few more tests before midnight.
20:04:55 <lewyssmith> Runninf linus variant here OK.
20:05:03 <tjandrews> I've had one with 32-bit kernel-linus on my nvidia340 system.
20:05:22 <DavidWHodgins> I'll do my full tests, which takes several hours. If no one findes any problems, I'd like to validate the updates sometime tomorrow.
20:05:25 <wilcal> Looks good to me. We're all kinda getting good at testing kernels
20:05:31 <Benmc> (been on holiday, among other things, so not much testing)
20:05:41 <tjandrews> Essentially, it won't install. Things freeze up.
20:06:03 <tmb> tjandrews, out of disk space ?
20:06:05 <hviaene|2> Hi all
20:06:12 <DavidWHodgins> So far, my testing has been limited to using the server kernel while testing other things. Haven't done my full testing yet.
20:06:18 <DavidWHodgins> HiYa Herman
20:06:19 <lewyssmith> hviaene|2, Good evening, Herman.
20:06:33 <tjandrews> Doubtful. I'll have to check.
20:06:33 <tarazed_> Hi there hero
20:06:53 <DavidWHodgins> tjandrews: Also, was the devel-latest package installed?
20:07:09 <tmb> the same kernel has been running in cauldron without issues so far... so I'm optimistic about it :)
20:07:34 <tjandrews> Well, no. It didn't get that far before everything froze.
20:07:43 <wilcal> And now we're going to turn all that upside down right
20:07:59 <wilcal> next subject
20:08:31 <tjandrews> I will give more details in the bug report. It's a complicated story.
20:08:33 <DavidWHodgins> #tjandrews we'll need more info on the problem
20:08:38 <tarazed_> tj: so you don't get to reboot?
20:08:40 <DavidWHodgins> :-)
20:09:09 <DavidWHodgins> Let's follow up on that in the bug report for the kernel
20:09:15 <DavidWHodgins> #topic * Spectre and Meltdown hardware flaws and kernel updates
20:09:32 <tjandrews> It won't close/shut down unless I use the reset button.
20:09:37 <wilcal> Scary stuff floating around on this
20:09:56 <DavidWHodgins> From what I've read, this is a hardware problem, that can only be mitigated, not fixed, but is not a panic situation.
20:10:16 <wilcal> I run into that from time to time tj. kinda have been just ignoring it
20:10:29 <tarazed_> tj: so do I
20:10:32 <DavidWHodgins> It's information disclosure, but appears to be extremely limited. I don't think it exposes all of ram, just what's in the cpu
20:10:34 <wilcal> More for cloud servers?
20:10:38 <hviaene|2> No idea what it is???
20:10:40 <Benmc> looks like my lappy is too old to care
20:11:02 <lewyssmith> Often old is better.
20:11:03 <DavidWHodgins> It's a side channel attack
20:11:04 <tmb> The reason for wanting to push 4.14.10 series kernels before we head on the PTI kernels is that I want a "known good 4.14 series kernel" out there to fall back on for users if needed
20:11:17 <wilcal> allows Virtual clients to closs boundries or even become root
20:11:26 <tarazed_> @herman; the Register has the story - I'll send a link
20:11:43 <DavidWHodgins> One program running in one thread on the cpu can potentially get read access to things leftover in the cpu by another thread
20:11:54 <tmb> AMD and Arm hw seens safer so far :)
20:12:05 <hviaene|2> I know the Registry - BOFH
20:12:16 <wilcal> only Intel platforms
20:12:24 <lewyssmith> I always seek AMD.
20:12:26 <tarazed_> Thsi affects Intel hardware for the last 10 years apparently.
20:12:35 <tmb> wilcal, mostly Intel...
20:12:38 <DavidWHodgins> What makes it scary is that it can only be mitigated by software updates, not fixed.
20:12:50 <wilcal> Fix will cost about 5% of performance
20:13:08 <DavidWHodgins> If there ever is a real usable exploit, that will be a problem.
20:13:13 <DavidWHodgins> For now, there isn't
20:13:16 <tarazed_> Up to 30%
20:13:27 <Benmc> depends on task
20:13:28 <DavidWHodgins> Only on some workloads
20:13:32 <tmb> wilcal, or more... postgresql takes up to 30% performance hit
20:13:35 <lewyssmith> And if you do not use VMs?
20:13:48 <DavidWHodgins> Mostly database access and similar types of work
20:14:11 <lewyssmith> You would need a rougue program running to exploit it.
20:14:18 <tmb> lewyssmith, apps can use the same attack vector to read passwords from other apps
20:14:42 <lewyssmith> See above.
20:14:47 <wilcal> Something about sharing "tables" RAM space can be compromised
20:14:49 <DavidWHodgins> It affects all systems, not just those in a vm. Being in a vm on the cloud just means other users could get info
20:15:25 <DavidWHodgins> lewyssmith: But, every web browser effectively is running untrusted code
20:15:42 <tmb> yeah, Amazon, Google & Microsoft are patching the clouud infra as fast as they can and reboot everything :)
20:15:47 <wilcal> You think this will force us to go back again to M5 to update it's kernel
20:16:15 <DavidWHodgins> Not unless there is an exploit in the wild, very soon.
20:16:25 <DavidWHodgins> tmb: Agreed?
20:16:39 <Benmc> may have no choice, as some will not update to 6
20:17:18 <tmb> there is already POC out there showing it works... so I'd expect the exploit to show up fast too :/
20:17:36 <DavidWHodgins> Is the POC public?
20:17:51 <tarazed_> You can see a gif image
20:18:17 <tarazed_> of the codse
20:18:27 <tmb> not yet AFAIk, but official embargo ends on January 9th, so we'll see then
20:18:30 <DavidWHodgins> A screen capture of a debugger running is not the same as a public POC
20:18:41 <tarazed_> OK
20:19:16 <tmb> I can provide a new kernel for mga5, but where would we draw the line ?
20:19:34 <Luigi12> don't we have infra still running 5?
20:19:52 <DavidWHodgins> So let's concentrate on getting Mageia 6 fixed. If it turns out next week that this is easily exploitable, we'll look at updating m5
20:20:01 <DavidWHodgins> Luigi12: Good point!
20:20:10 <Luigi12> so it'll still need to be taken care of
20:20:17 <tmb> kernel needs fixing, then microcode, then XQN/QEMU/Virtualbox, web-browsers, ...
20:20:31 <Luigi12> all of those will have patches for this mess?
20:21:06 <wilcal> All this recent work on M5, then eol, then we have to work it again. :-(
20:21:08 <Luigi12> well I don't imagine our mga5 infrastruture runs xen/qemu/vbox, so forget those
20:21:40 <tarazed_> wilcal: grin and bear it.
20:21:42 <DavidWHodgins> Do they need patching if the kernel on the host has been patched?
20:21:47 <tmb> IIRC Google aready have code in works to protect from javascript exploit, so I assume all other browsers will follow...
20:22:30 <Luigi12> I guess we mga5 users could install Chrome, so probably not much point in fooling with chromium-browser.  cjw tried to update it but didn't get all the way finished.
20:22:34 <Luigi12> Firefox is easy to update though
20:23:07 <tmb> for Mageia Infra, we do use qemu, but since we control both host and vm there is no exploit so far...
20:23:23 <DavidWHodgins> #info We will re-evaluate the possibility of more updates for Mageia 5, once more info is available
20:23:24 <tmb> this is not remote exploitable
20:23:55 <tmb> Yeah, I'm still watching the fallout on lkml and various lists...
20:24:28 <DavidWHodgins> This ties into the next subject ...
20:24:30 <Luigi12> I'm behind, I had to get up and shovel snow all morning, and none of this stuff started coming out until I was heading home from work and I wasn't on the computer last night
20:24:38 <DavidWHodgins> #topic * End of support and updates for Mageia 5 - Thanks everyone!!
20:24:44 <Luigi12> don't kill your mga5 VMs yet
20:24:52 <DavidWHodgins> Just wanted to say a quick thanks to everyone
20:24:57 <Luigi12> we pushed all of the updates assigned to QA and wiped everything from updates_testing we know didn't need pushed
20:25:12 <Luigi12> there are a few things left over (bugfix updates) that might be, just waiting on feedback from the packagers
20:25:21 <Luigi12> two have already said they should be, but they haven't filed bugs yet
20:25:21 <Benmc> (ahem -still running M5 here)
20:25:22 <DavidWHodgins> While we missed the planned Dec. 31st deadline, it wasn't by much.
20:25:37 <Luigi12> we should set a deadline though for assigning bugs to QA or we wipe them, can't wait forever
20:25:55 <Luigi12> note that these things have already been built, just in case it wasn't clear
20:26:17 <DavidWHodgins> My understanding is that submitting builds for m5 is frozen, without sysadmin assistance.
20:26:22 <Luigi12> yes, it is
20:26:53 <tmb> yeah, but I can re-open if decided so... but for now lets keep it locked
20:26:57 <Luigi12> that's why I'm talking about things already in updates_testing that were already built, just the packagers forgot to follow through
20:27:28 <DavidWHodgins> They are done, in my opinion. If they were not already assigned to qa, they are gone.
20:27:34 <Luigi12> anyway, I'm thinking of a deadline next week for those things already there
20:27:41 <Luigi12> packagers are forgetful sometimes
20:27:47 <tmb> otoh for stuff already built... if it wasn't important enough to assign to QA it cant be that important
20:27:48 <Luigi12> and like I said, two have already said they should be pushed
20:27:52 <Luigi12> the others don't look that important
20:28:22 <DavidWHodgins> We may as well hold off until we see what's happening with the kernel, etc. Once that's sorted, wipe the testing repos.
20:28:50 <Luigi12> how about Wednesday as the deadline to figure out what to do with the remaining packages in updates_Testing?
20:28:51 <DavidWHodgins> Which two Luigi12
20:29:00 <Luigi12> youri-check and cyrus-imapd
20:29:28 <Luigi12> BTW mdds, libixion, liborcus, libwps, lxde-common can be wiped
20:29:43 <Luigi12> DavidWHodgins: what about mga-advisories?  Shouldn't that have been pushed?
20:30:10 <tmb> the problem with the PTI stuff is that it's a "fast backport" to older stable kernels... so the risk for turning an security issue into a DOS when nothing boots is quite high...
20:30:26 <Luigi12> so the only ones I was waiting for a response from the packagers on was perl-YAML (neoclust) and mageia-doc (David Geiger)
20:31:45 <Luigi12> and I was waiting for Giuseppe Ghibo to make a bug for cyrus-imapd and Pascal to make a bug for youri-check (or maybe we can just push that one since it's infra stuff anyway)
20:31:54 <tmb> well, youri fix is already installed built for infra, and not many others use it, so not that important... and mga-advisories on infra also working as intended for now
20:32:14 <Luigi12> tmb: ok, do what you see fit with those two then
20:35:14 <tmb> yeah, I think I'll wipe them with the rest in a ~week
20:35:29 <DavidWHodgins> Sorry, Laptop overheated
20:35:29 <Luigi12> sounds good
20:35:43 <DavidWHodgins> Luigi12: what about the advisories?
20:35:56 <Luigi12> DavidWHodgins: for what?
20:36:14 <DavidWHodgins> pushing advisories?
20:36:27 <Luigi12> not following
20:36:40 <DavidWHodgins> [3:29:43 PM EST]<Luigi12> DavidWHodgins: what about mga-advisories?  Shouldn't that have been pushed?
20:36:59 <Luigi12> do you want that one pushed to core/updates ?
20:37:23 <DavidWHodgins> Doesn't really matter. It's only used by qa people who already have the update installed
20:37:51 <Luigi12> guess we're OK then
20:38:15 <DavidWHodgins> #topic * Testing updates - Any other difficulties, problems, issues?
20:38:33 <DavidWHodgins> As before, I'll concentrate on the kernels tonight
20:38:53 <tmb> note, https://bugs.mageia.org/show_bug.cgi?id=22256 is the only blocker left for 4.14 series kernels
20:38:55 <[mbot> [ 22256 – Updaate request: nvidia-current fix for 4.14.9-rc1+ ]
20:39:04 <DavidWHodgins> We don't have a lot of other updates. Let's try and keep the list small. :-)
20:39:25 <DavidWHodgins> That's one I can't help with testing, as I don't have any nvidia hardware
20:39:43 <Luigi12> openafs needs to be pushed for 4.14 kernel too
20:39:53 <tjandrews> Mine doesn't use nvidia-current.
20:40:00 <hviaene|2> Same here, used to have two machines, nut all gone in the past months
20:40:12 <tarazed_> All my machines are nvidia, 7 of them
20:40:18 <hviaene|2> nut=but
20:40:20 <lewyssmith> I sent a post about the nVidia thing, I think.
20:40:31 <tarazed_> you did
20:40:36 <DavidWHodgins> tarazed_: Any that use the current?
20:40:38 <tmb> I dont think it needs more testing, it's the same driver as currently in updates, its basically a rebuild for a missing include, so the fix is not arch dependent
20:40:38 <wilcal> I have no more 32-bit platforms. All went to the recyclier for my move
20:40:49 <tarazed_> Yes.
20:40:56 <tarazed_> I'll test it.
20:41:05 <DavidWHodgins> wilcal: Note that you don't need 32 bit hardware to test. Just a 32 bit install.
20:41:33 <lewyssmith> Easy on an MBR box; less so on EFI.
20:42:08 <DavidWHodgins> Don't the i586 iso images work on an efi box?
20:42:24 <lewyssmith> I posted the procedure at the time, but it was fiddly.
20:42:26 <wilcal> Kinda struggled with 32-bit installs on 64-bit platforms here
20:42:33 <tmb> if you have csm enabled, yes
20:42:49 <wilcal> Vbox stuff is ok
20:43:03 <lewyssmith> But not for nVidia!
20:43:08 <tmb> but depending on efi implemantation it can fight you hard
20:43:18 <lewyssmith> Not worth the hassle.
20:43:24 <wilcal> Ya that one in particular does not 32-bit installs here
20:43:33 <wilcal> does not like
20:44:09 <DavidWHodgins> My efi system defaults to booting in bios compatibility mode. Have to override it every boot to get it to boot in efi mode
20:44:55 <lewyssmith> That is your decision. EFI =EFI; why fight it?
20:45:11 <Benmc> mine is exactly the opposite Dave
20:45:16 <tmb> at work we have a hp laptop that only boots in efi mode regardless of what you set in bios :)
20:45:28 <DavidWHodgins> Ouch
20:46:01 <lewyssmith> Lucky it does not insist on booting Windows.
20:46:12 <tmb> so "bios mode" is slowly dying out :)
20:46:26 <DavidWHodgins> If we can't find anyone who can test nvidia in a 32 bit install, we'll have to approve it simply based on it installing cleanly over the prior version.
20:46:29 <lewyssmith> Live in hope; it is ytaking its time.
20:47:14 <DavidWHodgins> Any other questions on the updates before we move on?
20:47:32 <wilcal> not from me
20:47:36 <DavidWHodgins> #topic * Anything else?
20:47:37 <Luigi12> I have 3 things
20:47:54 <tjandrews> Uh-oh.
20:48:12 <tarazed_> I have one, OT
20:48:15 <Luigi12> if someone sets a feedback tag on a bug and the packager provides feedback and/or a fix, the feedback tag needs to be removed.  I found a few bugs that had had the feedback tag stuck on them for months after the packager had responded.
20:48:20 <hviaene|2> Then it is my turn with just one
20:48:50 <lewyssmith> Luigi12, David, the packager can remove it.
20:49:01 <Luigi12> lewyssmith: the packagers don't all know to do that
20:49:06 <DavidWHodgins> Ouch! I try to review the ones with the feedback marker periodically. Guess I missed that/those.
20:49:11 <Luigi12> so the QA team needs to be on the lookout for that
20:49:31 <lewyssmith> Normally whoever sets feedback will get the repsonse as an e-mail.
20:49:45 <Luigi12> a lot of testing recently seems to have concentrated on packaging the invididual package in a vaccum, and it seems like an awful lot of effort was expended in figuring out how to test them.  It would have been easier in most of those cases to see what other packages require/use them and test through those.  In fact, often that's better as it makes sure the update doesn't break the things that depend on it.
20:49:47 <DavidWHodgins> I'll keep a closer eye for that in future.
20:50:06 <Luigi12> For instance when testing a library, just testing the tools shipped with that library is insufficient, as there could still be ABI breakage
20:50:23 <Luigi12> so don't forget to check what requires the update and try to test through those, a lot of times that'll end up being easier anyway
20:50:51 <Luigi12> lewyssmith: yes, so they need to make sure to remove the tag then if the packager didn't.  Otherwise we need to check those.
20:50:54 <DavidWHodgins> #info Everyone please use "urpmq --whatrequires $package" to see what it's used by, when testing.
20:50:59 <lewyssmith> We are often not sure that a high level application actually uses the library in question.
20:51:17 <Luigi12> The reason I made a point of bringing up the feedback thing is the QA members usually ignore the bugs that are grayed out, so those things can slip through the cracks
20:51:27 <DavidWHodgins> lewyssmith: If needed, run the application under strace to ensure it's calling the library
20:51:37 <Luigi12> strace or ldd can confirm it
20:51:46 <lewyssmith> I do.
20:52:29 <DavidWHodgins> Point taken on the feeback marker. I'll watch more closely in future.
20:52:47 <Luigi12> finally, I mentioned this on the qa-discuss list but nobody said anything about it.  I think it's time we can officially stop requring tests on both arches to validate most things (other than things like kernel/vbox and any bugs where the issue being fixed is explicitily arch-dependent).  Any thoughts?
20:53:14 <DavidWHodgins> Agreed
20:53:17 <lewyssmith> We are validating most things on one architecture only now.
20:53:34 <wilcal> Agreed
20:53:42 <lewyssmith> That has been sort of policy for ages.
20:53:46 <tjandrews> Sounds OK to me.
20:53:55 <Luigi12> well we've gone back and forth on it depending on how busy we are in QA
20:54:00 <tarazed_> Yes I guess so
20:54:01 <Luigi12> I'm just proposing we make it official going forward
20:54:05 <hviaene|2> That would mean i can scrap my 32 slow laptop. Good!!
20:54:13 <lewyssmith> Excepting special things.
20:54:17 <Luigi12> right
20:54:18 <DavidWHodgins> I still prefer testing on both arches, except when there's a backlog, but I'm open to alowing that more often
20:54:19 <Benmc> it may pay to advise the community that QA is concentrating efforts on 64, but that 32 is still supported
20:54:37 <DavidWHodgins> hviaene|2: Still need if for kernel, vb, qemu, etc. testing.
20:54:46 <hviaene|2> ####
20:54:52 <lewyssmith> I think that should be Magei policy.
20:54:56 <hviaene|2> nasty words
20:55:01 <DavidWHodgins> Mostly kernel.
20:55:25 <DavidWHodgins> I think we can forget about running qemu etc. on a 32 bit system.
20:55:38 <hviaene|2> vb and qemu are out of the question on this laptop
20:55:41 <lewyssmith> Even VBox, we have long agreed.
20:55:50 <DavidWHodgins> Yes. Just the kernels
20:55:59 <tmb> and hw drivers
20:56:03 <Luigi12> vbox works fine on 32-bit hosts, but probably not 32-bit-only-hardware
20:56:11 <lewyssmith> We have said all this often before.
20:56:22 <tjandrews> Vbox is even worthless on some 64-bit boxes.
20:56:33 <Luigi12> lewyssmith: and we're discussing it again because we have yet to take an official permanent position on it
20:56:53 <Luigi12> tjandrews: yes if you don't have much RAM
20:57:00 <DavidWHodgins> That said, if someone does choose to test on both arches, there's no harm in doing so. We won't hold off validating though if tested only on 64 bit.
20:57:14 <lewyssmith> Luigi12,  Yes, it has been 'unofficial'.
20:57:17 <Luigi12> right, not trying to discourage the extra testing
20:57:47 <Luigi12> but, for instance, I'd rather QA find two different methods to test a package than find two different arches to test it on.  That would be more productive.
20:57:55 <Luigi12> so, just trying to make the best use of our resources
20:58:09 <DavidWHodgins> #info Except for the kernels and related hw drivers, ok to validate updates with just 64 bit testing
20:58:09 <tarazed_> Amen to that
20:58:16 <hviaene|2> Can an indication be given if 32-bit testing is needed
20:58:28 <lewyssmith> DavidWHodgins, Or just 32.
20:58:34 <Luigi12> hviaene|2: usually for security bugs if you read the CVE blurbs it will say if it only affects 32-bit
20:58:50 <Luigi12> I'll try to remember to point it out if I see that
20:58:58 <hviaene|2> Tx
20:59:26 <DavidWHodgins> If the text in the bug report doesn't mention a poc, I don't usually bother reading the details of each cve
20:59:32 <Luigi12> ok thanks that's all I had
20:59:39 <Luigi12> DavidWHodgins: I fear most users don't read them either :o)
20:59:39 <DavidWHodgins> Thanks Luigi12
20:59:52 <tarazed_> Herman?
21:00:38 <hviaene|2> Both on slow and fast laptop, having access to NFS shares
21:00:54 <hviaene|2> The shares are never mounted after boot
21:01:13 <tarazed_> Is fstab updated at any point?
21:01:25 <hviaene|2> Reason: boot log says "desktop name" cannot be resolved
21:01:43 <Luigi12> so the NFS mounts are trying to start too early
21:01:44 <hviaene|2> fstab has been updated allright
21:02:00 <hviaene|2> That's my guess as well
21:02:01 <Luigi12> that's been a common problem with NFS + systemd
21:02:06 <DavidWHodgins> So using dns name in fstab rather than ip address
21:02:21 <hviaene|2> yes
21:02:22 <tarazed_> Mine usually work but sometimes they have to be mounted later
21:02:32 <DavidWHodgins> Is the name in /etc/hosts?
21:02:38 <Luigi12> I've run into this on RHEL too at work
21:03:10 <DavidWHodgins> Or does it require name server lookups?
21:03:13 <hviaene|2> I did not see that in M5, but I did not check after avery reboot
21:03:24 <hviaene|2> Now I do
21:03:30 <lewyssmith> NFS is so mature that to have such a problem seems crazy to me. Is it down to systemd?
21:03:53 <hviaene|2> Yes, my desktop is my internal DNS server that also shares oout
21:03:58 <Luigi12> it's the systemd unit files for the NFS services
21:04:11 <Luigi12> they've been redone multiple times and the developers still have never gotten them quite right
21:05:01 <hviaene|2> So, is it worth filing a bug?
21:05:01 <Luigi12> I had to fix multiple issues in them myself on our NFS server at work, otherwise it wouldn't work right
21:05:21 <Luigi12> hviaene|2: sure
21:05:21 <tarazed_> Yes, I have had some really strange problems when moving base directories to another machine and trying to set up the system again.
21:05:26 <DavidWHodgins> On my systems I use sshfs, started by user login scripts, so haven't seen this. I only use nfs or samba, when testing, and that under vb.
21:05:29 <tmb> maybe it will start working again now that we slow everything down with kpti :)
21:05:36 <DavidWHodgins> lol
21:05:41 <Luigi12> could be
21:05:46 <Luigi12> it is a race condition right now
21:06:16 <DavidWHodgins> So slowing things down may either fix the problem, or make it worse, so easier to find and fix.
21:06:48 <Luigi12> services used for mounting the shares need to have After=nss-lookup.target, that's the most obvious thing for DNS issues
21:07:22 <DavidWHodgins> Ouch. The ancient laptop I'm running konversation on is up to 59C. WIll likely be force off again soon.
21:08:07 <tmb> DavidWHodgins, install a lighter DE :)
21:08:25 <Luigi12> or maybe kpti will make it run cooler
21:08:26 <Benmc> Dave: are you cypomining in the background?
21:08:37 <DavidWHodgins> I'm running m6 xfce on it now.
21:08:38 <Luigi12> Benmc: maybe his browser is :D
21:08:39 <wilcal> ii run psensor do you the same david
21:08:55 <DavidWHodgins> I have gkrellm running
21:09:07 <lewyssmith> tarazed_, Your question, Len?
21:09:14 <DavidWHodgins> I'll have to check the bios settings to see if I can slow it down
21:09:20 <wilcal> this old Dell 64-bit lappy does nicely with M6
21:09:45 <DavidWHodgins> It only has 1GB of ram
21:10:29 <wilcal> I've got 4GB DRAM on this one
21:10:34 <DavidWHodgins> tarazed_: Your OT question?
21:11:04 <tarazed_> Right.  This is a bit OT.  have spent the day trying to get Cauldron to boot to a graphics screen after an upgrade from mga6.  nvidia again.  It refuses to accommodate any X driver, not vesa, nouveau, modesetting or nvidia.
21:11:30 <tarazed_> Yet the Cauldron on this machine works fine.
21:11:38 <DavidWHodgins> Tried with and without the nokmsboot option?
21:12:30 <DavidWHodgins> With my upgrade switching from fglrx to ati I had to remove the nokmsboot kernel option.
21:12:43 <tarazed_> Yes, have tried everything.  Removing dkms-nvidia  n runlevel 3 and reinstalling it.  At one point the test came out positive so the driver is OK.
21:13:25 <Benmc> same or later kernel?
21:13:33 <tarazed_> The first time vesa has ever failed.
21:13:37 <DavidWHodgins> cauldron has a later kernel
21:14:02 <hviaene|2> Have to go, g'night all
21:14:12 <lewyssmith> Goodbye Herman.
21:14:13 <DavidWHodgins> Good night Herman
21:14:14 <tarazed_> ben: not sure but I think it was the same one.
21:14:27 <tarazed_> Bye Herman
21:15:02 <tmb> tarazed_, did you try 4.14 series kernel under mga6 on the failing system ?
21:15:47 <tarazed_> So, I'll check that.  What about missing packages.  Could ldtect-lst or its absence have anything to do with it.
21:15:54 <Benmc> I have had some similar issues with my Compaq (intel graphics), boots to a black screen, no greeter to login. seems to be a DM issue with the kernel
21:16:51 <DavidWHodgins> Please keep details of what cmdline and driver is used and put the info in bug reports.
21:16:55 <tmb> there is also an x11-server issue with atleast some intel hw
21:17:26 <tarazed_> tmb: I have done, but I am a bit hazy now about what mga6 was running.  I think it was 4.9.56
21:17:52 <DavidWHodgins> It's better to file a bug report that turns out to be not needed, then not to file one, and have updates released that cause problems
21:18:00 <tmb> marja have one system that fails with the new 1.19.6 x11-server
21:18:32 <tarazed_> OK.  More research needed.  Maybe a bug report.  Let's leaVE IT THERE.
21:18:36 <tarazed_> tHANKS.
21:19:12 <lewyssmith> And thanks to the big guns for showing up. It helps.
21:19:18 <DavidWHodgins> Ok. Looks like countdown time then
21:19:23 <wilcal> Bye all
21:19:24 <DavidWHodgins> t - 5
21:19:26 <DavidWHodgins> 4
21:19:27 <lewyssmith> Goodbye everyone.
21:19:29 <DavidWHodgins> 3
21:19:32 <DavidWHodgins> 2
21:19:35 <tarazed_> Goodnight all
21:19:36 <DavidWHodgins> 1
21:19:42 <DavidWHodgins> Thanks for coming everyone!
21:19:48 <DavidWHodgins> #endmeeting