haydibe

Sure, after work. I just need to change two digits of the value of the DOCKER_BASE_IMAGE variable in the outer Makefile for that. Technicaly it's possible to create an image that sets up the toolchain for Bromolow DSM7.0, but indeed so far there is no loader profile for it.

The redpill tool chain docker image builder is updated to v0.4: - proper DSM7 support for apollolake (thnx @jumkey) - switched from kernel sources based build to toolkit dev based builds for DSM6.2.4 and DSM7.0 (thnx @jumkey) - make targets for bromolow and apollolake merged: platform and version must be configure in the Makefile now - image is ~720-780MB instead of ~1.200-1.500MB now Note: since toolkit dev lacks the required sources for fs/proc, they are taken from the extracted DSM6.2.4 kernel sources. The build requires the sources for this single folder, but does not use the kernel source to build the redpill.ko module. If you see something is wrong in how the toolchain is build or have ideas how to make it better: please let me know. For every other problem: please address it to the community - I don't know more than others do. Note#2: before someone asks: I haven't managed a successfull installation/migration with the created bootloader so far. I am testing exclusivly on ESXi 6.7. The migration always stops at 56% and bails out with error 13. Usage: - (on host) configure the Makefile and configure TARGET_PLATFORM (default: bromolow) and TARGET_VERSION (default: 6.2 - will build 6.2.4) - (on host) create your own user_config.json or edit the USERCONFIG_* variables in the Makefile - (on host) build image: make build_image - (on host) run container: make run_container - (in container) build redpill.ko module and redpill bootloader image: make build_all After running `make build_all` the created redpill bootloader image will be present in the ./image folder on the host. Tested with hosts: Ubuntu 18.04 VM, Ubuntu 20.04 WSL2 and XPE (the make binary to build on Synology/XPE can be found here) Dependencies: make and docker redpill-tool-chain_x86_64_v0.4.zip

Feel free to point out if something in the process of setting up the toolchain is incorrect or can be done better. Appart from that: I have no idea if something in redpill-lkm, redpill-load or the generated bootloader image does not work - haven't managed a successful migration so far myself .. it always bails out at 56% with error 13 - I use ESXi 6.7 Please be sure to use the v0.3 version of the zip, as it moved from a ubuntu:18.04 base image to a debian:8 base image.

That was the missing piece, thank you!

Can you share what modifications you did to the Makefile? Did you just replace the value for LINUX_SRC? Actualy based on the tgz files downloaded by pkgscripts-ng for a specific platform and version, I was able to create a Dockerfile that bases on Scratch and just uses ADD to extract the tgz files into the images / folder. The image will have roughly 6.5GB size. Even though git is present in that image, the ca-certificates embedded in the tgz files are too old to allow a checkout from github - this can be fixed with trickery though.

So the approach the current redpill-lkm/Makefile uses can be replaced by a better approach that makes the kernel files irrelevant?

