FlexDSM Posted March 26 #1 Posted March 26 Ich schaffe es nicht und hoffe hier kann mir einer helfen! Eigentlich ganz einfach und doch so schwer... Ich verwende schon seit langem das All-in-One Installationsfile aus diesem Topic: Nun ist es erforderlich, dass ich für eine weitere Installation der DSM in einer ESXi VM die Datei synoboot.vmdk editiere, speziell hier die grub.cfg, da ich die MAC Adresse ändern muss. Sonst bekommen die DSM VMs im gleichen Subnetz die gleiche MAC, was zu Konflikten führt. Ich habe versucht die synoboot.vmdk mit OFSmount zu bearbeiten. Hier kann ich diese nur im Read-Only-Modus öffnen. Dann habe ich versucht die Datei über VMware Workstation Virtual Disk Mapper zu öffnen, das funktioniert, hier kann ich auch die Datei ändern und speichern. Sobald ich das gemappte Laufwerk auswerfe, sind die Änderungen aber nicht mehr gespeichert. Sehr merkwürdig, irgendwie muss die Datei synoboot.vmdk hier eine Art Schreibschutz haben, anders kann ich mir das nicht erklären. Wer kann mir weiterhelfen? Ich möchte nur die grub.cfg in der synoboot.vmdk ändern. Die synoboot.vmdk muss als solche erhalten bleiben. Ich kann die Datei auch gerne zur Verfügung stellen, bzw. ihr könnt euch diese immer noch in dem oben genannten Topic herunterladen. xpenology-ds3617xs-all-in-one.zip ist dort verlinkt und beinhaltet drei Dateien, DSM.ovf, DSM_DS3617xs_23739.pat und eben die synoboot.vmdk. Danke. Gruß Flex Quote
IG-88 Posted March 26 #2 Posted March 26 (edited) also ich habe immer eine *.img verwendet die ich mit den üblichen tools angepasst habe und für zugriff über vmdk (bei mir virtualbox) habe ich ein *.vmdk "textfile" das auf die img zeigt hier mal ein beispiel der vmdk als text file (synoboot..img -> 50.0 MB, 52.428.800 Bytes für größere img's dann mehr cylinders und die extend descrition a passen https://github.com/libyal/libvmdk/blob/main/documentation/VMWare Virtual Disk Format (VMDK).asciidoc synoboot.vmdk # Disk DescriptorFile version=1 CID=e2100854 parentCID=ffffffff createType="vmfs" # Extent description RW 102400 VMFS "synoboot.img" # The disk Data Base #DDB ddb.virtualHWVersion = "4" ddb.adapterType="lsilogic" ddb.geometry.cylinders="101" ddb.geometry.heads="16" ddb.geometry.sectors="63" ddb.geometry.biosCylinders="101" ddb.geometry.biosHeads="16" ddb.geometry.biosSectors="63" ddb.uuid.image="fd1ae3d1-d93b-4266-9be2-75e7add191af" ddb.uuid.parent="00000000-0000-0000-0000-000000000000" ddb.uuid.modification="811cfa7a-2046-4270-ad2b-2e92e61d63a9" ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000" ddb.comment="" ansonsten goggle doch mal "windows mount vmdk", da gibts noch andere lösungen als die vmware workstation Edited March 26 by IG-88 Quote
FlexDSM Posted March 27 Author #3 Posted March 27 Hallo IG-88, erstmal herzlichen Dank für deine Antwort. Freue mich sehr, dass ich hier eine Rückmeldung bekomme. Leider kann ich dem nicht ganz folgen was du meinst. Ich habe ja drei bzw. zwei Dateien mit denen ich die VM erstelle, also die OVF und die VMDK. Diese benötige ich für die VM im ESXi, so wie auch in der Anleitung beschrieben. Das mit der VDMK>TXT Datei und dann auf die img-Datei zu verweisen würde vermutlich in meinem Szenario nicht funktionieren. Ich hatte bereits auch mit dem StarWindConverter mein Glück versucht, komme da aber auch nicht zurecht, erhalte dann immer zwei Dateien. Ich brauche ja nur die vmdk und die sollte vom inhaltlichen Aufbau so erhalten bleiben wie das Original. Ich habe jetzt noch mit 7Zip die vmdk Date geöffnet, da komme ich auch überall rein uns sehe alle Partitionen und Dateien. Aber wenn ich die Änderungen speichern will kommt die Meldung, dass die Datei schreibgeschützt ist. Hier liegt das Problem. Wie kann ich den Schreibschutz aufheben bzw. entfernen? Unter Windows ist in den Dateieigenschaften zumindest kein Schreibschutz aktiviert, das wird dann wohl irgendwo in der Datei selbst sein? Wenn ich den aufheben kann wäre das Problem vermutlich gelöst. Quote
IG-88 Posted March 28 #4 Posted March 28 das paket vom tutorial ist "nur" ein ganz normaler jun 1.03b loader für 3617 bei dem in der grub.conf etwas angepasst wurde im orginal kommt jun's 1.03b loader mit einer img datei im grunde kannst du auch die vmdk verwerfen und statt dessen die orginal img von jun zusammen mit dem vmdk test file benutzen wenn die den zustand wie im tutorial willst dann holst du dir die drub.cfg aus dem vmdk (mit 7zip), mountesr jun's orginal mit osfmount und ersetzt die von jun durch die aus dem vmdk file vom tutorial wichtig ist das die vmdk text datei den gleichen namen hat wie die "alte" da ja vie vm' vorlage (ovf) auf diese verweist (aber auch die ovf ist nur eine test datei die man sich anpasse kann - wenn man nur sachen macht deren konsequenzen man überblickt) wie das *.img heist is egal, es muss nur zu dem passen was in der vmdk text datei steht, die vmdk test datei ist im grunde eine art übersetzungsanweisung zu der img datei (name der datei, wie groß, wie sind die "sektoren" angeordnet, ...) da in ovf vorlage auch die größe in bytes steht ( ovf:size="20823040") wäre es vermutlich sicherer erst die vm anlegen zu lassen und danach die erzeugte vmdk test mit dem img in das vm verzeichnis zu legen, die "alte" synoboot zu entfernen und diese neue disk dann der vm hinzufügen mal von den anderen möglichen wegen (vmware workstation hat im menü eine eigene funktion zum mounten einer vmdk - schon mal versucht?) kann man auch bei gestartetem dsm das boot medium mounten und dessen dateien verändern, dsm selbst macht das beim udpate da ja der neue kernel bei einem update auf das bootmedium muss, genauso kann man das boot medium aauch manuell mounten und die grub.cfg anpassen - setzt halt ein wenig linux kenntnisse voraus "sudo su" um sich root rechte zu veschaffen (man muss dann nicht mehr vor jeden befehl sudo schreiben) mkdir -p /mnt/synoboot1 mkdir -p /mnt/synoboot2 mkdir -p /mnt/synoboot3 echo 1 > /proc/sys/kernel/syno_install_flag mount /dev/synoboot1 /mnt/synoboot1 mount /dev/synoboot2 /mnt/synoboot2 mount /dev/synoboot3 /mnt/synoboot3 wenn man das dann gemountet hat kann man unter /mnt/synoboot1 in die grub.cfg gehen und das anpassen was man will würde ich aber so nur zum lernen/rumspielen empfehlen, da die 6.2 schon lange EOL ist, sicherheitslücken und keine updaes mehr bekommt in vielen fällen wäre ein neuer loader mit dsm 7.2 die bessere wahl Quote
FlexDSM Posted March 29 Author #5 Posted March 29 Vielen Dank für die ausführliche Antwort. Quote (vmware workstation hat im menü eine eigene funktion zum mounten einer vmdk - schon mal versucht?) Ich hatte bereits mit in VMware Worstation mit dem Disk Mapper (den meintest du wahrscheinlich) versucht die vmdk zu mounten. Da hat auch wunderbar geklappt, konnte alles editieren und speichern, aber sobald ich das wieder unmounte, sind alle Änderungen verworfen und ich habe wieder die ursprünglichen Dateien. Da komme ich leider auch nicht weiter. Quote im grunde kannst du auch die vmdk verwerfen und statt dessen die orginal img von jun zusammen mit dem vmdk test file benutzen wenn die den zustand wie im tutorial willst dann holst du dir die drub.cfg aus dem vmdk (mit 7zip), mountesr jun's orginal mit osfmount und ersetzt die von jun durch die aus dem vmdk file vom tutorial wichtig ist das die vmdk text datei den gleichen namen hat wie die "alte" da ja vie vm' vorlage (ovf) auf diese verweist (aber auch die ovf ist nur eine test datei die man sich anpasse kann - wenn man nur sachen macht deren konsequenzen man überblickt) wie das *.img heist is egal, es muss nur zu dem passen was in der vmdk text datei steht, die vmdk test datei ist im grunde eine art übersetzungsanweisung zu der img datei (name der datei, wie groß, wie sind die "sektoren" angeordnet, ...) Hier scheitert es bei mir an dem Wissen, wie genau der Textinhalt der TEST-vmdk für meinen Fall aussehen müsste. Der von dir gepostete Beispielinhalt wird mit den ganzen Werten dbb.xxxxxxxxxx nicht passen. Wie ich zu den Werten komme weiß ich nicht. Quote da in ovf vorlage auch die größe in bytes steht ( ovf:size="20823040") wäre es vermutlich sicherer erst die vm anlegen zu lassen und danach die erzeugte vmdk test mit dem img in das vm verzeichnis zu legen, die "alte" synoboot zu entfernen und diese neue disk dann der vm hinzufügen Hier komme ich nicht mit. Wenn die VM angelegt ist, dann habe ich eine Datei die heißt dann z. b. NAS01.vmdk da ich bei der Anlage den Namen NAS01 für die VM vergeben habe. Eine synoboot.vmdk gibt es dann gar nicht mehr, auch keine ovf Datei. Ich habe bei einer angelegten VM eine NAS01.vmdk, NAS01.vmsd und NAS01.vmx. Die NAS01.vmdk ist z. B. diese 50 MB Partiton, die immer vorhanden ist. Wie soll ich hier die geänderten Dateien rein bekommen und ersetzen? Quote bei gestartetem dsm das boot medium mounten und dessen dateien verändern, dsm selbst macht das beim udpate da ja der neue kernel bei einem update auf das bootmedium muss, genauso kann man das boot medium aauch manuell mounten und die grub.cfg anpassen - setzt halt ein wenig linux kenntnisse voraus Das klingt jetzt für mich am ehesten zum umsetzen. Frage hierzu. Muss ich alle drei images mounten, reicht nicht nur das erste Image? Wie unmounte ich das wieder? Oder reicht hier einfach ein Neustart? Quote würde ich aber so nur zum lernen/rumspielen empfehlen, da die 6.2 schon lange EOL ist, sicherheitslücken und keine updaes mehr bekommt in vielen fällen wäre ein neuer loader mit dsm 7.2 die bessere wahl Gebe ich dir natürlich recht, aber ich verwende diese XPEnology tatsächlich nur als Datenspeicher im LAN, nach außen kein Zugriff und Apps brauch ich auch nicht. Netzwerkfreigaben und Einbindung ins AD reicht völlig aus. Deshalb lieber was älteres, das zuverlässig und stabil läuft. Quote
FlexDSM Posted April 1 Author #6 Posted April 1 (edited) Also ich habe es mit dem Workaround gelöst. Auf die DSM mit SSH verbunden und diese Befehle ausgeführt sud su mkdir -p /mnt/synoboot1 echo 1 > /proc/sys/kernel/syno_install_flag mount /dev/synoboot1 /mnt/synoboot1 Die Datei grub.cfg im Ordner /mnt/synoboot1/grub editiert und gespeichert. Ich habe keinen Unmount Befehl benutzt/gefunden und nach Deaktivierung von SSH die VM heruntergefahren. Nach dem Neustart wurde mir die editierte MAC angezeigt. Problem gelöst. Schöner wäre es zwar gewesen die Bearbeitung der vmdk durchzuführen und gleich die Installation mit der neuen MAC zu machen, aber das schein wohl ein Ding der Unmöglichkeit zu sein. Danke an IG-88 für die Hilfe! Edited April 1 by FlexDSM Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.