seagate / openseachest

Cross platform utilities useful for performing various operations on SATA, SAS, NVMe, and USB storage devices.

openSeaChest

Cross platform utilities useful for performing various operations on SATA, SAS, NVMe, and USB storage devices

Copyright (c) 2014-2022 Seagate Technology LLC and/or its Affiliates, All Rights Reserved

Welcome to the openSeaChest open source project!

openSeaChest is a collection of comprehensive, easy-to-use command line diagnostic tools and programming libraries for storage devices that help you quickly determine the health and status of your storage product. The collection includes several tests that show device information, properties and settings. It includes several tests which may modify the storage product such as power management features or firmware download. It includes various commands to examine the physical media on your storage device. Close to 200 commands and sub-commands are available in the various openSeaChest utilities. These are described in more detail below.

Here is an overview presentation we gave at the Storage Networking Industry Association - Storage Developer Conference 2018 that describes the design architecture for the opensea API and openSeaChest storage resource management utilities:

(Note: The openSeaChest team has the utmost respect for the highly regarded sg3_utils, hdparm, sdparm and nvme-cli open source projects. Since this is all pretty low-level stuff, we chose the presentation title "What's better than sg3_utils, hdparm, sdparm?" only to grab the attention of a few extra people attending the SNIA SDC 2018 conference.)

About openSeaChest Command Line Diagnostics

Seagate offers both graphical user interface (GUI) and command line interface (CLI) diagnostic tools for our storage devices. SeaTools for end users is the most popular GUI tools These tools support 15 languages.

openSeaChest diagnostics are command line utilities which are available for expert users. These command line tools assume the user is knowledgeable about running software from the operating system command prompt. CLI tools are in the English language only and use "command line arguments" to define the various tasks and specific devices. openSeaChest diagnostics are available for both Linux and Windows environments.

Linux versions of openSeaChest tools are available as stand alone 32 or 64-bit executables you can copy to your own system. Windows OS versions of openSeaChest diagnostics are also available.

Technical Support for openSeaChest drive utilities is not available. If you have the time to send us some feedback about this software, especially if you notice something we should fix or improve, we would greatly appreciate hearing from you. To report your comments and suggestions, please use the issue reporting feature available in this git repository. Additionally, you can contact us through this email address seaboard @ seagate.com. Please let us know the name and version of the tool you are using.

openSeaChest drive utilities support SATA, SAS, NVMe and USB interface devices. In some cases openSeaChest has successfully recognized PATA and SCSI legacy devices, although the software is not expected to do so.

openSeaChest_Basics - Contains the most important tests and tools. These include Drive Self Test (DST), Device Information, simple firmware download, and a few of the simple data erasure commands.

Other openSeaChest "break out" utilities are available and listed below which offer more in-depth functionality in specific areas. These are:

openSeaChest_Configure - Tools to control various settings on the drives are brought together into this one tool. Typical commands, for example, include Write Cache and Read Lookahead Cache enable or disable. This is where you will find SCSI Mode Page and SCSI Log Page commands.

openSeaChest_Erase - The focus is on data erasure. There are many different choices for erasing data... from simple boot track erase to full cryptographic erasure (when supported). Some commands can take many hours to complete while others may take less than a minute. This tool is designed to erase data which will be lost forever so be sure to back up important data before using this tool. Actually, you should always maintain ongoing backups of your important data even if you do not intend to erase your drive. Seagate is not responsible for lost user data.

openSeaChest_Firmware - Seagate products are run by firmware. Having the latest firmware can improve performance and or reliability of your product. Seagate recommends applying new firmware to enhance the performance and or reliability of your drive. Most products may see one or two firmware updates within the early life of the product.

openSeaChest_Format - Storage products which utilize the SAS, SCSI or Fibre Channel interfaces are able to perform a full low-level media format in the field. The SCSI Format Unit command offers many specialty options to accommodate a variety of conditions and to fine tune the procedure. This complex command deserves its own "break out" utility.

openSeaChest_GenericTests - Read Tests are the original disk drive diagnostic which is to just read every sector on the drive, sequentially. This tool offers several common read tests which can be defined by either time or range. In addition, the Long Generic test has the ability to repair problem sectors, possibly eliminating an unnecessary drive return.

openSeaChest_Info - Historical generic activity logs (like total bytes written and power on hours) and performance logs (like temperature) are available for analytical review. Identification and inquiry data stored on the drive is also provided. A view of SMART and Device Statistics is available when supported by the drive.

openSeaChest_Logs - Several binary logs are maintained on disk drives. These logs are not stored in the user data area. Sometimes these logs are reviewed by support engineers to help analyze event history on the device. These binary data logs are saved to filenames using the drive's serial number and date-time. Some logs are Seagate-specific while many others are common to the interface specifications. Several of these binary logs may be parsed into human-readable form by using the openSeaChest_LogParser utility.

openSeaChest_NVMe - NVMe interface devices tend to have unique commands and challenges. Many of these commands are also unique to NVMe SSD products. This tool gathers the most important commands under one title. This tool is similar to openSeaChest_Basics but for NVMe.

openSeaChest_PassThroughTest - A comprehensive command line tool that can be used to identify and analyze the unique quirks which may be present in a USB-to-SATA or USB-to-NVMe bridge adapter. The findings from this tool are studied to help optimize openSeaChest libraries to send the best and safest device interface commands, which are passed through to the storage device.

openSeaChest_PowerControl - Disk drives offer a multitude of options to manage power. This tool manipulates the various power modes. Some power commands are Seagate-specific while many others are common to the interface specifications.

openSeaChest_Reservations - A tool to assist with persistent reservations available on SAS drives and supported NVMe drives. NOTE: NVMe support under Windows is unavailable. See https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/nvme-features-supported-by-stornvme for detail on which features are supported by the StorNVMe Miniport driver in Windows.

openSeaChest_Security - Various settings are available on modern Seagate disk drives which may be locked and unlocked. These settings may interact with the operating systems and systems BIOS. Options also include ATA Security Erase for SATA interface drives.

openSeaChest_SMART - This tool provides a closer look at the collected SMART attributes data. SMART stands for Self-Monitoring, Analysis and Reporting Technology. Short Drive Self Test is included as one of the standard SMART commands. In addition, the DST & Clean test has the ability to repair problem sectors, possibly eliminating an unnecessary drive return.

Important Notes

If this is your drive, you should always keep a current backup of your important data.

Many tests and commands are completely data safe, while others will change the drive (like firmware download or data erasure or setting the maximum capacity, etc). Be careful using openSeaChest because some of the features, like the data erasure options, will cause data loss. Some commands, like setting the maximum LBA, may cause existing data on the drive to become inaccessible. Some commands, like disabling the read look ahead buffer, may affect the performance of the drive. Seagate is not responsible for lost user data.

Important note: Many tests in this tool directly reference storage device data sectors, also known as Logical Block Addresses (LBA). Test arguments may require a starting LBA or an LBA range. The predefined variable 'maxLBA' refers to the last sector on the drive. Many older SATA and SAS storage controllers (also known as Host Bus Adapters [HBA]) have a maximum addressable limit of 4294967295 [FFFFh] LBAs hard wired into their design. This equates to 2.1TB using 512 byte sectors. This also means accessing an LBA beyond the 2.1TB limitation either will result in an error or simply the last readable LBA (usually LBA 4294967295 [FFFFh]) depending on the actual hardware. This limitation can have important consequences. For example, if you intended to erase a 4TB drive, then only the first 2TB will actually get erased (or maybe even twice!) and the last 2TB will remain untouched. You should carefully evaluate your system hardware to understand if your storage controllers provide support for greater than 2.1TB.

Note: One gigabyte, or GB, equals one billion bytes when referring to hard drive capacity. This software may use information provided by the operating system to display capacity and volume size. The Windows file system uses a binary calculation for gibibyte or GiB (2^30) which causes the abbreviated size to appear smaller. The total number of bytes on a disk drive divided by the decimal calculation for gigabyte or GB (10^9) shows the expected abbreviated size. See this FAQ for more information http://knowledge.seagate.com/articles/en_US/FAQ/172191en?language=en_US.

Binary Availability

BINARIES and SOURCE CODE files of the openSeaChest open source project have been made available to you under the Mozilla Public License 2.0 (MPL-2.0). The openSeaChest project repository is maintained at https://github.com/Seagate/openSeaChest.

Compiled binary versions of the openSeaChest utilities for various operating systems may be found at https://github.com/Seagate/ToolBin/tree/master/openSeaChest or in the releases section of this project.

This collection of storage device utility software is branched (forked) off of an original utility collection called the Seagate SeaChest Utilities by Seagate Technology LLC. The original SeaChest Utilities are still available at www.seagate.com or https://github.com/Seagate/ToolBin/tree/master/SeaChest. Binary versions are available for Linux or Windows, with the Windows versions signed by Seagate Technology LLC.

Repository Availability

With help from various community members across distributions, openSeaChest may be available from within your package manager.

Please be aware this list may not be complete. Seagate is happy to work with community members to help make openSeaChest available in other package repositories as well. Please reach out through an issue and we will do our best to help make it more available when possible.

The libraries

opensea-common - Operating System common operations, not specific to storage standards. Contains functions and defines that are useful to all other libraries.

opensea-transport - Contains standard ATA/SCSI/NVMe functions based on open standards for these command sets. This layer also supports different transporting these commands through operating systems to the storage devices. Code depends on opensea-common.

opensea-operations - Contains common use cases for operations to be performed on a storage device. This layer encapsulates the nuances of each command set (ATA/SCSI) and operating systems (Linux/Windows etc.) Depends on opensea-common and opensea-transport.

Source

Depending on your git version & client you can use either of the following two commands to clone the repository.

