mirror of
https://github.com/007revad/Synology_HDD_db.git
synced 2026-04-25 13:45:59 +03:00
[GH-ISSUE #373] Volume disappeared after rebooting, second attempt pre-boot #632
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#632
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 @Neobond on GitHub (Oct 22, 2024).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/373
I am running DSM 7.2.2 via ARC Patch on a F4-424 Max with a SHR volume on 2x NVMe and another volume on 2x HDDs. The last time I ran this script, DSM wouldn't boot, I think the volume on the NVMe was removed, even though I saved and ran the script from the HDD (volume2).
Just wondering if this looks good (have not rebooted yet, so I still have the firmware error for both TEAMGROUP SSDs)
And I created a boot task to run on boot (as root).
Kind of worried to reboot :P
@007revad commented on GitHub (Oct 22, 2024):
I see 2 issues:
To fix issue 1, run the script once with the --restore option to undue the previous changes, then run the script as normal.
For issue 2, what does "Storage Manager > HDD/SSD" show as the Model and Firmware?
@Neobond commented on GitHub (Oct 22, 2024):
Thanks for the reply. The 20TB drives are whitelabel (Seagate X22 20TB)
I followed the instructions to restore and reran the script, and it seems to add back the same 20000 data for the HDDs
Here is a snapshot of the drives in Storage Manager, they are TEAMGROUP MP44Q 4TB drives sent directly from the manufacturer (they are ex review drives) I have 4 in total and the other two do show T-FORCE in the name.
what the 4 drives look like
Other two showing T-FORCE in the name
But they are stickered the same!?
@Neobond commented on GitHub (Oct 23, 2024):
@007revad any idea if I can proceed safely with the screenshots I provided?
I was also wondering, if I disabled the compatibility list from updating, I wouldn;'t need to run the script on every boot right?
@007revad commented on GitHub (Oct 23, 2024):
Even with the compatible drives list updates disabled DSM will still update the list when you do a DSM update.
Both of them run the script during the junior boot process, and their loaders edit the model.dtb file (if it's a device tree model).
So if you have the hdddb addon enabled with different options it could undo what the syno_hdd_db script did when you ran it.
@Neobond commented on GitHub (Oct 23, 2024):
Ahh thanks, yes I do have that addon enabled with ARC bootloader, so I would have to go to the bootloader and disable the ARC addon compatibility, rebuild the loader and boot to DSM, which should then just trigger yours, and fix the firmware update message?
I am more worried if my SSD volume will disappear when using the script.
@007revad commented on GitHub (Oct 23, 2024):
Your SSD volume should not disappear, but I can't be 100% sure because I don't know what caused it to disappear.
@Neobond commented on GitHub (Oct 24, 2024):
I installed Arc Control and the disk and memory compatibility are unticked by default, I think it is because it was applied once in the original boot loader (to allow installation) but I can't be sure.
I am going to reboot to the loader and check the addons, if I lose the SSD volume I will have to do some more testing before I can start migrating.
@007revad commented on GitHub (Oct 24, 2024):
Is Arc Control a package? I assume it is included with Arc Loader?
I'd like to be able to have a look at Arc Control without having to setup a XPE box.
@Neobond commented on GitHub (Oct 24, 2024):
Can you DM me or something because the developer does not allow public sharing of ARC files.
Anyway I disabled the Arc compatibility addon/unticked synoboot compatibilty checking, and rebooted with just the script active and I still get the unrecognized firmware message.
@Neobond commented on GitHub (Oct 26, 2024):
I am not sure what got it working, possibly updating the ARC loader boot image from 24.10.04 to the latest one (24.10.25) I reenabled the hdddb addon, also ensured HDD and memory compatibility was checked in Synoboot options, and now the unknown firmware message is gone.
I am pretty sure I started off with this same exact config, so I am just going to blame it on the bootloader version difference.
Thanks for your help!