Jump to content
XPEnology Community

Jun's ds918+ loader modified for DSM-6.2.4


sunnyqeen

Recommended Posts

Hi All,

I modified jun's loader to work with DSM-6.2.4, for safe reason, I removed all the kmods from the extra.lzma but kept rtc_cmos.ko 

The loader is created with DSM-6.2.4 update 2

Tested working well with vmware, you will need change .vmx file to use e1000e as it's built-in.

      ethernet0.virtualDev = "e1000e"

It should work with main boards that have r8168, igb like J3455-ITX, etc

 

here is the step to create the loader.

1. prepare patched kernel zImage

    RedPill team already have that well explained, so just use their tool to generate one.

2. prepare patched ramdisk

    make the extra.cpio that contains modified files from jun's 1.0.4 loader, mainly the jun.patch to match the new files inside rd.gz

    you could add more kmods for network cards and storage cards to load, as there is a lot of them for RedPill loader already

    extract the rd.gz to rd.cpio

             lzma -dc < rd.gz > rd.cpio

    the kernel support multi-cpio booting, so just copy the 2 files to one 

             cat rd.cpio extra.cpio > rd_extra.cpio

    make new rd.gz that accepted by the kernel. original rd.gz has 64bytes sig, as the patched kernel already bypass the sig check, so we just need to add a fake sig to end of file.

    create a padding.bin which is 64bytes.

             lzma -9 rd_extra.cpio

             cat rd_extra.cpio.lzma padding.bin > rd_extra.lzma

  3. modify grub.cfg to boot with the new zImage and rd_extra.lzma

      copy the patched zImage to first EFI partition of the synoboot.img and replace bzImage

      copy the rd_extra.lzma to the second partition

      enable the initrd loading

            initrd /rd_extra.lzma

 

if all the steps are done you should have bootable 6.2.4 loader.

The modified files are attached. you should unpack the extra.cpio to see what are changed.

 

And you could try the made loader from here

https://ufile.io/hrdlt20r

 

            

UsedFiles.rar

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Interesting, will have to play with this a bit.

 

Can you explain this further?  Is your modification causing kernel panics?

17 hours ago, sunnyqeen said:

for safe reason, I removed all the kmods from the extra.lzma

 

17 hours ago, sunnyqeen said:

It should work with main boards that have r8168, igb like J3455-ITX, etc

This is because the native DS918+ has this NIC.

Link to comment
Share on other sites

2 hours ago, flyride said:

This is because the native DS918+ has this NIC.

no realtek in 918+, its intel (afair the realtek in the 918+ *.pat comes from another unit that is build on the same cpu architecture and uses the same base kernel config including drivers)

https://xpenology.com/forum/topic/14127-guide-to-native-drivers-dsm-621-on-ds918/

 

On 2/4/2019 at 12:46 AM, flyride said:

designed. Refer to the example below for DS918:

 

DS918    Reference Hardware:     
  CPU: Intel J3455 (Apollo Lake)
  GPU: Intel HD Graphics 500/505
  Chipset: Intel SOC
  2x1Gb Ethernet: Intel i211
  SATA:

88SE9215 PCIe SATA 6.0 Gb/s controller

 

Edited by IG-88
Link to comment
Share on other sites

3 hours ago, IG-88 said:

no realtek in 918+, its intel (afair the realtek in the 918+ *.pat comes from another unit that is build on the same cpu architecture and uses the same base kernel config including drivers)

https://xpenology.com/forum/topic/14127-guide-to-native-drivers-dsm-621-on-ds918/

As always, nothing gets by you man!  And using my own post to refute.  My point was that the realtek driver was part of the base image without Jun's add.  But I didn't phrase it that way, did I? :-)

 

26 minutes ago, sunnyqeen said:

I removed the kernel mods because they were built for 6.2.3

I am not sure if they are still working for 6.2.4 or not.

 

Technically they were built for 6.2.x as 6.2.3 did not exist when they were released.  And honestly, I've never checked to see if they are identical to the mods embedded in 1.02b (6.1.x) version of Jun's loader.

 

I don't think there would be much harm in leaving them in there if they did not cause a panic.  Thank you for clarifying your reasoning.

Link to comment
Share on other sites

@Nemesis you should make your own loader based on the post. most important, add your own net and storage drivers.

I tried my pc and VMware, both working fine.

because there is kernel update with 6.2.4 update 2

you will need to create 2 loader, 1 for orig 6.2.4, another for update 2.

install using the first one and after update using the second one.

 

