openSUSE Users July 2020

users@lists.opensuse.org

67 participants
68 discussions

[opensuse] Fw: [Bug 1128204] retext crashes with core dump

by Dave Howorth

Hmm, I just got this message from Atri, who I've seen looks at this list. I haven't migrated my bugzilla account because I don't want to continue to use the old account name. I just tried to respond and it wants details I cannot supply (I don't know what username/password are - I've never needed them - my browser supposedly knows them but apparently can't reproduce whatever information is required to respond to the 'migration portal') But more fundamentally, I don't use TW. I use Leap and I'm still on 15.0. Begin forwarded message: Date: Sun, 07 Jun 2020 19:16:08 +0000 From: bugzilla_noreply(a)suse.com To: ********* Subject: [Bug 1128204] retext crashes with core dump http://bugzilla.suse.com/show_bug.cgi?id=1128204 http://bugzilla.suse.com/show_bug.cgi?id=1128204#c11 --- Comment #11 from Atri Bhattacharya <badshah400(a)gmail.com> --- Sorry Dave, I missed the train on this one. Can you still reproduce this with the latest TW? -- You are receiving this mail because: You are on the CC list for the bug. You reported the bug. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 weeks, 2 days

[opensuse] Issue with smartd

by Carlos E. R.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have one disk that is giving me problems with the smartd daemon. I get this in the log: <3.6> 2018-10-21T13:45:23.829155+02:00 Isengard smartd 1173 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], state written to /var/lib/smartmontools/smartd.WDC_WD80EZAZ_11TDBA0-2TKST2SD.ata.state <3.6> 2018-10-21T13:45:24.483719+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], opened <3.6> 2018-10-21T13:45:24.484570+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], WDC WD80EZAZ-11TDBA0, S/N:2TKST2SD, WWN:5-000cca-26af51579, FW:83.H0A83, 8.00 TB <3.6> 2018-10-21T13:45:24.503334+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], not found in smartd database. <3.6> 2018-10-21T13:45:24.525071+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], enabled SMART Attribute Autosave. <3.6> 2018-10-21T13:45:24.530486+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], enabled SMART Automatic Offline Testing. <3.6> 2018-10-21T13:45:24.535003+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], is SMART capable. Adding to "monitor" list. <3.6> 2018-10-21T13:45:24.535627+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], state read from /var/lib/smartmontools/smartd.WDC_WD80EZAZ_11TDBA0-2TKST2SD.ata.state <3.6> 2018-10-21T13:45:24.880219+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], state written to /var/lib/smartmontools/smartd.WDC_WD80EZAZ_11TDBA0-2TKST2SD.ata.state <3.6> 2018-10-21T14:15:25.233525+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 147 to 144 <3.6> 2018-10-21T15:45:31.681938+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], not capable of SMART self-check <3.2> 2018-10-21T15:45:33.632399+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], failed to read SMART Attribute Data <3.6> 2018-10-21T16:15:24.678100+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], read SMART Attribute Data worked again, warning condition reset after 1 email <3.6> 2018-10-21T18:15:31.767150+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], not capable of SMART self-check <3.2> 2018-10-21T18:15:33.717688+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], failed to read SMART Attribute Data <3.6> 2018-10-21T18:45:24.587304+02:00 Isengard smartd 11255 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], read SMART Attribute Data worked again, warning condition reset after 1 email It intermitently but periodically fail to read atributes, triggering hundreds of emails sent to me to warn of the problem: +++------------ Subject: SMART error (FailedReadSmartData) detected on host: Isengard This message was generated by the smartd daemon running on: host name: Isengard DNS domain: valinor The following warning/error was logged by the smartd daemon: Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], failed to read SMART Attribute Data Device info: WDC WD80EZAZ-11TDBA0, S/N:2TKST2SD, WWN:5-000cca-26af51579, FW:83.H0A83, 8.00 TB For details see host's SYSLOG. You can also use the smartctl utility for further investigation. Another message will be sent in 24 hours if the problem persists. - ------------++- The disk is indeed smart capable and it works fine, as long as I call smartctl with "-d sat,16", which I do: Isengard:~ # smartctl --test=short -d sat,16 /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0\:0 smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.4.155-68-default] (SUSE RPM) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Short self-test routine immediately in off-line mode". Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 2 minutes for test to complete. Test will complete after Sun Oct 21 13:50:18 2018 Use smartctl -X to abort test. Isengard:~ # Isengard:~ # smartctl --health -d sat,16 /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0\:0 smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.4.155-68-default] (SUSE RPM) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED Isengard:~ # It is crucial to use "-d sat,16" or it fails: Isengard:~ # smartctl --health /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0\:0 smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.4.155-68-default] (SUSE RPM) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0: Unknown USB bridge [0x1058:0x25ee (0x4004)] Please specify device type with the -d option. Use smartctl -h to get a usage summary Isengard:~ # Of course I use that option on the config: Isengard:~ # cat /etc/smartd.conf | egrep -v "^[[:space:]]*$|^#" /dev/sda -a -o on -S on -s (S/../.././02|L/../../6/03) -m root(a)telcontar.valinor /dev/disk/by-id/wwn-0x5000000000000001 -a -o on -S on -s (S/../.././02|L/../../6/03) -m root(a)telcontar.valinor /dev/disk/by-id/wwn-0x5000c5009399305f -a -o on -S on -s (S/../.././02|L/../../6/03) -m root(a)telcontar.valinor /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 -d sat,16 -a -o on -S on -s (S/../.././02|L/../../6/03) -m root(a)telcontar.valinor Isengard:~ # What else am I missing? Is smartd not using "-d sat,16" somewhere else? Is it some other problem? Isengard:~ # rpm -q smartmontools smartmontools-6.6-135.1.x86_64 Isengard:~ # - -- Cheers Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlvM5UMACgkQtTMYHG2NR9WCwQCePjOt8PSMKsx6DwSe9bZJRhHf 2lQAn02eBTrtfAqmEg5ydZVagvMfW2r6 =eIzR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 month, 1 week

