Created attachment 11399 [details]
Attributes of a SSD PNY

Tis capture shows:
- 231 Temperature  marked as a failure
- unknown characters reported in Bug  25797

Thanks for the very helpful screenshot.
Wondering whether smartctl is relevant to SSDs - it is!
"smartctl controls the Self-Monitoring, Analysis and Reporting Technology  (SMART) system built into most ATA/SATA and SCSI/SAS hard drives and solid-state drives."
The figures are difficult to understand, see particularly ($ man smartctl) the -A --attributes parameter re Raw & Normalised values, also Threshold & Worst.
All but the RAW values are in the range 0-255.
Counter-intuitively, the device has trouble:
"If the Normalized value is *less than or equal to* the Threshold value, then the  Attribute is said to have failed. If the Attribute is a pre-failure Attribute, then disk failure is imminent."

In your example, "231 Temperature" (whatever it actually means, see "194 Temperature" above it) is not marked as failure - unless the highlight is from the program, not by yourself.
In comment 0, "231 Temperature_Celsius -> 99  (shown as a failure)"
Did smartctl itself output this, or is it your comment? It is shown as simply "231 Temperature"; "Failed never", "worst 100", "threshold 0".

If this bug is really a question of interpretation, then it can be closed; and the question would have been better put on the Mageia [French?] forum to start with.
OTOH If there is a real error in the software, it needs clarification please.

CC: (none) => lewyssmith

The attachment is a screenshot as is, without any modification.
The light magenta colour means a serious warning. A full failure is bright red. Generally, magenta means that the disk must be replaced rather soon.
I have often seen magenta but I have only seen red once or twice.

"231 Temperature" does not appear to correspond to any measurement.

The indication "Device is: Not in smartctl database" is perhaps the reason of the bad result.

In the opposite "194 Temperature" is a true value, exactly the same than the value given by hddtemp.

In normal operation, no background colour must be shown. I say that to owners of machines. If they see a colour, they are not able to do an accurate interpretation: They call me and are prepared to buy a new disk. When the disc is new, they do not admit that it is already defective.

Created attachment 11402 [details]
Full output of smartctl

Output of 'smartctl -a /dev/sdc'  on SSD disc PNY.

So  to  summarize: the Raw Attribute values are the ones that might have a real physical interpretation, such as "Temperature Celsius", "Hours", or "Start-Stop Cycles".  Each manufacturer  converts  these,  using their detailed knowledge of the disk's operations and failure modes, to Normalized Attribute values in the range 1–254.  The  current  and  worst  (lowest measured)  of these Normalized Attribute values are stored on the disk, along with a Threshold value that the manufacturer has determined will indicate that the disk is going to fail, or  that  it has exceeded its design age or aging limit.  smartctl does not calculate any of the Attribute values, thresholds, or types, it merely reports them from the  SMART  data  on the device. 

Note  that  starting with ATA/ATAPI-4, revision 4, the meaning of these Attribute fields has been made entirely vendor-specific.  However most newer ATA/SATA disks seem to respect their meaning, so we have retained the option of printing the Attribute values. 

Solid-state  drives use different meanings for some of the attributes.  In this case the attribute name printed by smartctl is incorrect unless the drive is already in  the  smartmontools drive database. 

Manual page smartctl(8) line 682 (press h for help or q to quit)
----------------------------------------------------------------------------
Many times I have read that vendors can extract the disk data in proprietary ways that cannot be accurately interpreted by smartmontools.  Here, the smartctl man page is saying exactly that for solid state drives that are "Not in smartctl database".

CC: (none) => rolfpedersen

The parameter 231 can mean:

# smartctl  -P showall | grep 231 |sort -u
                    231 Lifetime_Left
                    231 Perc_Rated_Life_Remain
                    231 SSD_Life_Left
                    231 SSD_Life_Left_Perc
                    231 Temperature_Celsius
                    231 Unknown_JMF_Attribute
                    231 Unknown_Marvell_Attr

