[RedPill - the new loader for 6.2.4 - Discussion]

2 hours ago, pocopico said:

 

@haydibeThanks for being commited to the project.

 

IMHO, once you have the extensions loaded into "custom" directory and since these get attached to the docker images, you have nothing more to do into the docker.

 

You can just add the ext-manager.sh into the root folder of toolchain builder, to get the ext-manager process outside the containers and attach the custom folder <as you already do> to the containers. It can be part of the build process to fetch the latest ext-manager.sh from the loader repo.

 

*** well, I just remembered that there are includes inside the ext-manager that will be required for ext-manager to run
 

 

You can find some more extensions in my github repository : 

 

https://github.com/pocopico/rp-ext    e.g.  https://github.com/pocopico/rp-ext/raw/main/tg3/rpext-index.json

 

 

checked the mpt2sas and mpt3sas. In the json, looks like the version numbers are incorrect for DS3615xs (14222 points 25556 like "ds3615xs_25556": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt2sas/releases/ds3615xs_41222.json"). Is this intentional or a typo?

[RedPill - the new loader for 6.2.4 - Discussion]

1 hour ago, urundai said:

Thank you @vbap. Very much appreciated.

 

I tried that and it's not found with find.synology.com. But, I do see that the IP address has been assigned. Interestingly, find.synology.com is not finding my other synology box either. So, need to do some local troubleshooting as to what's going on. Maybe pihole is black holing it. I will some more digging and will post an update.

 

Thank you for the help,

I was able to find the instance using Synology Assistant app on my machine. Thank you @vbap once again. I was really recompiling like crazy, not finding anything the log file. 

[RedPill - the new loader for 6.2.4 - Discussion]

18 hours ago, vbap said:

From what I have read in this thread, this is fine (I believe @WiteWulf requested ThorGroup to put a better message here, as Jun's loader did).

Have you looked for your diskstation on the network (find.synology.com) and started the install process?

Thank you @vbap. Very much appreciated.

 

I tried that and it's not found with find.synology.com. But, I do see that the IP address has been assigned. Interestingly, find.synology.com is not finding my other synology box either. So, need to do some local troubleshooting as to what's going on. Maybe pihole is black holing it. I will some more digging and will post an update.

 

Thank you for the help,

[RedPill - the new loader for 6.2.4 - Discussion]

I am sure I am doing something wrong.

 

I successfully compiled the img for DS3515xs using the toolkit V11 and Debian (running on vmware on my mac). I then converted it to vmdk using V2V converter. I created a new VM in my ESXI, set the network card to E1000e, set the correct MAC address.

 

When I start it up, I see the message to pick USB or SATA. Once I select SATA, it stops at 'Booting Kernel' message. Nothing happens and I don't see any obvious error message in the log (attached). 

 

I used the instructions from this post: Building Redpill image.

 

Did any of you run into the same problem? Any pointers on what I might be doing wrong?

 

 

log.txt

[DSM 6.2.2-24922 Update 4]

Outcome of the update: FAILED
- DSM version prior update: DSM 6.2.1-23824
- Loader version and model: JUN'S LOADER v1.03b - DS3617xs
- Using custom extra.lzma: NO
- Installation type: BAREMETAL - MFU X79 Board with Intel Xeon 2650

- Additionnal comment:  No Network. System has Realtek onboard NIC and HP NC364T PCIe 4 port. Onboard was never recognized even before but after update, the 4 port PCIe stopped working (even with onboard controller disabled). Had to migrate to 1.03b DS3615 which is working great.

[DSM 6.1.x Loader]

Yes, it seems that the loader for 3617xs doesn't patch all the system files correctly and a timebomb gets activated. Same problem here unfortunately (however, for the moment I'm saved due to having a working snapshot on ESXi). @Jun, are there any plans to update your 3617xs image to get rid of this?

 

I had the same problem but have used Jun's 3615XS loader and everything is working fine so far (no 'Page not found' error that happened in my 3617xs install and system has been up 24 hours+).

[DSM 6.1.x Loader]

I got the dreaded 'Sorry, the page you are looking for is not found' after 6.1 upgrade.

 

Digging around, looks like synoscgi upstart job fails to run and it's due to libsynoshare.so.6 (error while loading shared libraries: /lib/libsynoshare.so.6: invalid ELF header). Few other commands I tried (synoupgrade) failed for the same reason.

 

Typically, ELF header issues are due to mixing 32 and 64 bit dependencies (between executable and shared object libs). Hopefully, one of you with more experience with syno stuff can think of workarounds or things that can be tried.

some DSM models has extra checks after running around a few hours, if this check is not passed, a few .so will be deliberately corrupted,

the code to deal with this is not enabled for the model if you see "device not supported" in the kernel log

Yes, I do see 'Device Not Supported' in the kern.log.

 

I didn't have this issue with 6.02. So, something has changed in the 6.1 DSM code that enforces stricter checks? Is there something I can do to get around this or should I revert back to 6.02?

[DSM 6.1.x Loader]

I got the dreaded 'Sorry, the page you are looking for is not found' after 6.1 upgrade.

 

Digging around, looks like synoscgi upstart job fails to run and it's due to libsynoshare.so.6 (error while loading shared libraries: /lib/libsynoshare.so.6: invalid ELF header). Few other commands I tried (synoupgrade) failed for the same reason.

 

Typically, ELF header issues are due to mixing 32 and 64 bit dependencies (between executable and shared object libs). Hopefully, one of you with more experience with syno stuff can think of workarounds or things that can be tried.