[opensuse] How to turn OFF new html-ized directory listings at http://download.opensuse.org/source/distribution/leap/

by David C. Rankin

All, Just going through source listings at http://download.opensuse.org/source/distribution/leap/ there is some kind of new "Pretty Print" html-ized format being used that underlines the entire row containing the srpm instead of the normal raw directory listing that only underlines the package. This (1) doubles the height of the listing you have to scroll and (2) makes scanning the listing awkward. Is there some way, or switch, that will revert to the simple listing? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 months, 3 weeks

[opensuse] gcc 8 on Tumbleweed

by Roger Oberholtzer

I am using the NVIDIA NVCC GPU /CUDA compiler on Tumbleweed. The package I am building (darknet) seems to work best with NVCC 10.2. So I have been using that on Tumbleweed. I am setting up a new Tumbleweed system, and I see that gcc-8 (64-bit) is no longer available. I see gcc-7 and gcc-9. But no gcc-8. If it has been removed, is it perhaps still possible to find it for Tumbleweed? I did a search on openSUSE downloads, and it only had some Debian release. Nothing for openSUSE. I tried other GCC releases witn NVCC, but it complains that they are unsupported versions. It wants gcc-8. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 months, 4 weeks

[opensuse] Portkocking problem

by Marc Chamberlin

Hello - I am experiencing a problem with port knocking and am in need of some guidance from someone with a deeper understanding of the Linux/OpenSuSE architecture than I have. I have a computer with 2 NIC cards defined as eth0 and eth1. I am running 2 knockd daemons using nearly identical configuration files that define the knock sequences needed to open a port. The IP addresses for each card are on the same internal private subnet and assigned by a DHCPD server. When I send a knock sequence from my laptop to this system on it's eth0 interface all works fine. But when I send the same knock sequence to the eth1 interface it generally fails, although every once in awhile, as I am trying to figure out what is going on, it will work one time and then again fails on subsequent tests. I don't know what I am doing that causes these occasional successes. I have tried bringing down and back up the eth1 interface with ifup and ifdown, and tried restarting the firewalld, network, and knockd services. I have also tried putting both interfaces on the same (INTERNAL) zone (not what I really want to do, but this eliminates the possibility that placing each interface in separate zones could be causing problems.) I fired up wireshark on my target computer to monitor the eth1 interface (and the eth0 interface to see if there were any differences that might give me a clue) and wireshark does indeed show the arrival of the knock packets coming from my laptop, on both interfaces. So I know that I am sending the knocks OK and that they are indeed arriving on the appropriate interfaces. So I next inserted the following rule into the head of the INPUT chain of the iptables to monitor what it is seeing - *iptables -w -I INPUT 1 -s 192.168.10.10 -j LOG; tail -n-0 -f /var/log/messages|stdbuf -o0 grep 192.168.10.10* (192.168.10.10 is the IP address of my laptop) and while this does show the knocks coming in on eth0, it fails to show any knocks coming in on eth1 (except occasionally as I mentioned above). Does this command look correct? In particular I am not really sure where the LOG chain will send its output, I am guessing it is to the messages log file. (I have turned back on logging to the messages log file since I prefer using text files rather than the journal log which I find is too difficult to work with) I imagine that wireshark is directly monitoring eth1 by making low level calls to the eth1 driver and I would have expected iptables to be doing the same, but apparently not. So what lies between the low level driver for eth1 that wireshark is apparently using, and the beginning of the iptables chain that is blocking these port knock packets from reaching the iptables chains? Anyone with ideas? As always much appreciated and thanks in advance for taking the time to help me out! Marc.... -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 months, 4 weeks

