Balrog

I have some news about the failing services and how to disable them (mostly):

After upgrading from DSM 6.2 Update 3 to DSM 7.1.0-42661 Update 2 I see that there are some failing systemd services: root@test4:~# systemctl list-units --state failed UNIT LOAD ACTIVE SUB DESCRIPTION ● syno-oob-check-status.service loaded failed failed Out of Band Management Status Check ● synoindex-checkpackage.service loaded failed failed synoindex check if there are any synoindex-related packages ● SynoInitEth.service loaded failed failed Adjust NIC sequence LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 3 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. I got some news about the failed services! It seems that DSM 7.x phone home information at every boot and, if e.g. "Photos" is installed, even every 30 seconds(!): journalctl -u pkg-SynologyPhotos-js-server.service -b Jun 11 09:58:31 test4 systemd[1]: Starting SynologyPhotos JS Server... Jun 11 09:58:31 test4 synocloudserviceauth[15672]: cloudservice_get_api_key.cpp:21 Cannot get key Jun 11 09:58:31 test4 synocloudserviceauth[15672]: cloudservice_register_api_key.cpp:293 Register api key failed: Auth Fail Jun 11 09:58:31 test4 synofoto-bin-push-service[15669]: pushservice_update_ds_token.c:52 fgets failed Jun 11 09:58:31 test4 synofoto-bin-push-service[15669]: pushservice_update_ds_token.c:147 Can't set api key Jun 11 09:58:31 test4 systemd[1]: pkg-SynologyPhotos-js-server.service: control process exited, code=exited status=1 I think I got a solution. Just disable these services: systemctl disable pkg-SynologyPhotos-js-server.service systemctl stop pkg-SynologyPhotos-js-server.service There are 2 other systemd-services which runs at every boot and as they are depended by other services they can not be easily deactivated but we can "mask" them which means that the symlink from systemd will be made to `/dev/null`. So this service can't start anymore also. systemctl mask syno-oob-check-status.service systemctl mask SynoInitEth.service After a reboot there are no more failed systemd services: root@test4:~# systemctl list-units --state failed 0 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. WIN! As I don't know if the disabled services are important for a DSM update one can enable/activate them before updating in future: systemctl enable pkg-SynologyPhotos-js-server.service systemctl unmask syno-oob-check-status.service systemctl unmask SynoInitEth.service reboot I think the disabled services can't do any harm as they are failing anyway. But beware: I dont know any sideeffects till now! I will have an eye on the services anyway the next days. I got another test-installation where I got 2 additional failing services (but again: I do not see anything not working or missing): root@test2:~# systemctl list-units --state failed UNIT LOAD ACTIVE SUB DESCRIPTION ● syno-mount-usbfs.service loaded failed failed Mount usb fs ● syno-oob-check-status.service loaded failed failed Out of Band Management Status Check ● synoindex-checkpackage.service loaded failed failed synoindex check if there are any synoindex-related packages ● SynoInitEth.service loaded failed failed Adjust NIC sequence `synoindex-checkpackage.service` may be related to `Universal Search` but I am not 100% sure. I appreciate any additional thoughts and information about these failing services.