git clone --recurse-submodules -j8 https://github.com/Seagate/openSeaChest.git

or

git clone --recursive https://github.com/Seagate/openSeaChest.git

Note that cloning recursively is important as it clones all the necessary submodules.

See BUILDING.md for more information about how to use git.

Source Compatibility with various OSs

OpenSeaChest strives to be made available on any platform and any processor. Support for platforms has been added upon request from customers and issues that are created on this repository. The following tables illustrate platform support that exists today, at least in source code form, and contains notes about other platforms that are not currently supported, but may be possible to support. The list may not be complete. Feel free to request other OS support as well, but it may require more research or development in order to support. Please create an issue to request support for these other platforms when you need it!

SAS/SATA Compatibility

OS	Supported?	Notes
Windows	Yes	Windows vista and higher are supported
Linux	Yes	libATA blocks ATA security commands be default. Can add kernel parameter to disable this block. Only SG_IO IOCTL support implemented for version 3 today. HDIO support is not available. Should work on any 2.6 and later kernel. Earlier kernels may work too, but has not been tested.
FreeBSD	Yes	No known limitations at this time
UEFI Shell	Yes, but not currently maintained	While source code support is largely maintained for UEFI, it has not been updated or built due to many significant limitations on shipping systems. Some do not include the ATA driver that can respond to passthrough requests, only a block driver is available to allow booting the system. We are happy to revive this and find a way to add CI for this upon request.
Solaris	Yes	This column is for the Oracle release of Solaris. USCSI ioctl support is implemented for passthrough support. No known limitations at this time.
Illumos	Yes	This column is for Illumos based distributions/openSolaris. Uses same USCSI ioctl as Solaris. No known limitations at this time.
AIX	Yes	Support for SATA and SAS is available. Code was tested on version 7.1, but may work on earlier versions. Some flags may need adjusting for earlier systems. Build was completed using GCC available in AIX toolkit with gmake. Only rhdisk handles are supported. pdisk support is not known since IBM does not appear to provide information on passing requests through RAID with what is normally available.
ESXI	Yes	Uses SG_IO v3 like Linux through compatibility layer. Requires complicated build system with special GCC build/VM from VMWare and some other development packges installed to compile.
NetBSD	No, but possible
OpenBSD	No, but possible

NVMe Compatibility

OS	Supported?	Notes
Windows 10 & later	Yes	Microsoft driver has many limitations, but many are documented online. Sometimes need to use SCSI translation.
Windows 8.1	Limited	Mostly limited to SCSI translation except for FW update.
Windows 7	Limited	Entirely limited to SCSI translation
Windows openFabrics compatible driver	Yes	Supported, but may be limited to what commands are allowed by the driver (at least in latest openSource code). Some vendor's NVMe drivers reuse the IOCTL for passthrough from this driver and may be supported.
Linux	Yes	Using built-in kernel driver and IOCTLs
FreeBSD	Yes
UEFI Shell	Yes, but not currently maintained	While source code support is largely maintained for UEFI, it has not been updated or built due to many significant limitations on shipping systems. Some systems do not include an NVMe driver that can respond to passthrough requests, only a block driver is available to allow booting the system. We are happy to revive this and find a way to add CI for this upon request.
Solaris	No, but possible	This column is for the Oracle release of Solaris. Possible to support NVMe through UNVME ioctl.
Illumos	No, but possible	Been a while since last looked at, but appeared limited in what commands were available.
AIX	Yes, untested	Implemented according to header from AIX 7.2, but support has not been tested
ESXI	Yes	Requires complicated build system with special GCC build/VM from VMWare and some other development packges installed to compile.
NetBSD	No, but possible
OpenBSD	No, but possible

Building

See BUILDING.md for information on how to build the openSeaChest tools on Windows, Linux, FreeBSD, and Solaris/Illumos.

Contributions & Issues

See CONTRIBUTING.md for more information on contributions that will be accepted. This document also describes how to create an issue, generate a pull request, and licenses that will be accepted.

Security policy

See SECURITY.md for information on Seagate's security policy for details on how to report security vulnerabilities.

Names, Logos, and Brands

All product names, logos, and brands are property of their respective owners. All company, product and service names mentioned in the source code are for clarification purposes only. Use of these names, logos, and brands does not imply endorsement.

Support and Open Source Statement

Support from Seagate Technology for open source projects is different than traditional Technical Support. If possible, please use the Issues tab in the individual software projects so that others may benefit from the questions and answers. Include the output of --version information in the message. See the user guide section 'General Usage Hints' for information about saving output to a log file.

If you need to contact us through email, please choose one of these two email addresses:

• [email protected] for general questions and bug reports
• [email protected] for specific questions about programming and building the software

Seagate offers technical support for drive installation. If you have any questions related to Seagate products and technologies, feel free to submit your request on our web site. See the web site for a list of world-wide telephone numbers.

• http://www.seagate.com/support-home/
• Contact Us: http://www.seagate.com/contacts/

This software uses open source packages obtained with permission from the relevant parties. For a complete list of open source components, sources and licenses, please see our Linux USB Boot Maker Utility FAQ for additional information.

The newest online version of the openSeaChest Utilities documentation, open source usage and acknowledgement licenses, and our Linux USB Boot Maker FAQ can be found at: https://github.com/Seagate/openSeaChest.

Copyright (c) 2014-2022 Seagate Technology LLC and/or its Affiliates, All Rights Reserved

License

BINARIES and SOURCE CODE files of the openSeaChest open source project have been made available to you under the Mozilla Public License 2.0 (MPL). Mozilla is the custodian of the Mozilla Public License ("MPL"), an open source/free software license.

The license can be views at https://www.mozilla.org/en-US/MPL/ or LICENSE.md

openseachest's Issues

Make a CI/CD

Please make a CI/CD so people don't have to go through the build process itself..
Having the tools available just to run is so much faster for us.. so many work hours would be saved..
(windows exe files missing)

Win32 binary

Win32 binary release won't run on Windows 2003 R2 Server (non valid Win32 app error), it's either a 64 bit app or is not compatible with legacy OSes?

Remove "sas" tag

The vast majority of repositories under the "SAS" tag are in relation to SAS Software, not Serial Attached SCSI.

Would you consider removing or re-naming the SAS tag in this repo? Given you are in the top 10 repositories for "sas" !

https://github.com/topics/sas

Text files (.txt) a bit out of date compared with ToolBin

Comparing

https://github.com/Seagate/openSeaChest/tree/develop/docs

with

https://github.com/Seagate/ToolBin/tree/master/openSeaChest/docs

I see that the ToolBin docs are newer versions.

Not a big deal.

fatal error: format.h: No such file or directory

When running make release in Make/gcc of commit 5715ef44078a1dfcc63220543717459b35eac782, i get:

mkdir -p openseachest_exes
cc -Wall -c -std=gnu99 -O3 -I../../opensea-common/include -I../../opensea-transport/include -I../../opensea-transport/include/vendor -I../../include -I../../opensea-operations/include -DDISABLE_TCG_SUPPORT ../../utils/C/openSeaChest/openSeaChest_Erase.c -o ../../utils/C/openSeaChest/openSeaChest_Erase.o
../../utils/C/openSeaChest/openSeaChest_Erase.c:45:20: fatal error: format.h: No such file or directory
 #include "format.h"
                    ^
compilation terminated.
Makefile:245: recipe for target '../../utils/C/openSeaChest/openSeaChest_Erase.o' failed
make: *** [../../utils/C/openSeaChest/openSeaChest_Erase.o] Error 1

This can be fixed with:

cp ../../opensea-operations/include/format.h ../../include/

Is there any way to verify a Secure Erase or Sanitize operation completed successfully?

Often implementations, bugs and other such glitches mean that a finished command doesn't always run as it should, and when it comes to security, it's often necessary (and part of most modern data sanitisation standards like NIST 800-88) to verify that a wipe was actually completed.

If running an ordinary wipe using something like dd, I'd just check that there no non-zero characters on the disk. However, I'm guessing that due to the firmware nature of the ATA Secure Erase and Block Erase commands, this will be more complicated, and I've so far been unable to find a command in the Erase binary that will verify these operations.

Does the suite provide any way to verify that a Secure Erase or Block Erase operation completed successfully?

Solaris binary for openSeaChest_Security requested

Is it possible for you to rebuild The openSeaChest_Security binary on Solaris for me using the latest code so I can make use of the new features you have added regarding ATA Password management?

Unfortunately you have not yet shared the modules publicly for me to build this myself.

Achelon

build failure: undeclared identifier 'BLOCK_SIZE'

On FreeBSD, I see build failure with release 21.06.21:

cc -O2 -pipe -Werror=date-time -march=broadwell  -Wall -c -std=gnu99 -fstack-protector-strong -fno-strict-aliasing  -fdebug-prefix-map=/wrkdirs/usr/ports/sysutils/openseachest/work/openSeaChest-21.06.21=. -O3 -I../../opensea-common/include -I../../opensea-transport/include -I../../opensea-transport/include/vendor -I../../include -I../../opensea-operations/include -DDISABLE_TCG_SUPPORT ../../utils/C/openSeaChest/openSeaChest_NVMe.c -o ../../utils/C/openSeaChest/openSeaChest_NVMe.o
../../utils/C/openSeaChest/openSeaChest_NVMe.c:1279:33: error: use of undeclared identifier 'BLOCK_SIZE'
                uint32_t size = BLOCK_SIZE;
                                ^
../../utils/C/openSeaChest/openSeaChest_NVMe.c:1300:31: error: use of undeclared identifier 'BLOCK_SIZE'
                    offset += BLOCK_SIZE;
                              ^
