Very weird behavior after updating to DSM 7.2rc and running the Synology_HDD_db script

[007revad]

Very weird behavior after updating to DSM 7.2rc and running the Synology_HDD_db script

[007revad]

I just noticed the Synology's serial number was included so I redacted it for you. I also redacted the MAC addresses.

Yes, it is correct. In fact they're all correct.

[007revad]

@007revad, it might be a good idea to add the following (or similarly edited) to your script:

/usr/syno/bin/synosetkeyvalue /etc.defaults/synoinfo.conf support_m2_pool yes

Hit two birds with one stone, etc...

I added that 4 weeks ago in v1.2.15 :)

The later versions of the script will:

• Add the support_m2_pool="yes" line to synoinfo.conf if support_m2_pool doesn't exist in synoinfo.conf.
• Or change support_m2_pool="no" to support_m2_pool="yes" if it exists but is disabled.

[michealespinola]

Oh brother, I don't know how I missed that update. Sorry, and thank you!

[elisimpson]

Update: I applied the DSM7.2 final version that was released a few hours ago. On reboot, my M.2 storage pool was missing (as expected), but all the corruption issues were gone: Storage Manager & Snapshot Replication were accessible, Control Panel hardware tabs working, no "Unknown model", etc. Then I ssh'd in and changed the two synoinfo.conf files to support_m2_pool="yes", rebooted, and all appears to be back to normal. M.2 volume healthy and accessible.

[007revad]

Someone else reported the same thing. I'm trying to work out if it is a 7.2 RC bug or caused by my script somehow.

Did you also run one of my other scripts? If yes, which one?

[007revad]

It seems that 7.2 RC does have some bugs. https://community.synology.com/enu/forum/1/post/160221

Fixing the model name issue would be easy once we figure out which model name is corrupted or missing. DSM stores the model info in a few places.

[elisimpson]

Someone else reported the same thing. I'm trying to work out if it is a 7.2 RC bug or caused by my script somehow.

Did you also run one of my other scripts? If yes, which one?

Only the Synology_HDD_db script, but I had manually created a M.2 volume a year or so ago with the command line process that was shared on reddit.

My process was as such:

