haydibe
-
Posts
705 -
Joined
-
Last visited
-
Days Won
35
Posts posted by haydibe
-
-
3 hours ago, taiziccf said:
by the way 0.5.3 did not load virtio driver and 0.5.4 is loading correctly! bravo, thank you for the great work!
The tool chain loader is realy just a simple wrapper that coordinates the creation of a build environment and the build, but is not involved in how redpill-lkm or redpill-load work.Thus said, I am sure ThorGroup/jumkey are happy to read about it. Its the outcome of their doing in redpill-load Fully agree: they do a great job!
Update: I missed to address that the installation is now stuck on 55%, I am sure ThorGroup will see the post - or you might raise an issue on Github with attached serial connection logs.
-
I have no idea how to automate the downloads from a page that heavily relies on javascript.
Unless the files are on Github or a public available webpage with a direct download, it will be messy and brittle.
So if someone else is up to the task, feel free to incorporate it and publish the result here.
-
If someone shares the required details about how it's done, then we can give it a try
-
.. and another update of the tool chain loader with fixed repo details for redpill-load and apollolake-7.0-41890
# Inofficial redpill toolchain image builder
- Creates a OCI Container (~= Docker) image based tool chain.
- Takes care of downloading (and caching) the required sources to compile redpill.ko and the required os packages that the build process depends on.
- Caches .pat downloads inside the container on the host.
- Configuration is done in the JSON file `global_config.json`; custom <platform_version> entries can be added underneath the `building_configs` block. Make sure the id is unique per block!
## Changes
- Changes redpill-load sources for apollolake-7.0-41890 to https://github.com/RedPill-TTG/redpill-load.git and the master branch.
## Usage
1. Create `user_config.json` according https://github.com/RedPill-TTG/redpill-load and place it in the same folder as redpill_tool_chain.sh
2. Build the image for the platform and version you want:
`./redpill_tool_chain.sh build <platform_version>`
3. Run the image for the platform and version you want:
`./redpill_tool_chain.sh auto <platform_version>`
The "old way" with `./redpill_tool_chain.sh auto <platform_version>` and executing `make build_all` is still available.
Note: run `./redpill_tool_chain.sh` to get the list of supported ids for the <platform_version> parameter.
After step 3. the redpill load image should be build and can be found in the host folder "images".
Examples:
### See Help text
```
./redpill_tool_chain.sh
Usage: ./redpill_tool_chain.sh <action> <platform version>
Actions: build, auto, run
- build: Build the toolchain image for the specified platform version.
- auto: Starts the toolchain container using the previosuly build toolchain image for the specified platform.
Updates redpill sources and builds the bootloader image automaticaly. Will end the container once done.
- run: Starts the toolchain container using the previously built toolchain image for the specified platform.
Interactive Bash terminal.
Available platform versions:
---------------------
bromolow-6.2.4-25556
bromolow-7.0-41222
apollolake-6.2.4-25556
apollolake-7.0-41890
```
### Build toolchain image
For Bromolow 6.2.4 : `./redpill_tool_chain.sh build bromolow-6.2.4-25556`
For Bromolow 7.0 : `./redpill_tool_chain.sh build bromolow-7.0-41222`
For Apollolake 6.2.4 : `./redpill_tool_chain.sh build apollolake-6.2.4-25556`
For Apollolake 7.0 : `./redpill_tool_chain.sh build apollolake-7.0-41890`
### Create redpill bootloader image
For Bromolow 6.2.4 : `./redpill_tool_chain.sh auto bromolow-6.2.4-25556`
For Bromolow 7.0 : `./redpill_tool_chain.sh auto bromolow-7.0-41222`
For Apollolake 6.2.4 : `./redpill_tool_chain.sh auto apollolake-6.2.4-25556`
For Apollolake 7.0 : `./redpill_tool_chain.sh auto apollolake-7.0-41890`
- 4
- 4
-
21 minutes ago, ilovepancakes said:
Generated new image with latest redpill-load and saving of the boot option does not work still.
Even with disk mode "independent - persistant" for the bootloader drive?
-
3 hours ago, mcdull said:
need to change the global_config.json
update last redpill_load to
https://github.com/RedPill-TTG/redpill-load.git
and branch = master
Seems yumkey removed his branch, I was to lazy to create a 0.5.4 release to adjust the sources. Been buisy with migrating my three ESXi cluster nodxs one by one to Proxmox. I still need to figure out how to migrate my existing ESXi boxes to Proxmos, especialy the one with the HBA controller in passthrough mode.
-
3 hours ago, mcdull said:
@haydibe where should I put my custom user_config.json ?
Thanks.
In the folder where the redpill_tool_chain.sh is. It will be mounted into the container and used from redpill-load.
-
2 hours ago, Kaneske said:
Am I too stupid or foolish...
Why does the Built say:
[!] Failed to copy /home/xxx/Desktop/redpill-load-master/ext/rp-lkm/redpill-linux-v3.10.108.ko to /home/koljawenske/Desktop/redpill-load-master/build/1629220385/rd-ds3615xs_41222-unpacked/usr/lib/modules/rp.ko
/usr/bin/cp: cannot stat '/home/xxx/Desktop/redpill-load-master/ext/rp-lkm/redpill-linux-v3.10.108.ko': No such file or directory
*** Process will exit ***
Did you do step #2 form the redpill-load instructions?
https://github.com/jumkey/redpill-load:
QuoteCompile RedPill LKM and place it in ext/rp-lkm/redpill-linux-<VERSION>.ko (see platform config for details)
- 1
-
Forgive me, If I am not spending any time to figure out what's wrong on the snap version of docker, as it is well known to be broken...
[quote]
failed to solve with frontend dockerfile.v0: failed to build LLB: failed to compute cache key: failed to walk /var/snap/docker
[/quote]
Docker does only care whether you are allowed to access the docker.sock or not. All commands send to the docker.sock will be executed from the docker engine with root privileges.
-
Can you try to move the builder folder into your home folder and try again. Snap Docker does only allow to bind volumes from child folders of the user home folder. Could be the same for the build context. I am not going to work on symptoms caused by using a redistribution of Docker. It works with the package from the docker repos.
-
Astonishing: you did use the docker snap package before and it worked?!
The only docker package that provides reliable behavior is the package provided by the docker repos. Every other package is a re-distribution that may or may not behave like the "original" docker package, as maintainers can modifiy behavior to match their philosophy. What you experience is high likely caused by modifications snap did for their docker version. Don't use it!
-
Fixed in the Dockerfile.
- 2
-
44 minutes ago, djvas335 said:
chmod +x entrypoint.sh then rebuild the docker image
this actualy is the fix. With the zip archive the +x flag got removed from docker/entrypoint.sh.
- 1
-
3 hours ago, scoobdriver said:
@haydibe Thanks for your work .
the 'build' part seems to work , however when I run auto , I receive the following error , would you have any advise ?
root@ubuntu:/home/scoob/redpill-tool-chain_x86_64_v0.5.2# sudo ./redpill_tool_chain.sh auto bromolow-7.0-41222 docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/entrypoint.sh": permission denied: unknown. ERRO[0000] error waiting for container: context canceled
Thanks for spotting this - I missed that zips don't retain the file permissions. I should probably use tar in the future.
-
... and the toolchain builder is updated to v0.5.2.
Highlights: ´auto` action and the deactivated Docker build cache
# Inofficial redpill toolchain image builder
- Creates a OCI Container (~= Docker) image based tool chain.
- Takes care of downloading (and caching) the required sources to compile redpill.ko and the required os packages that the build process depends on.
- Caches .pat downloads inside the container on the host.
- Configuration is done in the JSON file `global_config.json`; custom <platform_version> entries can be added underneath the `building_configs` block. Make sure the id is unique per block!
## Changes
- Added an entrypoint script that updates the redill sources in the container, executes the build and exits the container once finished.
- Added action "auto", which starts the entypoint script. If you are not activily developing on redpill, then this is the action you wil want to use.
- The action "run" retained the old behavior: it skips the entrypoint script and drops you in a bash shell. This action is ment for devs.
- Deaktivated Docker build cache, to prevent changes in the redpill repos stay undetected when building a new image.
- Refactored the in-contaienr Makefile inside to detect the kernel version for redpill-load/ext/rp-lkm/redpill-linux-${KERNELVERSION}.ko from compiled redpill.ko
## Usage
1. Create `user_config.json` according https://github.com/RedPill-TTG/redpill-load
2. Build the image for the platform and version you want:
`./redpill_tool_chain.sh build <platform_version>`
3. Run the image for the platform and version you want:
`./redpill_tool_chain.sh auto <platform_version>`
The "old way" with `./redpill_tool_chain.sh run <platform_version>` and executing `make build_all` is still available.
Note: run `./redpill_tool_chain.sh` to get the list of supported ids for the <platform_version> parameter.
After step 3. the redpill load image should be build and can be found in the host folder "images".
Examples:
### See Help text
```
./redpill_tool_chain.sh
Usage: ./redpill_tool_chain.sh <action> <platform version>
Actions: build, auto, run
- build: Build the toolchain image for the specified platform version.
- auto: Starts the toolchain container using the previosuly build toolchain image for the specified platform.
Updates redpill sources and builds the bootloader image automaticaly. Will end the container once done.
- run: Starts the toolchain container using the previously built toolchain image for the specified platform.
Interactive Bash terminal.
Available platform versions:
---------------------
bromolow-6.2.4-25556
bromolow-7.0-41222
apollolake-6.2.4-25556
apollolake-7.0-41890
```
### Build toolchain image
For Bromolow 6.2.4 : ./redpill_tool_chain.sh build bromolow-6.2.4-25556
For Bromolow 7.0 : ./redpill_tool_chain.sh build bromolow-7.0-41222
For Apollolake 6.2.4 : ./redpill_tool_chain.sh build apollolake-6.2.4-25556
For Apollolake 7.0 : ./redpill_tool_chain.sh build apollolake-7.0-41890
### Create redpill bootloader image
For Bromolow 6.2.4 : ./redpill_tool_chain.sh auto bromolow-6.2.4-25556
For Bromolow 7.0 : ./redpill_tool_chain.sh auto bromolow-7.0-41222
For Apollolake 6.2.4 : ./redpill_tool_chain.sh auto apollolake-6.2.4-25556
For Apollolake 7.0 : ./redpill_tool_chain.sh auto apollolake-7.0-41890
- 3
- 6
-
Yep, hours of trial and error saves you from reading previous forum posts ^^
It's alway nice to get a recap of already established experience from people that tl;dr the previous posts
- 3
-
Since I have no idea how to anonymize the commits, like ThorGroup does on their commit, I'd rather not leave my marks on Github.. Though, feel free to do so. My contribution is as open source as it can get: feel free to do whatever you like with it
- 2
-
What does "related to the docker itself" mean? The docker engine or the build container? Can you try again with the official docker version: https://docs.docker.com/engine/install/ubuntu/.
Odd that this proving your user access to the docker group and allowing it to use the docker.sock is the the solution.
Since you already have been able to start the build, you have already been able to instruct the docker engine to start the build.
The docker engines is always run as root... Thus whoever is able to use the docker cli, can do everything with the docker engine.
But hey: whatever works
-
52 minutes ago, titoum said:
5 85.70 W: Failed to fetch http://deb.debian.org/debian/dists/jessie/InRelease
#5 85.70
#5 85.70 W: Failed to fetch http://security.debian.org/debian-security/dists/jessie/updates/InRelease
#5 85.70
#5 85.70 W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease
#5 85.70
#5 85.70 W: Failed to fetch http://security.debian.org/debian-security/dists/jessie/updates/Release.gpg Temporary failure resolving 'security.debian.org'
#5 85.70
#5 85.70 W: Failed to fetch http://deb.debian.org/debian/dists/jessie/Release.gpg Temporary failure resolving 'deb.debian.org'
#5 85.70
#5 85.70 W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/Release.gpg Temporary failure resolving 'deb.debian.org'
#5 85.70
#5 85.70 W: Some index files failed to download. They have been ignored, or old ones used instead.High likely, you either use a http_proxy to access internet (which the container so far does not know about) or you have a DNS Problem.
-
52 minutes ago, titoum said:
careful that with version 5.1, it doesn't seem to work anymore on ubuntu...
it think it is bound to debian distro now.
Wrong assumption It should work on whetever disto that has a recent docker version (if not, try to disable "use_buildkit" in the settings -> will slow down the image build by a lot!)
If you start the script with a none or wrong number of parameters, an unknown action or a non existing platform_version configuration -> you should get a help message that shows the available actions and platform_versions.
-
I incorparated the latest changes in the redpill universe into the toolchain builder:
For 6.2.4 builds: the kernel sources are configured to be used by default.
For 7.0 builds: the Toolkit Dev sources are configured to be used by default.
# Inofficial redpill tool chain image builder
- Creates a OCI Container (~= Docker) image based toolchain
- Takes care of downloading (and caching) the required sources to compile redpill.ko and the required os packages that the build process depends on.
- Caches .pat downloads inside the container on the host.
## Changes
- Migrated from Make to Bash (requires `jq`, instead of `make` now )
- Removed Synology Toolchain, the tool chain now consists of debian packages
- Configuration is now done in the JSON file `global_config.json`
- The configuration allows to specify own configurations -> just copy a block underneath the `building_configs` block and make sure it has a unique value for the id attribute. The id is used what actualy is used to determine the <platform_version>.
## Usage
1. Create `user_config.json` according https://github.com/RedPill-TTG/redpill-load
2. Build the image for the platform and version you want:
`redpill_tool_chain.sh build <platform_version>`
3. Run the image for the platform and version you want:
`redpill_tool_chain.sh run <platform_version>`
4. Inside the container, run `make build_all` to build the loader for the platform_version
Note: run `redpill_tool_chain.sh build` to get the list of supported <platform_version>
After step 4. the redpill load image should be build and can be found in the host folder "images".
Feel free to customize the heck out of every part of the toolchain builder and post it here. If things can be done better, feel free to make them better and share the result with us.
- 7
- 3
-
`make build_all` is a build target isinde the container. Though, it is not the one you use to creat the image or run the container. The "template" is just copied from the redpill-load readme.md.
By default the only thing that needs to be done inside the container is to execute `make build_all`, which will build redpill.ko and the loader image.
-
@titoum Please make sure to use the recent version of the script and actualy follow the instructions in "usage:". The "make build_image" commands and "make run_container" commands are the litteral commands to build the image and run the container. Also there is no reason to copy the user_config.json.template file to user_config.json inside the container. If you create the file in the folder where the "outer" Makefile is, it will be mounted into the container.
- 1
-
3 hours ago, cwiggs said:
Everything else seems to work fine on MacOS 10.15.7. However v0.3 was faster to `make build_image`, which is odd since the image is smaller.
I switch to a mulit-stage Dockerfile. The first "extract" image is volatile and simply extracts the kernel source and the toolkit dev, the second image copies only a copy of folders from bother extracted archvies into the main image. Each PLATFORM/VERSION combination will create the extract image, every follow up build will leverage docker's build cache to speed up things
RedPill - the new loader for 6.2.4 - Discussion
in Developer Discussion Room
Posted
If it's still relevant: you can see the url in global_config.json.