seagate / openseachest Goto Github PK
View Code? Open in Web Editor NEWCross platform utilities useful for performing various operations on SATA, SAS, NVMe, and USB storage devices.
License: Other
Cross platform utilities useful for performing various operations on SATA, SAS, NVMe, and USB storage devices.
License: Other
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:
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:
Modifying "Idle A" is my primary objective.
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.
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:
pacman -S --needed base-devel mingw-w64-x86_64-toolchain
and installed all packagesC:\msys64\usr\bin
and C:\msys64\mingw64\bin
to my PATHpacman -S git
git ls-remote --heads https://github.com/Seagate/openSeaChest.git | sed 's?.*refs/heads/??'
git clone --recurse-submodules --branch develop --single-branch https://github.com/Seagate/openSeaChest.git openSeaChest
openSeaChest
and run git submodule foreach --recursive 'git checkout develop'
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?
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
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
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.
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" !
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)
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
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
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
openSeaChest needs to be able to talk to FreeBSD nvme driver. As far as I'm aware just needs low level plumbing
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.
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
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
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!
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.
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.
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
Hello xahmad,
I noticed that there have been some problems scanning disks attached to pcie controllers..
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.
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
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
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.
Hi . Anybody else suffer from this problem ? ST91000460NS . What am I not doing ?
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!
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?
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:
/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?
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.
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.
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.
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?
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
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/
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?
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?
Hi,
should be nice to have makefile with :
CC ?= gcc
instead of :
CC = gcc
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
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?
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
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 2021Please 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?
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?
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.
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.
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?
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.
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?
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
.
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!
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.