Aigor

A question, when "official release" will be available, we should to make a new bootloader every time when a update will be available?

No, i'm still on 6.2 i have almost 16Tbyte of data and backup it's a little bit complicated to be use a euphemism 🤣

I have same hardware

Are there specific reasons of use Bromolov for HP Gen8 hardware with Xeon? Could be used different version? Thanks

Have you used a null-modem connection? If you want read from serial port thru another serial port you need a serial cable called "null-modem cable" search on google "null modem cable"

There isn't any DS3617XS bootloader, you better use DS3615XS https://xpenology.com/forum/applications/core/interface/file/attachment.php?id=12888 read this message readme.md from zip file # 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! - Supports a `user_config.json` per <platform_version> - Supports to bind a local redpill-load folder into the container (set `"docker.local_rp_load_use": "true"` and set `"docker.local_rp_load_path": "path/to/rp-load"`) - Supports to clean old image versions and the build cache per <platform_version> or for `all` of them at once. - Supports to auto clean old image versions and the build cache for the current build image, set `"docker.auto_clean":`to `"true"`. - Allows to configure if the build cache is used or not ("docker.use_build_cache") - Allows to specify if "clean all" should delete all or only orphaned images. ## Changes - fixed usage of label that determins the redpill-tool-chain images for clean up - add `"docker.use_build_cache": "false"` to global_settings.json - add `"docker.clean_images": "all"` to global_settings.json ## Usage 1. edit `<platform>_user_config.json` that matches your <platform_version> 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>` You can always use `./redpill_tool_chain.sh run <platform_version>` to get a bash prompt, modify whatever you want and finaly execute `make -C /opt/build_all` to build the boot loader image. After step 3. the redpill load image should be build and can be found in the host folder "images". Note1: run `./redpill_tool_chain.sh` to get the list of supported ids for the <platform_version> parameter. Note2: if `docker.use_local_rp_load` is set to `true`, the auto action will not pull latest redpill-load sources. Feel free to modify any values in `global_config.json` that suite your needs! Examples: ### See Help text ``` ./redpill_tool_chain.sh Usage: ./redpill_tool_chain.sh <action> <platform version> Actions: build, auto, run, clean - 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. - clean: Removes old (=dangling) images and the build cache for a platform version. Use `all` as platform version to remove images and build caches for all platform versions. `"docker.clean_images"`="all" only has affect with clean all. Available platform versions: --------------------- bromolow-6.2.4-25556 bromolow-7.0-41222 bromolow-7.0.1-42214 apollolake-6.2.4-25556 apollolake-7.0-41890 apollolake-7.0.1-42214 ``` ### 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 Bromolow 7.0.1 : `./redpill_tool_chain.sh build bromolow-7.0.1-42214` 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` For Apollolake 7.0.1 : `./redpill_tool_chain.sh build apollolake-7.0.1-42214` ### 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 Bromolow 7.0.1 : `./redpill_tool_chain.sh auto bromolow-7.0.1-42214` 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` For Apollolake 7.0.1 : `./redpill_tool_chain.sh auto apollolake-7.0.1-42214` ### Clean old redpill bootloader images and build cache For Bromolow 6.2.4 : `./redpill_tool_chain.sh clean bromolow-6.2.4-25556` For Bromolow 7.0 : `./redpill_tool_chain.sh clean bromolow-7.0-41222` For Bromolow 7.0.1 : `./redpill_tool_chain.sh clean bromolow-7.0.1-42214` For Apollolake 6.2.4 : `./redpill_tool_chain.sh clean apollolake-6.2.4-25556` For Apollolake 7.0 : `./redpill_tool_chain.sh clean apollolake-7.0-41890` For Apollolake 7.0.1 : `./redpill_tool_chain.sh clean apollolake-7.0.1-42214` For all : `./redpill_tool_chain.sh clean all`

I wait "official release" meanwhile, i'm going to make some test on vmware on how to migrate

The worst part of process 🤣 i have almost 18 Tbyte to backup

Forgive me if i'm dumb, if i would build loader for 7.01 for HP Gen8 Microserver, how should i do? Can i perform direct upgrade in place without lost config and data? Should i backup, perform new installation and restore? Which process should be better with balance between data integrity and less operation? many thanks

You don't need to Synology account is for internet access and some licensing, for example for Active Backup, but it needs real mac-address and real serial number.

Can you access into ILO to view serial output of gen8?

if you have a DHCP in your network try to see ip assigned, if you know mac-address of your baremetal, once targeted you can poi browser to this ip

Could be useful to add driver via config.json on script to build lkm first and loader after.

Yes, but could be a occasion to add openvmtools into spksrc framework for DSM7 spksrc is a framework to simplify the porting process of linux packages into DSM environment, there is already a github repos for spksrc and opnevmtools for synology, adding both we could have a new package for dsm7

you haved to add openvmtools via spk ti have vmxnet3

Do this method works with other drivers? I'm thinking to network card's driver other then intel

Good Job! can you share your method? Thanks

I'v lost some updates, there is some recap to know "state of the art" of bootloader? Thanks

Can you be more specific?

So, nope, thanks!

For core I3 you can try DS3615xs image. Start with Juns loader, to avoid entropy, but first check hardware to be sure that lkm are present into kernel

Core 2 duo are not supported from actual loader

There is DSM7 for DS3617xs, could be used to build loader using 3615 patch?

For DS3617xs too

try to telnet to ip address