haydibe

I am not sure what is wrong with trying to download the rpext-index.json from tossp's repository. Please always try first if the offical TTG build configs work, in order to isolate if there is a generall problem, or the problem is introduced due to using 3rd part repo. Also, It is kind of confusing that the error message of your last post is not present in this error message.

A VPN is not required. With the level of provided details: I have no idea. I can say that "auto" will not work if you require a http_proxy or https_proxy to access the internet (which almost no one uses in their home environment). You can also try to check if things remedy after restarting the docker service (it was the solution to a couple of docker related problems in this thread).

Please do NOT update to 6.2.4 or greater with any of Jun's bootloader -> it is not going to work. You either have to use redpill in it's current state, which is kind of beta-ish and is aimed toward advanced users and developers skilled in linux. I would advice non advanced users to wait until the beta is official and the approach to build a bootloader image is beginner friendly.

It does not. Docker just uses CGROUPS (=what ressources it is allowed to use), Kernel Namespaces (=comparable to fenced partition of kernel components) and capabilities (=what low level features is the processes allowed to use). From the host perspective, container are merly fenced processes that are restricted to see whatever part of the host it is allowed for them to see. The container itself has no idea that it is restricted from the outside (this is not 100% true because a container can access some stats from the outside like the host cpu count and the installed total memory... containerized java proccesses suffer from this if done wrong).

Oh, I realize this statement is not true ☺️ ...My toolchain builder requires docker. Of course a bootloader image can be build without Docker on Linux, as long as the required gcc version for the platform and version is present. It requires gcc < 5, e.g. 4.8.x or 4.9.x to build Bromolow boot image. Apollolake requires the same for a DSM6.2.4 bootloader or gcc 7.5.x for a DSM7.0 bootloader.

Good catch, both scripts assume that you run them s root. Copy/paste should work. The problem consists of two factors 1) the certicates themself (fixed by the script in the first link if run as root), 2) an openssl library that is able to handle the used algorithms of the new issued Letsencrypt certificates, which at least requires openssl libraries v1.1.0 - DSM6.2.3u3 has 1.0.2-k. Sorry to disapoint -> there is no way to fix this, except Synology fixes it.

Creation of the bootloader image requires docker, regardless of the OS. I use docker-ce on wsl2 (!=Docker for Desktop) with a modified Ubuntu 20.04 distro with enabled systemd (which is also the environment I created the toolchain builder in). Once you have the image, you can use any tool that allows to "burn" the image on a usb stick.

Can be scripted, see: note: the "add certificates to ca-certifactes" part is relevant. @Dingo Generate the new certificates using the UI. Then execut this script to detect which folder holds the files for that particular certificate: domain=the-domain-the-certificate-is-issued-for.com for current_domain_cert in /usr/syno/etc/certificate/_archive/*; do if [ -d ${current_domain_cert} ] && [ -f ${current_domain_cert}/cert.pem ];then openssl x509 -in ${current_domain_cert}/cert.pem -text | grep DNS:${domain} > /dev/null 2>&1 domain_found=$? if [ "${domain_found}" = "0" ]; then echo "certificate for ${domain} found in ${current_domain_cert}" fi fi done

@WiteWulf: If this can be done like this -> charming idea 😀

I am not going to implement functionality to the docker toochain that modifies the behavior of rp-lkm and rp-load. It is already hard enough for people to distinguished if problems are located in the docker toochain or rp-load. The only thing that might sense from my perspective is to support hooks for custom before/after scripts. Though, even that will introduce a new vector for problems nobody wants to deal with. On the other side, the toolchain builder script/files are all in "clear text" and not realy hard to understand.. Everyone is free to taylor them to their needs

The script just adds missing certifactes to the ca certifcates list and to the ca-certificates.crt file (which btw. IS important, as most tools use it instead of the loose single .pem and .cert files in the folder). Glad that it helped at least a single person Packages usualy provider their own libraries - updated versions of packages shouldn't be affected. curl for instance, will be affected until the openssl libraries are updated.

No need to touch those. The values are just "fallback values" if they are not provided by build-args, which they always are by the values from global_config.json.

The first red line of the error message indicates that the "no space left on device" error is raised by the target, which is the first patition of the bootloader image.

@jsjson You can apply a workaround to line 49 and 116 (which become 117 after inserting the line in 49) of the .sh file. Line 49 forces the image build to use the host network, line 116 forces the toolchain container to use the host network. You will want to add it to both possitions. --network host \ This shouldn't be necessary at all, and indicates that there indeed is a firewall problem.

Assumption: WSl2 on Win11?

das "nicht" gehört da nicht hin ^^

The problem you seen can only happen with versions below 0.10 or if you use a global_config.json copied from an older version. In case of problems always extract it fresh from the zip and execute the build action, then the auto action without any modifications.

v0.11 was extended and published by Orphée 😃

Ergibt Sinn - nachdem oben eine "nicht Dokumentierte" Variable stand, hatte ich die Hoffnung das die anderen evtl. auch einfach nicht Dokumentiert sind.. Aber es ergibts schon Sinn das etwas das nicht dokumentiert ist auch nicht vorhanden ist ^^ Wobei es mich schon etwas wundert, dass das linux.io image weniger komfortabel als das offizielle ist. Ist in diesem Fall wohl nicht so. Schade.

Das compose file sieht soweit gut aus. Bis auf die abweichende Einrückung von "environment" beim "nextcloud" Service und der "REDIS_HOST" environment Variable - die ich in der Doku nicht finden kann - sieht alles gut aus. Beim offiziellen NC Image kann man die Erstinstallation vollständig durch setzen von Variablen erreichen - man landet dann direkt im Login-Bildschirm, statt im Setup-Dialog. In der Beschreibung von linuxserver/nextcloud ist das scheinbar nicht vorgesehen. Wenn es mit der nicht dokumentierten REDIS_HOST Variable klappt, vielleicht gehen diese von offiziellen NC Image dann auch? environment: NEXTCLOUD_ADMIN_USER: {NEXTCLOUD_ADMIN_USER} NEXTCLOUD_ADMIN_PASSWORD: {NEXTCLOUD_ADMIN_PASSWORD} NEXTCLOUD_DATA_DIR: {muss zum volume mapping passen, oder einfach Variable weg lassen und Default verwenden} NEXTCLOUD_TRUSTED_DOMAINS: {domains auf die Nextcloud "horcht", Komma, Semicolon oder Leerzeichen separiert... keine Ahnung was davon genau} MYSQL_HOST: {exakter Wert wie bei nextcloud-db} MYSQL_DATABASE: {exakter Wert wie bei nextcloud-db} MYSQL_USER: {exakter Wert wie bei nextcloud-db} MYSQL_PASSWORD: {exakter Wert wie bei nextcloud-db} Vermutlich werden die "ENV" Variablen ignoriert - wenn nicht, dann kann man so die Grundinstallation einer NC-Installation erzeugen (die Host-Seite des Volume-MAppings muss dabei leer sein, damit es überhaupt etwas bewirkt).

Seems not to be a problem with virtio drivers on DS918 + DSM7.0-41890 VM on same host: Other host:

Indeed, variabels that require paths needed double quoting. When I saw an unquoted variable, I wrapped it in quotes ... but I am not sure if I cought all of them. Indeed it is another error. pigr8: do you mind beeing more precise and less ambigous?

@imdgg: you manged to ignore two important things of my post: 1. the error is not related to the tool chain builder at all 2. the error is caused by a configuration that is NOT provided by default You can see a difference of the type of error pigr8 posted and the one you posted, don't you?

You might address this question to the whole community - as everyone uses it @everyone: is there a problem with 0.11 and the default provided build configurations? Please share the build config you used to get that error - as something must be missing or wrong configured in it. Also: have you tested the behavior of a freshly extracted 0.11 without any modifications?

DSM6.2.3 commes with OpenSSL 1.0.2u-fips, which has problems with the algorithms used by the new Letsencrypt certificates. You will either have to wait until a u4.pat gets released that includes openssl libraries >=1.1.0. Chances are high that this will never happen. DSM7 (does not work with Jun's bootloaders) commes with OpenSSL 1.1.1k and an update list of ca certificates. Both are required to make Letsencrypt certificates work again. It does not suffer from the problem. I have no idea what OpenSSL version commes with DSM6.2.4 (does not work with Jun's bootloaders) Many recent updates of SynoCommunity packages shouldn't be affected as well, as they provide their own and updated OpenSSL library under the hood. Since the SynoCommunity repo can't be access due their webservers use a Letsencrypt certificate, you will need to download recent packages from here https://search.synopackage.com/sources/synocommunity, and install them manualy.