The mac needs to be without ":" char. And of course the general file must look like this (see: https://github.com/RedPill-TTG/redpill-load#how-to-use-it) Whatever you enter into the extra_cmdline block, will be used as boot param in grub. Please let us know if you identified usefull additional parameters. Thanks!

Never though about that its actualy possible to bind the serial port to a telnet port. Thanks! I ended up adding three serial ports, exposing them from 10021 to 10023 and then settings custom firewall rules for them: On the ESXi Host shell: $ esxcli network firewall set --enabled false $ esxcli network firewall unload $ chmod 644 /etc/vmware/firewall/service.xml $ vi /etc/vmware/firewall/service.xml $ chmod 444 /etc/vmware/firewall/service.xml $ esxcli network firewall load $ esxcli network firewall set --enabled true Thanks again for the info!

Yep, haswell is the earliest supported pc @Orphée Do you mind sharing how you enabled telnet access?

@cwiggs The variable CROSS_COMPILE is responsible that the Synology tool chain is used. Can you try if the result changes if you execute `unset CROSS_COMPILE` before `make build_all` What if using the official Synology tool chain wasn't such a good idea at all. At least for the Apollolake build, these tree warning are there regardless wether gcc from the Synology Toolchain, or gcc4.9.2 from the debian package is used for the build: ... CC [M] /opt/redpill-lkm/config/runtime_config.o /opt/redpill-lkm/config/runtime_config.c: In function 'validate_runtime_config': /opt/redpill-lkm/config/runtime_config.c:137:47: warning: passing argument 2 of 'validate_nets' discards 'const' qualifier from pointer target type valid &= validate_nets(config->netif_num, config->macs); ^ /opt/redpill-lkm/config/runtime_config.c:49:20: note: expected 'char (**)[13]' but argument is of type 'char (* const*)[13]' static inline bool validate_nets(const unsigned short if_num, mac_address *macs[MAX_NET_IFACES]) ^ ... CC [M] /opt/redpill-lkm/shim/bios/bios_shims_collection.o /opt/redpill-lkm/shim/bios/bios_shims_collection.c:11:13: warning: 'shim_null_void' defined but not used [-Wunused-function] static void shim_null_void(void) { } ^ ... CC [M] /opt/redpill-lkm/shim/uart_fixer.o /opt/redpill-lkm/shim/uart_fixer.c: In function 'swap_uarts': /opt/redpill-lkm/shim/uart_fixer.c:89:9: warning: unused variable 'out' [-Wunused-variable] int out = 0; ^ ... I am not sure if the ubuntu:18.04 based image had the same warning.. it does, just with some colored parts in the warning (same as with gcc 5.4) Update: I just tried ubuntu:14.04 as base image -> The lkm build shows the same warnings as obove, just the packaging of the laoder fails, because losetup in ubuntu 14.04 doesn't know the `--partscan` option. Update2: tried ubuntu:16.04 as base image -> same warnings as above, compiles with Synology tool chain or without (gcc 5.4, colored output) Update3: tried ubuntu:18.04 as base image -> same warnings as above, compiles with Synology tool chain (colored output, for the kernel module build, non colored for the lkm module build) or without (gcc 7.5.0, colored output everywhere and many warnings) additional warning: HOSTCC arch/x86/tools/relocs_64.o In file included from arch/x86/tools/relocs_64.c:17:0: arch/x86/tools/relocs.c: In function 'process_64': arch/x86/tools/relocs.c:949:2: warning: argument 1 null where non-null expected [-Wnonnull] qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from arch/x86/tools/relocs.h:6:0, from arch/x86/tools/relocs_64.c:1: /usr/include/stdlib.h:827:13: note: in a call to function 'qsort' declared here extern void qsort (void *__base, size_t __nmemb, size_t __size, ^~~~~

FYI: I have the same results with and without those lines with the apollake builds -> error 13 at 56%

I get the same console output. Though, Syno assistent finds the box and opens the browser page to migrate to the new OS version. I assume due to missing parameters in the user_config.json the installer tries to write on the boot device and fails. I took these parameters from the old grub.cfg and added them to the user_config.json. "bootdev": "sata", "sata_args": "sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C SataPortMap=1 SasIdxMap=0" "bootdev": "sata", "sata_args": "sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C SataPortMap=1 SasIdxMap=0" Still no luck.

The redpill tool chain docker image builder is updated to v0.3: - added support to use DSM7 fork of redpill-load for DSM918+ as done by @rlatn0123 (just comment/uncomment the required lines in the "outer" Makefile) - base image can now be configured, defaults to debian:8 now (as seen in a recommendation from ThorGroup) - uses generic jq 1.6 regardless of the base image Please bare in mind, that this image builder creates an environment based on the official Synology tool chain and kernel sources, and the sources of redpill-lkm and ledpill-load. The Makefile to create the image is just for your convience. The Makefile to build the bootloader follows the instructiosn of redpill-load. @ThorGroupcan you take a look at the image builder and "aprove" that it actualy meets the expectation? Usage bromolow: - (on host) build image: make build_image_bromolow - (on host) create your own user_config.json or edit the USERCONFIG_* variables in the Makefile - (on host) run container: make run_container_bromolow - (in container) build kernel and loader image: make build_all Usage apollolake: - (on host) build image: make build_image_apollolake - (on host) create your own user_config.json or edit the USERCONFIG_* variables in the Makefile - (on host) run container: make run_container_apollolake - (in container) build kernel and loader image: make build_all After running `make build_all` the created redpill bootloader image will be present in the ./image folder on the host. Tested with hosts: Ubuntu 18.04 VM, Ubuntu 20.04 WSL2 and XPE (the make binary to build on Synology/XPE can be found a couple of posts earlier) Dependencies: make and docker redpill-tool-chain_x86_64_v0.3.zip

I took a look at the DSM918+ build chain for 41890. The filename apollolake-gcc750_glibc226_x86_64-GPL.txz indicates that the tool chain is based on gcc7.50 now. I would expect the kernel sources to be gcc7.5 complient as well. Sadly I have no copy of the kernel sources.

I see, you used the old script package. The new does the modification in Dockerfile.apollolake obselete. The second that changes the build parameter for build-loader.sh. This works, if the kernel for DS918 is identical for 7.0-41890 and 6.2.4-25556.

There is a fork of redpill-load, that hopefilly will be merge back into the official redpill-load. This is the reason why I made the checkout URLs for redpill-load and redpill-lkm configurable in the new version of the tool chain image builder. Though, without the 7.0 kernel sources for the redpill-lkm build, I highly doubt that redpill-load will be able to create a bootable image...

Did you set the vNIC interface to E1000E before booting? Haven't succeeded in the migration on ESXi 6.7 myself: the box can be found with Syno Assistent, though the migration aboards with error 13.

The redpill tool chain docker image builder is updated: - bind-mounts an existing user_config.json file into the redpill-load folder (and then skips autogeneration of the file inside the container) - added variables in the Makefile to specify the redpill-lkm and redpill-load repository urls and branches - added variables in the Makefile to specify the urls for the bromolow and apollolake toolchain/kernel - refactored repated code blocks into Make functions - refactored to single Dockerfile using ARGs to build the target bromolow or apolloake image Usage bromolow: - (on host) build image: make build_image_bromolow - (on host) create your own user_config.json or edit the USERCONFIG_* variables in the Makefile - (on host) run container: make run_container_bromolow - (in container) build kernel and loader image: make build_all Usage apollolake: - (on host) build image: make build_image_apollolake - (on host) create your own user_config.json or edit the USERCONFIG_* variables in the Makefile - (on host) run container: make run_container_apollolake - (in container) build kernel and loader image: make build_all After running `make build_all` the created redpill bootloader image will be present in the ./image folder on the host. Tested with hosts: Ubuntu 18.04 VM, Ubuntu 20.04 WSL2 and XPE (the make binary to build on Synology/XPE can be found a couple of posts earlier) Dependencies: make and docker redpill-tool-chain_x86_64_v0.2.zip

That's for someone else to answer. The only thing I can say is that the first partition can be mounted with OSFMount and has the grub.cfg, like we are with jun's loader image. Though, OSFMount can mount the other two partitions, but windows won't show anything. Couldn't get it to work with `losetup` either. A closer look into the redpill-load sources would actualy show its used there. It works with kpartx ootb: # kpartx -v -a redpill-DS918+_6.2.4-25556_b1628193299.img add map loop2p1 (252:0): 0 98304 linear 7:2 2048 add map loop2p2 (252:1): 0 153600 linear 7:2 100352 add map loop2p3 (252:2): 0 8192 linear 7:2 253952 # mkdir /tmp/mount # mount /dev/mapper/loop2p1 /tmp/mount # ls -l /tmp/mount total 26979 drwxr-xr-x 3 root root 512 Jan 1 1970 ./ drwxrwxrwt 13 root root 4096 Aug 6 00:14 ../ drwxr-xr-x 3 root root 512 Jul 27 21:15 boot/ -rwxr-xr-x 1 root root 24150016 Aug 5 21:55 rd.gz* -rwxr-xr-x 1 root root 3470496 Aug 5 21:55 zImage* # umount /tmp/mount # mount /dev/mapper/loop2p2 /tmp/mount # ls -l /tmp/mount total 12 drwx------ 2 root root 12288 Jul 25 07:27 lost+found # umount /tmp/mount # mount /dev/mapper/loop2p3 /tmp/mount mount: /tmp/mount: wrong fs type, bad option, bad superblock on /dev/mapper/loop2p3, missing codepage or helper program, or other error. # kpartx -v -d redpill-DS918+_6.2.4-25556_b1628193299.img del devmap : loop2p3 del devmap : loop2p2 del devmap : loop2p1 loop deleted : /dev/loop2 Partition 1 is the one with the grub.cfg. Partition 2 is empty. I couldn't get Partition 3 to mount. Update: got it to work with losetup, the outcome is of course the same: # losetup -P /dev/loop2 redpill-DS918+_6.2.4-25556_b1628193299.img # mount /dev/loop2p1 /tmp/mount # ls /tmp/mount boot rd.gz zImage # umount /tmp/mount # mount /dev/loop2p2 /tmp/mount # ls /tmp/mount lost+found # umount /tmp/mount # mount /dev/loop2p3 /tmp/mount mount: /tmp/mount: wrong fs type, bad option, bad superblock on /dev/loop2p3, missing codepage or helper program, or other error. # losetup -d /dev/loop2 The -P parameter was missing in my previous attempt.

This should be sufficient to compile an image: on the host `make run_container_apollolake` inside the container `make build_all` The user_config.json is auto generated and populated with the variables configured in the Makefile of the host. The image creation should work regardless wether you set the user_config variables or not. But in order to create an image that boots, you will have to set the variables. You don't need to build the docker image again, the variables will be passed into the container when running run_container_apollolake. I haven't tested the created image yet, as I first wanted to share the outcome of the tool chain creation first.

Did you use the make target run_container_apollolake to actualy run the container, or did you start it with `docker run`? The container needs a shitload of permissions and trickery to actualy lift the image repackaging part. The docker run statement ecapsulated in the run_container_apollolake takes care of setting the required parameters.

For all of you that want a "redpill tool chain". Well, I created a make based project that creates a docker image with the toolchain for brolow or apollolake make targets `build_image_bromolow` and `build_image_apollolake`: - download matching toolchain and kernel version on the host before building the image - base image ubuntu:18.04 - sources of redpill-lkm fetched while building the image - sources of redpill-load fetched while building the image - A Makefile is added inside the image, that allows to generate the user_data.json based on container environment variables and cover build of redpill.ko and the image make targets 'run_container_bromolow` and `run_container_apollolake` - mount a volume for the redpill-load/cache folder - mount a folder to the redpill-load/image folder - set parameters for user_data.json (requires editing of the Makefile) - take care of parameters that allow to mount the loop device while creating the image Though, there is one caveat: the project requires make, which is not available on Synology Note1: once you compile make for Synology (out of scope for this tool chain), you can actualy create and use the image on a Synology or XPE box Note2: even works on wsl2 with enabled systemd, installed docker.io and make package Usage: change into the folder you extracted the zip into and run `make` to see the list of available targets. Update: re-uploaded, because I accidently broke the apollolake part in the Makefile . Update2: for those who feel brave, I added my build of make for Synology as attachement. I placed mine in /usr/local/bin/make. Don't forget to chmod +x the file after copying to your Syno/XPE box. redpill-tool-chain.zip syno-make-x86_64.zip

It is not enough to just create the folder. You need to have the kernel sources to be extracted into that folder! Download from here.

I would consider the level of details as headline level - enough to get a rough idea about the topic, though not enough to see how things are configured and where things might need to be configured differently. I am just saying that I (me personaly) am not able to help you like this. I hope someone else will be able to pitch in. Good luck!

Nope. no idea. The reason why I shared the blog post was that no relevant details have been shared that allowed to understand where things go wrong. Its still not any different I can tell from experience: it does work, I used it in the past - but I did use docker-compose to bootstrap my containers. Though, I deleted it again because the Android Client app was crap back in those days (~2years ago) - it drained the battery too much.