if the loader and installation package do not match, you will see dsm recovery page. if you have serial port enabled, you will see the log message of mismatch.

  • Like 1
Link to comment
Share on other sites

On 2/3/2022 at 2:38 PM, sunnyqeen said:

@Nemesis you should make your own loader based on the post. most important, add your own net and storage drivers.

I tried my pc and VMware, both working fine.

because there is kernel update with 6.2.4 update 2

you will need to create 2 loader, 1 for orig 6.2.4, another for update 2.

install using the first one and after update using the second one.

 

if the loader and installation package do not match, you will see dsm recovery page. if you have serial port enabled, you will see the log message of mismatch.

How do you enable serial port and get the logs?

Link to comment
Share on other sites

  • 3 weeks later...
23 hours ago, tintun2022 said:

I tried it, but always bootup at recover screen

Try the new loader, I removed some version check.

So it should work for 6.2.4 with/without update.

And also attached new extra.cpio with the jun.patch update

 

--- a/usr/syno/sbin/check_root_junior_match.sh
+++ b/usr/syno/sbin/check_root_junior_match.sh
@@ -43,9 +43,4 @@
 if [ "$UniqueRD" != "kvmx64" -a "$UniqueRD" != "nextkvmx64" -a "$UniqueRD" != "kvmcloud" ]; then
 	AssertDirectory "${RootMnt}.syno/patch/"
 	AssertFileKeyValueEqual "/${VERSION_DEF}" "${RootMnt}${VERSION_UPDATER}" buildnumber
-	AssertFileKeyValueEqual "/${VERSION_DEF}" "${RootMnt}${VERSION_UPDATER}" smallfixnumber
-	if [ ! -f ${RootMnt}.SkipCheckPackingMatch ]; then
-		AssertFileKeyValueEqual "/${VERSION_DEF}" "${RootMnt}${VERSION_UPDATER}" packing
-		AssertFileKeyValueEqual "/${VERSION_DEF}" "${RootMnt}${VERSION_UPDATER}" packing_id
-	fi
 fi

 

https://ufile.io/az21xwu0

extra.cpio

Edited by sunnyqeen
update content
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
On 1/31/2022 at 12:59 AM, sunnyqeen said:

Hi All,

I modified jun's loader to work with DSM-6.2.4, for safe reason, I removed all the kmods from the extra.lzma but kept rtc_cmos.ko 

The loader is created with DSM-6.2.4 update 2

Tested working well with vmware, you will need change .vmx file to use e1000e as it's built-in.

      ethernet0.virtualDev = "e1000e"

It should work with main boards that have r8168, igb like J3455-ITX, etc

 

here is the step to create the loader.

1. prepare patched kernel zImage

    RedPill team already have that well explained, so just use their tool to generate one.

2. prepare patched ramdisk

    make the extra.cpio that contains modified files from jun's 1.0.4 loader, mainly the jun.patch to match the new files inside rd.gz

    you could add more kmods for network cards and storage cards to load, as there is a lot of them for RedPill loader already

    extract the rd.gz to rd.cpio

             lzma -dc < rd.gz > rd.cpio

    the kernel support multi-cpio booting, so just copy the 2 files to one 

             cat rd.cpio extra.cpio > rd_extra.cpio

    make new rd.gz that accepted by the kernel. original rd.gz has 64bytes sig, as the patched kernel already bypass the sig check, so we just need to add a fake sig to end of file.

    create a padding.bin which is 64bytes.

             lzma -9 rd_extra.cpio

             cat rd_extra.cpio.lzma padding.bin > rd_extra.lzma

  3. modify grub.cfg to boot with the new zImage and rd_extra.lzma

      copy the patched zImage to first EFI partition of the synoboot.img and replace bzImage

      copy the rd_extra.lzma to the second partition

      enable the initrd loading

            initrd /rd_extra.lzma

 

if all the steps are done you should have bootable 6.2.4 loader.

The modified files are attached. you should unpack the extra.cpio to see what are changed.

 

And you could try the made loader from here

https://ufile.io/hrdlt20r

 

            

UsedFiles.rar 84.22 kB · 52 downloads

Hi, I was wondering if this could be used for DS3617xs for 6.2.4-25556 and what has to be changed?

Link to comment
Share on other sites

  • 1 month later...
On 1/30/2022 at 5:59 PM, sunnyqeen said:

Hi All,

I modified jun's loader to work with DSM-6.2.4, for safe reason, I removed all the kmods from the extra.lzma but kept rtc_cmos.ko 

The loader is created with DSM-6.2.4 update 2

