openSUSE Users July 2020

users@lists.opensuse.org

67 participants
69 discussions

[opensuse] Raid, Raid6, what file system for good fault tolerance?

by cagsm

Hi list, speaking about software raid, not hardware controller based. I am trying to go for some local OpenSuse machine and adding some storage to it. Was considering Raid6, and now reading about a bit and people left and right scaremongering about the larger the disks these days in the double digit terabyte capacities even, the more likely it is that during a reconstruction of a raid subsequent errors would occur. I would absolutely like to keep my data consistent, and I am not thinking about double digit terabytes either, would stick to 2TB or 4TB disks, with Raid6 thats at least 4 physical drives. Now I am wondering if it possible to use a good robust file system that can add some more parity or check blocks or redundancy on top of the hardware disks, to absolutely be able to always read my data. I can't add multiple machines or like those high availability stuff like clusters and what not I read about DRBD (Distributed Replicated Block Device), or maybe I am just too scared by those technical terms or consider myself to be just a simpleton and wanting to keep it rather simple. My use case here is also not constant availablity, when a disk needs to be replaced, so be it, but I don't want to lose my data that I can not ever read certain parts of it again or such stuff. The thing that came to my mind was, if there is some file systems that would add redundancy and robustness onto the mdraid system of the linux kernel? Anyone with some useful insights? Roughly speaking, I was considering some simple pcie esata interfaced controller card and an external case enclosure with esata port and portmulitplier stuff inside, that can present at least 4 physical disks as JBOD, just a bunch of disks, so that the Linux can seem them all separately. Speed and rebuild times are not my concern, but data persistence and data integrity. Not even number of physical disks, I could live with even one of those 8 bay device enclosures and cases that are out there on the market. Thanks for any help and hints. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 months, 1 week

[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

3 months, 1 week

[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

4 months, 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

6 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

6 months, 3 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

6 months, 3 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-----

6 months, 3 weeks

[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

6 months, 4 weeks

[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

6 months, 4 weeks

[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

7 months

2021

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