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
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=1128204http://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
-----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
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
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
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
-----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-----
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
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