Seagate
[BUG] - 25.05.3 crashes when trying to list drive information
Describe the bug In v25.05.3-linux-x86_64-portable on Proxmox (6.17.2-2-pve kernel), I can't list information about a drive. I have tried both new drives and existing drives, and I always get the error below.
To Reproduce
- Run
./openSeaChest_Info -d <disk> -i - Crashes
Expected behavior Should list info
Verbose Output
⚡ /h/c/openSeaChest-v25.05.3-linux-x86_64-portable ./openSeaChest_Info -d /dev/disk/by-id/ata-INTEL........... -i -v4
==========================================================================================
openSeaChest_Info - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2025 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Info Version: 2.9.2 X86_64
Build Date: Oct 9 2025
Today: 20251202T113446 User: root
==========================================================================================
abort_handler_s: snprintf_error_handler_macro: error in snprintf
Error code: 22
Additional Error info:
File: sg_helper.c
Line: 338
Function: get_Partition_List
Expression: snprintf_err_handle((partitionInfoList + matchesFound)->fsName, PART_INFO_NAME_LENGTH, "%s", va args)
fish: Job 1, './openSeaChest_Info -d /dev/dis…' terminated by signal SIGABRT (Abort)
This same command in v22.07 works just fine:
✘ ⚡ /h/c/openSeaChest-v25.05.3-linux-x86_64-portable ../openSeaChest-refs-tags-v22.07-linux-x86_64/openSeaChest_Info -d /dev/disk/by-id/ata-INTEL_SSDSC2KB019T8_xxx -i
==========================================================================================
openSeaChest_Info - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2022 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Info Version: 2.1.2-3_2_1 X86_64
Build Date: Jul 26 2022
Today: Tue Dec 2 11:35:40 2025 User: root
==========================================================================================
- INTEL SSDSC2KB019T8 - xxx - XCV10132 - ATA
Model Number: INTEL SSDSC2KB019T8
Serial Number: xxx
Firmware Revision: XCV10132
World Wide Name: xxx
Drive Capacity (TB/TiB): 1.92/1.75
Native Drive Capacity (TB/TiB): 1.92/1.75
...............lots more output..........
Desktop (please complete the following information):
- OS: Linux
- Proxmox (latest)
✘ ⚡ /h/c/openSeaChest-v25.05.3-linux-x86_64-portable ./openSeaChest_Info --version
==========================================================================================
openSeaChest_Info - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2025 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Info Version: 2.9.2 X86_64
Build Date: Oct 9 2025
Today: 20251202T113641 User: root
==========================================================================================
Version Info for openSeaChest_Info:
Utility Version: 2.9.2
opensea-common Version: 6.0.4
opensea-transport Version: 10.2.0
opensea-operations Version: 9.3.0
Build Date: Oct 9 2025
Compiled Architecture: X86_64
Detected Endianness: Little Endian
Compiler Used: GCC
Compiler Version: 11.2.1
Operating System Type: Linux
Operating System Version: 6.17.2-2
Operating System Name: Debian GNU/Linux 13 (trixie)
I just backtested versions, and the last version that works for my system is v24.08.1
@Clete2, Thank you for reporting this error. I think I may have run into this myself recently, but I will investigate if this is still an issue. In your case, do all of these drives have partitions on them? Or are some of them new and raw so they haven't had partitions created yet?
@Clete2,
If you are willing to share your file /etc/mtab that is what is being read when this crash occurs.
The two things we are reading from there are the file system name and the mount path.
These are looked at to determine whether there is a file system on the drive or not so that other parts of the software or software like SeaTools can determine when to filter out certain tests or provide more warnings to the user about certain tests.
The idea was we could also create a --skipBootDrive and --skipActiveFSDrive options, however due to Seagate/opensea-transport#10 we don't have these as we do not have a solution for ZFS at this time.
If you do not want to share the exact mount paths or names, you can change them in the file, but the length needs to be the same as what you currently have in it. So if one is 30 characters long and you want to replace it with something like ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ that is fine....the name itself doesn't matter right now, just the length.
The max length we have for a name is 32 characters and max for path is 64 characters....that might be triggering the error.
@vonericsen I don't mind posting my mtab file, there's nothing too sensitive there other than you can see some info about my ZFS structure.
I also suspected it had to do with an uninitialized drive. I run the SeaChest utility whenever I get a new blank drive to format it to 4096 byte sectors. Necessarily, I run it on an empty uninitialized drive. But since I was getting this error, I took time to format the drive and add a new blank partition before running the command.
Now, right this second, there is a drive inserted into the system which has no partition scheme because I am running the shred utility on it before disposing of it.
Edit: blanked out all except for the longest FS
~> cat /etc/mtab
…
tank/backup/zfs/ga/rpool/data/subvol-114-disk-0 /tank/backup/zfs/ga/rpool/data/subvol-114-disk-0 zfs rw,noatime,xattr,noacl,casesensitive 0 0
…
Here is some info about my drives:
- 2x Intel SSD in a ZFS mirror pool (root/boot drives)
- 5x Seagate HDDs in a RAIDZ2 pool
(X'd out serial #s below)
~> zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 1.74T 911G 875G - - 54% 51% 1.00x ONLINE -
mirror-0 1.74T 911G 875G - - 54% 51.0% - ONLINE
ata-INTEL_SSDSC2KB019T8_PHYFXXXXXXXP9DGN-part3 1.75T - - - - - - - ONLINE
ata-INTEL_SSDSC2KB019T8_PHYFXXXXXXXP9DGN-part3 1.75T - - - - - - - ONLINE
tank 63.7T 47.7T 15.9T - - 45% 74% 1.00x ONLINE -
raidz2-0 63.7T 47.7T 15.9T - - 45% 75.0% - ONLINE
ata-ST24000NM000H-3KS103_ZXXXXXXX 21.8T - - - - - - - ONLINE
ata-ST14000NM000J-2TX103_ZXXXXXXX 12.7T - - - - - - - ONLINE
ata-ST14000NM000J-2TX103_ZXXXXXXX 12.7T - - - - - - - ONLINE
ata-ST14000NM000J-2TX103_ZXXXXXXX 12.7T - - - - - - - ONLINE
ata-ST14000NM000J-2TX103_ZXXXXXXX 12.7T - - - - - - - ONLINE
Thank you for sharing that! This is definitely due to a length issue for the file system name. Our code allows 32 characters, but this is 49. Since this causes truncation, it is triggering the abort handler installed for this kind of problem.
We implemented a lot of security functions to prevent out of bounds accesses and truncation issues that could affect various parts of our utilities, and this is one that is being triggered by a long name.
I think a quick, temporary solution is to allow the truncation due to how this data is handled and used, this should be ok.
A longer term solution will be refactoring this code and allocating memory long enough for each field. This code is almost duplicated in each OS we support so I would want to wrap it for all of them to clean it up a bit...the worst part is there is no standard function across them all. They are all ever so slightly different, so it may take a little longer for this, but would reduce duplication overall.
Fascinating, so it must be due to some of my nested ZFS datasets.
I edited out all my FS names except one of the long ones.
Looks like ZFS on Linux supports paths up to 1023 bytes. https://github.com/openzfs/zfs/pull/15921
Thanks for the link! This bug probably affects any other OS with ZFS support, so I need to review those as well.
I'll work on changes to allow bypassing the truncation and share a build on here when I have one. What this code really does is it just checks whether the device handle provided to the tool has a matching /dev/sdX handle in this file or not. It's not super complicated, so truncation for a long name like this is ok. The only "risk" is if a device handle was really long and could possibly match a different device in this.
Like: passing handle as /dev/this/is/a/really/long/path1
But there is an entry in this file as /dev/this/is/a/really/long/path2 and the 1|2 from the end were truncated so the comparison looked the same (/dev/this/is/a/really/long/path). This would generate a problem, but since the device handles openSeaChest looks for are much shorter as /dev/sdX or /dev/sdXXX I don't think it is likely this will trigger any bad behavior....at least not in openSeaChest since this isn't used to screen anything. SeaTools? Maybe, but still very unlikely to do anything other than block a data destructive operation from being accessed on the non-boot drive.
Ideally we switch to the long term solution and allocate the full name length and mount path length, then compare things to make sure there are no mismatches, but that will take a little longer to get done, so this will be ok for now until that is rewritten. This long term solution will not have a limit since it will allocate as much memory as is necessary to save the whole thing without padding and if no more system memory is available, it can report an error instead.
@Clete2,
I've attached a build with the change to allow truncation. I left it configured with a warning error handler, so it will still print out some error information, but it should continue to run. Can you give it a test and share any error info it outputs? I expect it to say something about a truncation error, but I want to be sure before I turn off the error output.
linux-x86_64-portable.zip multiple.intoto.jsonl (1).zip
Note: The multiple.intoto.jsonl is for SLSA verification to verify the zip file came from this repository if you want to run the SLSA verifier.
@vonericsen
Funny enough, I just thought to run the current release (v25.05.3) with ./openSeaChest_Info -d /dev/sda -i and it works using /dev/sda! I should have tried that in the past.
When I insert the disks, I always look at the engraved serial number on the front edge, and just find them in /dev/disk/by-id/ata-XXX; and that is also best practice for using in zpool replace commands, such that reordering SATA/SAS cables does not mess up your pool.
Below is output from your new build! Thanks so much for doing this.
✘ cleteServer ~/openSeaChest-feature-fix_crash_for_long_mntent_names-linux-x86_64-portable sudo ./openSeaChest_Info -d /dev/disk/by-id/ata-ST24000NM000H-3KS103_XXXXXXXX -i
==========================================================================================
openSeaChest_Info - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2025 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Info Version: 2.9.2 X86_64
Build Date: Dec 9 2025
Today: 20251209T190657 User: root
==========================================================================================
warn_handler: snprintf_error_handler_macro: output was truncated
Error code: 34
Additional Error info:
File: sg_helper.c
Line: 339
Function: get_Partition_List
Expression: snprintf_err_handle((partitionInfoList + matchesFound)->fsName, PART_INFO_NAME_LENGTH, "%s", va args)
warn_handler: snprintf_error_handler_macro: output was truncated
Error code: 34
Additional Error info:
File: sg_helper.c
Line: 339
Function: get_Partition_List
Expression: snprintf_err_handle((partitionInfoList + matchesFound)->fsName, PART_INFO_NAME_LENGTH, "%s", va args)
warn_handler: snprintf_error_handler_macro: output was truncated
Error code: 34
Additional Error info:
File: sg_helper.c
Line: 339
Function: get_Partition_List
Expression: snprintf_err_handle((partitionInfoList + matchesFound)->fsName, PART_INFO_NAME_LENGTH, "%s", va args)
warn_handler: snprintf_error_handler_macro: output was truncated
Error code: 34
Additional Error info:
File: sg_helper.c
Line: 339
Function: get_Partition_List
Expression: snprintf_err_handle((partitionInfoList + matchesFound)->fsName, PART_INFO_NAME_LENGTH, "%s", va args)
warn_handler: snprintf_error_handler_macro: output was truncated
Error code: 34
Additional Error info:
File: sg_helper.c
Line: 339
Function: get_Partition_List
Expression: snprintf_err_handle((partitionInfoList + matchesFound)->fsName, PART_INFO_NAME_LENGTH, "%s", va args)
warn_handler: snprintf_error_handler_macro: output was truncated
Error code: 34
Additional Error info:
File: sg_helper.c
Line: 339
Function: get_Partition_List
Expression: snprintf_err_handle((partitionInfoList + matchesFound)->fsName, PART_INFO_NAME_LENGTH, "%s", va args)
- ST24000NM000H-3KS103 - XXXXXXXX - SN04 - ATA
Model Number: ST24000NM000H-3KS103
Serial Number: XXXXXXXX
Firmware Revision: SN04
World Wide Name: XXXXXXXX
Date Of Manufacture: Week 34, 2024
Drive Capacity (TB/TiB): 24.00/21.83
Native Drive Capacity (TB/TiB): 24.00/21.83
Temperature Data:
Current Temperature (C): 32
Highest Temperature (C): 50
Lowest Temperature (C): 28
Power On Time: 8 days
Power On Hours: 192.00
MaxLBA: 5859442687
Native MaxLBA: 5859442687
Logical Sector Size (B): 4096
Physical Sector Size (B): 4096
Sector Alignment: 0
Rotation Rate (RPM): 7200
Form Factor: 3.5"
Last DST information:
Time since last DST (hours): 19.00
DST Status/Result: 0x0
DST Test run: 0x2
Long Drive Self Test Time: 1 day 8 hours 24 minutes
Interface speed:
Max Speed (Gb/s): 6.0
Negotiated Speed (Gb/s): 6.0
Annualized Workload Rate (TB/yr): 1781.63
Total Bytes Read (TB): 24.65
Total Bytes Written (TB): 14.40
Encryption Support: Not Supported
Cache Size (MiB): 512.00
Read Look-Ahead: Enabled
Write Cache: Enabled
Low Current Spinup: Disabled
SMART Status: Good
ATA Security Information: Supported
Firmware Download Support: Full, Segmented, Deferred
Specifications Supported:
ACS-5
ACS-4
ACS-3
ACS-2
ATA8-ACS
ATA/ATAPI-7
ATA/ATAPI-6
ATA/ATAPI-5
SATA 3.3
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:
Read/Write Multiple
Sanitize
All Write Cache Non-Volatile
SATA NCQ [QD=32]
SATA Software Settings Preservation [Enabled]
SATA Device Initiated Power Management
Power Management
Security
SMART [Enabled]
48bit Address
Set Max Security Extension
PUIS
GPL
Streaming
SMART Self-Test
SMART Error Logging
DSN
AMAC
EPC [Enabled]
Sense Data Reporting
Write-Read-Verify
SCT Write Same
SCT Error Recovery Control
SCT Feature Control
SCT Data Tables
Host Logging
Set Sector Configuration
Storage Element Depopulation + Restore
Command Duration Limits
Field Accessible Reliability Metrics (FARM)
Seagate In Drive Diagnostics (IDD)
Adapter Information:
Adapter Type: Unknown
Vendor ID: Not available.
Product ID: Not available.
Revision: Not available.
@Clete2,
Thanks for testing that and also the info about the /dev/disk/by-id!
I'll remove the warnings and I'm also going to add checking if the handle is a link (which /dev/disk/by-id is to /dev/sdX). If it is a link, we'll get what it points to instead which seems like it can also prevent this kind of issue (and help other parts of our code look up things properly in the /sys tree like the adapter information that is showing as empty for you currently)
Alright, I went and implemented the long term solution and deduplicated code across various OS's in the process.
I am happy to share one of those builds, but I don't think you will notice any differences from the last one since you are using ZFS which I will figure out eventually how we want to handle....but that is another project for another day.
Really appreciate it. To be honest I only use the tools for changing sector size and viewing firmware revision. I’m not sure what ZFS support would buy me but I’m all for it whenever it comes around.
I'm not sure about the status of this issue.
I have installed the deb package (25.05.3) on my debian 12 system and ran into this issue.
what is your proposal? downgrade to v24.08.1?
thanks in advance :-)
PS: nevermind, 24.08.1 works for me.
@rome-legacy,
I have fixed our develop branch code so far for this issue (but facing a different issue with upcoming JSON support now).
If you can use /dev/sdX or /dev/sgX handles instead, then it will not trigger the same abort sequence reported in here.
Downgrading also works since it allowed truncation to happen silently.
I'm assessing a patch update versus how far away the new JSON code is from ready to decide what to do.