Tested working well with vmware, you will need change .vmx file to use e1000e as it's built-in.

      ethernet0.virtualDev = "e1000e"

It should work with main boards that have r8168, igb like J3455-ITX, etc

 

here is the step to create the loader.

1. prepare patched kernel zImage

    RedPill team already have that well explained, so just use their tool to generate one.

2. prepare patched ramdisk

    make the extra.cpio that contains modified files from jun's 1.0.4 loader, mainly the jun.patch to match the new files inside rd.gz

    you could add more kmods for network cards and storage cards to load, as there is a lot of them for RedPill loader already

    extract the rd.gz to rd.cpio

             lzma -dc < rd.gz > rd.cpio

    the kernel support multi-cpio booting, so just copy the 2 files to one 

             cat rd.cpio extra.cpio > rd_extra.cpio

    make new rd.gz that accepted by the kernel. original rd.gz has 64bytes sig, as the patched kernel already bypass the sig check, so we just need to add a fake sig to end of file.

    create a padding.bin which is 64bytes.

             lzma -9 rd_extra.cpio

             cat rd_extra.cpio.lzma padding.bin > rd_extra.lzma

  3. modify grub.cfg to boot with the new zImage and rd_extra.lzma

      copy the patched zImage to first EFI partition of the synoboot.img and replace bzImage

      copy the rd_extra.lzma to the second partition

      enable the initrd loading

            initrd /rd_extra.lzma

 

if all the steps are done you should have bootable 6.2.4 loader.

The modified files are attached. you should unpack the extra.cpio to see what are changed.

 

And you could try the made loader from here

https://ufile.io/hrdlt20r

 

            

UsedFiles.rar 84.22 kB · 64 downloads

Can you re-upload your loader again, maybe to Google Drive, MEGA, Amazon Drive...curious to try it out.  Just tried to download https://ufile.io/hrdlt20r and informed "The hosting period for this file has now expired, only paid users can download it.  To download this file, you must first subscribe to a paid plan"

 

Thanks

Link to comment
Share on other sites

@sunnyqeen

Is there a change to create or deliver this also for the "pure metal" operation of the HP microserver Gen7 (N36L/40L/54L (also Gen 8?)) (that would be: Bromollow 3.10.105 (DSM6) module):

i.e. -->  Jun's Loader v1.03b DS3615xs modified for DSM-6.2.4?

 

Background:
I have set up several Gen7/Gen8 HP microserver at friends of mine for several years as their data storage and backup.
None of their HP microserver is additionally equipped with SATA extensions or additional NICs/PC-Cards, all "pure metal" of the original HP server.
So driver support is enough for me/us, which was present in the wonderful original "Jun's Loader v1.03b DS3615xs".

I will probably not switch to DSM-7.x soon, I don't see any advantages for me/us at the moment, but I would always like to get the security updates from Synology, until DSM-6.x is no longer supported by Synology.

 

No question, redpill is the future for DSM-7.x support and also for additional SATA/PC cards or other mainboards,
but for about the next two years, DSM-6.2.4 (with Jun's Loader v1.03b DS3615xs...) is probably enough for me/us with my limited hardware.
:-)

 

I could imagine, that many other owners of HP Gen7/Gen8 servers feel the same way, who would like to get the security updates of the DSM-6.x. ...

Edited by uaus
Link to comment
Share on other sites

  • 4 weeks later...
On 5/17/2022 at 2:30 AM, uaus said:

, but I would always like to get the security updates from Synology, until DSM-6.x is no longer supported by Synology.

that's 6/2023 for dsm 6.2

 

not sure where the problems with microserver and dsm 7.x would be, there is even a 3615 version and the 3617 should more or less work the same and afair there are people using 3622 without problems

main problem can be 3rd party packages with 7.x as there are changes in dsm

 

there is also still support in tc rp loader for dsm 6.2.4, so maybe check out that for 3615 and if you have time you can use the new skills with tc to check on 7.x

https://github.com/pocopico/redpill-load/tree/master/config/DS3615xs

https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/

 

Link to comment
Share on other sites

  • 1 month later...
10 hours ago, DSfuchs said:

Hello, is there a loader for version 6.2.4 that can be downloaded somewhere that works. Tried redpill 4.6, negative.
I'm happy to hear from you.

Here you go: https://drive.google.com/file/d/1loNStLxKC711qG3zl_kTtUfnC8nu-M38/view?usp=sharing

I've not tried using the modified synoboot created by @sunnyqeen yet, but here are all the files rar'ed into 1 file for download.

Edited by gericb
  • Thanks 1
Link to comment
Share on other sites

  • 4 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...