July 2020 - openSUSE Users - openSUSE Mailing Lists

[opensuse] Portkocking problem
by Marc Chamberlin 06 Aug '20

06 Aug '20

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

4 14

[opensuse] Question about zypper local directory repo
by Carlos E. R. 03 Aug '20

03 Aug '20

-----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-----

3 9

[opensuse] Hard disk crash
by Carlos E. R. 01 Aug '20

01 Aug '20

-----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 14

[opensuse] Hot-swapable SCSI disks
by Roger Oberholtzer 01 Aug '20

01 Aug '20

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

2 3

[opensuse] kernel-default-5.3.18-lp152.33.1.x86_64 crashes
by Markus Kolb 30 Jul '20

30 Jul '20

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 12

[opensuse] Boot problems after Leap 15.2 upgrade on libvirt host
by Radosław Wyrzykowski 29 Jul '20

29 Jul '20

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

3 3

[opensuse] Discord on Linux?? (not the nicest player from a privacy standpoint)
by David C. Rankin 29 Jul '20

29 Jul '20

On factory, I read the message about onboard tutorials being given via Discord on Linux. [opensuse-factory] next openQA tutorial/onboarding livestream on Wednesday July 29th 11 AM UTC I've heard my kids talk about it, but never tried it myself. I guess it is just a glorified IRC type chat app. I was even more surprised to find it is the main/update repos?? Okay. Well, I installed it, updated it, and it looks pretty much like it does on windows, and with any net "aware" app, I then set about picking through the settings to determine what avenues it provides for data to be lifted from my computer without my consent -- and shocked I was. Anyone installing will need to take a detailed walk through the Privacy settings and I would avoid testing the webcam. There are numerous setting your a opted-in to by default where you will be sending all kinds of data back to discord to "help make it better..." It also decides by default it will start every time you start your computer and will minimize to the system tray instead of exiting when you use the close-window control. (you may want to change both) All and all -- it looks like the same thing I've seen on the kids machine, and one of these days I'll figure out what it does. I was happy to learn how to use 'alien -r -c yourfile.deb' to turn a .deb file into an .rpm that can be installed to update it... So it was a worthwhile foray :) -- 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

4 7

[opensuse] resolv.conf and VPNs
by Michael Fischer 29 Jul '20

29 Jul '20

For $WORK, I have to use a vpn which writes its own version of /etc/resolv.conf, but as of 2 days ago, I'm on 15.2, which has the whole /var/run/netconfig/resolv.conf thing going on. I'm noticing VERY frequent DNS failures in web browser contexts. I wonder if the browsers are flapping back and forth between what the vpn put in /etc/resolv.conf and what is in /var/run/netconfig/resolv.conf. dig(1) seems to consistently use what is in /etc/resolv.conf, so that isn't helping me debug... Thoughts? Suggestions? Thanks. Michael -- Michael Fischer michael(a)visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 8

Re: [opensuse] Discord on Linux?? (not the nicest player from a privacy standpoint)
by Carlos E. R. 28 Jul '20

28 Jul '20

On 28/07/2020 20.20, Daniel Stevenson wrote: > On Tuesday, July 28, 2020 12:25 PM, Carlos E. R. <> wrote: > >> On 28/07/2020 17.52, David C. Rankin wrote: Please remember to post to the list, not to me in private, so that everybody can benefit from the information. >>> On factory, >>> >>>> I read the message about onboard tutorials being given via Discord on Linux. >>>> [opensuse-factory] next openQA tutorial/onboarding livestream on Wednesday >>>> July 29th 11 AM UTC >>>> I've heard my kids talk about it, but never tried it myself. I guess it is >>>> just a glorified IRC type chat app. I was even more surprised to find it is >>>> the main/update repos?? Okay. >> >> As I don't have kids, I have not heard about it :-p >> >> I think there is are ongoing effort to connect openSUSE channels on discord to IRC, so that we could use an IRC client instead. > > Indeed, this is handled through Matrix. However, this would obviously > be limited to text chat. I believe the reason they are pushing Discord > is that it has built-in screen sharing and voice calling in addition to > text making it easy to run something that resembles a class. The > openSUSE Discord "server" (a collection of rooms managed by a single > team, not a literal server) is actually very active. > >>>> Well, I installed it, updated it, and it looks pretty much like it does on >>>> windows, and with any net "aware" app, I then set about picking through the >>>> settings to determine what avenues it provides for data to be lifted from my >>>> computer without my consent -- and shocked I was. >>>> Anyone installing will need to take a detailed walk through the Privacy >>>> settings and I would avoid testing the webcam. There are numerous setting your >>>> a opted-in to by default where you will be sending all kinds of data back to >>>> discord to "help make it better..." >>>> It also decides by default it will start every time you start your computer >>>> and will minimize to the system tray instead of exiting when you use the >>>> close-window control. (you may want to change both) >> >> Well, the IRC client I use does the same. I use Pidgin. If I hit "close", an applet remains in the bar. I think (but not tried) that if I "closed" it, I can still be called by someone that wants to call me - like a phone. That's why it doesn't really close. >> >>>> All and all -- it looks like the same thing I've seen on the kids machine, >>>> and one of these days I'll figure out what it does. >>>> I was happy to learn how to use 'alien -r -c yourfile.deb' to turn a .deb >>>> file into an .rpm that can be installed to update it... So it was a worthwhile >>>> foray :) >> >> The conference is tomorrow, I understand? >> >> There other communication avenues. I hear talking about "matrix", for instance. No, I don't know what it is. There is mention of it in https://en.opensuse.org/openSUSE:Communication_channels >> >> +++----------------- >> Other methods >> Other >> >> There are plenty of other ways to communicate with openSUSE users or to get support: >> >> Telegram >> Discord >> Matrix Community >> Usenet (Newsgroups). >> Jabber Multi-User-Chat (MUC). >> Wikis, a great source of documentation. See in particular openSUSE.org (this site) and the openSUSE-Community.org website. >> -----------------++- >> >> The "matrix" link is not hosted on the opensuse wiki, it is on https://matrix.to/#/+opensuse:matrix.org and I don't understand what it is about. There is no Linux tool to use it, only for IOS, so I don't really understand why we talk about it. > > You were probably searching for the wrong thing. Well, I'm following the official information available at the opensuse.org site. I posted the full URLs, see above. > I don't blame you; the > naming scheme isn't the greatest, but Matrix is actually a protocol, > like IRC, Ah. > and you can use many clients with it. Huh? > It is designed to be a > completely open source chat protocol that supports modern features like > image sharing and a chat history. Additionally, it can bridge with many > other protocols--it is how the openSUSE Discord server is connected to > IRC, as I mentioned previously. The flagship client is called Element, > and is available for all major OS's. There are of course other clients > out there that you can try, but Element is generally considered the most > feature complete. Element is the only client mentioned at the official opensuse link, and when I opened the page at another computer it said the only system supported was IOS. "IOS & ". Ie, nothing after the "&". Now I see Android after the "&", on the line beneath it. Not very clear to read. No Linux client supported (nor Windows). Very strange. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

2 1

[opensuse] What are we doing for Tbird 78 - No Enigmail support?
by David C. Rankin 28 Jul '20

28 Jul '20

All, There was a warning that appeared in Thunderbird 68 explaining that Enigmail will not work in Thunderbird 78, but that gpg would take its place. However, there seem to be issues with the gpg implementation. I rely on enigmail religiously -- what are we doing to address this? a. stick with 68 as long as possible? b. patch/fix enigmail or gqg so one or the other works as enigmail does now? -- 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

4 5