[opensuse] Question about zypper local directory repo

by Carlos E. R.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have one local repository: cer@Telcontar:~> cat /etc/zypp/repos.d/Local_RPMs.repo [Local_RPMs] name=Local RPMs enabled=1 autorefresh=1 baseurl=dir:/data/storage_c/repositorios_zypp/LocalRPMs path=/ type=plaindir priority=100 keeppackages=0 cer@Telcontar:~> In it, I have one rpm which is a symlink: cer@Telcontar:/data/storage_c/repositorios_zypp/LocalRPMs> l auto* lrwxrwxrwx 1 cer users 74 Jul 23 11:33 autofirma-1.6.5-1.noarch_SUSE.rpm -> /home/cer/aeat/programas/autofirma_linux/autofirma-1.6.5-1.noarch_SUSE.rpm cer@Telcontar:/data/storage_c/repositorios_zypp/LocalRPMs> "zypper se" (after a forced refresh) does not see it. Telcontar:~ # zypper se autofirma Loading repository data... Reading installed packages... No matching items found. Telcontar:~ # If I replace the symlink with the actual file, and refresh, zypper sees it: Telcontar:~ # zypper se autofirma Loading repository data... Reading installed packages... S | Name | Summary | Type - --+-----------+-----------------------------------------------------------------+-------- | autofirma | Aplicación de firma electrónica en escritorio y en trámites web | package Telcontar:~ # Is this a bug, or a feature? (Leap 15.1) P.S: If you are curious, the rpm comes from the Spanish government, for signing documents, and it is GNU GPL v. 2.0 and EUPL v. 1.1 <https://firmaelectronica.gob.es/Home/Descargas.html> - -- Cheers Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXxlbVRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVePoAn0AUpR3k830n0jFxImL2 6eJkHXkrAJsGDUUV4TMS8DFjbDptXoqah2j7eA== =Ik8c -----END PGP SIGNATURE-----

4 months

[opensuse] Hard disk crash