I am back in business!! In the end the solution was easy! With the typo in the script rploader.sh the DiskIdxMap is not correct. So the first time (with the typo) i got: Computed settings: SataPortMap=126 DiskIdxMap=000103 As I only have 1 VMDK (as a single virtual SSD) as data disk and 4 HDDs on the physical internal SATA-Controller of the Microserver Gen8 this even works and I was able to do the upgrade from DSM 6.2U3 to DSM 7.1. The step where things went a little bit wrong were as I updated to DSM 7.1U2. I have to boot after the update into TCRP again and fire up: sudo ./rploader.sh update sudo ./rploader.sh postupdate broadwellnk-7.1.0-42661 exitcheck.sh reboot Then I read about the type in rploader.sh and recognize my fault about the missing second NIC in the user_config.json. I added the second NIC, repaired the rploader.sh and got this (new & correct) satamap in the end: Computed settings: SataPortMap=126 DiskIdxMap=100002 Then I compiled the loader again: sudo ./rploader.sh clean sudo ./rploader.sh fullupgrade sudo ./rploader.sh listmods broadwellnk-7.1.0-42661 sudo ./rploader.sh build broadwellnk-7.1.0-42661 sudo ./rploader.sh backup exitcheck.sh reboot After the next reboot I got the page "Welcome back: Click here to migrate your diskstation". And here is the trick: - DO NOT JUST REBOOT into DSM after click on "Migrate"! - Reboot again in TCRP and run (once again): sudo ./rploader.sh postupdate broadwellnk-7.1.0-42661 exitcheck.sh reboot The "postupdate"-command will throw a lot of messages about a lot of existing files and folders. But in the end there will be the message: ... The new smallupdate version will be : 7.1-42661-2 Do you want to use this for the loader ? [yY/nN] : y Recreating ramdisk 52185 blocks Adding fake sign ... The next boot will be successfully and the NAS will be normal, stable and functional. So i learned: If a minor patch is installed on top of a major DSM-Release, one have to boot into TCRP again and run the "postupdate"-function again even after a "Migration" when changing e.g. the NIC-Settings and recreating the whole boot-loader. I still have some error messages but I got these also on my other installations: root@diskstation:~# systemctl list-units --state failed UNIT LOAD ACTIVE SUB DESCRIPTION ● syno-oob-check-status.service loaded failed failed Out of Band Management Status Check ● synoindex-checkpackage.service loaded failed failed synoindex check if there are any synoindex-related packages ● SynoInitEth.service loaded failed failed Adjust NIC sequence LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 3 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. Do someone knows if these failing services are important or irrelevant? The NICs are running fine and I miss nothing and can't see anything which is not running correctly.

So for today I went the "easy route": - I made a backup from the TCRP before testing to build a new loader without the typo in the loader-script. - I attached the backup as SATA0:0 on my VM. - DSM boots fine for now into 7.1 U2 (of course with the error on the 2.nd NIC and some error messages at boot, but this wont hurt for now). - So I am able to make a full backup now. I will work on this issue again at the weekend if I got more time for this issue. I remember some old information about boot and mounting e.g. an Linux Live ISO, mounting the 2.4 GByte-RAID1 where DSM is installed and change some files to be able to "simulate" an upgrade situation again. But I do not know what files to change exactly anymore... In the worst case I can wipe the 2.4 Gbyte-RAID1 and make a full "new installation". But I will test this scenario first on another test-installation.

Thank you very much! I will try it later without hurry and give feedback afterwards.

I have a little bit trouble with another installation (also a VMware based installation as DS3622xs+) : - Yesterday I went straight into the little type bug where awk-F"/" should be awk -F"/" but I build the loader with these settings (my fault...) - The loader starts well in the end besides some error messages at booting and I was able to install DSM 7.1.0-42661 - I upgraded successfully to DSM 7.1.0-42661u2 with sudo ./rploader.sh update sudo ./rploader.sh postupdate broadwellnk-7.1.0-42661 exitcheck.sh reboot - Today I want to re-create the boot loader and booted into TCRP, adjusted the typo ( awk -F"/" ) and re-run the whole process. - "satamap" found indeed different Mappings as the first time with the typo. - I added also a missing second NIC manually into the user_config.json which forgot yesterday: cat user_config.json { "extra_cmdline": { "pid": "0xa4a5", "vid": "0x0525", "sn": "<SN>", "mac1": "<MAC1>", "mac2": "<MAC2>", "netif_num": "2", "SataPortMap": "126", "DiskIdxMap": "100002" }, "synoinfo": { "internalportcfg": "0xffff", "maxdisks": "16", "support_bde_internal_10g": "no", "support_disk_compatibility": "no", "support_memory_compatibility": "no" }, "ramdisk_copy": {} } - the process of autoloading the addons and building the loader went well: sudo ./rploader.sh listmods broadwellnk-7.1.0-42661 sudo ./rploader.sh build broadwellnk-7.1.0-42661 sudo ./rploader.sh backup exitcheck.sh shutdown - I adjusted the MAC-Adresses of the vNICs with the calculated settings from TCRP and started the VM. - The boot messages looks very good without the error messages from the first time and both NICs were adressed well and the vNIC which is connected gets an DHCP-Address assigned. Now the NAS will be found every time as "Recoverable" and not "Migratable". I can reboot multiple times but the system wont "repair" itself. How I am able to force DSM to let me install the pat-file again? Should I rebuild the loader with a different type (e.g. DS-918) and do a "Migration"and the back to DS3622xs+ with another new builded loader? I do not want to corrupt anything as I am sure that the installation itself is in good shape.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.3-25426 Update 3 - Loader version and model: Tinycore-Redpill v0.8 - DS3622xs+ - Using custom extra.lzma: NO - Installation type: VMware ESXi 7.0 update 3 - Additional comments: I upgraded one of my backup NAS with a flashed Dell H200 HBA succesfully in 2 steps - step 1: from DSM 6.2.3-25426 Update 3 to DSM 7.1.0-42661 (like described in the tutorial "Tutorial: Install/Migrate to DSM 7.x with TinyCore RedPill (TCRP) Loader") - step 2: Upgraded to DSM 7.1.0-42661u2 via GUI - After Step 2 update, booted into TCRP and run: ./rploader.sh update sudo ./rploader.sh postupdate broadwellnk-7.1.0-42661 exitcheck.sh reboot