1. Updated to 7.2. On restart it went through the automatic package update process. Everything looked okay on initial login. Package Center and Snapshot Replication shortcuts were still on my desktop, although I didn't actually go to them. Notification came up that one of my drives was unsupported (the nvme drive), but the volume still was available.
2. The notification led me to try running your script. I logged to SSH and first ran the script with the -sn switch
3. It appeared to run okay, but I realized my understanding of the -n switch was incorrect (I thought it was like a "dry run" switch that wouldn't actually apply any changes but tell you which changes would be made.) I thought I'd undo and try again so I ran the script again with --restore
4. This is where I encountered my first bug: the script hung up at the syno_disk_db_update --update command. At the time I didn't know what was happening, but this is probably related with the other connection to Synology issues I'm seeing from this issue (DSM update can't connect when checking for update). Probably because it can no longer tell what model is trying to connect.
5. As restore didn't appear to work I tried running the script again with no switches. It finished without errors
6. On reboot, I noticed Storage Manager and Snapshot replication shortcuts were no longer on my desktop. Neither were available in the Synology "Start" menu either. Clicking the Storage "widget" which normally launches Storage Manager did nothing. On opening the control panel I could see many tabs were missing in the Hardware & Power section. The Info Center section showed "Unknown Model" as the model name.
7. At this point I thought running the script had corrupted something, but now I'm not so sure it wasn't already corrupted by the DSM upgrade. I noticed all the problems because of the second reboot, but they may have been there already. The fact the the --restore switch hung on syno_disk_db_update --update before I had rebooted points to the issue already being a problem at that point... but of course I'm just speculating.

[007revad]

Someone with a DS1823xs+ who upgraded from 7.2 Beta to 7.2 RC also reported that they lost access to Storage Manager after restarting the NAS. But I still don't know if it's 7.2 RC bug or if it's (somehow?) caused by my script. They had an empty drive bay and were able to fix the problem here.

Can you download this: https://github.com/007revad/Synology_HDD_db/archive/refs/tags/get_syno_model.tar.gz
Then extract it and run the get_syno_model.sh file and report back it's output.

It should output what DSM thinks is the model like:

unamee:
synology_v1000_1821+

/etc/synoinfo.conf unique:
synology_v1000_1821+

/etc.defaults/synoinfo.conf unique:
synology_v1000_1821+

/etc/synoinfo.conf upnpmodelname:
DS1821+

/etc.defaults/synoinfo.conf upnpmodelname:
DS1821+

/proc/cmdline syno_hw_version:
DS1821+

/rpco/sys/kernel syno_hw_version:
DS1821+

[elisimpson]

unamee:
synology_apollolake_918+

/etc/synoinfo.conf unique:
synology_apollolake_918+

/etc.defaults/synoinfo.conf unique:
synology_apollolake_918+

/etc/synoinfo.conf upnpmodelname:
DS918+

/etc.defaults/synoinfo.conf upnpmodelname:
DS918+

/proc/cmdline syno_hw_version:
4

/rpco/sys/kernel syno_hw_version:
DS918+

Looks like /proc/cmdline syno_hw_version is corrupt

[007revad]

Can you report back what the following command returns:
cat /proc/cmdline

[elisimpson]

root=/dev/md0 earlyprintk=apl console=ttyS2,115200n8 ihd_num=4 netif_num=2 HddHotplug=1 SataPortMap=23 sata_remap=0>2:1>3:2>0:3>1 syno_hw_version=DS918+ vender_format_version=2 syno_hdd_detect=18,179,176,175 syno_hdd_enable=21,20,19,9 syno_usb_vbus_gpio=13@0000:00:15.0@1,11@0000:00:15.0@2 sn=XXXXXXXXXXXXX macs=XXXXXXXXXXXX,XXXXXXXXXXXX

So it's actually correct in that file... hmm

[007revad]

I notice that 7.2 RC has extra bits of information and 2 of them stand out:

syno_hdd_detect=18,179,176,175
syno_hdd_enable=21,20,19,9

I have no idea what they mean, yet.

Can you attach a zipped copy of the following (name the zip file edited.zip)
/etc.defaults/synoinfo.conf
/var/lib/disk-compatibility/

And a zipped copy of the following (name the zip file clean.zip)
/etc/synoinfo.conf
/var.defaults/lib/disk-compatibility/

Let me know if you don't how to get those files and directories.

[elisimpson]

There's quite a bit of personal info in the /etc/synoinfo.conf file. Do you need the whole thing or is there specific parts you're interested in?

EDIT: also I've noticed the 7.2rc .pat download has been removed from the DS918+ download page.

[007revad]

The 7.2 RC download has also been removed from the DS1821+ download page. It looks like Synology have realised it contains some nasty bugs and have removed it until they they can upload a fixed version.

[elisimpson]

edited.zip
clean.zip

I've attached the files you asked for, except for /etc/synoinfo.conf. Please let me know if there's any specific settings you'd like from that file

[007revad]

DSM 7.2 RC is back online. It has the same build number but the .pat file size is different so Synology has changed something.

I wonder if DSM 7.2 RC lets you reinstall DSM 7.2 RC

[elisimpson]

It wouldn't let me install it because it's the same build number :/

[007revad]

I think Synology screwed up by not changing the build number. Hopefully they'll fix it once they become aware of it.

[007revad]

I've noticed that 7.2 RC has 2 extra fields in the .db files for all drives. In 7.2 Beta they only existed in entries for Synology drives.

Synology drives have:

"smart_test_ignore": true,
"smart_attr_ignore": true

Other drives have:

"smart_test_ignore": false,
"smart_attr_ignore": false

[007revad]

I've manually edited your ds918+_host_v7.db file to add the missing lines for each of your drives.
ds918+_host_v7_fixed.zip

Can you replace ds918+_host_v7.db and ds918+_host_v7.db.new in /var.defaults/lib/disk-compatibility/ with those in the attached zip file.

Then run the following command to get DSM to reload those files (or you can reboot)
sudo /usr/syno/sbin/synostgdisk --check-all-disks-compatibility

[elisimpson]

Just to be clear: there is no ds918+_host_v7.db.new in /var.defaults/lib/disk-compatibility/

so I replaced ds918+_host_v7.db and added ds918+_host_v7.db.new

I ran the command and it completed without any messages or errors. I don't notice any changes within DSM though

[007revad]

Okay. Do the same again, but this time /var/lib/disk-compatibility

[elisimpson]

Done. No message or error when running command, no noticeable change in DSM. Should I reboot?

[007revad]

It certainly wouldn't hurt to reboot.

[elisimpson]

No change in DSM. Still "Unknown Model", Hardware & Power missing tabs, no Storage Manager, etc. It didn't hurt anything though: volumes are still healthy and accessible.

[007revad]

Do you have backups of your data and DSM system configuration?

[elisimpson]

Right now I'd say I have good backups of about 85% of my files. I don't have a recent DSM config backup, but I can make one now (although it might include whatever is messed up right now). If I have to reset the NAS I will, but I don't think I want to try that until a new DSM 7.2 version drops that I can actually install.

I wish I had an empty bay...

[007revad]

I've been thinking about how you could repair the DSM partition but I didn't want to suggest anything if you didn't have backups. I've thought 3 different ways but they'd put your data at risk.

[elisimpson]

Well I'm interested in what they are, even if I'm not ready to try them yet. As my actual files and volumes are all healthy at this point it seems prudent to wait to see if future DSM 7.2 updates will fix it. If not I might try a "Level 2" reset, which as I understand reinstalls DSM without blowing away your volumes.

https://kb.synology.com/en-global/DSM/tutorial/How_to_reset_my_Synology_NAS_7#t2

I'm looking into buying another large HDD so I can backup the remaining files on the 918+ that aren't currently backed up. If I were to loose them it wouldn't be a disaster, just time consuming. All the really important stuff is already backed up multiple places.

[007revad]

I'm certain that you lose your data when doing the mode 2 reset because the installation wizard formats the drives.

Waiting for a future DSM 7.2 update would my choice.

Other possible options:

1. Edit /etc.defaults/VERSION to an earlier version so it will let you re-install the version you are already using (there's actually a lot more steps involved). If done correctly your data should be safe.
2. Run the command that DSM uses to repair the system partition. Normally when the system partition becomes corrupt storage manager will offer to repair it... but you can't get into storage manager. So I thought why not try the same command that storage manager uses, but I haven't found out exactly what that command is yet. Your data should be safe with this method.
3. A third possible option might be a variation on what Tom did here. NOTE the following are not the exact steps (it's a short description of an idea). Instead of using an empty drive bay you'd install an unused drive in bay 4, and when you get to the step of re-inserting your existing drives just insert drives 1, 2 and 3 and let the NAS repair DSM on drive's 1, 2 and 3 from drive 4. The storage pool will show as degraded. Then remove the spare drive 4 and insert your original drive 4 and let the NAS repair the degraded storage pool.

But since the final version of DSM 7.2 should be less than a month away (and there could be other RC versions before then) I'd wait for the next DSM 7.2 update.

[elisimpson]

I'm fine to wait until the next DSM update comes out (with a new build number this time hopefully). This seems the most prudent approach as at this point all my data is fine and accessible.

I've been thinking about buying a 1621+ or 1821+ as an upgrade so I guess if I did that I could do option 3 from above (Tom's approach) without needing to degrade the storage pool.

I'm really surprised you say a "Mode 2" reset will format the storage pools. Everything I've read specifically says it doesn't. It always recommends having a backup but says the volumes should be intact. I guess if I ever have to try it as a last resort I'll make sure I have absolutely everything backed up first.

[michealespinola]

@007revad, it might be a good idea to add the following (or similarly edited) to your script:

/usr/syno/bin/synosetkeyvalue /etc.defaults/synoinfo.conf support_m2_pool yes

Hit two birds with one stone, etc...

[007revad]

That's excellent news @elisimpson

[elisimpson]

Quick question: I updated to DSM7.2-64570-update1 yesterday and lost the m2 volume again (as expected). Edited /etc.defaults/synoinfo.conf with support_m2_pool="yes" and all was well again.

Am I correct in assuming if I set up a scheduled task "on boot" with synosetkeyvalue "/etc.defaults/synoinfo.conf" "support_m2_pool" "yes" it will prevent the problem on future updates? Will that script run before DSM disables the volume on reboot from a DSM update?

[007revad]

Am I correct in assuming if I set up a scheduled task "on boot" with synosetkeyvalue "/etc.defaults/synoinfo.conf" "support_m2_pool" "yes" it will prevent the problem on future updates? Will that script run before DSM disables the volume on reboot from a DSM update?

That would work. But most people just schedule syno_hdd_db.sh to run at boot.

FYI I was recently able to reproduce your original issue of "no storage manager or model number etc" and found that it was caused when the script restored a backup of synoinfo.conf that was backed up when using an older DSM version. I have a solution that I've been working on that will be in the next syn_hdd_db version to prevent it happening again.