by Carlos E. R.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I had a hard disk crash last month and another one yesterday. I had to hit the hardware reset button to "recover". First occurrence: <3.6> 2020-06-22T12:40:25.270365+02:00 Telcontar smartd 1470 - - Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 66 to 63 <3.6> 2020-06-22T12:40:25.270606+02:00 Telcontar smartd 1470 - - Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 34 to 37 <3.6> 2020-06-22T12:40:25.270710+02:00 Telcontar smartd 1470 - - Device: /dev/sda [SAT], previous self-test completed without error <3.6> 2020-06-22T12:40:25.642623+02:00 Telcontar smartd 1470 - - Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 67 to 64 <3.6> 2020-06-22T12:40:25.642829+02:00 Telcontar smartd 1470 - - Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 33 to 36 <3.6> 2020-06-22T12:40:25.642949+02:00 Telcontar smartd 1470 - - Device: /dev/sdb [SAT], previous self-test completed without error <3.6> 2020-06-22T12:40:25.835124+02:00 Telcontar smartd 1470 - - Device: /dev/sdc [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 67 to 65 <3.6> 2020-06-22T12:40:25.835308+02:00 Telcontar smartd 1470 - - Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 33 to 35 <3.6> 2020-06-22T12:40:25.835408+02:00 Telcontar smartd 1470 - - Device: /dev/sdc [SAT], previous self-test completed without error <3.6> 2020-06-22T12:40:26.184405+02:00 Telcontar smartd 1470 - - Device: /dev/sdd [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 65 to 63 <3.6> 2020-06-22T12:40:26.184628+02:00 Telcontar smartd 1470 - - Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 35 to 37 <3.6> 2020-06-22T12:40:26.184745+02:00 Telcontar smartd 1470 - - Device: /dev/sdd [SAT], previous self-test completed without error <3.6> 2020-06-22T12:47:17.731257+02:00 Telcontar dbus-daemon 9743 - - [session uid=1000 pid=9743] Activating service name='org.gnome.keyring.SystemPrompter' requested by ':1 .428' (uid=1000 pid=27919 comm="/usr/bin/pinentry-gnome3 ") <3.6> 2020-06-22T12:47:17.773078+02:00 Telcontar dbus-daemon 9743 - - [session uid=1000 pid=9743] Successfully activated service 'org.gnome.keyring.SystemPrompter' <9.6> 2020-06-22T12:50:01.855266+02:00 Telcontar CRON 28033 - - (root) CMD ([ -x /usr/lib64/sa/sa1 ] && exec /usr/lib64/sa/sa1 1 1) <3.6> 2020-06-22T13:00:00.267363+02:00 Telcontar systemd 1 - - Started Timeline of Snapper Snapshots. <3.6> 2020-06-22T13:00:00.302345+02:00 Telcontar dbus-daemon 1350 - - [system] Activating service name='org.opensuse.Snapper' requested by ':1.3164' (uid=0 pid=28336 comm="/ usr/lib/snapper/systemd-helper --timeline ") (using servicehelper) <3.6> 2020-06-22T13:00:00.369997+02:00 Telcontar dbus-daemon 1350 - - [system] Successfully activated service 'org.opensuse.Snapper' <9.6> 2020-06-22T13:00:01.902111+02:00 Telcontar CRON 28346 - - (root) CMD ([ -x /usr/lib64/sa/sa1 ] && exec /usr/lib64/sa/sa1 1 1) <10.6> 2020-06-22T13:00:01.973157+02:00 Telcontar cron 28342 - - pam_unix(crond:session): session opened for user cer by (uid=0) <10.6> 2020-06-22T13:00:01.974030+02:00 Telcontar cron 28343 - - pam_unix(crond:session): session opened for user cer by (uid=0) <9.6> 2020-06-22T13:00:01.974400+02:00 Telcontar CRON 28394 - - (cer) CMD (/home/cer/bin/dar_la_hora_en_cron hora) <10.6> 2020-06-22T13:00:01.992853+02:00 Telcontar CRON 28343 - - pam_unix(crond:session): session closed for user cer <10.6> 2020-06-22T13:00:02.209451+02:00 Telcontar CRON 28342 - - pam_unix(crond:session): session closed for user cer <0.3> 2020-06-22T13:01:38.170168+02:00 Telcontar kernel - - - [250558.404347] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen <0.3> 2020-06-22T13:01:38.170183+02:00 Telcontar kernel - - - [250558.404350] ata3.00: failed command: FLUSH CACHE EXT <0.3> 2020-06-22T13:01:38.170184+02:00 Telcontar kernel - - - [250558.404353] ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 22 <0.3> 2020-06-22T13:01:38.170184+02:00 Telcontar kernel - - - [250558.404353] res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) <0.3> 2020-06-22T13:01:38.170185+02:00 Telcontar kernel - - - [250558.404354] ata3.00: status: { DRDY } <0.6> 2020-06-22T13:01:38.170186+02:00 Telcontar kernel - - - [250558.404357] ata3: hard resetting link <0.3> 2020-06-22T13:01:48.167284+02:00 Telcontar kernel - - - [250568.404421] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:01:48.167294+02:00 Telcontar kernel - - - [250568.404424] ata3: hard resetting link <0.3> 2020-06-22T13:01:58.169610+02:00 Telcontar kernel - - - [250578.404658] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:01:58.169622+02:00 Telcontar kernel - - - [250578.404661] ata3: hard resetting link <0.3> 2020-06-22T13:02:33.170216+02:00 Telcontar kernel - - - [250613.405141] ata3: softreset failed (1st FIS failed) <0.4> 2020-06-22T13:02:33.170228+02:00 Telcontar kernel - - - [250613.405144] ata3: limiting SATA link speed to 3.0 Gbps <0.6> 2020-06-22T13:02:33.170229+02:00 Telcontar kernel - - - [250613.405146] ata3: hard resetting link <0.6> 2020-06-22T13:02:38.382166+02:00 Telcontar kernel - - - [250618.616572] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 320) <0.7> 2020-06-22T13:02:38.382179+02:00 Telcontar kernel - - - [250618.616576] ata3.00: link online but device misclassified <0.4> 2020-06-22T13:02:43.422167+02:00 Telcontar kernel - - - [250623.656580] ata3.00: qc timeout (cmd 0xec) <0.4> 2020-06-22T13:02:43.422179+02:00 Telcontar kernel - - - [250623.656587] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) <0.3> 2020-06-22T13:02:43.422180+02:00 Telcontar kernel - - - [250623.656589] ata3.00: revalidation failed (errno=-5) <0.6> 2020-06-22T13:02:43.422181+02:00 Telcontar kernel - - - [250623.656592] ata3: hard resetting link <0.3> 2020-06-22T13:02:53.422148+02:00 Telcontar kernel - - - [250633.657229] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:02:53.422161+02:00 Telcontar kernel - - - [250633.657232] ata3: hard resetting link <0.3> 2020-06-22T13:03:03.422144+02:00 Telcontar kernel - - - [250643.657623] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:03:03.422154+02:00 Telcontar kernel - - - [250643.657625] ata3: hard resetting link <0.3> 2020-06-22T13:03:38.422151+02:00 Telcontar kernel - - - [250678.657249] ata3: softreset failed (1st FIS failed) <0.4> 2020-06-22T13:03:38.422163+02:00 Telcontar kernel - - - [250678.657253] ata3: limiting SATA link speed to 1.5 Gbps <0.6> 2020-06-22T13:03:38.422165+02:00 Telcontar kernel - - - [250678.657254] ata3: hard resetting link <0.6> 2020-06-22T13:03:43.642165+02:00 Telcontar kernel - - - [250683.876788] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) <0.7> 2020-06-22T13:03:43.642180+02:00 Telcontar kernel - - - [250683.876792] ata3.00: link online but device misclassified <0.4> 2020-06-22T13:03:53.822166+02:00 Telcontar kernel - - - [250694.056819] ata3.00: qc timeout (cmd 0xec) <0.4> 2020-06-22T13:03:53.822180+02:00 Telcontar kernel - - - [250694.056827] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) <0.3> 2020-06-22T13:03:53.822181+02:00 Telcontar kernel - - - [250694.056828] ata3.00: revalidation failed (errno=-5) <0.6> 2020-06-22T13:03:53.822183+02:00 Telcontar kernel - - - [250694.056832] ata3: hard resetting link <0.3> 2020-06-22T13:04:03.822166+02:00 Telcontar kernel - - - [250704.057810] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:04:03.822179+02:00 Telcontar kernel - - - [250704.057812] ata3: hard resetting link <0.3> 2020-06-22T13:04:13.822163+02:00 Telcontar kernel - - - [250714.057147] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:04:13.822175+02:00 Telcontar kernel - - - [250714.057150] ata3: hard resetting link <0.3> 2020-06-22T13:04:48.822154+02:00 Telcontar kernel - - - [250749.057907] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:04:48.822167+02:00 Telcontar kernel - - - [250749.057911] ata3: hard resetting link <0.6> 2020-06-22T13:04:54.038172+02:00 Telcontar kernel - - - [250754.273047] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) <0.7> 2020-06-22T13:04:54.038185+02:00 Telcontar kernel - - - [250754.273051] ata3.00: link online but device misclassified <3.6> 2020-06-22T13:05:21.032478+02:00 Telcontar systemd 1 - - Stopping Dovecot IMAP/POP3 email server... <0.4> 2020-06-22T13:05:25.470153+02:00 Telcontar kernel - - - [250785.705150] ata3.00: qc timeout (cmd 0xec) <0.4> 2020-06-22T13:05:25.470167+02:00 Telcontar kernel - - - [250785.705158] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) <0.3> 2020-06-22T13:05:25.470168+02:00 Telcontar kernel - - - [250785.705159] ata3.00: revalidation failed (errno=-5) <0.4> 2020-06-22T13:05:25.470169+02:00 Telcontar kernel - - - [250785.705161] ata3.00: disabled <0.6> 2020-06-22T13:05:25.470170+02:00 Telcontar kernel - - - [250785.705172] ata3: hard resetting link <0.3> 2020-06-22T13:05:35.470168+02:00 Telcontar kernel - - - [250795.705351] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:05:35.470182+02:00 Telcontar kernel - - - [250795.705353] ata3: hard resetting link <0.3> 2020-06-22T13:05:35.470168+02:00 Telcontar kernel - - - [250795.705351] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:05:35.470182+02:00 Telcontar kernel - - - [250795.705353] ata3: hard resetting link <0.3> 2020-06-22T13:05:45.470146+02:00 Telcontar kernel - - - [250805.705811] ata3: softreset failed (1st FIS failed) <0.6> 2020-06-22T13:05:45.470161+02:00 Telcontar kernel - - - [250805.705814] ata3: hard resetting link <3.6> 2020-06-22T13:06:03.103885+02:00 Telcontar pulseaudio 9815 - - ICE default IO error handler doing an exit(), pid = 9815, errno = 11 <3.6> 2020-06-22T13:06:03.119549+02:00 Telcontar at-spi-bus-launcher 9862 - - XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" <3.6> 2020-06-22T13:06:03.119724+02:00 Telcontar at-spi-bus-launcher 9862 - - after 115009 requests (115009 known processed) with 0 events remaining. <1.7> 2020-06-22T13:06:03.121490+02:00 Telcontar sddm-helper 9726 - - [PAM] Closing session and reboot. The disk or the interface can be identified on next boot: <0.6> 2020-06-22T13:08:00.540722+02:00 Telcontar kernel - - - [ 2.512438] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) <0.6> 2020-06-22T13:08:00.540723+02:00 Telcontar kernel - - - [ 2.515338] ata3.00: ATA-10: ST4000DM004-2CV104, 0001, max UDMA/133 <0.6> 2020-06-22T13:08:00.540725+02:00 Telcontar kernel - - - [ 2.515343] ata3.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA <0.6> 2020-06-22T13:08:00.540726+02:00 Telcontar kernel - - - [ 2.517902] ata3.00: configured for UDMA/133 <0.5> 2020-06-22T13:08:00.540726+02:00 Telcontar kernel - - - [ 2.518066] scsi 2:0:0:0: Direct-Access ATA ST4000DM004-2CV1 0001 PQ: 0 ANSI: 5 <0.5> 2020-06-22T13:08:00.540726+02:00 Telcontar kernel - - - [ 2.518210] sd 2:0:0:0: Attached scsi generic sg2 type 0 <0.5> 2020-06-22T13:08:00.540727+02:00 Telcontar kernel - - - [ 2.518262] sd 2:0:0:0: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) <0.5> 2020-06-22T13:08:00.540727+02:00 Telcontar kernel - - - [ 2.518267] sd 2:0:0:0: [sdc] 4096-byte physical blocks <0.6> 2020-06-22T13:08:00.540764+02:00 Telcontar kernel - - - [ 2.578542] sdc: sdc1 sdc2 sdc3 sdc4 sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 sdc12 sdc13 sdc14 <0.5> 2020-06-22T13:08:00.540765+02:00 Telcontar kernel - - - [ 2.578979] sd 2:0:0:0: [sdc] Attached SCSI disk Yesterday event: <1.6> 2020-07-29T19:53:38.848734+02:00 Telcontar org.freedesktop.thumbnails.Cache1 4259 - - Registered thumbailer gsf-office-thumbnailer -i %i -o %o -s %s <1.6> 2020-07-29T19:53:38.849607+02:00 Telcontar org.freedesktop.thumbnails.Cache1 4259 - - Registered thumbailer /usr/bin/totem-video-thumbnailer -s %s %u %o <1.6> 2020-07-29T19:53:38.849730+02:00 Telcontar org.freedesktop.thumbnails.Cache1 4259 - - Registered thumbailer /usr/bin/gdk-pixbuf-thumbnailer -s %s %u %o <1.6> 2020-07-29T19:53:38.849990+02:00 Telcontar org.freedesktop.thumbnails.Cache1 4259 - - Registered thumbailer xreader-thumbnailer -s %s %u %o <3.6> 2020-07-29T19:53:38.867963+02:00 Telcontar dbus-daemon 4259 - - [session uid=1000 pid=4259] Successfully activated service 'org.freedesktop.thumbnails.Cache1' <9.6> 2020-07-29T20:00:01.248507+02:00 Telcontar CRON 32222 - - (root) CMD ([ -x /usr/lib64/sa/sa1 ] && exec /usr/lib64/sa/sa1 1 1) <3.6> 2020-07-29T20:00:01.254182+02:00 Telcontar systemd 1 - - Started Timeline of Snapper Snapshots. <10.6> 2020-07-29T20:00:01.285419+02:00 Telcontar cron 32218 - - pam_unix(crond:session): session opened for user cer by (uid=0) <3.6> 2020-07-29T20:00:01.302968+02:00 Telcontar dbus-daemon 1488 - - [system] Activating service name='org.opensuse.Snapper' requested by ':1.4309' (uid=0 pid=32230 comm="/usr/lib/snapper/systemd-helper --timeline ") (using servicehelper) <10.6> 2020-07-29T20:00:01.334902+02:00 Telcontar cron 32219 - - pam_unix(crond:session): session opened for user cer by (uid=0) <9.6> 2020-07-29T20:00:01.335326+02:00 Telcontar CRON 32275 - - (cer) CMD (/home/cer/bin/dar_la_hora_en_cron hora) <10.6> 2020-07-29T20:00:01.349451+02:00 Telcontar CRON 32219 - - pam_unix(crond:session): session closed for user cer <3.6> 2020-07-29T20:00:01.369929+02:00 Telcontar dbus-daemon 1488 - - [system] Successfully activated service 'org.opensuse.Snapper' <10.6> 2020-07-29T20:00:01.555092+02:00 Telcontar CRON 32218 - - pam_unix(crond:session): session closed for user cer <0.3> 2020-07-29T20:01:21.690682+02:00 Telcontar kernel - - - [320053.217028] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen <0.3> 2020-07-29T20:01:21.690694+02:00 Telcontar kernel - - - [320053.217030] ata3.00: failed command: FLUSH CACHE EXT <0.3> 2020-07-29T20:01:21.690695+02:00 Telcontar kernel - - - [320053.217034] ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 6 <0.3> 2020-07-29T20:01:21.690696+02:00 Telcontar kernel - - - [320053.217034] res 40/00:ff:ff:00:00/00:00:00:00:00/40 Emask 0x4 (timeout) <0.3> 2020-07-29T20:01:21.690697+02:00 Telcontar kernel - - - [320053.217036] ata3.00: status: { DRDY } <0.6> 2020-07-29T20:01:21.690698+02:00 Telcontar kernel - - - [320053.217039] ata3: hard resetting link <0.3> 2020-07-29T20:01:31.690677+02:00 Telcontar kernel - - - [320063.217607] ata3: softreset failed (1st FIS failed) <0.6> 2020-07-29T20:01:31.690690+02:00 Telcontar kernel - - - [320063.217609] ata3: hard resetting link <0.3> 2020-07-29T20:01:41.690680+02:00 Telcontar kernel - - - [320073.217267] ata3: softreset failed (1st FIS failed) <0.6> 2020-07-29T20:01:41.690692+02:00 Telcontar kernel - - - [320073.217270] ata3: hard resetting link <0.3> 2020-07-29T20:02:16.688064+02:00 Telcontar kernel - - - [320108.218075] ata3: softreset failed (1st FIS failed) <0.4> 2020-07-29T20:02:16.688075+02:00 Telcontar kernel - - - [320108.218078] ata3: limiting SATA link speed to 3.0 Gbps <0.6> 2020-07-29T20:02:16.688076+02:00 Telcontar kernel - - - [320108.218080] ata3: hard resetting link <0.6> 2020-07-29T20:02:21.853511+02:00 Telcontar kernel - - - [320113.381256] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 320) <0.7> 2020-07-29T20:02:21.853523+02:00 Telcontar kernel - - - [320113.381260] ata3.00: link online but device misclassified <0.4> 2020-07-29T20:02:26.930684+02:00 Telcontar kernel - - - [320118.457272] ata3.00: qc timeout (cmd 0xec) <0.4> 2020-07-29T20:02:26.930699+02:00 Telcontar kernel - - - [320118.457280] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) <0.3> 2020-07-29T20:02:26.930701+02:00 Telcontar kernel - - - [320118.457282] ata3.00: revalidation failed (errno=-5) <0.6> 2020-07-29T20:02:26.930708+02:00 Telcontar kernel - - - [320118.457285] ata3: hard resetting link <0.3> 2020-07-29T20:02:36.930677+02:00 Telcontar kernel - - - [320128.457434] ata3: softreset failed (1st FIS failed) <0.6> 2020-07-29T20:02:36.930692+02:00 Telcontar kernel - - - [320128.457437] ata3: hard resetting link <0.3> 2020-07-29T20:02:46.930682+02:00 Telcontar kernel - - - [320138.457591] ata3: softreset failed (1st FIS failed) <0.6> 2020-07-29T20:02:46.930695+02:00 Telcontar kernel - - - [320138.457594] ata3: hard resetting link <0.3> 2020-07-29T20:03:21.930679+02:00 Telcontar kernel - - - [320173.458400] ata3: softreset failed (1st FIS failed) <0.4> 2020-07-29T20:03:21.930693+02:00 Telcontar kernel - - - [320173.458404] ata3: limiting SATA link speed to 1.5 Gbps <0.6> 2020-07-29T20:03:21.930695+02:00 Telcontar kernel - - - [320173.458406] ata3: hard resetting link <0.6> 2020-07-29T20:03:27.146680+02:00 Telcontar kernel - - - [320178.673492] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) <0.7> 2020-07-29T20:03:27.146694+02:00 Telcontar kernel - - - [320178.673496] ata3.00: link online but device misclassified <0.4> 2020-07-29T20:03:37.330677+02:00 Telcontar kernel - - - [320188.857523] ata3.00: qc timeout (cmd 0xec) <0.4> 2020-07-29T20:03:37.330690+02:00 Telcontar kernel - - - [320188.857532] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) <0.3> 2020-07-29T20:03:37.330691+02:00 Telcontar kernel - - - [320188.857533] ata3.00: revalidation failed (errno=-5) <0.6> 2020-07-29T20:03:37.330692+02:00 Telcontar kernel - - - [320188.857538] ata3: hard resetting link <0.3> 2020-07-29T20:03:47.328555+02:00 Telcontar kernel - - - [320198.858357] ata3: softreset failed (1st FIS failed) <0.6> 2020-07-29T20:03:47.328569+02:00 Telcontar kernel - - - [320198.858359] ata3: hard resetting link 2020-07-29 20:05:16+02:00 - Booting the system now ================================================================================ Linux Telcontar 4.12.14-lp151.28.52-default #1 SMP Wed Jun 10 15:32:08 UTC 2020 (464fb5f) x86_64 x86_64 x86_64 GNU/Linux <3.6> 2020-07-29T20:05:17.812270+02:00 Telcontar systemd 1 - - systemd 234 running in system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 -IDN default-hierarchy=hybrid) I did not bother to do a software halt this time, useless. It is the same disk. I did a long SMART test the previous time on all disks, found nothing. What should I look at? The machine is currently running Leap 15.1, with an AMD Ryzen 5 processor, one NVME M.2 "disk" (new), and four mechanical hard disks (old), migrated from the previous Intel Core 2 machine this year, where I didn't have any issues like this. The four disks are the same brand and family, different ages. If there is some missing info, just ask. Both times, it happened one second after this line: <3.6> 2020-07-29T20:00:01.254182+02:00 Telcontar systemd 1 - - Started Timeline of Snapper Snapshots. What should I look at? - -- Cheers Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXyLLaxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVsDcAoJI4vzQWBUNRTeOsxVGi uZ17uPYsAJ9IYmGHqHISq4PFn7inljg8kj4DoQ== =s50+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 months