Please try: sudo ./rploader postupdate 918+ After I used the "sudo" with the "postupdate"-command my test installation with DS3622xs+ boots correctly.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 7.1-42661 - Loader version and model: Tinycore-Redpill v0.8 - DS3622xs+ - Using custom extra.lzma: NO - Installation type: VMware ESXi 7.0 update 3 - Additional comments: After update, booted into TCRP and: ./rploader.sh update sudo ./rploader.sh postupdate broadwellnk-7.1.0-42661 The sudo was important as without I got an error: ... Creating temp ramdisk space Mounting partition sdb1} Mounting partition sdb2} Extracting update ramdisk unlzma: /mnt/sdb2/rd.gz: Compressed data is corrupt cpio: dev/net/tun: Cannot mknod: Operation not permitted cpio: dev/console: Cannot mknod: Operation not permitted 52176 blocks Found Version : 7.1-42661-2 Do you want to use this for the loader ? [yY/nN] : y Extracting redpill ramdisk cpio: dev/console: Cannot mknod: Operation not permitted cpio: dev/net/tun: Cannot mknod: Operation not permitted cpio: lib not created: newer or same age version exists ... cpio: ./etc/shadow: Cannot open: Permission denied ... Just run the command again with sudo and DSM boots correctly after Update 2.

Thank you very much for the new repositories! After looking around it seems that all of them are the "good solution" with a SPK at the end so it will be installable natively in DSM without docker. I think the SPK solution will be have a hard time running on DSM 7.x as there is no root-access for a SPK anymore, if I am not completly wrong. I see today that I was not the first one with the idea to update the dockerfile from "yale-wp" and have found this (much better written) update to it: https://github.com/delta-whiplash/docker-xpenology-open-vm-tools This docker image runs under an actual Ubuntu and is even downloadable from the docker registry with one command: docker run -d --restart=always --net=host -v /root/.ssh/:/root/.ssh/ --name open-vm-tools whiplashorus/docker-xpenology-open-vm-tools I deleted my github repository as the one from "delta-whiplash" is much better. But it is all about to learn and become better. Sadly I am not able to modify the first post, so I would appreciate if a mod can exchange the wget link at "# 2." with wget https://github.com/delta-whiplash/docker-xpenology-open-vm-tools/archive/refs/heads/master.zip or even delete the whole Thread as it is not needed to build the image personally if it can be downloaded and started with a single line. I will tag some members I think they may be interested in a working VMware Tools solution too: @pocopico , @haydibe , @WiteWulf

