Virtualbox directly from Oracle doesn't build the vboxdrv module. Output from dmesg:
vboxdrv: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
Works for me.. Regression tests pass OK. My occasional freezes/lockups may have also stopped (hopefully) Maybe related to #1513150 but I could never track down the culprit so cannot confirm.
x86_64 work station, Plasma DE, X-server, nVidia card GTX 650 (GK107) /nouveau
@ibims@nucleo@juml So that patch in theory shouldn't matter for Fedora, the problem is the retpoline capable version of gcc used to build kernels was never submitted as an update. They were waiting for gcc 7.3 which is building now. I will also need to wait for 7.3 to finish building or another build root override to do a rebuild. Which wasn't to say that I won't back the patch out (it is reverted upstream, we will follow), just to say that in the meantime, if you wanted to grab the retpoline gcc from koji, that should work as well. Kernel builds take a while.
I end up getting
nvidia: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
wl: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
and get stuck at a black screen. System works fine booting back into 4.14.14-300
This breaks external module loading:
vboxdrv: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
it87: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
nvidia: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
WTF - give a 0 karma - don't you realize that your out-of-tree kernel modules are UNSUPPORTED AT ALL?
if you use them you are supposed to deal with the fallout - what when 4.15 makes it to Fedora and your third-party crap don#t support the neew kernel at all? do you give then also negative karma while smart people seek solutions for problems triggered outside Fedora at their own all the years?
... except the problem isn't with an external module - its with this build being built with a gcc version that does not currently exist in the testing repo. This has nothing to do with the validity of an external module - as such, it is not 'generally functional'.
you really don't understand cause&effect: the root-cause is your out-of-tree kernel-module and it's exactly the same as if it would be a major kernel update: you have to wait until your out-of-tree module is supported correctly - but what you do is by stupidity holding back SECURITY updates for Fedora users
and guess what - i am running VMware workstation built with the GCC from koji
You have the cause & effect wrong. THIS kernel is built with a GCC version currently ONLY available via koji. This breaks the general functionality for a lot of cases. The fixes are: 1) rebuild this with a version of GCC that IS available via normal means, or 2) hold it back until the required dependencies are in place. Its not that hard to grasp.
GOD DAMNED: this kernel update is nothing different than a 4.14 to 4.15 - if vmware workstation don't build i have to ssek on the internet for patches as usual - in that case the source of this patch is for now koji - your out-of-tree-module is NOT RELEVANT for Fedora at all and there is NO SINGLE reason hold anything back as long it don#t break software SHIPPED WITH FEDORA ITSELF
Broken combination of gcc and kernel update, this is in fact an issue here in Fedora, not one with 3rdparty modules itself. As this can break user setups I leave -1 for now but will revert when everything is fine again.
I'm also having an issue with locally built kernel modules not loading. While those modules are not part of Fedora (they are for unique FPGA hardware), my expectation as a user is that I can go kernel module development. I had to download gcc-7.2.1-7 using koji client. But first I wasted time with mjg's COPR providing gcc-7.2.1-7, it failed to install due to broken dependency on libgcc_s.so.1.
Okay, as I said before, I have backed out the module vermagic patch because upstream has done the same, but the real issue is this: This kernel refuses to load your local modules because they are vulnerable. The 301 that is building now will load them, but they will still be vulnerable. The proper solution to all of this is to install the 7.3.1-1 gcc compiler (or 7.2.1-7 if you had that installed).
There is still an interesting question in all of this, when your kernel is build with a retpoline compiler, it shows "Spectre V2 mitigation: Mitigation: Full generic retpoline" . As soon as you load a module built with a non retpoline compiler, that is no longer the case. At least with the vermagic, people knew that something wasn't right. Going forward, you will have no indication.
@jforbes: thx for clarification.
But, if i understand the whole things correct, the following question is now, why is the gcc-7.3.1 not pushed for testing in the repo?
@ibims good question, I know they didn't push 7.2.1-7 because they knew that 7.3.1 was on the way. Not sure why 7.3.1 is built but not pushed. Possibly travel? I know a lot of people are at devconf.cz
Would it be possible to go to gcc 7.2.1-7 first? gcc 7.3.1 forces me to change unit tests involving optional values from BOOST_TEST(optional_value) to BOOST_TEST(static_cast<bool>(optional_value)). I believe some conflict is happening between Boost optional and libstdc++ optional. It's better to follow single responsibility principle and limit security updates to security issues.
This update has been submitted for testing by jforbes.
got it from koji. Works for me.
Virtualbox directly from Oracle doesn't build the vboxdrv module. Output from dmesg: vboxdrv: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
It works with 4.14.14.
Works for me.
wfm: desktop 16GB Intel i7-3770 CPU, laptop 16GB Intel i7-3610QM CPU, laptop 8GB Intel i5-2520M CPU Lenovo T420 - all using the Mate Desktop Environment
(Unlike 4.14.14, this version passed the regression tests, and the laptops didn't take an excessive time to do so!)
Works for me.. Regression tests pass OK. My occasional freezes/lockups may have also stopped (hopefully) Maybe related to #1513150 but I could never track down the culprit so cannot confirm.
x86_64 work station, Plasma DE, X-server, nVidia card GTX 650 (GK107) /nouveau
@ibims on Virtualbox problem: Appears related to recent revert in kernel master https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5132ede0fe8092b043dae09a7cc32b8ae7272baa
This update has been pushed to testing.
@juml thx a lot for this hint.
@jforbes is it possible for you to start a new build with this patch above? Thank you.
wireguard: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
There is a 'used uninitialized' problem with kernel/futex.c which has not been addressed yet AFAIK. See: https://lkml.org/lkml/2018/1/22/295 Fix suggested: https://lkml.org/lkml/2018/1/23/557
works for me
@ibims @nucleo @juml So that patch in theory shouldn't matter for Fedora, the problem is the retpoline capable version of gcc used to build kernels was never submitted as an update. They were waiting for gcc 7.3 which is building now. I will also need to wait for 7.3 to finish building or another build root override to do a rebuild. Which wasn't to say that I won't back the patch out (it is reverted upstream, we will follow), just to say that in the meantime, if you wanted to grab the retpoline gcc from koji, that should work as well. Kernel builds take a while.
I end up getting nvidia: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline ' wl: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
and get stuck at a black screen. System works fine booting back into 4.14.14-300
Boots on T450s, XS35GTv2 and a VM.
This breaks external module loading: vboxdrv: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline ' it87: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline ' nvidia: version magic '4.14.15-300.fc27.x86_64 SMP mod_unload ' should be '4.14.15-300.fc27.x86_64 SMP mod_unload retpoline '
damned - would you guys please stop give negative karma because of 3rd party kernel modules NOT part of Fedora and READ OTHER COMMENTS? here you go: https://koji.fedoraproject.org/koji/buildinfo?buildID=1020649
Yes. Lets give positive karma to what amounts to broken dependencies right now... I read it. I still -'ed it.
Its built with a gcc version not yet even in updates-testing - hence for everyone not going to koji is broken.
Happy to change from negative to positive karma when the rest of the tree lines up.
WTF - give a 0 karma - don't you realize that your out-of-tree kernel modules are UNSUPPORTED AT ALL?
if you use them you are supposed to deal with the fallout - what when 4.15 makes it to Fedora and your third-party crap don#t support the neew kernel at all? do you give then also negative karma while smart people seek solutions for problems triggered outside Fedora at their own all the years?
... except the problem isn't with an external module - its with this build being built with a gcc version that does not currently exist in the testing repo. This has nothing to do with the validity of an external module - as such, it is not 'generally functional'.
you really don't understand cause&effect: the root-cause is your out-of-tree kernel-module and it's exactly the same as if it would be a major kernel update: you have to wait until your out-of-tree module is supported correctly - but what you do is by stupidity holding back SECURITY updates for Fedora users
and guess what - i am running VMware workstation built with the GCC from koji
[harry@srv-rhsoft:~]$ lsmod | grep vm vmw_vmci 81920 0 vmmon 102400 22 vmnet 61440 12
You have the cause & effect wrong. THIS kernel is built with a GCC version currently ONLY available via koji. This breaks the general functionality for a lot of cases. The fixes are: 1) rebuild this with a version of GCC that IS available via normal means, or 2) hold it back until the required dependencies are in place. Its not that hard to grasp.
GOD DAMNED: this kernel update is nothing different than a 4.14 to 4.15 - if vmware workstation don't build i have to ssek on the internet for patches as usual - in that case the source of this patch is for now koji - your out-of-tree-module is NOT RELEVANT for Fedora at all and there is NO SINGLE reason hold anything back as long it don#t break software SHIPPED WITH FEDORA ITSELF
works for me
works
Broken combination of gcc and kernel update, this is in fact an issue here in Fedora, not one with 3rdparty modules itself. As this can break user setups I leave -1 for now but will revert when everything is fine again.
I'm also having an issue with locally built kernel modules not loading. While those modules are not part of Fedora (they are for unique FPGA hardware), my expectation as a user is that I can go kernel module development. I had to download gcc-7.2.1-7 using koji client. But first I wasted time with mjg's COPR providing gcc-7.2.1-7, it failed to install due to broken dependency on libgcc_s.so.1.
Breaks building kernel modules.
Okay, as I said before, I have backed out the module vermagic patch because upstream has done the same, but the real issue is this: This kernel refuses to load your local modules because they are vulnerable. The 301 that is building now will load them, but they will still be vulnerable. The proper solution to all of this is to install the 7.3.1-1 gcc compiler (or 7.2.1-7 if you had that installed). There is still an interesting question in all of this, when your kernel is build with a retpoline compiler, it shows "Spectre V2 mitigation: Mitigation: Full generic retpoline" . As soon as you load a module built with a non retpoline compiler, that is no longer the case. At least with the vermagic, people knew that something wasn't right. Going forward, you will have no indication.
@jforbes: thx for clarification. But, if i understand the whole things correct, the following question is now, why is the gcc-7.3.1 not pushed for testing in the repo?
@ibims good question, I know they didn't push 7.2.1-7 because they knew that 7.3.1 was on the way. Not sure why 7.3.1 is built but not pushed. Possibly travel? I know a lot of people are at devconf.cz
@jforbes that could be possible. We should still wait a little bit?
I don't see any reason to wait, I have had retpoline compilers installed locally for most of the month and haven't had any issues.
Would it be possible to go to gcc 7.2.1-7 first? gcc 7.3.1 forces me to change unit tests involving optional values from BOOST_TEST(optional_value) to BOOST_TEST(static_cast<bool>(optional_value)). I believe some conflict is happening between Boost optional and libstdc++ optional. It's better to follow single responsibility principle and limit security updates to security issues.
7.2.1-7 works fine, it has the retpoline patches and is available in koji. I don't have control of those updates, so no clue how they will be filed.
Works fine, even with nvidia module.
Works fine on Lenovo E560, kernel tests passed
No errors in boot log or dmesg after reboot
This update has been obsoleted by kernel-4.14.15-301.fc27.
No sound via displayport and like you can see i have no choice in menu to select dp/hdmi sound Monitor:dell u3415w gpu driver nouveau
[URL=http://pimpandhost.com/image/80976362][IMG]http://ist4-1.filesor.com/pimpandhost.com/1///_/1/5/t/L/E/5tLEm/Screenshot%20from%202018-01-28%2017-33-20_s.jpg[/IMG][/URL]
http://pimpandhost.com/image/80976362?size=original
karma: -1