../../utils/C/openSeaChest/openSeaChest_NVMe.c:1314:49: error: use of undeclared identifier 'BLOCK_SIZE'
                            fullSize = offset + BLOCK_SIZE * teleHdr->teleDataArea1;
                                                ^
../../utils/C/openSeaChest/openSeaChest_NVMe.c:1319:49: error: use of undeclared identifier 'BLOCK_SIZE'
                            fullSize = offset + BLOCK_SIZE * teleHdr->teleDataArea2;
                                                ^
../../utils/C/openSeaChest/openSeaChest_NVMe.c:1324:49: error: use of undeclared identifier 'BLOCK_SIZE'
                            fullSize = offset + BLOCK_SIZE * teleHdr->teleDataArea3;
                                                ^
../../utils/C/openSeaChest/openSeaChest_NVMe.c:1344:43: error: use of undeclared identifier 'BLOCK_SIZE'
                                offset += BLOCK_SIZE;
                                          ^
../../utils/C/openSeaChest/openSeaChest_NVMe.c:1350:157: error: use of undeclared identifier 'BLOCK_SIZE'
                                        printf("Error: Could not retrieve Log Page %" PRIu8 " for offset %" PRIu64 "\n", GET_TELEMETRY_IDENTIFIER, offset - BLOCK_SIZE);
                                                                                                                                                            ^
../../utils/C/openSeaChest/openSeaChest_NVMe.c:1382:47: error: use of undeclared identifier 'BLOCK_SIZE'
                                    offset += BLOCK_SIZE;
                                              ^
../../utils/C/openSeaChest/openSeaChest_NVMe.c:1388:161: error: use of undeclared identifier 'BLOCK_SIZE'
                                            printf("Error: Could not retrieve Log Page %" PRIu8 " for offset %" PRIu64 "\n", GET_TELEMETRY_IDENTIFIER, offset - BLOCK_SIZE);
                                                                                                                                                                ^
9 errors generated.

Exos X16 doesn't offer setSectorSize

Thanks for the OSS tooling to manipulate the advanced features of Seagate drives! I really appreciate it.

I have a bunch of new Exos X16 drives, model ST16000NM001G-2KK103 with firmware revision SN03. According to the datasheet for the drive, it's a 512E drive that should support FastFormat to switch to 4k blocks.

However with openSeaChest compiled at HEAD on linux, neither "fast format" nor "set sector size" are listed in the supported features:

$ ./openSeaChest_Configure -d /dev/sda -i
==========================================================================================
 openSeaChest_Configure - openSeaChest drive utilities - NVMe Enabled
 Copyright (c) 2014-2021 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_Configure Version: 2.0.0-2_1_0 X86_64
 Build Date: Jan 27 2021
 Today: Wed Jan 27 22:15:16 2021	User: root
==========================================================================================

/dev/sda - ST16000NM001G-2KK103 - ZL27EN69 - ATA
	Model Number: ST16000NM001G-2KK103
	Serial Number: ZL27EN69
	Firmware Revision: SN03
	World Wide Name: 5000C500C7556E6E
	Drive Capacity (TB/TiB): 16.00/14.55
	Temperature Data:
		Current Temperature (C): 31
		Highest Temperature (C): 37
		Lowest Temperature (C): 28
	Power On Time:  12 days 10 hours 
	Power On Hours: 298.00
	MaxLBA: 31251759103
	Native MaxLBA: Not Reported
	Logical Sector Size (B): 512
	Physical Sector Size (B): 4096
	Sector Alignment: 0
	Rotation Rate (RPM): 7200
	Form Factor: 3.5"
	Last DST information:
		DST has never been run
	Long Drive Self Test Time:  23 hours 49 minutes 
	Interface speed:
		Max Speed (Gb/s): 6.0
		Negotiated Speed (Gb/s): 6.0
	Annualized Workload Rate (TB/yr): 10.83
	Total Bytes Read (GB): 190.47
	Total Bytes Written (GB): 178.10
	Encryption Support: Not Supported
	Cache Size (MiB): Not Reported
	Read Look-Ahead: Enabled
	Write Cache: Enabled
	Low Current Spinup: Disabled
	SMART Status: Unknown or Not Supported
	ATA Security Information: Supported
	Firmware Download Support: Full, Segmented
	Specifications Supported:
		ACS-4
		ACS-3
		ACS-2
		ATA8-ACS
		ATA/ATAPI-7
		ATA/ATAPI-6
		ATA/ATAPI-5
		SATA 3.2
		SATA 3.1
		SATA 3.0
		SATA 2.6
		SATA 2.5
		SATA II: Extensions
		SATA 1.0a
		ATA8-AST
	Features Supported:
		Sanitize
		SATA NCQ
		SATA Software Settings Preservation [Enabled]
		SATA Device Initiated Power Management
		Power Management
		Security
		SMART [Enabled]
		48bit Address
		PUIS
		GPL
		Streaming
		SMART Self-Test
		SMART Error Logging
		Write-Read-Verify
		DSN
		AMAC
		EPC [Enabled]
		Sense Data Reporting [Enabled]
		SCT Write Same
		SCT Error Recovery Control
		SCT Feature Control
		SCT Data Tables
		Host Logging
		Seagate In Drive Diagnostics (IDD)
	Adapter Information:
		Vendor ID: 1AF4h
		Product ID: 0008h
		Revision: Not available.

As expected, if I try to format anyway, I just get errors that the drive doesn't support those commands. As a result, AFAICT I'm unable to switch to 4k sectors.

Is this something I'm doing wrong, or is there something missing in openSeaChest to support these drives?

Which Secure Erase command will clear the HPA and DCO hidden areas?

Firstly, thanks for a great set of tools. As someone who securely wipes hard drives as a part-time job, I've been looking for a replacement to perform Secure Erase on ATA hard drives ever since hdparm stopped being maintained on Cygwin, so it's good to finally have something.

Looking at the Erase binary, I see the following:

    --ataSecureErase [normal | enhanced]            (SATA only)
            Use "normal" to start a standard ATA security erase
            or "enhanced" to start an enhanced ATA security erase.

            ATA Security Erase takes a very long time to complete at
            approximately three (3) hours per Tera-byte (HDD). Some Seagate
            SED models will perform a quick cryptographic erase in enhanced
            mode and the time for completion is reported as 2 minutes by
            the drive, but will take only seconds. This industry
            standard command begins by locking the drive with a temporary
            password which is cleared at the end of the erasure. Do not run
            this command unless you have ample time to allow it to run
            through to the end. If the procedure is interrupted prior to
            completion, then the drive will remain in a locked state and
            you must manually restart from the beginning again. The
            tool will attempt to automatically clear the password that was set
            upon failure. The default password used by the tool is
            "SeaChest", plain ASCII letters without the quotes

            * normal writes binary zeros (0) or ones (1) to all user
            data areas.

            * enhanced will fill all user data areas and reallocated
            user data with a vendor specific pattern. Some Seagate
            Instant Secure Erase will perform a cryptographic
            erase instead of an overwrite.

    --sanitize [info | blockerase | cryptoerase |
                overwrite | freezelock | antifreezelock]
            Use the info argument to show supported sanitize operations.
            Optionally, use blockerase, cryptoerase, or overwrite to start
            a sanitize operation. Adding the --poll option will cause
            openSeaChest_Erase to poll the drive for progress until the
            operation is complete, or has aborted for some reason. All
            sanitize erase operations are persistent across a power cycle
            and cannot be stopped
            Example: --sanitize blockerase --poll

            Note: Windows 8 and higher block sanitize commands. Sanitize
            operations will show a failure status on these systems.

            * blockerase on some solid state drives is very fast at less
            than one (1) second, while others may take more that 30 seconds
            This operation performs a physical low level block erase
            operation on all current, past, and potential user data.
            The contents on user data are indeterminate upon completion.

As far as I can make out, both of these commands wipe only user-accessible areas, which generally wouldn't include hidden areas like the HPA and the DCO.

Do any of these commands wipe these hidden areas in spite of what their documentation seems to say? If not, is there a command in the suite that does?

FreeBSD NVME support

openSeaChest needs to be able to talk to FreeBSD nvme driver. As far as I'm aware just needs low level plumbing

data cmplt err -75 & -71

On a brand new WD green SSD (SATA, 480GB), plugged via this enclosure, any openSeaChest operation triggers the following warning:

sd 3:0:0:0: [sg3] tag#28 data cmplt err -75 uas-tag 1 inflight: CMD 
sd 3:0:0:0: [sg3] tag#28 CDB: Report luns a0 00 00 00 00 00 00 00 00 08 00 00
sd 3:0:0:0: [sg3] tag#29 data cmplt err -71 uas-tag 1 inflight: CMD 
sd 3:0:0:0: [sg3] tag#29 CDB: Inquiry 12 01 00 00 60 00

Activating && or || depending on short DST result with different Error Levels for failing disks and empty slots

I want to start automatic short self-tests every week, and launch a warning message with && or || if there are errors. At first, I was looking at smartctl, but that always returns an exit code of 0 as soon as the test begins, even if it completes with errors. It appeared openSeaChest provided this functionality, as there is a long list of exit codes including 3 for Operation Failure, but only --shortGeneric waits to send an exit code until finished, while --shortDST always activates && after starting. There should be a --shortDST option that waits to send an exit code until completion.

Both --shortDST and --shortGeneric activate || if a disk with the specified number is not connected. It's not practical to have failure warnings appear when a disk doesn't happen to be available at a specified number (such as PD4, which may be empty most of the time). I understand || is activated by anything above 0, so it will be activated even if the Error Code for failing and unavailable disks is different, but echo %ErrorLevel% shows that 3 is the Error Code for an empty slot, so it is the same Error Code as when disks fail with errors, assuming Error Code 3 is even used for failed tests.

Feature Request: CLI flag to control the units used when displaying drive size

