Comments

416 Comments
karma

Forgot to click on "generally functional"... It isn't cause it includes a serious regression.

This update has been unpushed.

This update has been unpushed.

Please report bugs / glitches here: https://github.com/megous/megatools/issues So they can be addressed in future releases.

Fixes this bug - which has been going on since 4.17.4 https://bugzilla.redhat.com/show_bug.cgi?id=1598462

Not sure why it isn't showing up below. Considering the number of people who experienced it and the cc: list is now at 49

Works for me

Resolves #1574255. Thanks for the quick response.

Resolves #1574255. Thanks for the quick response.

karma

I re-installed and the problem disappeared - not sure if something went wrong with the dnf process first time around or what - need to trudge through all the logs - but in the meantime changing the feedback.

@lslebodn Ok, I'll file a bug, etc... but will take a bit of time since I'm on travel.

@lslebodn - well I find it difficult to believe that the problems weren't the result of your update. You need to investigate further. Immediately after applying your update I stopped getting a ssh prompt to my remote machine. It would just time out. I had a friend reboot the machine several times to no avail. Immediately after removing your updates: dnf downgrade sssd*; followed by 1 reboot the problem immediately disappeared. That isn't just a coincidence. I'm not in a situation to play around with the remote server. I'm travelling internationally and am dependant on being about to access the remote machine via SSH. Apparently the above testers don't use ssh or sudo.

karma

After applying this update I could no longer login to my system via ssh. Also, I started getting errors with sudo. I've backed out via: dnf downgrade sssd* and things are once again working properly. This change should not be pushed to stable.

karma

Thanks for taking the time to give clamav much needed attention.

Test Case ClamAV

Thanks... that worked... here is what I had previously to the change...

[Unit]
Description = clamd scanner (%i) daemon
After = syslog.target nss-lookup.target network.target

[Service]
Type = simple
ExecStart = /usr/sbin/clamd -c /etc/clamd.d/%i.conf --foreground=yes
Restart = on-failure
PrivateTmp = true

I did some quick reading and understand that foreground and forking are contradictory - but shouldn't we be keeping PrivateTmp?

My clamd@scan.service looks like this: .include /lib/systemd/system/clamd@.service

[Unit] Description = Generic clamav scanner daemon

[Install] WantedBy = multi-user.target

So, I modified clamd@.service to look like this: [Unit] Description = clamd scanner (%i) daemon After = syslog.target nss-lookup.target network.target

[Service] Type = forking ExecStart = binary --daemonize=yes Restart = on-failure

Now I receive the following message:

start clamd@scan.service Failed to start clamd@scan.service: Unit clamd@scan.service is not loaded properly: Exec format error. See system logs and 'systemctl status clamd@scan.service' for details.

systemctl status clamd@scan.service ● clamd@scan.service - clamd scanner (scan) daemon Loaded: error (Reason: Exec format error) Active: failed (Result: exit-code) since Wed 2018-01-17 06:10:01 PST; 12min ago Main PID: 7846 (code=exited, status=0/SUCCESS)

Jan 17 06:10:01 charon systemd[1]: Stopped Generic clamav scanner daemon. Jan 17 06:10:01 charon systemd[1]: clamd@scan.service: Start request repeated too quickly. Jan 17 06:10:01 charon systemd[1]: Failed to start Generic clamav scanner daemon. Jan 17 06:10:01 charon systemd[1]: clamd@scan.service: Unit entered failed state. Jan 17 06:10:01 charon systemd[1]: clamd@scan.service: Failed with result 'exit-code'. Jan 17 06:10:06 charon systemd[1]: /lib/systemd/system/clamd@.service:7: Executable path is not absolute: binary /usr/sbin/clamd -c /etc/clamd.d/%i.conf --daemonize=yes Jan 17 06:10:36 charon systemd[1]: /lib/systemd/system/clamd@.service:7: Executable path is not absolute: binary --daemonize=yes Jan 17 06:18:40 charon systemd[1]: /lib/systemd/system/clamd@.service:7: Executable path is not absolute: binary --daemonize=yes Jan 17 06:20:41 charon systemd[1]: /lib/systemd/system/clamd@.service:7: Executable path is not absolute: binary --daemonize=yes Jan 17 06:21:52 charon systemd[1]: /lib/systemd/system/clamd@.service:7: Executable path is not absolute: binary --daemonize=yes