SSD are registred in the DB but not all. As My PNY is not in the data base, the first 231 encounted has been taken. 
I had such a problem with sensors 4 or 5 years ago.
I have also used a SSD Crucial 240G: gsmartctl worked fine.
How is it possible to update the DB for PNY ?

> How is it possible to update the DB for PNY ?
 https://www.smartmontools.org/
"Device Information
If your drive is not in the ​current version of smartmontools drive database you can help to improve smartmontools information by sending a report about your drive to our mailinglist ​smartmontools-database."
 which sentence contains two relevant links to do it.
So please can you do this; and post here the URL to your post there.
If eventually we are able to update the package accordingly, we will ask *you* to test it.

Assigning to DavidG as the active maintainer; pending upstream update of the smartctl database.

Keywords: (none) => UPSTREAM
Assignee: bugsquad => geiger.david68210
Source RPM: gsmartcontrol => smartmontools-7.0-1.mga7.src.rpm

Reportedustream on 
https://listi.jpberlin.de/pipermail/smartmontools-database/2019-December/000465.html

and what's if you update the database with command:

# /usr/sbin/update-smart-drivedb

# /usr/sbin/update-smart-drivedb
/usr/share/smartmontools/drivedb.h is already up to date

This means that the data-base of mga7 is not yet updated

A new 7.1 release is out, is your issue fixed in this release?

What about the upstream bug report?


https://www.smartmontools.org/query?milestone=Release+7.1

I got the sources of 7.1 but the database is the same:

# diff /usr/share/smartmontools/drivedb.h /home/pierre/smartmontools-7.1/drivedb.h
71c71
<   { "$Id$",
---
>   { "$Id: drivedb.h 5008 2019-12-28 21:40:37Z chrfranke $",


PNY CS900 family is still not in the database

Must I compile this release or expect a new version in testing?

@jarillon@free.fr I searched their tracking system using
https://www.smartmontools.org/query?status=accepted&status=assigned&status=new&status=reopened&summary=~PNY&order=priority
and this query returned nothing.

I suggest that you reply to your email https://listi.jpberlin.de/pipermail/smartmontools-database/2019-December/000465.html to try and get some attention to this. Perhaps change the subject from "SSD PNY CS900" to "SSD PNY CS900 needs to be supported".

CC: (none) => rihoward1

Also you can create a new bug upstream here: https://www.smartmontools.org/newticket

Done: https://www.smartmontools.org/ticket/1281#ticket

So you can test the upcoming smartmontools-7.2-1.mga7 update in Core/Updates_testing repo!

Assigning to QA,


Suggested advisory
===================================

This new update added some new features and some new devices especially the SSD PNY CS900 reported in bug#25859.

===================================


Packages in 7/core/updates_testing:
========================
smartmontools-7.2-1.mga7.i586.rpm
smartmontools-7.2-1.mga7.x86_64.rpm

Source RPM:
========================
smartmontools-7.2-1.mga7.src.rpm

Assignee: geiger.david68210 => qa-bugs

System information: 64-bit Plasma system, i5 2500 processor, Intel graphics. Three internal hard drives, one Adata SSD, one WD Blue "rust" drive, one Seagate "rust" drive. In addition, there is a "hot Swap" bay, containing another Adata ssd at the moment, inserted just a few minutes ago.

Smartmontools and the GSmartControl gui to use it were already installed on this system. I do not have the PNY CS900, so I can't test that, but...

Ran GSmartControl, looked at information for each drive. All was correct, no drive errors reported. Viewed the log, no problems there, either.

Updated smartmontools, no installation issues. Rand GSmartControl again, looked at the same information as before, with no changes noted.

Giving this an OK, and Validating. Advisory in Comment 17.

Additional information: I also have this version of smartmontools installed in a Mageia 8 install on a laptop with a new TEAM Group SSD only a few days old. GSmartControl had no problems obtaining the information for this new drive.

CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: (none) => MGA7-64-OK

Advisory pushed to SVN.

Keywords: (none) => advisory
CC: (none) => ouaurelien

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2021-0003.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED