mcdull

need to change the global_config.json update last redpill_load to https://github.com/RedPill-TTG/redpill-load.git and branch = master

interesting, I managed to run fine after reinstall the docker-ce. But after I changed the json and do it again, I hit error again. Even I removed the json and run again, its still the same. oo... https://github.com/jumkey/redpill-load.git -b 7.0-41890 This is really missing from source. => ERROR [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/jumk 2.9s ------ > [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.551 Cloning into '/opt/redpill-lkm'... #6 1.755 Cloning into '/opt/redpill-load'... #6 2.594 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

@haydibe where should I put my custom user_config.json ? Thanks.

yes. in any case you can passthorugh the GPU to the vm, even signle GPU environment is fine. Although it is much easier if you have an extra display adaptor to share to the VM. Intel may also support GPU sharing under some cirumstances. But these setting may cost you weeks of time to set up the host. For simple passthrough under proxmox or ESXi with compatible hardware, it should not be much difficult than running loader in this thread.

I think barematel is not the best option for xpenology. virtualization is very mature and safe enough to be used in production environment. And it will create a lot less trouble when further development is required to support later version of DSM. Yet the perfomance loss is very little.

Sorry, I were wrong with the version. My exsiting working config was build by earlier version that still required to make build_all inside the container.

I used root and I already run it under /root ubuntu 18 LTS

the 0.51 package works for me

got some issue with this version. root@ubuntu:~# ./redpill_tool_chain.sh build apollolake-7.0-41890 [+] Building 61.2s (9/14) => [internal] load build definition from Dockerfile 0.1s => => transferring dockerfile: 32B 0.0s => [internal] load .dockerignore 0.2s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/debian:10-slim 2.1s => CACHED [extract 1/2] FROM docker.io/library/debian:10-slim@sha256:1b138699146ca36569f2f2098c8e22c56756b5776f7668a6a 0.0s => [internal] load build context 0.1s => => transferring context: 195B 0.0s => [stage-1 2/9] RUN apt-get update && apt-get install --yes --no-install-recommends ca-certificates build-essent 58.8s => [extract 2/2] ADD downloads/ds.apollolake-7.0.dev.txz / 11.0s => CACHED [stage-1 3/9] RUN git clone https://github.com/RedPill-TTG/redpill-lkm.git -b master /opt/redpill-lkm && 0.0s => ERROR [stage-1 4/9] COPY --from=extract /usr/local/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/usr/lib/modules 0.0s ------ > [stage-1 4/9] COPY --from=extract /usr/local/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/usr/lib/modules/DSM-7.0/build/ /opt/redpill-lkm/toolkit_dev-apollolake-7.0-41890: ------ failed to solve with frontend dockerfile.v0: failed to build LLB: failed to compute cache key: failed to walk /var/snap/docker/common/var-lib-docker/tmp/buildkit-mount973695330/usr/local/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/usr/lib/modules/DSM-7.0: lstat /var/snap/docker/common/var-lib-docker/tmp/buildkit-mount973695330/usr/local/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/usr/lib/modules/DSM-7.0: no such file or directory Cannot figure out where is the problem.

try not use sudo, but use root direct.

How did you overcome the issue https://github.com/RedPill-TTG/redpill-lkm/issues/10?

May I clarify under what config apollolake-7.0 will work? Only in barematel? Qemu over proxmox won't work?

why not boot a real usb stick under gen8?

Yes. Same under proxmox. Apollolake will not work. But 3615 works just fine because of the older kernel.

Oic. You used img as sata which will not work. You need to emulate it as USB device with qemu pid vid specified.

You need to check the error message under /var/log/messages Best bet is wrong vid pid?

probably network config issue. https://stackoverflow.com/questions/61567404/docker-temporary-failure-resolving-deb-debian-org

if you look into the json, he uses different debian base image. only apollolake + 7.0 uses debian 10, other uses debian 8. Let me try apollolake + 7.0. Update: I confirmed no problem under ubuntu 18 to generate apollolake + 7.0 images

i did it in ubuntu 18. debian 8 is defined inside docker. and it run just fine under ubuntu

I am a noob too, here is what I have done. install ubuntu (I uses 18lts), and choose docker runtime during install (or can install later) `sudo -i` `apt update` `apt install docker.io` `apt install jq` `apt install unzip` download the zip file (I uses v0.51) `unzip redpill*.zip` `vi user_config.json` - update vid/pid in format (0x0000) - update mac address in format 001122334455 run `chmod +x edpill_tool_chain.sh` `edpill_tool_chain.sh build bromolow-7.0-41222` or replace bromolow-7.0-41222 with otherr version you desired `edpill_tool_chain.sh run bromolow-7.0-41222` you will then be redirect into the docker `make build_all` `exit` `cd images` the img file is here

Thanks, the tools is running perfect to generate the boot image for me. Let me share the environment. Proxmox v7 running on AMD 3900X with ds3615xs, kernel 3.x, DSM7, seems running fine. I expect some feature does not work as in 6.2.3 (i.e. virtual machine manager, and Photo AI tag on subject) with ds918+, kernel 4.x, DSM fails to initialise the usb boot drive during boot, which the /dev/synoboot /dev/synoboot2 /dev/synoboot3 are missing. This is one of the many know issues of the new 4.x kernel.

did you see /dev/synoboot /dev/synoboot1 /dev/synoboot2 ??

seems esxi requires dom support which is not yet implemented.

which profile you use?

I run it under Proxmox. Its rock solid, except Virtual machine does not work. There is no need to use VMM if I have proxmox anyway