This howto shows how to compile and run the current VMware Tools in a docker container. After a long time of not having enough free time to look at Xpenology I finally got the opportunity to study at which point the project is. (I read a looot of threads ). I tested today if I am able to migrate a test installation from a DSM 6.2.3 (DS 3615) to DSM 7.1.0-42661 (DS3622xs) under VMware ESXi. Thanks to the very good Tutorials from @flyride (THANK YOU VERY MUCH!) from here: and here I was able to do the migration. Also a big THANK YOU to all other contributors to this project too! Awesome solutions were build the last months! Afterwards I was looking around what is running and what is missing in my new DSM 7.1.0. The most visible missing part were the VMware Tools. Even Docker runs (till now) stable and without problems. After looking around the topic "VMware Tools under DSM 7" I found an 5 year old repository which contains the information about a Docker container for the VMware Tools. I am aware that a 5 year old container is not safe to run today but the author added the source Dockerfile also in the repository, so I am able to have a look HOW the docker image was build. I am no real Developer so my knowledge about docker is a little bit limited but I managed with a few changes to build the container with an actual Debian Image as a base containing the current VMware-Tools. So these steps worked perfectly for me: ## 1. Prerequisites - Install Docker in DSM - Enable SSH access in DSM - Login via ssh as admin: ssh admin@ds - become root: sudo -i - cd into docker-dir: cd /volume1/docker __________________________________________ ## 2. Download Source Repo The original Repository is here: https://github.com/yale-wp/docker-xpenology-open-vm-tools - I forked it and adjusted it a little bit: https://github.com/MrE101/docker-xpenology-open-vm-tools - Download the current repo as a zip-file to the current directory (/volume1/docker): wget https://github.com/MrE101/docker-xpenology-open-vm-tools/archive/refs/heads/master.zip __________________________________________ ## 3. Extract Source Repo root@ds4:/volume1/docker# 7z x master.zip __________________________________________ ## 4. Adjust Dockerfile - cd into extraction-directory: root@ds4:/volume1/docker# cd docker-xpenology-open-vm-tools-master/ __________________________________________ ## 5. Compile the Image and run the Docker-Container afterwards - compile the docker image and name the image "open-vm-tools": docker build -t open-vm-tools -f Dockerfile . - Start the container from the new image: docker run -d --restart=always --net=host -v /root/.ssh/:/root/.ssh/ --name open-vm-tools open-vm-tools With this command the container will run at every boot. __________________________________________ The ESXi is happy and I am happy too. Even the IP addresses (IPv4 & IPv6 including the docker addresses) are shown! I have tested successfully a "shutdown guest" and "reboot guest". So for me everything works as expected. Feel free to use or correct my findings as needed. I am sure that my solution is not the best but it works for me.

Ahhh, v0.5.4 did the trick! Thank you very much for the hint! Now the loader will compile. I only get some warnings: ... include/linux/kfifo.h:390:37: warning: initialization of 'unsigned char' from 'int *' makes integer from pointer without a cast [-Wint-conversion] ... /opt/redpill-lkm/config/cmdline_delegate.c:405:74: warning: value computed is not used [-Wunused-value] ... /opt/redpill-lkm/config/runtime_config.c:168:53: warning: passing argument 2 of 'validate_nets' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] I will be able to test the image hopefully tomorrow.

I am currently not able to build the Apollolake 7.0 image for #41890: ... > [stage-1 3/9] RUN git clone https://github.com/RedPill-TTG/redpill-lkm.git -b master /opt/redpill-lkm && git clone https://github.com/jumkey/redpill-load.git -b 7.0-41890 /opt/redpill-load: #6 0.438 Cloning into '/opt/redpill-lkm'... #6 1.081 Cloning into '/opt/redpill-load'... #6 1.426 fatal: Remote branch 7.0-41890 not found in upstream origin ------ executor failed running [/bin/sh -c git clone ${REDPILL_LKM_REPO} -b ${REDPILL_LKM_BRANCH} ${REDPILL_LKM_SRC} && git clone ${REDPILL_LOAD_REPO} -b ${REDPILL_LOAD_BRANCH} ${REDPILL_LOAD_SRC}]: exit code: 128 Is the remote branch for 7.0-41890 deactivated and I have missed this?

Hello together! I have never read such a good thread ever before!! Absolutely awesome! Thanks to @ThorGroup, @haydibe, @flyride, @mcdull and all other I forgot for the very good information! I am very busy at work so I can't work much in here but I read a lot. I have spin up an Ubuntu 20.04 VM via Vagrant under VMware Workstation (under Windows) and was able to build with the help of the docker from @haydibe in a few minutes the loader (Apollolake, 6.2.4 and 7.0). (Testing of the loaders are note done yet due to lack of time). If anyone is interested in a "Vagrant how to", leave a short note: I have documented everything and can post it here.

So, I just go the lazy route: - Deinstall Docker 20.10.3-0552 without wiping the config and images - manual download the old docker: https://global.download.synology.com/download/Package/spk/Docker/18.09.0-0519/Docker-x64-18.09.0-0519.spk - install Docker 18.09.0-0519 - all Containers including Wireguard are up and running For the long term I have to move Wireguard to another machine but for now everything is running fine.