starred/Synology_HDD_db

Fork 0

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

[GH-ISSUE #411] synosetkeyvalue error while run #647

New issue

Closed

opened 2026-03-11 12:52:26 +03:00 by kerem · 5 comments

kerem commented

2026-03-11 12:52:26 +03:00

Owner

Originally created by @phit42 on GitHub (Dec 29, 2024).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/411

Should I worry when the script throws an error right in the middle of things and then apparently continues?

./syno_hdd_db.sh: line 2139: /tmpRoot/usr/syno/bin/synosetkeyvalue: No such file or directory

Here is the full log:
Synology_HDD_db-OUTPUT.txt

Also a little feature request: even when the vendor id has been matched, show it somewhere in the output to be able to confirm it.

Originally created by @phit42 on GitHub (Dec 29, 2024). Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/411 Should I worry when the script throws an error right in the middle of things and then apparently continues? `./syno_hdd_db.sh: line 2139: /tmpRoot/usr/syno/bin/synosetkeyvalue: No such file or directory` Here is the full log: [Synology_HDD_db-OUTPUT.txt](https://github.com/user-attachments/files/18270116/Synology_HDD_db-OUTPUT.txt) Also a little feature request: even when the vendor id has been matched, show it somewhere in the output to be able to confirm it.

kerem closed this issue

2026-03-11 12:52:31 +03:00

kerem commented

2026-03-11 12:52:37 +03:00

Author

Owner

@007revad commented on GitHub (Dec 29, 2024):

Should I worry when the script throws an error right in the middle of things and then apparently continues?
Normally I would worry too, except in this the error was trivial and the script did actually do what it was supposed to on the previous line.

/usr/syno/bin/synosetkeyvalue /etc.defaults/synoinfo.conf drive_db_test_url "127.0.0.1"
[ -d /tmpRoot ] && /tmpRoot/usr/syno/bin/synosetkeyvalue /tmpRoot/etc.defaults/synoinfo.conf drive_db_test_url "127.0.0.1"

The 2nd line was added by one of the xpenology devs, and I assumed they knew what they doing. I guess they didn't care if there was a trivial error message because they run the script while DSM is booting so nobody would see the message.

The reason they wanted that line added was because during DSM's junior boot process /usr/syno/bin/synosetkeyvalue is not available, so during boot xpe has it's own copy of synosetkeyvalue (and other files) that run from /tmpRoot

I'm not sure how your NAS has /tmpRoot but it does not contain /tmpRoot/usr/syno/bin/synosetkeyvalue

To make that line bulletproof I'd need to check both files exist in /tmpRoot

if [ -f /tmpRoot/usr/syno/bin/synosetkeyvalue ] && [ -f /tmpRoot/etc.defaults/synoinfo.conf ]; then
    /tmpRoot/usr/syno/bin/synosetkeyvalue /tmpRoot/etc.defaults/synoinfo.conf drive_db_test_url "127.0.0.1"
fi

@007revad commented on GitHub (Dec 29, 2024): > Should I worry when the script throws an error right in the middle of things and then apparently continues? Normally I would worry too, except in this the error was trivial and the script did actually do what it was supposed to on the previous line. ``` /usr/syno/bin/synosetkeyvalue /etc.defaults/synoinfo.conf drive_db_test_url "127.0.0.1" [ -d /tmpRoot ] && /tmpRoot/usr/syno/bin/synosetkeyvalue /tmpRoot/etc.defaults/synoinfo.conf drive_db_test_url "127.0.0.1" ``` The 2nd line was added by one of the xpenology devs, and I assumed they knew what they doing. I guess they didn't care if there was a trivial error message because they run the script while DSM is booting so nobody would see the message. The reason they wanted that line added was because during DSM's junior boot process /usr/syno/bin/synosetkeyvalue is not available, so during boot xpe has it's own copy of synosetkeyvalue (and other files) that run from /tmpRoot I'm not sure how your NAS has /tmpRoot but it does not contain /tmpRoot/usr/syno/bin/synosetkeyvalue To make that line bulletproof I'd need to check both files exist in /tmpRoot ``` if [ -f /tmpRoot/usr/syno/bin/synosetkeyvalue ] && [ -f /tmpRoot/etc.defaults/synoinfo.conf ]; then /tmpRoot/usr/syno/bin/synosetkeyvalue /tmpRoot/etc.defaults/synoinfo.conf drive_db_test_url "127.0.0.1" fi ```

kerem commented

2026-03-11 12:52:42 +03:00

Author

Owner

@007revad commented on GitHub (Dec 29, 2024):

A bigger concern is why one of your drive models is shown as "4TB"
4TB,VE0R5305,4000 GB

From a quick google for VE0R5305 it looks like that SSD drive is an Intenso SSD 4TB

Also a little feature request: even when the vendor id has been matched, show it somewhere in the output to be able to confirm it.
Good idea.

FYI the script only checks the vendor id for NVMe drives. There has never been a need to get the vendor id for SATA, or SAS, SSDs and HDDs.

@007revad commented on GitHub (Dec 29, 2024): A bigger concern is why one of your drive models is shown as "4TB" `4TB,VE0R5305,4000 GB` From a quick google for VE0R5305 it looks like that SSD drive is an Intenso SSD 4TB > Also a little feature request: even when the vendor id has been matched, show it somewhere in the output to be able to confirm it. Good idea. FYI the script only checks the vendor id for NVMe drives. There has never been a need to get the vendor id for SATA, or SAS, SSDs and HDDs.

kerem commented

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

Author

Owner

@phit42 commented on GitHub (Dec 30, 2024):

A bigger concern is why one of your drive models is shown as "4TB" 4TB,VE0R5305,4000 GB

From a quick google for VE0R5305 it looks like that SSD drive is an Intenso SSD 4TB

Also a little feature request: even when the vendor id has been matched, show it somewhere in the output to be able to confirm it.
Good idea.

FYI the script only checks the vendor id for NVMe drives. There has never been a need to get the vendor id for SATA, or SAS, SSDs and HDDs.

Because it is a cheap rip-off, I now assume :(

Anyway, thank you for the quick fix.
Should my tmpRoot point to sth and is broken, or is it sth the script is using?

@phit42 commented on GitHub (Dec 30, 2024): > A bigger concern is why one of your drive models is shown as "4TB" `4TB,VE0R5305,4000 GB` > > From a quick google for VE0R5305 it looks like that SSD drive is an Intenso SSD 4TB > > > Also a little feature request: even when the vendor id has been matched, show it somewhere in the output to be able to confirm it. > > Good idea. > > FYI the script only checks the vendor id for NVMe drives. There has never been a need to get the vendor id for SATA, or SAS, SSDs and HDDs. Because it is a cheap rip-off, I now assume :( Anyway, thank you for the quick fix. Should my tmpRoot point to sth and is broken, or is it sth the script is using?

kerem commented

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

Author

Owner

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

tmpRoot is created by DSM when booting. But it should not exist once DSM has booted. None of my 3 Synology NAS has a /tmpRoot folder or symlink.

@007revad commented on GitHub (Dec 31, 2024): tmpRoot is created by DSM when booting. But it should not exist once DSM has booted. None of my 3 Synology NAS has a /tmpRoot folder or symlink.

kerem commented

2026-03-11 12:52:57 +03:00

Author

Owner

@phit42 commented on GitHub (Dec 31, 2024):

Thanx 007revad. This can be closed.

@phit42 commented on GitHub (Dec 31, 2024): Thanx 007revad. This can be closed.