karma

This update broke my daemon setup. systemd fills my log with: Received 0 file descriptor(s) from systemd.

After backout, ,everything works fine: systemctl status clamd@scan.service ● clamd@scan.service - Generic clamav scanner daemon Loaded: loaded (/usr/lib/systemd/system/clamd@scan.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2018-01-16 07:02:44 PST; 31s ago Main PID: 5701 (clamd) Tasks: 2 (limit: 4915) CGroup: /system.slice/system-clamd.slice/clamd@scan.service └─5701 /usr/sbin/clamd -c /etc/clamd.d/scan.conf --foreground=yes

Jan 16 07:02:54 charon clamd[5701]: Portable Executable support enabled. Jan 16 07:02:54 charon clamd[5701]: ELF support enabled. Jan 16 07:02:54 charon clamd[5701]: Mail files support enabled. Jan 16 07:02:54 charon clamd[5701]: OLE2 support enabled. Jan 16 07:02:54 charon clamd[5701]: PDF support enabled. Jan 16 07:02:54 charon clamd[5701]: SWF support enabled. Jan 16 07:02:54 charon clamd[5701]: HTML support enabled. Jan 16 07:02:54 charon clamd[5701]: XMLDOCS support enabled. Jan 16 07:02:54 charon clamd[5701]: HWP3 support enabled. Jan 16 07:02:54 charon clamd[5701]: Self checking every 600 seconds.

With this applied service never starts - it gets stuck in activating: systemctl status clamd@scan.service ● clamd@scan.service - Generic clamav scanner daemon Loaded: loaded (/usr/lib/systemd/system/clamd@scan.service; enabled; vendor preset: disabled) Active: activating (start) since Tue 2018-01-16 06:55:34 PST; 1min 22s ago Cntrl PID: 5172 (clamd) Tasks: 2 (limit: 4915) CGroup: /system.slice/system-clamd.slice/clamd@scan.service └─5172 /usr/sbin/clamd -c /etc/clamd.d/scan.conf --foreground=yes

Jan 16 06:55:43 charon clamd[5172]: Portable Executable support enabled. Jan 16 06:55:43 charon clamd[5172]: ELF support enabled. Jan 16 06:55:43 charon clamd[5172]: Mail files support enabled. Jan 16 06:55:43 charon clamd[5172]: OLE2 support enabled. Jan 16 06:55:43 charon clamd[5172]: PDF support enabled. Jan 16 06:55:43 charon clamd[5172]: SWF support enabled. Jan 16 06:55:43 charon clamd[5172]: HTML support enabled. Jan 16 06:55:43 charon clamd[5172]: XMLDOCS support enabled. Jan 16 06:55:43 charon clamd[5172]: HWP3 support enabled. Jan 16 06:55:43 charon clamd[5172]: Self checking every 600 seconds.

karma

Installed on two different AMD systems. Didn't notice any differences from previous kernel. Output from the two AMD systems is below.

======================================================================= dmesg | grep Spectre [ 0.015059] Spectre V2 mitigation: Vulnerable: Minimal AMD ASM retpoline

grep spectre /proc/cpuinfo bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2

=========================================================================

dmesg | grep Spectre [ 0.017130] Spectre V2 mitigation: Vulnerable: Minimal AMD ASM retpoline

grep spectre /proc/cpuinfo bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2

karma

Works for me!

BZ#1513641 pyotherside package requires old version of qt5-qtbase