mirror of
https://github.com/007revad/Synology_HDD_db.git
synced 2026-04-25 21:55:59 +03:00
[GH-ISSUE #73] Very weird behavior after updating to DSM 7.2rc and running the Synology_HDD_db script #739
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Synology_HDD_db#739
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @007revad on GitHub (Apr 28, 2023).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/73
On reddit dukdukgoose wrote:
I no longer have access to the Storage Manager app, the Snapshot Replication app, and most of the Hardware tab in control panel (fan speed, beep setting, etc). Also in Control Panel/Info Center "Model name" is listed as "Unknown Model" (instead of DS918+) and "Fan Speed Mode" is blank... probably because most of the hardware features are disabled because it doesn't know what the model is any more.
Any ideas how to resolve this? I tried the --restore switch on the script but that actually made it worse as it caused DSM to stop seeing my M.2 volume... so I ran the script again and volume returned.
The good news is I haven't lost any data, but not having the Storage Manager and hardware features working is a big problem. I could try a level 2 reset of DSM, but I'd rather not if it's not necessary.
@007revad commented on GitHub (Apr 28, 2023):
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 commented on GitHub (Apr 28, 2023):
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 commented on GitHub (Apr 29, 2023):
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:
syno_disk_db_update --updatecommand. 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.syno_disk_db_update --updatebefore I had rebooted points to the issue already being a problem at that point... but of course I'm just speculating.@007revad commented on GitHub (Apr 29, 2023):
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:
@elisimpson commented on GitHub (Apr 29, 2023):
Looks like /proc/cmdline syno_hw_version is corrupt
@007revad commented on GitHub (Apr 29, 2023):
Can you report back what the following command returns:
cat /proc/cmdline@elisimpson commented on GitHub (Apr 29, 2023):
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,XXXXXXXXXXXXSo it's actually correct in that file... hmm
@007revad commented on GitHub (Apr 29, 2023):
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 commented on GitHub (Apr 29, 2023):
I notice that 7.2 RC has extra bits of information and 2 of them stand out:
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 commented on GitHub (Apr 29, 2023):
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 commented on GitHub (Apr 29, 2023):
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 commented on GitHub (Apr 29, 2023):
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 commented on GitHub (Apr 29, 2023):
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 commented on GitHub (Apr 29, 2023):
It wouldn't let me install it because it's the same build number :/
@007revad commented on GitHub (Apr 29, 2023):
I think Synology screwed up by not changing the build number. Hopefully they'll fix it once they become aware of it.
@007revad commented on GitHub (Apr 29, 2023):
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:
Other drives have:
@007revad commented on GitHub (Apr 29, 2023):
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 commented on GitHub (Apr 29, 2023):
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 commented on GitHub (Apr 29, 2023):
Okay. Do the same again, but this time /var/lib/disk-compatibility
@elisimpson commented on GitHub (Apr 29, 2023):
Done. No message or error when running command, no noticeable change in DSM. Should I reboot?
@007revad commented on GitHub (Apr 29, 2023):
It certainly wouldn't hurt to reboot.
@elisimpson commented on GitHub (Apr 29, 2023):
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 commented on GitHub (Apr 30, 2023):
Do you have backups of your data and DSM system configuration?
@elisimpson commented on GitHub (Apr 30, 2023):
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 commented on GitHub (Apr 30, 2023):
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 commented on GitHub (Apr 30, 2023):
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 commented on GitHub (Apr 30, 2023):
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:
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 commented on GitHub (Apr 30, 2023):
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 commented on GitHub (May 2, 2023):
@007revad, it might be a good idea to add the following (or similarly edited) to your script:
Hit two birds with one stone, etc...
@007revad commented on GitHub (May 2, 2023):
I added that 4 weeks ago in v1.2.15 :)
The later versions of the script will:
support_m2_pool="yes"line to synoinfo.conf if support_m2_pool doesn't exist in synoinfo.conf.@michealespinola commented on GitHub (May 2, 2023):
Oh brother, I don't know how I missed that update. Sorry, and thank you!
@elisimpson commented on GitHub (May 22, 2023):
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 commented on GitHub (May 22, 2023):
That's excellent news @elisimpson
@elisimpson commented on GitHub (Jun 21, 2023):
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 commented on GitHub (Jun 22, 2023):
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.