[opensuse] Hot-swapable SCSI disks

by Roger Oberholtzer

We are using a SuperMicro computer that has 24 removable hot-swappable disks. During use, disks will independently be swapped in and out. For this to work, we need to know which physical slot a disk gets inserted into. There are many many disks, so tracking a disk id of the disk itself is not really feasible. And the disks are a mix of ext4 and ntfs. We have done this before with SuperMicro computers that had, say, 4 such drive bays. We have udev rules that track activity on adds to the block subsystem The detection and all works fine. The problem we have is that detecting which physical slot the disk has been inserted into is not consistent. We use the /dev/disk/by-path entries for this. As we have done in the past. This hardware information must, I guess, be assigned by the SuperMicro BIOS (or the modern equivalent) each time a disk is inserted. It really looks like the hardware info changes. There are 24 hardware values that seem to be used (this is consistent), but the physical slot to which they refer seems somewhat random. Does it make sense to expect the hardware information in /dev/disk/by-path to consistently refer to the same physical SCSI interface? I know that at the end of the day it all comes down to what the BIOS tells when a disk is added. But I want to make sure that I am not doing something silly in the Linux part of this. Like I should be looking elsewhere, or running some obscure command to get this consistent hardware address. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 months

[opensuse] kernel-default-5.3.18-lp152.33.1.x86_64 crashes