I am requesting a cli flag to control the units used to report drive size.

In GNU Parted, for example, the user can specify s for sectors, unit b for bytes, k for kb, m for mb, mib for MiB, etc, and all sizes displayed are in that unit.

In openSeaChest -i, afaict, it 'optimizes' automatically to display in 4 digits or less. That's great for humans. --less so for scripts. I'd like to see a cli flag like -u --unit. h or a could mean human or auto, the default. s for sectors, b for bytes. mb for megabytes, mib for mibibytes, etc.

release tarballs aren't buildable

The release tarballs don't include the git submodules, which makes them unbuildable. Tested on OpenSeaChest 18.04 with the release tarball posted on GitHub.

Proprietary SeaChest bootable does not allow erasing non-Seagate disks

I have a Western Digital Black WD6003FZBX that fell-apart after 5 weeks, since Western Digital has become a scam company. It cannot be recognized by any tool in Windows, Linux, or FreeBSD. It does appear in the firmware settings of a computer with Legacy BIOS. SeaTools Bootable with the proprietary version of SeaChest is the only thing able to recognize the WD6003FZBX besides the BIOS on that computer, but it cannot erase the HDD because it is non-Seagate. The WD Black is connected directly with SATA.

Is there a flag to bypass this? Why is this restriction in place? I don't care if it's bricked by not being compatible with Western Digital's proprietary secrets, because it is already bricked and absolutely nothing else is able to recognize it anyway. It needs to be formatted before sending it in for warranty, since it has terabytes of personal files.

No such file or directory when trying to build with MSYS2

I'm trying to build a Windows version of the tools using MSYS2, so that I can then run the binaries under Cygwin.

Here's what I've done so far using MSYS2, following the README in the gccWin folder:

1. Run pacman -S --needed base-devel mingw-w64-x86_64-toolchain and installed all packages
2. Added C:\msys64\usr\bin and C:\msys64\mingw64\bin to my PATH
3. Run pacman -S git
4. List branches with: git ls-remote --heads https://github.com/Seagate/openSeaChest.git | sed 's?.*refs/heads/??'
5. Run git clone --recurse-submodules --branch develop --single-branch https://github.com/Seagate/openSeaChest.git openSeaChest
6. cd into openSeaChest and run git submodule foreach --recursive 'git checkout develop'
7. cd into Make/gccWin/ and run make -f Makefile.gccWin

At the very last step, I get a fatal error:

