haydibe

Members
  • Content count

    297
  • Joined

  • Last visited

  • Days Won

    1

haydibe last won the day on October 12 2017

haydibe had the most liked content!

Community Reputation

4 Neutral

About haydibe

  • Rank
    Super Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. haydibe

    Tutorial - Install DSM 6.2 on ESXi 6.7

    The first download includes the bootload 1.01b and a vmdk that points to the synoboot.img. You can easily replace the synoboot.img with a newer bootloader. Just replace it in the datastore.
  2. haydibe

    DSM 6.2 Loader

    forget the L5640. The 4th gen i7 is a Haswell. I just installed DSM 6.2.1 in ESXi on a Sandy Bridge System with bootload 1.03b.
  3. In diesem Post wird Zusatzinformation zu Folgendem englischsparachigen Post gegeben: luchuma created a topic in Tutorials and Guides Die CPU vom HP MicroServer Gen8 is so so alt, dass damit eine DS 918+ nicht betrieben werden kann. Von den angegeben Downloads sind 1) und 2) umbedingt notwendig. Je nachdem, ob ihr die Pat-Datei erst herunterladen und dann installieren wollte oder der Installer das selber machen soll, könnt Ihr Download 3) durchführen oder überspringen. 4) ist erst Relevant wenn die DS fertig installiert ist. 5) Ist das Schweizer-Taschenmesser der Tools die für XPE verwendet werden (können). Ich habe bei der Installation nur zwei Werkzeuge verwendet um erfolgreich DS3615sx 6.1.7 auf DS3615sx 6.2.1 zu aktuallieren: - OSFMount: zum Anpassen der grub.cfg in der .img-Datei - WinSCP: zum hochladen der vmdk und .img-Datei auf den ESXi Datastore. Im Abschnitt "Preparation" habe ich folgendes gemacht: - entpacken von 1) ; in dem Zip sind wir nur an der vmdk-Datei interessiert. Sie hilft uns die modifizierte 1.03b synoboot.img-Datei in ESXi direkt einzubinden. - entpacken von 2) - Starten von OSFMount und mounten der Datei synoboot.img aus 2), dort wie angezeigt Partition 0 mounten und die grub.cfg anpassen. Anders als es auf den Screenshots zu sehen ist, habe ich NUR die Seriennummer und die MAC1 angepasst (dieses sollte zur MAC der späteren Netzwerkkarte passen), da alles andere bei mir zu Probleme geführt hat. Danach in OSFMount den Mount wieder unmounten - wenn hier ein Popup kommt, dann verhindert irgendetwas das unmounten... wenn man "forced" unmountet kann es sein, dass die Änderungen an der grub.cfg weg sind. Nicht abgebildete Aktionen: - kopieren der bearbeiteten synoboot-img-Datei in das Verzeichnis 1). - Hochladen der img- und vmdk-Datei in den Datastore mit WinSCP. Der ESXi Part its als Schablone für die VM-Einstellungen zu verstehen. Dabei ist folgendes zu beachten: - das neue Synoboot-Laufwerk muss als SATA 0:0 gemoutet werden - wenn die grub.cfg nicht beschädigt wird, dann ist dieses Laufwerk unsichtbar für DSM. - Um Datendisks zu verwenden, muss ein neuer virtueller SATA-Controller angelegt werden, alle Datenfestplatten MÜSSEN dann SATA 1:x verwenden um im DSM sichtbar zu sein. - Alternativ kann ein supporteter Hardware-Controller mittels Passthrough in die VM gehangen werden. - Die Netzwerkkarte muss auf Intel 1000e gestellt sein, ihre MAC-Adresse sollte identisch sein, mit der in der grub.cfg. Darüber hinaus habe ich folgende Erfahrung gemacht: - Eine NeuInstallation ist unproblematischer als eine Migration, da Fehler in der grub.cfg sich hier leichter identifzieren lassen. - Vor einer Migration lohnt es sich die Konfiguration aus DSM zu exportieren. - Fehler in der grub.cfg sorgen dafür das SATA0:0 nicht unsichtbar ist für DSM und verhindern die Installation (Es wird gefragt ob n +1 Festplatten formatiert werden soll) . - Es kann sein, dass die Systempartition auf bestehenden Systemen zu Problemen führt, die eine Migration verhindern! Letzteres war bei meiner ersten Migration mit meinem "nur Docker System" der Fall. Ich musste die VM ausschalten, die Platte mit Altdaten von SATA1:0 wieder entfernen, eine frische vmdk an SATA1:0 erzeugen und dann DMS normal installieren. Nach der Installation habe ich das System dann heruntergefahren und dann die Platte mit den Altdaten als SATA1:1 eingehangen und die VM wieder gestartet. Nach dem Einloggen in die DSM-UI wurde angzeigt das eine defekte Systempartition vorliegen würde - diese habe ich reparieren lassen... Die Shares und Daten waren alle wieder da. Nun habe ich die VM wieder heruntergefahren. um die temporäre SATA1:0 zu löschen und die Platte mit den Altdaten auf SATA1:0 zu ändern. Nach einem weiteren Neustart habe ich dann das Docker-Paket installiert, wobei die Container SOFORT wieder in Betrieb genommen wurden, ohne das ich irgendetas tun musste (standen alle auf Autostart). Zusätzlich habe ich noch Webstation und die VMWare Tools installiert, Letsencrypt und meine Aufgaben wieder angelegt und die Migration war abgeschlossen. Lession learned: hätte ich die Einstellungen mal vorher exportiert (cry). Ich hoffe das hilft auch anderen das Update durchzuführen. Ich habe keine Ahnung bei XPE mit VMWare mit nicht Xeon-Systemen, daher werde ich keine Fragen beantworten können zu Themen wie "funktioniert das auch mit Mainboard x oder CPU z"?
  4. haydibe

    DSM 6.2 Loader

    Yesterday, I migratet my "non-storage" instance from bootload 1.02b / DSM 6.1.7 to bootload 1.03b / DSM 6.2.1 on a HP Microserver Gen8 / ESXi 6.5. Some details realy took some time to sink in for me: 1. Only SATA harddisks are supported: 1.1 the bootloader needs to be on SATA 0:0, which makes it invisible for DSM. When the grub.cfg is messed up, the drive will be visable and prevent an instalation/migration. 1.2 all datadisks need to be on a passthrough SATA Controller OR on an additionaly added virtual SATA controller -> SATA1. All drives assigned to SATA 1:n will be visible to DSM. 2. the network addapter must be Intel 1000e 3. let grub select the default boot entry itself, choosing vmware boot explicitly always broke things for me... 4. If the installation does not work because of a formating issue OR the number of expected data disks is higher by 1, it is high likely the grub.cfg was messed up. Side note: the migration failed initialy because the installer complained there wouldn't be enough space on the system partition. I had to unattach my existing disk (which was set to SATA1:0) and add another harddisk as SATA1:0 temporarily. This led to a clean installation, rather than a real migration. Though, after the installation, i attached the existing disk to SATA1:1, started the system, repaired the system partition, shut the system down, removed the temporary disk and set my repaired disk to SATA1:0. The system booted again and all shares and their content was present Though, letsencrypt, webstation, docker and tasks required to be installed and configured again. I am not entirely sure if this behavior was special to the system or will happen on the next two systems i have to upgrade as well.
  5. haydibe

    SSL Zertifikat DYNDNS

    Eigene Domain registrieren? - Du betreibst eine Website, die von aussen frei zugänglich ist: http://www.dot.tk/de/index.html (nur kostenlos mit Website, wird sonst zeitnah gelöscht!) - Du bist bereit etwas Geld in die Hand zu nehmen? Dann eine .de oder .com Domain erwerben. Je nachdem, ob Du eine feste IP-Adresse hast oder nicht, musst du dann entsprechend eine Subdomain anlegen und - bei einer festen IP als A-Record auf die IP zeigen lassen - bei einer dynamische IP einen zusätzlichen DynDns-Account anlegen und als CNAME auf die DynDns-URL ziegen lassen (für Fritzbox Besiter geht auch die MyFritz-Url vom Myfritz-Account) Nach deine Subdomain nun auf deine WAN-IP zeigt, kannst Du letsencrypt für diese Domain verwenden. Mich kostet der Spass im Jahr 5€ für die Domain. Ich selber verwende eine Subdomain mit CNAME auf meine Myfritz-URL.
  6. 1. Not every server board actualy leverages the iGPU, most have a dedicated on board gfx adapter (like the HP Microserver gen8...) 2. You need to at least have a XEON E3 v3 CPU to have a iGPU providing the required features. A V2 CPU is not sufficient.
  7. haydibe

    Progress of 6.2 loader

    No Xeon e3 12x0 commes with a build in GPU. Having hardware accelaration with a XEON E3-1220v3 is impossible due lack of an iGPU. Most server mainboard either depend on an iGPU or provide a crappy onboard GPU. The later ones usualy don't support to use the iGPU instead.
  8. haydibe

    Installation Xpenology Xeon 1225

    Plex SPK/Docker? Berechtigungen richtig gesetz?
  9. haydibe

    XPEnology on Acer AC100

    Hmmm, i just gave away an acer ac-100 with a baremetal xpe intallation on a micro usb stick. Back in the days I liked it way more than the HP Microserver Gen8. The AC-100 has easier to use drive encasings and is considerably smaller in size. Though, the lack of a fifth sata port and the lack of room for an additional ssd made me switch anyway. Back to the topic: the solution is somewhere in the bios. Though, I made the required change long time ago. I don't realy remember what I did. Though it must be located in the drive boot order section. Good luck!
  10. Without editing the grub.cfg in the bootloader only a single XPE instance can be operated in a single network segment! If you don't change the grub.cfg for at least the second instance (regardless wheter it's a second vm on the same/other host or baremetal in the same network) you will cause a MAC collision, which will confuse your switch/router and result in unstable connections (if any at all!) My 2nd XPE instance on the same ESXi host operates webstation and docker containers which are exposed to the internet. If someone manages to exploit one of those services, the lost is limited to whatever is running on that system.
  11. haydibe

    DSM 6.1.6-15266

    - Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 6.1.5 15254 Update 1 - Loader version and model: Jun's Loader v1.02b - DS3617xs - Using custom extra.lzma: NO - Installation type: ESXi 6.5u1 / open-vm-tools 10.1.15-4 uninstalled before update / Passed-through LSI 2008 Controller + SSD VMDK - Additional comments: REBOOT REQUIRED & REPERATION REQUIRED ... finaly my third update on ESXi 6.5u1 failed as well. I had updates with passed-through controllers and without. I had updates with open-vm-tools installed and without. The outcome was always the same: a migration to Jun's Loader v1.02b - DS3615sx was necessary to get the sytem up and running again. I wonder why on my first system the static ip remained untouched, while it was set on dhcp on my other two systems. Just changing from dhcp to a static ip was not sufficient to get the Docker package running again. A restart DSM restart was.
  12. ich habe zwei ESXi hosts mit LSI9211-8i Controllern im Pass-through modus. Der erste Bootloader für DSM6 den ich verwendet hatte, war der von Oktisme. Mit Oktisme's Bootloader war es möglich die Integritätsprüfung unter DSM6 zu verwenden und die Smart-Details auch angezeigt zu bekommen. Seitdem ich Jun's Bootloader (1.02b mit DS3617sx oder DS3615sx mit und ohne extra.lzma) verwende, erscheint immer die Meldung "Nicht Verfügbar" beim Öffnen der Integritätsprüfung. In der HDD/SSD Übersicht werden Informationen wie SMART-Zustand, Temparatur, Seriennummer, Firmwareversion angezeigt. Da es mit Oktismes Bootloader damals ging, frage ich mich, ob ein findiger Bastler die von den Bootloadern durchgeführten Änderungen nicht untersuchen kann? Kann es damit zusammenhängen, dass ich eine vmdk über SCSI(0:0) eingebunden habe (es wird als /dev/sda eingbunden), während die Platten vom LSI9211-8i auch als SCSI erkannt werden (/dev/sdb - /dev/sde)?
  13. haydibe

    DSM 6.1.6-15266

    - Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 6.1.5 15254 Update 1 - Loader version and model: Jun's Loader v1.02b - DS3617xs - Using custom extra.lzma: NO - Installation type: ESXi 6.5u1 / open-vm-tools 10.1.15-4 / single SSD VMDK (no pysical disks) - Additional comments: REBOOT REQUIRED & REPERATION REQUIRED This is my second instance and it had the same problem like the first. Seems like a general problem with DS3617xs Bootloader on ESXi. On the third system I am going to uninstall open-vm-tools before the update. On this instance the Docker package fails to start. A reinstalltion didn't help so far. I am glad it didn't happend on one of my main machines. // Update: the static ip was set to dhcp. After setting a static ip, the docker package started to work again.
  14. Been there, done that and had the same result. The issue is more of a ESXi user issue, rather then an ESXi issue Make sure your vSwtich has following settings in the security policy it uses: Allow promiscuous mode -> Yes Allow forged transmits -> Yes Allow MAC changes -> Yes Though, be aware that transfer speeds will drop slightly and won't be as stable as they are without these settings. When i was tinkering around with docker and the macvlan network mode, people in the syno forums could get it up and running and i couldn't. That made me dig into the ESXi vSwtich settings. After the settings have been made, it worked flowless.
  15. haydibe

    DSM 6.1.6-15266

    - Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 6.1.5 15254 Update 1 - Loader version and model: Jun's Loader v1.02b - DS3617xs - Using custom extra.lzma: NO - Installation type: ESXi 6.5u1 / Pass-through LSI2008 + SSD VMDK / open-vm-tools - Additional comments: REBOOT REQUIRED, REPERATION REQUIRED :/ After the update, the logfile contained severall thread dumps when the ssd vmdk was loaded. After the bootloader was replaced with Jun's Loader v1.02b - DS3615xs a full migration to DSM 6.1.6-15266 could be done. Since the open-vm-tools installation was for broadwell, the package needed to be uninstalled and replaced with the bromolow package. Everything else works as it did before.