by Markus Kolb

Hi, the July patches in kernel-default-5.3.18-lp152.33.1.x86_64 has here introduced a problem with hard lockups. No logging about the problem. Does anyone see the same crashing with the new kernel package? kernel-default-5.3.18-lp152.26.2.x86_64 works. Thanks Markus -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 months

[opensuse] Boot problems after Leap 15.2 upgrade on libvirt host

by Radosław Wyrzykowski

Hello, Yesterday, having successfully updated two VMs I run services on to Leap 15.2 in the weeks before, I figured upgrading the host they run on shouldn't be a problem. So, I replaced 15.1 with releasever in my repo addresses, ran zypper --releasever=15.2 ref and then zypper --releasever=15.2 dup and kexec'ed as usual... And the server didn't come up. And when I plugged a monitor in, I was greeted with a GRUB rescue prompt. It said it can't load normal.mod from / @/.snapshots/{default subvolume snapshot number}/snapshot/boot/grub2/i386-pc. Well, we know that grub resides on a separate subvolume in OpenSUSE's default btrfs layout, and lo and behold, it was there and pointing GRUB to the proper place was enough to get a normal shell. From there tried sourcing the config file which failed because it couldn't find the font, apparently. So I booted from a pendrive, checked everything looks alright, looked up the correct commandline and manually pointed it to the kernel and initrd. I thought: okay, that can be figured out soon enough, I'll ask about it later. Everything seemed fine, neither the RAID controller (some LSI MegaRAID that doesn't even support JBOD) nor btrfs reported any errors. But then, docker in both VMs failed to start, throwing up errors that, after some internet searching, were attributed to heavy IO loads (something about failed atomic operations). And when I manually stopped and started docker, it turned out docker.sock had magically spawned as a folder and I had to delete it before it could start, too. I tried rebooting everything (guests are shut down and started up again by libvirt-guests) to no avail. Everything went down identically. I tried force reinstalling grub2-i386-pc and grub2-branding-openSUSE. I've looked all over the journal in search of anything that would point me to some indication of where the problem is and found nothing. Potentially important info: - Both the host and VMs use btrfs on GPT on BIOS (no EFI in the picture) - Each of them has several GBs of unallocated space - The storage is a MegaRAID RAID 10 array - I've been using the hardware without any problems with 15.0 and 15.1 - The VMs are configured with qcow2 images via VirtIO SCSI with discard configured (otherwise the host file system gets clogged up with unused allocations - not too much disk space here) - I haven't had any problems prior to upgrading the host to 15.2 - the VMs have been running 15.2 without any difficulty for the last week or two. I've even installed some updates since upgrading them (I know, I know, not the most efficient way of doing things. It's served me reasonably well for the last 1,5 years) What more can I do to diagnose the problems? What could be the reasons? AFAIK, all the hardware is still going strong and, once all the dancing around with grub, rmdir and systemctl is done with, everything runs as it should. (Maybe a little slower? I might be imagining it or it could be unprimed disk caches) I think that later today, I'll revert to the snapshot from before the upgrade and see if that helps for the time being. Regards Radosław Wyrzykowski -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

openSUSE Users July 2020