$ make -f Makefile.gccWin rm -f *.o *.a openseachest_exes/openSeaChest_* rm -f ../../src/*.o rm -f ../../utils/C/openSeaChest/*.o rm -rf openseachest_exes rm -f *.o *.a make -C ../../opensea-common/Make/gccWin -f Makefile.gccWin clean make[1]: Entering directory '/openSeaChest/opensea-common/Make/gccWin' rm -f lib/libopensea-common.a lib/libopensea-common.so.1.18.0 *.o ../../src/*.o rm -rf lib make[1]: Leaving directory '/openSeaChest/opensea-common/Make/gccWin' make -C ../../opensea-transport/Make/gccWin -f Makefile.gccWin clean make[1]: Entering directory '/openSeaChest/opensea-transport/Make/gccWin' rm -f lib/libopensea-transport.a lib/libopensea-transport.so* *.o ../../src/*.o rm -rf lib make[1]: Leaving directory '/openSeaChest/opensea-transport/Make/gccWin' make -C ../../opensea-operations/Make/gccWin -f Makefile.gccWin clean make[1]: Entering directory '/openSeaChest/opensea-operations/Make/gccWin' rm -f lib/libopensea-operations.a lib/libopensea-operations.so.1.20.0 libopensea-operations.so *.o ../../src/*.o rm -rf lib make[1]: Leaving directory '/openSeaChest/opensea-operations/Make/gccWin' mkdir -p openseachest_exes gcc -Wall -Wextra -Wno-format -c -std=gnu99 -isystem -O3 -I../../opensea-common/include -I../../opensea-transport/include -I../../opensea-transport/include/vendor -I../../opensea-operations/include -I../../include -DSTATIC_OPENSEA_TRANSPORT -DSTATIC_OPENSEA_OPERATIONS -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -DENABLE_CSMI -DWIN_API_TARGET_VERSION=100162990L -DDISABLE_TCG_SUPPORT ../../utils/C/openSeaChest/openSeaChest_Basics.c -o ../../utils/C/openSeaChest/openSeaChest_Basics.o make: gcc: No such file or directory make: *** [Makefile.gccWin:425: ../../utils/C/openSeaChest/openSeaChest_Basics.o] Error 127

From what I understand I'm missing an object file - if so, why would this be?

openSeaChest_Logs: FARM data in stdout

It would be nice if we can pipe the FARM data from openSeaChest_Logs to openSeaChest_LogParser and not go through a file on disk (i.e. openSeaChest_Logs --farm -o - | openSeaChest_LogParser ...).
Currently, the openSeaChest_Logs saves the data to a file. That takes a little logic to find what the file name is (need the serial number and the time the log was generated), it's more automation friendly to allow piping.

Problems scanning Seagate IronWolf disk thorough PCIe controller

Hello xahmad,

I noticed that there have been some problems scanning disks attached to pcie controllers..

"
$$ openSeaChest_Basics --scan

openSeaChest_Basics - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2018 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Basics Version: 2.8.0-1_19_0 ARM
Build Date: Feb 28 2019
Today: Sat Mar 2 18:13:39 2019

open: Bad address
open failure
Error: 14 - Bad address
open: Bad address
open failure
Error: 14 - Bad address
"
I know that openSeachest tools offers options for "pass-through":
ata - show only ATA (SATA) devices
usb - show only USB devices
scsi - show only SCSI (SAS) devices
interfaceATA - show devices on an ATA interface
interfaceUSB - show devices on a USB interface
interfaceSCSI - show devices on a SCSI or SAS interface
sd - show sd device handles
sgtosd - show the sd and sg device handle mapping

Is there any option for PCIe controllers that work?
Nowadays Pcie controllers are very used due to their bandwidth and amount of drives we can put there..

Does you know how to surpasse this?
Thanks in Advance for your time.

Unable to change powermode seagate expansion +

Hi.
I have an issue with my new 2.5"HDD, where it doesn't automatically spin down or go in to sleep mode. I have tried installing openSeaChest with the latest git pull. unfortunately I'm unable to change the power settings on it, and get this error message:

/dev/sg0 - Expansion+ - NA***** - SCSI
Failed to check if drive supports modifying power conditions!
ERROR: Could not change power mode settings.

It also seems to me that I don't get all the info from the HDD:

---

openSeaChest_Basics - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2020 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Basics Version: 2.9.0-1_21_12 X86_64
Build Date: Jan 25 2020
Today: Sat Jan 25 00:42:20 2020

/dev/sg0 - Expansion+ - NA***** - SCSI
Vendor ID: Seagate
Model Number: Expansion+
Serial Number: NA******
Firmware Revision: 9300
World Wide Name: 5000000000000001
Drive Capacity (TB/TiB): 5.00/4.55
Temperature Data:
Current Temperature (C): Not Reported
Highest Temperature (C): Not Reported
Lowest Temperature (C): Not Reported
Power On Time: Not Reported
Power On Hours: Not Reported
MaxLBA: 9767541166
Native MaxLBA: Not Reported
Logical Sector Size (B): 512
Physical Sector Size (B): 4096
Sector Alignment: 0
Rotation Rate (RPM): Not Reported
Form Factor: Not Reported
Last DST information:
Not supported
Long Drive Self Test Time: Not Supported
Interface speed:
Not Reported
Annualized Workload Rate (TB/yr): Not Reported
Total Bytes Read (B): Not Reported
Total Bytes Written (B): Not Reported
Encryption Support: Not Supported
Cache Size (MiB): Not Reported
Read Look-Ahead: Enabled
Write Cache: Enabled
SMART Status: Unknown or Not Supported
ATA Security Information: Not Supported
Firmware Download Support: Full, Segmented
Specifications Supported:
SPC-4
SBC-3
UAS
SPC-4
Features Supported:
Power Conditions
Informational Exceptions [Mode 0]
Adapter Information:
Vendor ID: 0BC2h
Product ID: 2323h
Revision: 0000h

Is this a bug within the openSeaChest, or is it just the lack of support from the HDD firmware?

Can't build openSeaChest_Security

Hi,

I have been trying to compile this toolset on Solaris 11.3 and everything builds fine but openSeaChest_Security is never generated and the source files required to compile it don't seem to be included. Is this by design or in error?

Advice appreciated.

Regards,
Achelon

error: conflicting types for '__uintptr_t'

The build fails on FreeBSD 11.2 because openSeaChest defines __uintptr_t differently than the system's C library. Tested with git head @1d5cadd.

> gmake release
mkdir -p openseachest_exes
gmake -C ../../opensea-common/Make/gcc
gmake[1]: Entering directory '/usr/home/somers/src/github/seagate/openSeaChest/opensea-common/Make/gcc'
rm -f lib/libopensea-common.a lib/libopensea-common.so.1.17.5 *.o ../../src/*.o
rm -rf lib
mkdir -p lib
gcc -Wall -c -std=gnu99 -O3 -c -fPIC -I. -std=gnu99 -DDISABLE_TCG_SUPPORT  -I../../include ../../src/common.c -o ../../src/common.o
gcc -Wall -c -std=gnu99 -O3 -c -fPIC -I. -std=gnu99 -DDISABLE_TCG_SUPPORT  -I../../include ../../src/common_platform.c -o ../../src/common_platform.o
gcc -Wall -c -std=gnu99 -O3 -c -fPIC -I. -std=gnu99 -DDISABLE_TCG_SUPPORT  -I../../include ../../src/common_nix.c -o ../../src/common_nix.o
rm -f lib/libopensea-common.a
ar cq lib/libopensea-common.a ../../src/common.o ../../src/common_platform.o ../../src/common_nix.o
gmake[1]: Leaving directory '/usr/home/somers/src/github/seagate/openSeaChest/opensea-common/Make/gcc'
gmake -C ../../opensea-transport/Make/gcc
gmake[1]: Entering directory '/usr/home/somers/src/github/seagate/openSeaChest/opensea-transport/Make/gcc'
rm -f lib/libopensea-transport.a lib/libopensea-transport.so* *.o ../../src/*.o
rm -rf lib
mkdir -p lib
gcc -Wall -c -std=gnu99 -O3 -c -fPIC -I. -std=c99 -DDISABLE_TCG_SUPPORT -D_GNU_SOURCE  -I../../include -I../../../opensea-common/include   ../../src/ata_cmds.c -o ../../src/ata_cmds.o
gcc -Wall -c -std=gnu99 -O3 -c -fPIC -I. -std=c99 -DDISABLE_TCG_SUPPORT -D_GNU_SOURCE  -I../../include -I../../../opensea-common/include   ../../src/ata_legacy_cmds.c -o ../../src/ata_legacy_cmds.o
gcc -Wall -c -std=gnu99 -O3 -c -fPIC -I. -std=c99 -DDISABLE_TCG_SUPPORT -D_GNU_SOURCE  -I../../include -I../../../opensea-common/include   ../../src/ata_helper.c -o ../../src/ata_helper.o
gcc -Wall -c -std=gnu99 -O3 -c -fPIC -I. -std=c99 -DDISABLE_TCG_SUPPORT -D_GNU_SOURCE  -I../../include -I../../../opensea-common/include   ../../src/cmds.c -o ../../src/cmds.o
In file included from ../../include/nvme_helper_func.h:18:0,
                 from ../../src/cmds.c:18:
../../include/nvme_helper.h:18:23: error: conflicting types for '__uintptr_t'
 typedef unsigned int* __uintptr_t;
                       ^~~~~~~~~~~
In file included from /usr/include/machine/_types.h:6:0,
                 from /usr/include/sys/_types.h:33,
                 from /usr/include/stdio.h:41,
                 from ../../../opensea-common/include/common.h:34,
                 from ../../include/common_public.h:17,
                 from ../../include/cmds.h:16,
                 from ../../src/cmds.c:15:
/usr/include/x86/_types.h:114:20: note: previous declaration of '__uintptr_t' was here
 typedef __uint64_t __uintptr_t;
                    ^~~~~~~~~~~
gmake[1]: *** [Makefile:98: ../../src/cmds.o] Error 1
gmake[1]: Leaving directory '/usr/home/somers/src/github/seagate/openSeaChest/opensea-transport/Make/gcc'
gmake: *** [Makefile:181: opensea-libs] Error 2

With disk permissions, -s gives warning but does not output data without root access/sudo

After a recent change, with disk access, openSeaChest now outputs drive data with the -i flag without root/sudo while only producing a warning rather than an error. However, even with disk permissions, when running a scan with -s, a warning is still produced but no data is outputted unless run with root/sudo.

Do not assume that Linux is using LGPL GNU libc

openSeaChest/src/EULA.c

Lines 415 to 417 in 7e4e2d1

	#elif defined (__linux__)
	//in other 'nix systems, we need to show this since we are using gnu libc
	print_GNU_LGPL_License();

Linux does not necessarily use GNU libc. For example, MIT-license musl could be used instead. I propose to check if __GLIBC__ is defined instead of __linux__.

Errors on Solaris 11.4

Hi,

I have been testing this application on the newly released Solaris 11.4 and am receiving errors in the system log that did not occur in Solaris 11.3. While I appreciate this may indicate a regression within the Operating System itself, I'd appreciate it if someone could take a look at this and let me know if this is a bug in OpenSeaChest and what the implications of it is.

An example of the issue is as follows. I execute:

sudo ./openSeaChest_Info --deviceInfo --device /dev/rdsk/c1t0d0

The command completes successfully but the system log shows:

Aug 30 21:37:00 ahci: [ID 296163 kern.warning] WARNING: ahci0: ahci port 0 has task file error
Aug 30 21:37:00 ahci: [ID 687168 kern.warning] WARNING: ahci0: ahci port 0 is trying to do error recovery
Aug 30 21:37:00 ahci: [ID 693748 kern.warning] WARNING: ahci0: ahci port 0 task_file_status = 0x451
Aug 30 21:37:00 ahci: [ID 332577 kern.warning] WARNING: ahci0: the below command (s) on port 0 are aborted
Aug 30 21:37:00 ahci: [ID 117845 kern.warning] WARNING: satapkt 0xffffa1c01451f990: cmd_reg = 0x47 features_reg = 0x0 sec_count_msb = 0x0 lba_low_msb = 0x0 lba_mid_msb = 0x0 lba_high_msb = 0x0 sec_count_lsb = 0x1 lba_low_lsb = 0x30 lba_mid_lsb = 0x9 lba_high_lsb = 0x0 device_reg = 0xa0 addr_type = 0x4 cmd_flags = 0x52
Aug 30 21:37:01 ahci: [ID 657156 kern.warning] WARNING: ahci0: error recovery for port 0 succeed
Aug 30 21:37:01 ahci: [ID 811322 kern.info] NOTICE: ahci0: ahci_tran_reset_dport port 0 reset device
Aug 30 21:37:01 scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci103c,1609@11/disk@0,0 (sd0):
Aug 30 21:37:01	disk not responding to selection

Please see attachment seachest_log.txt for verbose log of data exchange with the Seagate drive.

Regards,
Achelon

Pull upstream change of wingetopt

Hi,

When I tried to build on MSVC with meson, it comes up with a linker warning that both debug and release runtime are linked: warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library. This could also be seen in your GitHub Actions: https://github.com/Seagate/openSeaChest/runs/4744648956?check_suite_focus=true

I guess it may due to release / debug build type is not correctly passed from Meson to CMake. So I made a workaround to meson.build like:

if target_machine.system() == 'windows'
  if not c.has_header('getopt.h')
    cmake = import('cmake')

    opt_var = cmake.subproject_options()
    if get_option('debug')
      opt_var.add_cmake_defines({'CMAKE_BUILD_TYPE': 'Debug'})
    else
      opt_var.add_cmake_defines({'CMAKE_BUILD_TYPE': 'Release'})
    endif
    wingetopt = cmake.subproject('wingetopt', options: opt_var)
    wingetopt_dep = wingetopt.dependency('wingetopt')
    os_deps += [wingetopt_dep]
  endif
  windows = import('windows')
  resources = windows.compile_resources('openSeaChest.rc')
  common_sources += [resources]
  add_project_arguments('-D_CRT_SECURE_NO_WARNINGS', language : 'c')
endif

And it works.

Furthermore, I could see that, the upstream wingetopt has updated recently to support Meson: alex85k/wingetopt#3

So I would suggest to pull upstream changes of wingetopt, and thus all subprojects will be all Meson, and also resolve the problem above by the way.

Feature Request: Traditional Linux-style device files in Linux

I understand that the sg driver is capable of more than sd driver, and that it's indeed necessary to work with sg in order to do most of the things that openSeaChest does.

But nobody else, and no other tools in common use in linux touch the sg objects by their /dev/sg# name. I know the sg's exist, but I'm hard pressed to think of the last time I ever referenced them. So I conject that it causes unnecessary confusion and takes unnecessary time to translate between sd* and sg* objects for the user.

Can openSeaChest default to displaying sd* drive names in linux? Or offer it as a command-line flag?

Can't upgrade firmware of ST2000DM001-1CH164

Hello

I'm trying to upgrade the firmware of my ST2000DM001-1CH164 from CC27 to CC29

Machine

CPU : Ryzen 3700X
RAM : 16 GB DDR4 3200 Mhz
Motherboard: Asus X570 Gaming Plus
OS : Arch Linux
Kernel Version : 5.6.4 or 5.4.32-lts (tried with both)

SHA256 of the GBP2TBCC29.LOD file is:

be1c6c79b8da5e2b7caa86f6aa86fd972ebcf88dbd627bc1e71aae487f8e941c

Cannot compare to anything as Seagate does not provide any hash

OpenSeaChest Scan returns

root:Downloads/ # ./openSeaChest_Firmware --scan                                                                                                                                                                                                                              [23:47:33]
==========================================================================================
 openSeaChest_Firmware - openSeaChest drive utilities - NVMe Enabled
 Copyright (c) 2014-2020 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_Firmware Version: 2.8.1-1_21_30 X86_64
 Build Date: Mar  9 2020
 Today: Fri Apr 17 23:47:52 2020
==========================================================================================
Vendor   Handle       Model Number            Serial Number          FwRev     
ATA      /dev/sda     ST2000DM001-1CH164      Z340EMCF               CC27      
ATA      /dev/sdb     Samsung SSD 850 PRO 256GB S251NXAG819278X        EXM04B6Q  
ATA      /dev/sdc     HGST HDN726040ALE614    K3GPBP0L               APGNW7JH  
NVMe     /dev/nvme0n1 Sabrent Rocket 4.0 500GB 036C079A181100340429   RKT401.1  

After running the command

openSeaChest_Firmware -d /dev/sda --downloadFW GBP2TBCC29.LOD

I get the message

root:Downloads/ # ./openSeaChest_Firmware -d /dev/sda --downloadFW GBP2TBCC29.LOD                                                                                                                                                                                             [23:48:30]
==========================================================================================
 openSeaChest_Firmware - openSeaChest drive utilities - NVMe Enabled
 Copyright (c) 2014-2020 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_Firmware Version: 2.8.1-1_21_30 X86_64
 Build Date: Mar  9 2020
 Today: Fri Apr 17 23:49:28 2020
==========================================================================================

/dev/sda - ST2000DM001-1CH164 - Z340EMCF - ATA
.....................................................
Firmware Download successful
Firmware Download time (ms): 189.62
Average time/segment  (ms): 3.57
Activate Time          (ms): 125.28
New firmware version is CC27

So, it did not upgrade the firmware, CC27 is the actual firmware of the device

If I run the same command with verbosity 2 I get

.Sending ATA Download Microcode, subcommand 0x3 Download Microcode returning: FAILURE

Full logs in here: openseachest_logs.zip

All commands run as root

Can you help me?

Cheers

openSeaChest_SMART --smartCheck prints nothing with verbose 0

Hi,
I did this:

D:\dev\SeaChest>builddir\openSeaChest_SMART.exe -d PD1 --smartCheck -v 0

It prints nothing. But with -v 1:

D:\dev\SeaChest>builddir\openSeaChest_SMART.exe -d PD1 --smartCheck -v 1
==========================================================================================
 openSeaChest_SMART - openSeaChest drive utilities - NVMe Enabled
 Copyright (c) 2014-2022 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_SMART Version: 2.1.0-2_4_0 X86_64
 Build Date: Mar  2 2022
 Today: Wed Mar  2 23:15:59 2022        User: thund (admin)
==========================================================================================

\\.\PhysicalDrive1 - ST2000DM008-2FR102 - WFL1XYAL - 0001 - ATA
SMART Check
SMART Check Passed!

I think the result SMART Check Passed! should not be suppressed in verbose=0. Would you like to think over it?

Cross Compilation issue

Hi,

should be nice to have makefile with :
CC ?= gcc
instead of :
CC = gcc

autotools or cmake support

Especially for a "cross platform utility" support for cross compiling is an important issue. Pure makefiles aren't a good way to handle this.

Therefor this project should get support for GNU Autotools or CMake!

Not possible to see FreeFall values in IronWolf Disks

Hello,
I have compiled this set of tools, on Armv7( cortex A9 ), and I have been experimenting with it on linux..

First problem I encoutered:
Compiling the code..
git clone --recursive --branch v19.01.31 https://github.com/Seagate/openSeaChest.git

with make release -j2, I got errors:

cd lib && ln -s libopensea-transport.so* libopensea-transport.so ln: target 'libopensea-transport.so' is not a directory Makefile:101: recipe for target 'libopensea-transport.a' failed make[2]: *** [libopensea-transport.a] Error 1 make[2]: Leaving directory '/opt/openSeaChest/opensea-transport/Make/gcc' Makefile.openSeaChest_firmware:99: recipe for target 'opensea-libs' failed make[1]: *** [opensea-libs] Error 2 make[1]: Leaving directory '/opt/openSeaChest/Make/gcc' Makefile:212: recipe for target 'openSeaChest_Firmware' failed make: *** [openSeaChest_Firmware] Error 2 make: *** Waiting for unfinished jobs....

Probably because of parallel compilation process..
Then I git cloned again, and issued only 'make release', since then it all compiled the last release version..

And all seems ok now.
But 'openSeaChest_Configure', tels me that FreeFal Aceleration values are not availlable.
root@helios4:~# openSeaChest_Configure --device /dev/sda --freeFall info|grep -E "dev|Free" /dev/sg0 - ST4000VN008-2DR166 - ZDH4MM9E - ATA Free Fall control feature is not supported on this device.

Does FreeFall feature is not availlable( for IronWolfs ),
Or the tool is incapable of reporting the values, or they are even static, without possibility to query?
I would like to know, if the discs are capable to detect a FreeFall.

Thanks in Advance for your time, and also for the Seagate tools, its a needed project and a nice one!
Best Regards
tux

Add option to change ready led status on USB Seagate drives e.g. Backup Plus

When you use SeaChest_Basics or SeaChest_Configure and use the --readyLED option, it says it isn't supported, even thought the Seagate Dashboard used to be able to change this setting, before Toolkit removed this option. My drive is a Backup Plus Slim 2TB, serial number: NA9B5G8B

Typo in "Total Bytes Read"

I have a brand new 18T x18 disk. It has been written to once (as part of a zfs send) and scrubbed twice (so 2x reads of the sent data).

When running:

./openSeaChest_Logs -d /dev/disk/by-id/ata-ST18000NM000J-2TV103_SERIAL -i

The following line says "PB" when it should say "TB":
Total Bytes Read (PB): 20.71
Total Bytes Written (TB): 10.71

I'm guessing just a typo, but that's a big one!

Making the openSeaChest EFI binaries

Hi,

Apologies for the beginner questions, but could you give me some clues about setting up an appropriate build environment for building the EFI binaries for this project? A recommendation for an appropriate distro, distro version and supporting libraries that would mimic closely your own would be helpful.

Regards,
Richard

Not able to wipe/sanitize a Capacity Enterprise 2TB drive...please help

Result from --deviceInfo:

ATA Security Information: Supported, Enabled, Locked
Features Supported:
Sanitize
Security [Enabled]

Result from --ataSecurityInfo:

Security State: 4
Enabled: True
Locked: True
Frozen: False
Password Attempts Exceeded: False
Master Password Capability: High
Master Password Identifier: 65534 (may be set to manufacture master password)
Enhanced Erase Time Estimate: 3 hours 16 minutes
Security Erase Time Estimate: 3 hours 16 minutes
All user data is encrypted: False
Restricted Sanitize Overrides ATA Security: False
SAT security protocol supported: False

Result from --sanitize info:

Sanitize
The following sanitize commands are supported:
Overwrite --sanitize overwrite

Result from --sanitize overwrite:

Sanitize
Starting Sanitize Overwrite Erase
Sanitize command failed!

Result from --ataSecureErase normal:

ATA Security Erase
Starting ATA Security Erase using User password: "SeaChest" (User)
Current Time: Sun Feb 28 00:27:34 2021
Drive reported completion time: 3 hours 16 minutes from now.
Estimated completion Time : Sun Feb 28 03:43:34 2021

Please DO NOT remove power to the drive during the erase
as this will leave it in an uninitialized state with the password set.
If the power is removed, rerun this test with your utility.
Upon erase completion, the password is automatically cleared.

ATA Security erase failed to complete after

WARNING!!! The drive is in a security state where clearing the password is not possible!
Please power cycle the drive and try clearing the password upon powerup.
Erase password that was used was: "SeaChest" (User)

What am I doing wrong?

Device ST10000DM0004. "EPC Feature is not supported by this device".

OS: Windows 7 64bit.
Device: ST10000DM0004
Tools: OpenSeaChest_PowerControl (64bit), OpenSeaChest_PowerControl(32bit)

Using OpenSeaChest_PowerControl to set idle times, or to completely disable EPC, does not work, with messages indicating that the operation is not supported on the device. I tried the arguments:

• --idle_a 20
• --EPCfeature disable

According to the manual of the device, and to the best of my understanding of it, these operations are supported by the device. The following setting does work:

• --showEPCSettings

Modifying "Idle A" is my primary objective.

Unlocking a drive locked with Toolkit using openSeaChest?

I have some Seagate Backup Plus Ultra Touch drives that can be locked, with a password, using Toolkit on Windows.

It would be really useful to be able to unlock them on other platforms (FreeBSD, Linux, OmniOS, ...) using either a utility or the libraries from openSeaChest.

Are there any example scripts or code to do this?

openSeachest is crashing while trying to fetch details of NVMe device

We have a machine with NVMe device attached in the following configuration

admin@ip-10-1-38-168:~$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme0n1     259:1    0  128G  0 disk 
└─nvme0n1p1 259:2    0    8G  0 part /
nvme1n1     259:0    0 69.9G  0 disk 

We are using openseachest library to get disk information in openebs/node-disk-manager. The code is written in golang and cgo bindings are used to interact with seachest library.
make release is used to generate the static libs of openseachest.
The binary is being run inside a docker container on the node and this container is a part of a larger kubernetes cluster. We are hitting a crash with the below logs.

I0716 10:22:44.142004       7 controller.go:217] Disk CRD is available
I0716 10:22:44.144204       7 controller.go:233] BlockDevice CRD is available
I0716 10:22:44.144226       7 filter.go:58] registering filters
I0716 10:22:44.144248       7 filter.go:66] configured os disk exclude filter : state enable
I0716 10:22:44.144420       7 filter.go:66] configured vendor filter : state enable
I0716 10:22:44.144430       7 filter.go:66] configured path filter : state enable
I0716 10:22:44.144436       7 probe.go:62] registering probes
I0716 10:22:44.144445       7 probe.go:83] configured seachest probe : state enable
I0716 10:22:44.144462       7 probe.go:83] configured smart probe : state enable
I0716 10:22:44.144470       7 probe.go:83] configured mount probe : state enable
I0716 10:22:44.144508       7 probe.go:83] configured udev probe : state enable
I0716 10:22:44.144587       7 udevprobe.go:210] starting udev probe listener
I0716 10:22:44.146152       7 probe.go:83] configured capacity probe : state enable
I0716 10:22:44.146176       7 sparsefilegenerator.go:171] Sparse file already exists: 0-ndm-sparse.img
I0716 10:22:44.146209       7 sparsefilegenerator.go:223] Updating the BlockDevice CR for Sparse file: sparse-a235dcc97377568f64273332683c8cdf
I0716 10:22:44.148759       7 eventhandler.go:49] Processing details for disk-b33d9997949d356995b047615e5558b9
I0716 10:22:44.148903       7 probe.go:107] details filled by udev probe
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x119f07d]

runtime stack:
runtime.throw(0x144ff90, 0x2a)
	/home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/panic.go:617 +0x72 fp=0x7ffc2d7a6c20 sp=0x7ffc2d7a6bf0 pc=0x43ddd2
runtime.sigpanic()
	/home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/signal_unix.go:374 +0x4a9 fp=0x7ffc2d7a6c50 sp=0x7ffc2d7a6c20 pc=0x4528c9

goroutine 157 [syscall]:
runtime.cgocall(0x1115b20, 0xc000519008, 0x18)
	/home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/cgocall.go:128 +0x5b fp=0xc000518fd8 sp=0xc000518fa0 pc=0x41461b
github.com/openebs/node-disk-manager/pkg/seachest._Cfunc_get_SCSI_Drive_Information(0xc00028a000, 0xc00035c000, 0xc000000000)
	_cgo_gotypes.go:986 +0x4d fp=0xc000519008 sp=0xc000518fd8 pc=0x11049ad
github.com/openebs/node-disk-manager/pkg/seachest.(*Identifier).SeachestBasicDiskInfo(0xc0005193f0, 0x0, 0x0)
	/home/travis/gopath/src/github.com/openebs/node-disk-manager/pkg/seachest/seachest.go:89 +0x292 fp=0xc000519378 sp=0xc000519008 pc=0x1104d12
github.com/openebs/node-disk-manager/cmd/ndm_daemonset/probe.(*seachestProbe).FillDiskDetails(0xc0003c5310, 0xc0000b7ba0)
	/home/travis/gopath/src/github.com/openebs/node-disk-manager/cmd/ndm_daemonset/probe/seachestprobe.go:98 +0x82 fp=0xc0005196d0 sp=0xc000519378 pc=0x110fec2
github.com/openebs/node-disk-manager/cmd/ndm_daemonset/controller.(*Probe).FillDiskDetails(...)
	/home/travis/gopath/src/github.com/openebs/node-disk-manager/cmd/ndm_daemonset/controller/probe.go:47
github.com/openebs/node-disk-manager/cmd/ndm_daemonset/controller.(*Controller).FillDiskDetails(0xc0003162d0, 0xc0000b7ba0)
	/home/travis/gopath/src/github.com/openebs/node-disk-manager/cmd/ndm_daemonset/controller/probe.go:106 +0xe1 fp=0xc000519750 sp=0xc0005196d0 pc=0x10fef11
github.com/openebs/node-disk-manager/cmd/ndm_daemonset/probe.(*ProbeEvent).addDiskEvent(0xc0000b2000, 0x1426869, 0x3, 0xc00048ffa0, 0x3, 0x4)
	/home/travis/gopath/src/github.com/openebs/node-disk-manager/cmd/ndm_daemonset/probe/eventhandler.go:50 +0x225 fp=0xc000519f20 sp=0xc000519750 pc=0x110eb05
github.com/openebs/node-disk-manager/cmd/ndm_daemonset/probe.(*udevProbe).listen(0xc00048fec0)
	/home/travis/gopath/src/github.com/openebs/node-disk-manager/cmd/ndm_daemonset/probe/udevprobe.go:215 +0x1d4 fp=0xc000519fd8 sp=0xc000519f20 pc=0x1112bd4
runtime.goexit()
	/home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc000519fe0 sp=0xc000519fd8 pc=0x46a6b1
created by github.com/openebs/node-disk-manager/cmd/ndm_daemonset/probe.(*udevProbe).Start
	/home/travis/gopath/src/github.com/openebs/node-disk-manager/cmd/ndm_daemonset/probe/udevprobe.go:115 +0x3f

The complete logs are available here

The following is the backtrace generated when we evalauted the core dump using gdb

#0  runtime.raise () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/sys_linux_amd64.s:150
#1  0x000000000045291b in runtime.dieFromSignal (sig=6) at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/signal_unix.go:424
#2  0x0000000000452e9d in runtime.sigfwdgo (sig=6, info=0xc0003174b0, ctx=0xc000317380, ~r3=<optimized out>)
    at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/signal_unix.go:629
#3  0x0000000000451fc0 in runtime.sigtrampgo (sig=<optimized out>, info=0xc0003174b0, ctx=0xc000317380)
    at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/signal_unix.go:289
#4  0x000000000046c2a3 in runtime.sigtramp () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/sys_linux_amd64.s:357
#5  <signal handler called>
#6  runtime.raise () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/sys_linux_amd64.s:150
#7  0x000000000045291b in runtime.dieFromSignal (sig=6) at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/signal_unix.go:424
#8  0x0000000000452aba in runtime.crash () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/signal_unix.go:518
#9  0x0000000000466f21 in runtime.fatalthrow.func1 () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/panic.go:676
#10 0x000000000043dfa7 in runtime.fatalthrow () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/panic.go:669
#11 0x000000000043ddd2 in runtime.throw (s=...) at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/panic.go:617
#12 0x00000000004528c9 in runtime.sigpanic () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/signal_unix.go:374
#13 0x000000000119f07d in sntl_Check_Operation_Code_and_Service_Action ()
#14 0x00000000011a0bf2 in sntl_Translate_SCSI_Report_Supported_Operation_Codes_Command ()
#15 0x00000000011a10df in sntl_Translate_SCSI_Command ()
#16 0x000000000116fce8 in scsi_Send_Cdb ()
#17 0x00000000011702d8 in scsi_Report_Supported_Operation_Codes ()
#18 0x000000000112854f in get_Supported_FWDL_Modes ()
#19 0x000000000111ccea in get_SCSI_Drive_Information ()
#20 0x0000000001115b3b in _cgo_8a300aa9fb36_Cfunc_get_SCSI_Drive_Information (v=0xc0004a3008) at cgo-gcc-prolog:104
#21 0x0000000000469e30 in runtime.asmcgocall () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/asm_amd64.s:635
#22 0x0000000002403d80 in runtime.timers ()
#23 0x0000000000000003 in ?? ()
#24 0x00000000015c0059 in func.* ()
#25 0x00007ff0cd4e7f90 in ?? ()
#26 0x000000c0004a2df8 in ?? ()
#27 0x0000000000001068 in ?? ()
#28 0x000000c00031d380 in ?? ()
#29 0x0000000000442380 in ?? () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/proc.go:1082
---Type <return> to continue, or q <return> to quit---
#30 0x00007ff0ca675ae0 in ?? ()
#31 0x0000000000800000 in internal/x/net/http/httpguts.init.ializers ()
    at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/internal/x/net/http/httpguts/guts.go:31
#32 0x000000c0000b5080 in ?? ()
#33 0x0000000000442380 in ?? () at /home/travis/.gimme/versions/go1.12.7.linux.amd64/src/runtime/proc.go:1082
#34 0x000000000111602b in threadentry (v=<optimized out>) at gcc_linux_amd64.c:102
#35 0x00007ff0cce616ba in start_thread (arg=0x7ff0c248a700) at pthread_create.c:333
#36 0x00007ff0ccb9741d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Additional Info:

openSeachest : Tag `Hotfix-Makefile_fix`

Machine in which openseachest and binary was compiled
============================================
OS : Ubuntu 16.04.6 LTS
Kernel Version : 4.15.0-1028-gcp, Systemd 229

Machine which reported the crash
=========================
AWS EC2 instance. (m5d.large)
admin@ip-10-1-38-168:~$ uname -a
Linux ip-10-1-38-168 4.4.148-k8s #1 SMP Thu Aug 16 19:29:46 UTC 2018 x86_64 GNU/Linux

admin@ip-10-1-38-168:~$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian

admin@ip-10-1-38-168:~$ docker version
Client:
 Version:      17.03.2-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   f5ec1e2
 Built:        Tue Jun 27 02:09:56 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.2-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   f5ec1e2
 Built:        Tue Jun 27 02:09:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

admin@ip-10-1-38-168:~$ sudo udevadm info /dev/nvme0n1
P: /devices/pci0000:00/0000:00:04.0/nvme/nvme0/nvme0n1
N: nvme0n1
E: DEVNAME=/dev/nvme0n1
E: DEVPATH=/devices/pci0000:00/0000:00:04.0/nvme/nvme0/nvme0n1
E: DEVTYPE=disk
E: ID_PART_TABLE_TYPE=dos
E: ID_PART_TABLE_UUID=66d7a366
E: MAJOR=259
E: MINOR=1
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=4147

admin@ip-10-1-38-168:~$ sudo udevadm info /dev/nvme1n1
P: /devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1
N: nvme1n1
E: DEVNAME=/dev/nvme1n1
E: DEVPATH=/devices/pci0000:00/0000:00:1f.0/nvme/nvme1/nvme1n1
E: DEVTYPE=disk
E: MAJOR=259
E: MINOR=0
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=54026

make release fails in 19.06 release

make release fails in Release-19.06, with the following error

make: *** No rule to make target '../../src/seachest_util_options.o', needed by 'openSeaChest_NVMe'.  Stop.

Platform:

uname -a
Linux MayaData 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Incorrect exit code returned when permissions error occurs with --onlySeagate flag

When running a -i on all drives (-d all) without proper permissions (i.e. user not in disk group and/or not run as root/sudo), the drive information is not accessed and the exit code returned is 3. However, when including the --onlySeagate flag, the drive information is similarly not accessed, and a permissions error is displayed, but the exit code returned is 0, indicating a successful operation.

The same bug occurs with a --modelMatch ST flag as well. The issue also occurs on a machine with all Seagate drives. I have included a few images of the issue occurring below, where the user is neither a superuser nor in the "disk" group.

openSeaChest_Logs: Add JSON output format to determine if FARM data is available

JSON output is needed for openSeaChest_Logs to check if FARM data is available on the drive (the log page).
Something like:
./openSeaChest_Logs --listSupportedLogs -d /dev/sda --json

Cannot download nor update firmware at all

Hi . Anybody else suffer from this problem ? ST91000460NS . What am I not doing ?

ST16000VN001 EPCfeature disable not supported

Hello,

I have 4 Seagate Ironwolf NAS 16 TB ST16000VN001 drives.
I would like to change the EPCfeature but for some reason Seachest reports that these drives do not support EPC

SeaChest_PowerControl_201_12130_64.exe -d PD2 --EPCfeature disable
EPC Feature is not supported by this device \\.\PhysicalDrive2.

Nevertheless, -i shows that EPC is enabled

I have opened a ticket with Seagate but after about 5 replies I am convinced the people replying have absolutely no connection to Seagate.

Ridiculous number of compiler warnings building on a modern Linux system

Hey, I'm sorry if the title seems "mean" - but it is, at least, apt.

When building openSeaChest, there are a ton of compiler warnings.

Things like:

/usr/include/bits/stdio2.h:36:10: note: '__builtin___sprintf_chk' output between 2 and 21 bytes into a destination of size 19
   36 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   37 |       __bos (__s), __fmt, __va_arg_pack ());
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And:

In function 'strncpy',
    inlined from 'main' at ../../utils/C/openSeaChest/openSeaChest_Logs.c:279:17:
/usr/include/bits/string_fortified.h:106:10: warning: '__builtin___strncpy_chk' specified bound depends on the length of the source argument [-Wstringop-overflow=]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../utils/C/openSeaChest/openSeaChest_Logs.c:28:
../../utils/C/openSeaChest/openSeaChest_Logs.c: In function 'main':
../../utils/C/openSeaChest/openSeaChest_Logs.c:279:62: note: length computed here
  279 |                 strncpy(MODEL_STRING_FLAG, optarg, M_Min(40, strlen(optarg)));
../../opensea-common/include/common.h:264:35: note: in definition of macro 'M_Min'
  264 |     #define  M_Min(a,b)    (((a)<(b))?(a):(b))
      |                                   ^

I can't be the only person seeing these warnings.

These warnings are usually a sign that the code uses unsafe C programming practices.

Is there a plan to get these cleaned up?

Multiple undefined references on FreeBSD

OpenSeaChest fails to build on FreeBSD 11.2 due to multiple undefined references. It looks like it might be a Makefile error, because the symbols in question are defined within OpenSeaChest itself.

> gmake release
...
gcc ../../utils/C/openSeaChest/openSeaChest_Erase.o ../../src/EULA.o ../../src/openseachest_util_options.o -DDISABLE_TCG_SUPPORT -Wall ../../opensea-operations/Make/gcc/lib/libopensea-operations.a ../../opensea-transport/Make/gcc/lib/libopensea-transport.a ../../opensea-common/Make/gcc/lib/libopensea-common.a -o openseachest_exes/openSeaChest_Erase
../../utils/C/openSeaChest/openSeaChest_Erase.o: In function `main':
openSeaChest_Erase.c:(.text.startup+0x1ba1): undefined reference to `get_Device'
openSeaChest_Erase.c:(.text.startup+0x1e44): undefined reference to `get_Device_Count'
openSeaChest_Erase.c:(.text.startup+0x2f0d): undefined reference to `get_Device_List'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(cmds.o): In function `read_LBA':
cmds.c:(.text+0x1aa1): undefined reference to `os_Read'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(cmds.o): In function `write_LBA':
cmds.c:(.text+0x1ac1): undefined reference to `os_Write'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(cmds.o): In function `verify_LBA':
cmds.c:(.text+0x1d39): undefined reference to `os_Verify'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(cmds.o): In function `flush_Cache':
cmds.c:(.text+0x1dd9): undefined reference to `os_Flush'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(common_public.o): In function `scan_And_Print_Devs':
common_public.c:(.text+0x1f85): undefined reference to `get_Device_Count'
common_public.c:(.text+0x1fe0): undefined reference to `get_Device_List'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(sat_helper.o): In function `send_SAT_Passthrough_Command':
sat_helper.c:(.text+0x10b3): undefined reference to `send_IO'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(sat_helper.o): In function `translate_SCSI_ATA_Passthrough_Command':
sat_helper.c:(.text+0x5254): undefined reference to `send_IO'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(scsi_cmds.o): In function `scsi_Send_Cdb':
scsi_cmds.c:(.text+0x1f6): undefined reference to `send_IO'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(nvme_cmds.o): In function `nvme_Read_Ctrl_Reg':
nvme_cmds.c:(.text+0xb8b): undefined reference to `pci_Read_Bar_Reg'
../../opensea-transport/Make/gcc/lib/libopensea-transport.a(nvme_cmds.o): In function `nvme_Cmd':
nvme_cmds.c:(.text+0x1b7): undefined reference to `send_NVMe_IO'
collect2: error: ld returned 1 exit status
gmake: *** [Makefile:233: openSeaChest_Erase] Error 1

openSeaChest_Configure fail to set SAS Mode Page

Hi,
When I use openSeaChest_Configure to set SAS Mode Page, for example WCE on page 08h:

[root@localhost ~]# ./openSeaChest_Configure -d /dev/sdp --showSCSIMP 08

/dev/sg15 - ST1200MM0129 - WFK49Q0G0000K94575NM - SCSI

===========================================================
 Page 8h Caching
 Current Values
===========================================================
88 12 14 00 FF FF 00 00 FF FF FF FF 91 20 00 00 00 00 00 00

[root@localhost ~]# ./openSeaChest_Configure -d /dev/sdp --setSCSIMP 08:2:2:1=0

/dev/sg15 - ST1200MM0129 - WFK49Q0G0000K94575NM - SCSI
*** Error in `/root/seachest_exes_gcc/SeaChest_Configure_x86_64-redhat-linux': free(): invalid next size (fast): 0x000000000255e010 ***

But it works with sdparm:

[root@localhost ~]# sdparm --page=08h --hex /dev/sdp
Caching (SBC) [0x8] mode page:
    Current:
 00     88 12 14 00 ff ff 00 00  ff ff ff ff 91 20 00 00
 10     00 00 00 00
    Changeable:
 00     88 12 a5 00 00 00 ff ff  ff ff 00 00 21 00 00 00
 10     00 00 00 00
    Default:
 00     88 12 10 00 ff ff 00 00  ff ff ff ff 90 20 00 00
 10     00 00 00 00
    Saved:
 00     88 12 14 00 ff ff 00 00  ff ff ff ff 91 20 00 00
 10     00 00 00 00
[root@localhost ~]# sdparm --page=08h --set=2:2:1=0 --save /dev/sdp
    /dev/sdp: SEAGATE   ST1200MM0129      C006
[root@localhost ~]# sdparm --page=08h --hex /dev/sdp
Caching (SBC) [0x8] mode page:
    Current:
 00     88 12 10 00 ff ff 00 00  ff ff ff ff 91 20 00 00
 10     00 00 00 00
    Changeable:
 00     88 12 a5 00 00 00 ff ff  ff ff 00 00 21 00 00 00
 10     00 00 00 00
    Default:
 00     88 12 10 00 ff ff 00 00  ff ff ff ff 90 20 00 00
 10     00 00 00 00
    Saved:
 00     88 12 10 00 ff ff 00 00  ff ff ff ff 91 20 00 00
 10     00 00 00 00

Could you please have a look? Thanks!

Suggestion to provide a bit of documentation on building

The Building section of the docs is blank - would be great to see a little bit of information there. Maybe it's as simple as "make; make install" but these utilities are low level and important and your users want to be sure to do the right thing in compiling them. Thanks.

"openSeaChest_Info --scan" fails with "Bad address"

I've cross compiled the latest HEAD for use in an embedded linux device.

If I try to call the binaries there's always a "Bad address" error reported.

# openSeaChest_Info --scan
==========================================================================================
 openSeaChest_Info - openSeaChest drive utilities
 Copyright (c) 2014-2017 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_Info Version: 1.3.0-1_17_8 ARM
 Build Date: Feb  1 2018
 Today: Fri Feb  2 10:54:53 2018
==========================================================================================
open: Bad address
open failure
Error: 14 - Bad address

Here's the output of the related smartctl info

# smartctl -i /dev/sda
smartctl 6.5 2016-05-07 r4318 [armv7l-linux-4.1.15-2.0.0-ga+yocto+g719fb24] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     ST2000LV000-2G2174
Serial Number:    WDZ2WMSV
LU WWN Device Id: 5 000c50 0a896080e
Firmware Version: ZZZZ
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      2.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 3b
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Fri Feb  2 10:54:46 2018 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Totally unworkable on Linux with fatal errors and Error 2 while compiling

On Windows, openSeaChest just works properly, like anything on Windows. On Manjaro, Linux Mint, and Ubuntu 21.10, there are fatal errors and Error 2 when using make release, make clean or make. This is totally unworkable and is a waste of hours for nothing. Why aren't binaries provided for more than only CentOS?

Because make is from GNU, an organization that spends most of their time relentlessly whining about how any traces of anything proprietary is malicious, it is not possible to compile anything with make without ruining the day. make is trash to an extent like nothing else and is the very single worst thing about using Linux instead of Windows. In fact, I was entering a long series of commands through multiple pages of instructions for openSeaChest UEFI, and did not reach an error until stupid evil make raged into presence as a dumpster fire, ruining hours of effort. This issue is about openSeaChest Linux, but make deserves shaming words to be mentioned at every opportunity.

The only solution is to provide binaries for Debian and Arch based systems, or provide source code that can be compiled without any involvement of make, which shouts at you with *** that represent rage and the word Stop telling you to give up. GCC is installed and the Linux kernel version is 5.13.19-2.