DSM 7.3 Neue Version 7.3.2 – 86009

[Benie]

Sieht so aus ! Das automatische Update der Laufwerksdatenbank ist heute Nachmittag gelaufen. Manuell habe ich die eh noch nie Upgedatet.

Edit: auf der DS 920+ Hatte ich bisher diesbezüglich noch nie Probleme.

 

[DaveR]

DSM used to check for Drive Database updates at midnight, or when a new drive was inserted. DSM 7.3 seems to also check at random times (which may only occur on '25+ models).

@Benie It sounds like you are using a version of syno_hdd_db from before 3.6.115

• Bug fix for DSM 7.3 not disabling compatible drive database auto update.

 

[Benie]

That's right, it was probably the version Synology_HDD_db-3.6.112 or Synology_HDD_db-3.6.113. I think I used the version from my DS920+without thinking, hence the slightly older version. I will use the newer version so that this doesn't happen to me again. Thanks for your tips on this.

 

[Benie]

Dear @DaveR

What happens with this Script File wich was also in the Zip Synology_HDD_db-3.6.118

"syno_hdd_shutdown.sh"

 

[DaveR]

It's for people whose 3rd party NVMe volume does not appear until after a 2nd reboot, after a DSM update.

synopkg in DSM 7.3 seems to have changed to automatically "repair" packages whose volume is missing by installing them on the first available volume (usually a HDD volume). But I noticed that packages that are stopped before the DSM update don't get started after boot-up so they don't get automatically repaired.

syno_hdd_shutdown.sh is for scheduling to run as root at shutdown to prevent DSM updates from "repairing" missing NVMe packages (by installing on them on the HDD volume). It's only needed if you have packages, or shared folders that packages depend on, installed on a 3rd party NVMe volume.

syno_hdd_shutdown.sh is not finished yet, but the first test version accidentally got copied from dev to main.

When finished syno_hdd_shutdown.sh will:

1. Check for packages installed on a 3rd party NVMe volume.
2. Check for other packages that depend on the packages installed on a 3rd party NVMe volume.
3. Check for packages that depend on a shared folder that is on a 3rd party NVMe volume.
4. Stop those packages and create a log of the packages it stopped and the NVMe volume number(s).

Then I need to update syno_hdd_db.sh so it:

1. Checks if there is a log of stopped packages.
2. Checks if the NVMe volumes those packages need is writable.
3. If 2 is okay then start the packages listed in the log and delete the log.

 

[Benie]

Thank you for your explanations.

I think I remember that you have already described this problem here in the forum and can now assign it.
Today, when I looked in my DS920+ which version I had saved there (always save the currently used zip file) I remember that I had also this problem with the app installations on a different volume on my DS920+ during the first or second update with 7.3.x. I think this was already fixed with a newer script version (....312, .....313)

The description of the shut_down_script sounds good. Here in Germany we say when we hear something like this: "You're already a clever fox" (Foxes are said to be particularly clever and sophisticated)

 

[MissErfolg]

Ich möchte nur kurz über mein Update von 7.2.2 Update 5 auf 7.3.2 Update berichten. Das Kritische ist, dass ich die M.2-Slots als Volume eingebunden habe. Sonst wäre das Update Standard gewesen.

Bin wie folgt vorgegangen:

1) Dass HDD-Script von DaveR beim Herunter- und Herauffahren eingebunden (mit E-Mail Benachrichtigung, damit man sieht, dass es wirklich läuft).

2) Zusätzlich das neue Scipt von DaveR beim Herunterfahren eingebunden, welches alle laufenden Apps stoppt.

3) Zur Sicherheit alle Apps, die auf Volume2 (M.2) laufen, manuell gestoppt.

4) Update laufen lassen -> Volume2 "defekt". Achtung! Hier keine Apps manuell starten, sondern die Kiste direkt neu starten -> Volume wieder ordentlich eingebunden.

5) Einige Apps starten sich beim Hochbooten automatisch, ohne dass ich einen Weg gefunden habe, dies zu verhindern. Da Volume2 nicht vorhanden ist, die DS aber meint, dass bestimmt Apps vorhanden sein müssen, installieren sich diese dann nicht auf Volume2, weil das zu dem Zeitpunkt noch defekt ist (beim ersten Neustart). Sie sind dann auf Volume1 im "nackten" Zustand (alte Einstellungen nicht mehr vorhanden). Diese Apps nun deinstallieren und auf Volume2 neu installieren und starten. Alte Einstellungen der Apps sind wieder da.

Jetzt läuft bei mir wohl die Indexierung. Mal gucken, wie lange das anhält. Ansonsten sehe ich aktuell keine Auffälligkeiten.

 

[s3b0r]

Ich brauchte einen zweiten Neustart auf der DS920+ (DX517), da der NVME-SSD Speicherpool offline war, wegen nicht unterstützter NVME Module. Es lief wieder diese komische Paketaktualisierung (ich hatte vorher extra im Paketzentrum geschaut, es wurden keine Updates angeboten) während des Neustarts, welcher wohl das Ausführen des hdd_db Scripts verhindert.
Nach dem erneuten Neustart, läuft alles wie gewohnt.

Moin,
mein DS920+ mit DX517 und NVME-SSDs als Cache zeigt jetzt Volume1 abgestürzt nach dem Upgrade, hattest du das auch und was kann ich jetzt tun? Es kann doch nicht alles weg sein!
Ich brauche dringend Unterstützung, da waren ne Menge wichtiger Daten drauf.
Neben Volume1 abgestürzt werden auch die beiden NVMEs mit Fehler: Erkannt! angezeigt. Was kann ich tun?

 

[Benie]

Downloade Dir die neueste Script Date von @DaveR runter und lass diese wieder per Aufgabenplaner laufen und alles wird wieder gut. Bitte auch einen Reebot zum Test durchführen.


https://github.com/007revad/Synology_HDD_db

 

[s3b0r]

Ich habe die DS920+ jetzt einmal heruntergefahren und DS920+ und DX517 20 Sekunden vom Strom getrennt und dann wieder eingeschaltet, leider ohne Erfolg. NMVEs immer noch als Erkannt mit rotem Ausrufezeichen gezeigt und das Volume1 ist weiter im Status abgestürzt.

 

[MissErfolg]

Hast du denn das Script laufen lassen? Danach ist das Volume mit an Sicherheit grenzender Wahrscheinlichkeit wieder da.

 

[DaveR]

2) Zusätzlich das neue Scipt von DaveR beim Herunterfahren eingebunden, welches alle laufenden Apps stoppt.

I have a new version of the shutdown script but I haven't finished testing it yet.

1. It stops all apps installed on an NVMe volume.
2. Stops all apps on a HDD volume that depend on an app installed on an NVMe volume.
3. If run with the -e option, stops all apps installed on a volume in an expansion unit, or depend on apps installed on a volume in an expansion unit.
4. If run with the -eunits=<eunit-model> option, stops all apps installed on a volume in the specified expansion unit model, or depend on apps installed on a volume in the specified expansion unit model.

3 and 4 are for people who use my Syno_enable_eunit script to use an incompatible Synology expansion unit with their NAS. Like a RX418 on a DS NAS, DX517 on an RS NAS, or an old model DX or RX expansion unit with a recent model DS or RS NAS.

I haven't decided if I need to also stop apps that depend on shared folders on an NVMe volume (or expansion unit volume).

I'm also considering preventing packages from auto updating (for '25+ models):

1. Get and save the current Package Center Auto Update settings.
2. Disable Package Center Auto Update.
3. Then syno_hdd_dd would restore the previous Package Center Auto Update settings once the NVMe volume (and/or expansion unit volume) was back online.