Jump to content
XPEnology Community

haydibe

Contributor
  • Posts

    705
  • Joined

  • Last visited

  • Days Won

    35

Posts posted by haydibe

  1. 3 hours ago, psychoboi32 said:

    Thanks for making this it really make most of job very easy (as mac user). Can I know what version of linux-4.4.x.txz is downloading because the speed is slow as snail, I can use aria2c and then paste on download folder previous version give me error so trying this version if there any other update please tag me or don't know how to get notification if update came. Thank you

    If it's still relevant: you can see the url in global_config.json.

     

    • Like 1
  2. 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.

     

  3. .. 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`

     

    redpill-tool-chain_x86_64_v0.5.4.zip

    • Like 4
    • Thanks 4
  4. 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.

  5. 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:

    Quote

    Compile RedPill LKM and place it in ext/rp-lkm/redpill-linux-<VERSION>.ko (see platform config for details)

     

    • Like 1
  6. 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.

     

  7. 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! 

  8. 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.  

  9. ... 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

     

    redpill-tool-chain_x86_64_v0.5.2.zip

    • Like 3
    • Thanks 6
  10. 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 :)

  11. 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. 

  12. 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.

  13. 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.

     

    redpill-tool-chain_x86_64_v0.5.1.zip

    • Like 7
    • Thanks 3
  14. @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.

     

     

    • Like 1
  15. 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 :)

×
×
  • Create New...