starred/Synology_HDD_db

Fork 0

mirror of https://github.com/007revad/Synology_HDD_db.git synced 2026-04-25 05:35:59 +03:00

[GH-ISSUE #270] "Invalid json format" syslog output #598

New issue

Closed

opened 2026-03-11 12:28:47 +03:00 by kerem · 5 comments

kerem commented

2026-03-11 12:28:47 +03:00

Owner

Originally created by @paulirish on GitHub (Mar 31, 2024).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/270

Originally assigned to: @007revad on GitHub.

While running sudo journalctl -xef --no-pager during a HDD_db script update (after a DSM update).. i see these logs:

synostgdisk[13736]: disk/disk_sb_firm_status_get.cpp:141 Invalid json format: {"compatibility_interval":[{"barebone_installable":true,"compatibility":"support","fw_dsm_update_status_notify":false,"not_yet_rolling_status":"support","smart_attr_ignore":false,"smart_test_ignore":false}]}

The logged string is valid JSON as far as I can tell... So I'm not sure what thats about. Thoughts?

(About to reboot so we'll see if anything persists on the other side)

This was after an update from DSM 7.2.0-XXXXX Update 3 to DSM 7.2.1-69057 Update 4

Originally created by @paulirish on GitHub (Mar 31, 2024). Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/270 Originally assigned to: @007revad on GitHub. While running `sudo journalctl -xef --no-pager` during a HDD_db script update (after a DSM update).. i see these logs: > synostgdisk[13736]: disk/disk_sb_firm_status_get.cpp:141 Invalid json format: {"compatibility_interval":[{"barebone_installable":true,"compatibility":"support","fw_dsm_update_status_notify":false,"not_yet_rolling_status":"support","smart_attr_ignore":false,"smart_test_ignore":false}]} ![image](https://github.com/007revad/Synology_HDD_db/assets/39191/dd2eb7cd-68cc-4136-af49-5ce08cacb0f7) The logged string is valid JSON as far as I can tell... So I'm not sure what thats about. Thoughts? (About to reboot so we'll see if anything persists on the other side) This was after an update from DSM 7.2.0-XXXXX Update 3 to `DSM 7.2.1-69057 Update 4`

kerem

2026-03-11 12:28:47 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-11 12:29:03 +03:00

Author

Owner

@paulirish commented on GitHub (Mar 31, 2024):

Some logs from right after the restart as bootup was finishing:

everything looks fine otherwise.

but perhaps there's a rogue hdd db entry that's missing something key?

@paulirish commented on GitHub (Mar 31, 2024): Some logs from right after the restart as bootup was finishing: ![image](https://github.com/007revad/Synology_HDD_db/assets/39191/5100a456-c558-41d4-90db-ad496156c083) everything looks fine otherwise. but perhaps there's a rogue hdd db entry that's missing something key?

kerem commented

2026-03-11 12:29:08 +03:00

Author

Owner

@007revad commented on GitHub (Mar 31, 2024):

I get those log entries as well. I couldn't find anything invalid with the string.

You're the first person to notice and mention it.

@007revad commented on GitHub (Mar 31, 2024): I get those log entries as well. I couldn't find anything invalid with the string. You're the first person to notice and mention it.

kerem commented

2026-03-11 12:29:13 +03:00

Author

Owner

@007revad commented on GitHub (Mar 31, 2024):

Which version of the script did you use?

Which Synology NAS do you have? And does it have a M2D20, M2D18 or E10M20-T1 with NVMe drives installed?

I just checked all my DS1821+ .db files and ds1821+_e10m20-t1_v7.db contains an extra } on the 3rd last line (when the file is formatted).

It has this:

        }
    }
}, "nas_model": "ds1821+"
}

when it should have this:

        }
    }, "nas_model": "ds1821+"
}

Before editing the M2D20, M2D18 and E10M20-T1 db files are what I call empty db7 files:

{
    "disk_compatbility_info": {},
    "nas_model": "ds1821+"
}

@007revad commented on GitHub (Mar 31, 2024): Which version of the script did you use? Which Synology NAS do you have? And does it have a M2D20, M2D18 or E10M20-T1 with NVMe drives installed? I just checked all my DS1821+ .db files and **ds1821+_e10m20-t1_v7.db** contains an extra `}` on the 3rd last line (when the file is formatted). It has this: ``` } } }, "nas_model": "ds1821+" } ``` when it should have this: ``` } }, "nas_model": "ds1821+" } ``` Before editing the M2D20, M2D18 and E10M20-T1 db files are what I call empty db7 files: ``` { "disk_compatbility_info": {}, "nas_model": "ds1821+" } ```

kerem commented

2026-03-11 12:29:18 +03:00

Author

Owner

@007revad commented on GitHub (Mar 31, 2024):

I've released a new version that fixes the invalid json string issue.
https://github.com/007revad/Synology_HDD_db/releases/tag/v3.4.87

It won't replace the existing invalid ]}}}}, in your db file(s) with the correct ]}}},

To fix them you can run the script with the --restore option, then run it with your preferred options.

@007revad commented on GitHub (Mar 31, 2024): I've released a new version that fixes the invalid json string issue. https://github.com/007revad/Synology_HDD_db/releases/tag/v3.4.87 It won't replace the existing invalid `]}}}},` in your db file(s) with the correct `]}}},` To fix them you can run the script with the --restore option, then run it with your preferred options.

kerem commented

2026-03-11 12:29:23 +03:00

Author

Owner

@007revad commented on GitHub (Mar 31, 2024):

I'm still getting those log entries after I run synostgdisk --check-all-disks-compatibility

What is strange is that none of the files in /var/lib/disk-compatibility contain the string in the log, which has the key value pairs sorted:

{
    "compatibility_interval": [{
            "barebone_installable": true,
            "compatibility": "support",
            "fw_dsm_update_status_notify": false,
            "not_yet_rolling_status": "support",
            "smart_attr_ignore": false,
            "smart_test_ignore": false
        }
    ]
}

All of the .db files in my /var/lib/disk-compatibility contain the string with key value pairs in the following order:

{
    "compatibility_interval": [{
            "compatibility": "support",
            "not_yet_rolling_status": "support",
            "fw_dsm_update_status_notify": false,
            "barebone_installable": true,
            "smart_test_ignore": false,
            "smart_attr_ignore": false
        }
    ]
}

I get one of those log entries for each drive around 5:30am every day, and then 2 more time about 13 minutes apart.

It looks like DSM checks drive compatibility every morning, as well as a boot and when a new drive is installed.

@007revad commented on GitHub (Mar 31, 2024): I'm still getting those log entries after I run `synostgdisk --check-all-disks-compatibility` What is strange is that none of the files in /var/lib/disk-compatibility contain the string in the log, which has the key value pairs sorted: ``` { "compatibility_interval": [{ "barebone_installable": true, "compatibility": "support", "fw_dsm_update_status_notify": false, "not_yet_rolling_status": "support", "smart_attr_ignore": false, "smart_test_ignore": false } ] } ``` All of the .db files in my /var/lib/disk-compatibility contain the string with key value pairs in the following order: ``` { "compatibility_interval": [{ "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true, "smart_test_ignore": false, "smart_attr_ignore": false } ] } ``` I get one of those log entries for each drive around 5:30am every day, and then 2 more time about 13 minutes apart. It looks like DSM checks drive compatibility every morning, as well as a boot and when a new drive is installed.