Version-Release number of selected component:<br />
kernel<br />
<br />
Truncated backtrace:<br />
WARNING: CPU: 5 PID: 7 at drivers/thunderbolt/nhi.c:108 ring_interrupt_active+0x23b/0x280 [thunderbolt]<br />
Modules linked in: tcp_lp fuse thunderbolt xt_CHECKSUM tun xt_MASQUERADE nf_conntrack_netlink xt_addrtype overlay ccm ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_nat iptable_mangle iptable_security iptable_raw nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c rmi_smbus rmi_core ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter bnep sunrpc dm_mirror dm_region_hash dm_log dm_mod intel_pmc_core_pltdrv intel_pmc_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm iTCO_wdt irqbypass iTCO_vendor_support mei_wdt crct10dif_pclmul wmi_bmof crc32_pclmul intel_wmi_thunderbolt snd_hda_codec_hdmi ghash_clmulni_intel snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi snd_hda_codec_realtek vfat snd_hda_codec_generic fat snd_soc_core<br />
snd_compress snd_pcm_dmaengine ac97_bus snd_hda_intel snd_intel_nhlt aesni_intel crypto_simd snd_hda_codec cryptd glue_helper btusb snd_usb_audio snd_hda_core iwlmvm intel_cstate btrtl snd_usbmidi_lib cdc_ether btbcm usbnet snd_rawmidi snd_hwdep intel_rapl_perf btintel snd_seq r8152 mii pcspkr snd_seq_device joydev input_leds i2c_i801 mac80211 bluetooth libarc4 snd_pcm uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev snd_timer ecdh_generic sg iwlwifi ecc hid_logitech_hidpp mc mei_me cfg80211 mei intel_pch_thermal processor_thermal_device intel_soc_dts_iosf wmi thinkpad_acpi ledtrig_audio snd soundcore int3403_thermal rfkill int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad sch_fq_codel ip_tables ext4 mbcache jbd2 hid_logitech_dj sd_mod uas usb_storage i915 crc32c_intel serio_raw i2c_algo_bit e1000e cec ptp rc_core pps_core drm_kms_helper syscopyarea nvme sysfillrect sysimgblt fb_sys_fops nvme_core drm video i2c_hid<br />
CPU: 5 PID: 7 Comm: kworker/u16:0 Not tainted 5.4.14-1.el7.elrepo.x86_64 #1<br />
Hardware name: LENOVO 20KH002RUS/20KH002RUS, BIOS N23ET69W (1.44 ) 11/25/2019<br />
Workqueue: kacpi_hotplug acpi_hotplug_work_fn<br />
RIP: 0010:ring_interrupt_active+0x23b/0x280 [thunderbolt]<br />
Code: 55 c8 44 89 45 d4 e8 54 96 85 e0 44 8b 45 d4 48 8b 55 c8 48 89 c6 4d 89 f1 4c 89 e1 48 c7 c7 b0 47 d7 a0 31 c0 e8 95 4b 33 e0 <0f> 0b e9 d0 fe ff ff f7 d3 21 c3 e9 b9 fe ff ff 41 0f b6 57 78 d3<br />
RSP: 0018:ffffc900000bfb20 EFLAGS: 00010082<br />
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006<br />
RDX: 0000000000000000 RSI: 0000000000000092 RDI: ffff888491557940<br />
RBP: ffffc900000bfb68 R08: 000000000000048b R09: 000000000000048b<br />
R10: 0000000000000058 R11: ffffffff826fe104 R12: ffffffffa0d73c5c<br />
R13: 0000000000038200 R14: ffffffffa0d73c4b R15: ffff88848edf66c0<br />
FS: 0000000000000000(0000) GS:ffff888491540000(0000) knlGS:0000000000000000<br />
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br />
CR2: 00007f7960002d80 CR3: 000000048bdb2005 CR4: 00000000003606e0<br />
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br />
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br />
Call Trace:<br />
tb_ring_stop+0x127/0x180 [thunderbolt]<br />
tb_ctl_stop+0x3c/0xe0 [thunderbolt]<br />
tb_domain_remove+0x42/0x70 [thunderbolt]<br />
nhi_remove+0x4b/0x60 [thunderbolt]<br />
pci_device_remove+0x3e/0xd0<br />
device_release_driver_internal+0xf3/0x1c0<br />
device_release_driver+0x12/0x20<br />
pci_stop_bus_device+0x63/0x90<br />
pci_stop_and_remove_bus_device+0x12/0x20<br />
trim_stale_devices+0x155/0x190<br />
trim_stale_devices+0xaf/0x190<br />
trim_stale_devices+0xaf/0x190<br />
? get_slot_status+0xa2/0x100<br />
acpiphp_check_bridge.part.12+0xe4/0x130<br />
acpiphp_hotplug_notify+0x178/0x1d0<br />
? acpiphp_post_dock_fixup+0xd0/0xd0<br />
acpi_device_hotplug+0x9f/0x4d0<br />
acpi_hotplug_work_fn+0x1e/0x30<br />
process_one_work+0x179/0x390<br />
worker_thread+0x4f/0x3e0<br />
kthread+0x105/0x140<br />
? max_active_store+0x80/0x80<br />
? kthread_bind+0x20/0x20<br />
ret_from_fork+0x35/0x40
↧
0017043: [abrt] kernel-ml: WARNING: CPU: 5 PID: 7 at drivers/thunderbolt/nhi.c:108 ring_interrupt_active+0x23b/0x280 [thunderbolt]
↧
0017294: http://vault.centos.org/7.7.1908/os/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
I'm trying to Update my centos7 OS but I'm getting the following failure message:<br />
<br />
Stdout from the command:<br />
Loaded plugins: fastestmirror<br />
<br />
<br />
Stderr from the command:<br />
<a href="http://vault.centos.org/7.7.1908/os/x86_64/repodata/repomd.xml:">http://vault.centos.org/7.7.1908/os/x86_64/repodata/repomd.xml:</a> [Errno 14] HTTP Error 404 - Not Found<br />
Trying other mirror.<br />
To address this issue please refer to the below knowledge base article<br />
<br />
<a href="https://access.redhat.com/articles/1320623">https://access.redhat.com/articles/1320623</a><br />
<br />
If above article doesn't help to resolve this issue please create a bug on <a href="https://bugs.centos.org/">https://bugs.centos.org/</a><br />
<br />
One of the configured repositories failed (CentOS-7.7.1908 - Base),<br />
and yum doesn't have enough cached data to continue. At this point the only<br />
safe thing yum can do is fail. There are a few ways to work "fix" this:<br />
<br />
1. Contact the upstream for the repository and get them to fix the problem.<br />
<br />
2. Reconfigure the baseurl/etc. for the repository, to point to a working<br />
upstream. This is most often useful if you are using a newer<br />
distribution release than is supported by the repository (and the<br />
packages for the previous distribution release still work).<br />
<br />
3. Disable the repository, so yum won't use it by default. Yum will then<br />
just ignore the repository until you permanently enable it again or use<br />
--enablerepo for temporary usage:<br />
<br />
yum-config-manager --disable C7.7.1908-base<br />
<br />
4. Configure the failing repository to be skipped, if it is unavailable.<br />
Note that yum will try to contact the repo. when it runs most commands,<br />
so will have to try and fail each time (and thus. yum will be be much<br />
slower). If it is a very temporary problem though, this is often a nice<br />
compromise:<br />
<br />
yum-config-manager --save --setopt=C7.7.1908-base.skip_if_unavailable=true<br />
<br />
failure: repodata/repomd.xml from C7.7.1908-base: [Errno 256] No more mirrors to try.<br />
<a href="http://vault.centos.org/7.7.1908/os/x86_64/repodata/repomd.xml:">http://vault.centos.org/7.7.1908/os/x86_64/repodata/repomd.xml:</a> [Errno 14] HTTP Error 404 - Not Found
↧
↧
0017296: sssd_be keeps crashing
● sssd.service - System Security Services Daemon<br />
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)<br />
Active: failed (Result: exit-code) since Mon 2020-04-27 12:34:35 EDT; 16h ago<br />
Process: 1245 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=1/FAILURE)<br />
Main PID: 1245 (code=exited, status=1/FAILURE)<br />
<br />
Apr 27 12:34:05 localhost.localdomain sssd[be[LDAPGADM]][6397]: Starting up<br />
Apr 27 12:34:35 localhost.localdomain sssd[1245]: Exiting the SSSD. Could not restart critical service [LDAPGADM].<br />
Apr 27 12:34:35 localhost.localdomain sssd[sudo][1271]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[ssh][1270]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[pam][1269]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[nss][1268]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[be[LDAPOPS]][1259]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[be[implicit_files]][1257]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain systemd[1]: sssd.service: Main process exited, code=exited, status=1/FAILURE<br />
Apr 27 12:34:35 localhost.localdomain systemd[1]: sssd.service: Failed with result 'exit-code'.
↧
0017295: sssd_be keeps crashing
● sssd.service - System Security Services Daemon<br />
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)<br />
Active: failed (Result: exit-code) since Mon 2020-04-27 12:34:35 EDT; 16h ago<br />
Process: 1245 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=1/FAILURE)<br />
Main PID: 1245 (code=exited, status=1/FAILURE)<br />
<br />
Apr 27 12:34:05 localhost.localdomain sssd[be[LDAPGADM]][6397]: Starting up<br />
Apr 27 12:34:35 localhost.localdomain sssd[1245]: Exiting the SSSD. Could not restart critical service [LDAPGADM].<br />
Apr 27 12:34:35 localhost.localdomain sssd[sudo][1271]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[ssh][1270]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[pam][1269]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[nss][1268]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[be[LDAPOPS]][1259]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain sssd[be[implicit_files]][1257]: Shutting down<br />
Apr 27 12:34:35 localhost.localdomain systemd[1]: sssd.service: Main process exited, code=exited, status=1/FAILURE<br />
Apr 27 12:34:35 localhost.localdomain systemd[1]: sssd.service: Failed with result 'exit-code'.
↧
0017297: Conflict exists between AppSteam and HighAvailability module.
Hi, Conflict exists between AppSteam and HighAvailability module:<br />
<br />
$ dnf update <br />
Last metadata expiration check: 1:28:59 ago on Tue 28 Apr 2020 09:56:07 BST.<br />
Error: <br />
Problem: package corosync-3.0.2-3.el8_1.1.x86_64 requires corosynclib(x86-64) = 3.0.2-3.el8_1.1, but none of the providers can be installed<br />
- cannot install both corosynclib-3.0.3-2.el8.x86_64 and corosynclib-3.0.2-3.el8_1.1.x86_64<br />
- cannot install the best update candidate for package corosynclib-3.0.2-3.el8_1.1.x86_64<br />
- cannot install the best update candidate for package corosync-3.0.2-3.el8_1.1.x86_64<br />
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)<br />
<br />
$ dnf list --showduplicates corosynclib<br />
Last metadata expiration check: 1:29:15 ago on Tue 28 Apr 2020 09:56:07 BST.<br />
Installed Packages<br />
corosynclib.x86_64 3.0.2-3.el8_1.1 @AppStream <br />
Available Packages<br />
corosynclib.i686 3.0.2-3.el8 AppStream <br />
corosynclib.i686 3.0.2-3.el8 Stream-AppStream<br />
corosynclib.x86_64 3.0.2-3.el8 AppStream <br />
corosynclib.x86_64 3.0.2-3.el8 Stream-AppStream<br />
corosynclib.i686 3.0.2-3.el8_1.1 AppStream <br />
corosynclib.i686 3.0.2-3.el8_1.1 HighAvailability<br />
corosynclib.i686 3.0.2-3.el8_1.1 Stream-AppStream<br />
corosynclib.x86_64 3.0.2-3.el8_1.1 AppStream <br />
corosynclib.x86_64 3.0.2-3.el8_1.1 Stream-AppStream<br />
corosynclib.i686 3.0.3-2.el8 Stream-AppStream<br />
corosynclib.x86_64 3.0.3-2.el8 Stream-AppStream
↧
↧
0017298: [abrt] python2-dnf: cli.py:137:print_versions:UnicodeDecodeError: 'ascii' codec can't decode byte 0xeb in position 4: ...
Description of problem:<br />
When I run "dnf-2 --version", this issue occurred.<br />
<br />
Version-Release number of selected component:<br />
python2-dnf-4.0.9.2-1.el7_6<br />
<br />
Truncated backtrace:<br />
cli.py:137:print_versions:UnicodeDecodeError: 'ascii' codec can't decode byte 0xeb in position 4: ordinal not in range(128)<br />
<br />
Traceback (most recent call last):<br />
File "/usr/bin/dnf-2", line 58, in <module><br />
main.user_main(sys.argv[1:], exit_code=True)<br />
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 179, in user_main<br />
errcode = main(args)<br />
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 64, in main<br />
return _main(base, args, cli_class, option_parser_class)<br />
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 95, in _main<br />
cli.configure(list(map(ucd, args)), option_parser())<br />
File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 868, in configure<br />
self.base.output)<br />
File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 137, in print_versions<br />
sm_ui_time(pkg.installtime)))<br />
UnicodeDecodeError: 'ascii' codec can't decode byte 0xeb in position 4: ordinal not in range(128)<br />
<br />
Local variables in innermost frame:<br />
ver: u'0:4.11.3-43.el7.x86_64'<br />
name: '\x1b[1mrpm\x1b(B\x1b[m'<br />
sm_ui_time: <function sm_ui_time at 0x7f285daa6a28><br />
base: <dnf.cli.cli.BaseCli object at 0x7f285daac290><br />
done: True<br />
pkg: <hawkey.Package object id 2596, rpm-4.11.3-43.el7.x86_64, @System><br />
output: <dnf.cli.output.Output object at 0x7f285daac3d0><br />
rpmdb_sack: <dnf.sack.Sack object at 0x7f285da8d890><br />
pkgs: <libdnf.module.VectorString; proxy of <Swig Object of type 'std::vector< std::string > *' at 0x7f285da52240> >
↧
0017299: SELinux is preventing /usr/bin/mongod from read access on the file memory.limit_in_bytes.
SELinux is preventing /usr/bin/mongod from read access on the file memory.limit_in_bytes.<br />
This Error prevents mongodb from running. <br />
This is the second time i have fun into this error. <br />
The first time was immediately after a fresh install of CentOS8. <br />
Mongo was installed using "dnf install mongodb-org-4.2.6-1.el8.x86_64" and this error prevented mongo from running at all. In frustration and not being able to find a solution and using the suggested semodule command was not fixing the problem I reformatted and reinstalled CentOS8.<br />
<br />
This second time the error did not happen and i was able to get mongodb running and a test database imported and in use for 2 weeks. <br />
This morning i ran dnf update and now mongodb returns this same error when i try to start the service. <br />
<br />
# systemctl status mongod.service<br />
● mongod.service - MongoDB Database Server<br />
Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; vendor preset: disabled)<br />
Active: failed (Result: exit-code) since Tue 2020-04-28 08:07:00 CST; 11s ago<br />
Docs: <a href="https://docs.mongodb.org/manual">https://docs.mongodb.org/manual</a><br />
Process: 3893 ExecStart=/usr/bin/mongod $OPTIONS (code=exited, status=14)<br />
Process: 3889 ExecStartPre=/usr/bin/chmod 0755 /var/run/mongodb (code=exited, status=0/SUCCESS)<br />
Process: 3888 ExecStartPre=/usr/bin/chown mongod:mongod /var/run/mongodb (code=exited, status=0/SUCCESS)<br />
Process: 3886 ExecStartPre=/usr/bin/mkdir -p /var/run/mongodb (code=exited, status=0/SUCCESS)<br />
<br />
Starting MongoDB Database Server...<br />
about to fork child process, waiting until server is ready for connections.<br />
forked process: 3897<br />
ERROR: child process failed, exited with error number 14<br />
To see additional information in this output, start without the "--fork" option.<br />
mongod.service: Control process exited, code=exited status=14<br />
mongod.service: Failed with result 'exit-code'.<br />
Failed to start MongoDB Database Server.<br />
<br />
<br />
# journalctl -xe<br />
***** Plugin catchall (100. confidence) suggests **************************<br />
<br />
If you believe that mongod should be allowed read access on the memory.limit_in_bytes file by default.<br />
Then you should report this as a bug.<br />
You can generate a local policy module to allow this access.<br />
Do<br />
allow this access for now by executing:<br />
# ausearch -c 'mongod' --raw | audit2allow -M my-mongod<br />
# semodule -X 300 -i my-mongod.pp
↧
0017300: The %autosetup macro mishandles multiple -a arguments
The arguments to the %autosetup macro are supposed to have the same semantics as those to the older %setup macro, with a few exceptions. The -a option is not documented among the exceptions, but %setup accepts and processes multiple -a# options, whereas %autosetup accepts but ignores all but the last.
↧
0017155: perl-IO-Socket-IP-0.39-6.module_el8.1.0+229+cd132df8.noarch.rpm built with older perl (5.24) which causes conflicts.
perl-IO-Socket-IP-0.39-5 is built with perl 5.26, but 0.39-6 is built with 5.24.<br />
<br />
Causes havoc when building ISO images from local repo.
↧
↧
0017156: perl-libnet-3.11-4.module_el8.1.0+229+cd132df8.noarch.rpm built with older perl (5.24) which causes conflicts.
perl-libnet-3.11-3.el8.noarch.rpmis built with perl 5.26, but 3.11-4 is built with 5.24.<br />
<br />
Causes havoc when building ISO images from local repo.
↧
0017157: perl-Thread-Queue-3.13-2.module_el8.1.0+229+cd132df8.noarch.rpm built with older perl (5.24) which causes conflicts.
perl-Thread-Queue-3.13-1.el8.noarch.rpmis built with perl 5.26, but 3.13-2 is built with 5.24.<br />
<br />
Causes havoc when building ISO images from local repo.
↧
0017154: perl-Digest-MD5-2.55-397 built with older perl (5.24) which causes conflicts.
Perl-Digest-MD5-2.55-396 is built with perl 5.26, but 397 is built with 5.24.<br />
<br />
Causes havoc when building ISO images from local repo.
↧
0017301: GNOME crashes several times a day -- clutter_input_device_get_device_type: assertion 'CLUTTER_IS_INPUT_DEVICE (device)' failed
We have a touch screen application running from a "kiosk" user that is well locked down.<br />
<br />
UI runs an angular app in google-chrome in full screen mode.<br />
<br />
Several times throughout the day we are getting crashes across multiple systems. Was hoping that the latest kernel upgrade might fix however it did not.<br />
The following example is what we see in /var/log/messages indicating the event.<br />
<br />
Apr 28 19:21:17 5041-15219-7a2f7243 kernel: perf: interrupt took too long (4984 > 4943), lowering kernel.perf_event_max_sample_rate to 40000<br />
Apr 28 19:21:23 5041-15219-7a2f7243 journal: clutter_input_device_get_device_type: assertion 'CLUTTER_IS_INPUT_DEVICE (device)' failed<br />
Apr 28 19:21:23 5041-15219-7a2f7243 journal: JS ERROR: TypeError: this._trackedWindows.get(...) is <a href="mailto:undefined#012_onWindowActorRemoved@resource">undefined#012_onWindowActorRemoved@resource</a>:///org/gnome/shell/ui/panel.js:841:<a href="mailto:9#012wrapper@resource">9#012wrapper@resource</a>:///org/gnome/gjs/modules/_legacy.js:82:22<br />
Apr 28 19:21:23 5041-15219-7a2f7243 journal: clutter_actor_iter_next: assertion 'ri->age == ri->root->priv->age' failed<br />
Apr 28 19:21:23 5041-15219-7a2f7243 kernel: gnome-shell[27294]: segfault at 244 ip 00007f93cab7d540 sp 00007ffcb1ca1128 error 4 in libmutter-2.so.0.0.0[7f93caac3000+16d000]<br />
Apr 28 19:21:23 5041-15219-7a2f7243 abrt-hook-ccpp: Process 27294 (gnome-shell) of user 1001 killed by SIGSEGV - dumping core<br />
Apr 28 19:21:28 5041-15219-7a2f7243 gnome-session-binary[1908]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11<br />
Apr 28 19:21:28 5041-15219-7a2f7243 gnome-session: gnome-session-binary[1908]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11<br />
Apr 28 19:21:28 5041-15219-7a2f7243 abrtd: Size of '/var/spool/abrt' >= 5000 MB (MaxCrashReportsSize), deleting old directory 'ccpp-2020-04-28-18:31:54-2110'
↧
↧
0016929: ipa-server-trust-ad appears to built with the incorrect samba version
With:<br />
samba-4.10.4-101.el8_1.x86_64<br />
ipa-server-trust-ad-4.8.0-11.module_el8.1.0+253+3b90c921.x86_64<br />
<br />
# pdbedit -s /dev/null -b ipasam -d5<br />
<br />
errors with:<br />
<br />
Attempting to find a passdb backend to match ipasam (ipasam)<br />
No builtin backend found, trying to load plugin<br />
load_module_absolute_path: Probing module '/usr/lib64/samba/pdb/ipasam.so'<br />
Error loading module '/usr/lib64/samba/pdb/ipasam.so': /usr/lib64/samba/pdb/ipasam.so: undefined symbol: DEBUGLEVEL_CLASS<br />
<br />
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1744926">https://bugzilla.redhat.com/show_bug.cgi?id=1744926</a> seems to suggest that it was build with the wrong samba version
↧
0017302: *-azure-common-release tags locked
Hi,<br />
<br />
I seems that for some reason the *-azure-common-release tags I'm using to release packages are now locked [1].<br />
<br />
This wasn't the case with our last release in March. I'm not sure if this is an error or if maybe there has been a some change in the process that I'm not aware of. Is there something I should do to re-enable these tags?<br />
<br />
[1]: <a href="https://cbs.centos.org/koji/taginfo?tagID=1562">https://cbs.centos.org/koji/taginfo?tagID=1562</a> and <a href="https://cbs.centos.org/koji/taginfo?tagID=1558">https://cbs.centos.org/koji/taginfo?tagID=1558</a>
↧
0017303: HDD failes from time to time. Sometimes sdb now it´s sda
Sometimes when my system is doing an mdraid (LVM Raid1 with XFS) test where it is checking the consistency (Sundays) it happens that a hard disk is failing. it happened now the 4th time during the last 6 months.<br />
last time it was sdb. I did an Segate SeaChest long test (over 12h) and the result is that the HDD is perfectly fine.<br />
I also opened an ticket at Supermicro but they can not really help beside RMA which I did when it happened the 1st time, but the issue still exist.<br />
<br />
Does somebody has an Idea what it can be or how to solve?
↧
0017304: HDD failes from time to time. Sometimes sdb now it´s sda
During the last 6 months it happened now 4 times that one of my HDD fails during the MDRAID sync check Sundays (LVM Raid1 with XFS).<br />
I also opened a case at Supermicro but there soulution was a RMA which did not solve the issue.<br />
Last time sdb failed and I did a check with Seagate SeaChest_SMART I executed the long test which took me around 13h and the result was that the HDD is perfectly fine. I did not checked sda as it takes long and sdb failed...<br />
I guess this WE I will have to check sda as well, to be on the sure side.<br />
<br />
Does somebody know what the reason for this issue could be? Kernel, Driver? both is CentOS related as it is impossible that the new MB has an issue with the controller as well.<br />
After an reboot the HDD will work normal and as expected, until it will fail again...
↧
↧
0016504: libsmi-devel and libsmi-debuginfo not available in CentOS 8
The libsmi-debuginfo package is not available from debuginfo.centos.org and the libsmi-devel package is nowhere to be found (except on <a href="https://koji.mbox.centos.org/koji/buildinfo?buildID=1215">https://koji.mbox.centos.org/koji/buildinfo?buildID=1215</a> but it's not downloadable for mortals from there).
↧
0017305: kernel-plus has no megaraid module
Megaraid was supported in RHEL 7, but not in RHEL 8. So no support in kernel-core in CentOS 8.<br />
There could be a driver in the centos-plus kernel, but is not. The directory is empty:<br />
<br />
ls /lib/modules/4.18.0-147.5.1.el8_1.centos.plus.x86_64/kernel/drivers/scsi/megaraid/<br />
<br />
Please rebuild kernel with megaraid modules enabled.<br />
See bugs #0016397 and #0016704 where megaraid is mentioned.
↧
0016196: Tracking for centosplus kernels: CentOS-8
The kernel-plus package for CentOS-8.
↧