pocopico

After the last commits, the installation of DS918+ and DS3615xs loaders on VMware are working fine with a minor issue at the grub of DS918+ - Install and migration for DS918 and DS3615 works - Creation of volume works without the need for the previous workaround @ThorGroup Someone should add an entry at GRUB on the 918 loader for the SATA dom. I needed to add synoboot_satadom=2 manually to properly boot.

With both 918+ and 3615 images, I have issues installing on VMware workstation. Will try again after the last commits. Did anyone succeed?

There was an error in module code, see issues on GitHub. Recreate the image and try again

Hi, i got the same issue as you, it looks like redpill is failing at the time of the boot device shim and then i get no synoboot @ThorGroup [ 9.296466] <redpill/boot_device_shim.c:48> Registering boot device router shim [ 9.297930] <redpill/native_sata_boot_shim.c:205> Registering native SATA DOM boot device shim [ 9.298931] BUG: unable to handle kernel NULL pointer dereference at (null) [ 9.300841] IP: [<ffffffffa0009663>] register_native_sata_boot_shim+0x33/0x1d0 [redpill] [ 9.302811] PGD 137f9c067 PUD 137f9b067 PMD 0 [ 9.303770] Oops: 0000 [#1] SMP [ 9.303944] Modules linked in: redpill(OF+) [ 9.304117] CPU: 3 PID: 521 Comm: insmod Tainted: GF O 3.10.108 #42214 [ 9.304291] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [ 9.304465] task: ffff880137d68820 ti: ffff880135d4c000 task.ti: ffff880135d4c000 [ 9.314116] RIP: 0010:[<ffffffffa0009663>] [<ffffffffa0009663>] register_native_sata_boot_shim+0x33/0x1d0 [redpill]

There are two things that come in mind : 1. 10Gb driver is not loaded correctly 2. /etc/synoinfo.conf does not have the support_10g=y log in with ssh and verify the above

Line 285 in your case. /lib/modules is linked to /usr/lib/modules . insmod /lib/modules/xxx

Oh ! then that looks like a great opportunity for @haydibe to include the module creation on his next redpill_tool_chain release

@ThorGroup @jumkey Should/could someone create a compiled module repository in GH ? This way we can offload this thread from module requests

Right after that, the system is supposed to extract the ramdisk. The issue can be that you have a big or corrupted rd.gz. I noticed that only the uncompressed image gets extracted successfully on some systems for some reason ***edit : and the reason is explained on the loader Documentation for developers : https://github.com/RedPill-TTG/redpill-load/blob/master/FOR_DEVS.md

You do not need to recreate the whole loader. Just extract the rd, modify it (add the modules to usr/lib/modules, modify linuxrc.syno.impl to load the modules line #285) and repack it. Then copy it to the usb stick in place of the old one. For EFI its on the second usb stick partition for Legacy is on first partition. Unfortunately the legacy partition is small and thus there is not enough space for rd.gz

I always used this little tool instead. You cant go wrong with this tool https://win32diskimager.org/

It looks to me that you didnt copy the .config from the synology source. for apollolake.

When it fails at 56% usually the inetd gets started and you can telnet to the same ip with user root. Then you should check the existence of /dev/synoboot* thats probably your problem

It’s only for kernel module compilation. Kernel itself will not build as it relies on unreleased - from Synology - code. kernel modules were built using the described process. Which modules are you looking to build maybe I can provide.

Just for testing purposes, It looks that it is possible to install 918+ 7.0.1 in vmware. Steps include linking the detected SATA loader to /dev/synoboot like that : # ln -s /dev/sdXX /dev/synoboot # ln -s /dev/sdXX1 /dev/synoboot1 # ln -s /dev/sdXX2 /dev/synoboot2 # ln -s /dev/sdXX3 /dev/synoboot3 where sdXX is your loader vmdk disk whose disk name can be found running : # fdisk -l Once you have it installed there will be no need to fake it again as md raid devices are discovered and mounted during boot and are not related to the loader. Anyway you may relink using the same commands. *** edit : you need to relink after boot, I will do some more testing Again, wait for developers to release a final version before installing on your production systems.

well running DiskStation> uname -a Linux DiskStation 4.4.180+ #42214 SMP Sat Aug 28 02:41:15 CST 2021 x86_64 GNU/Linux synology_apollolake_918+ DiskStation> reports kernel version v4.4.180

For two days in a row i'm trying to fix my microserver G7 test system, which stopped booting the loader, until i found out that C1E was enable in the BIOS after i found that the ten years lithium battery was dead. I changed back C1E to disabled and now everything is working again with 7.0.1. I will now continue working on the mptsas issues. Anyone had any luck with that ?

Thanks ! failed in the same situation with failed battery and configuration went back to C1E enabled .. now everything is working

@ThorGroup Could it be that redpill is somehow messing things up for SAS driver ? I tried almost every trick i know and still no luck ! Anybody has any ideas or have had any success with SAS drives ?

I actually feel lucky to even be able to install 7.01 on my G7 that for some reason refuses to die. 😂

Usually when the install fails, you get the chance to telnet with user root to the system and check a few known things. One is the existence of /dev/synoboot device that actually proves that you have successfully shim the usb. If not which I think is the case, check with the following command the VID/PID # cat /proc/cmdline and that you have selected USB boot for physical/qemu or SATA for VMware during boot time. The default is set to USB

I have an old SAS HBA so i'm using mptsas.ko and not mpt2sas. I'm not sure why SAS drives are blocked in a non SAS synology device. For now i'm still using the embedded 4 Sata ports.

Actually since i have the pci-e occupied with an old SAS hba, i had to use the embedded LAN so i added tg3.ko and added the mptsas drivers which i havent tested yet. Other than that and the usual VID/PID,SN/MAC etc pretty much nothing. Already though i have tried the face recognition and is not working.

I have succesfully booted with a modified loader (DS3615xs) my old and brave ten years old Microserver G7 and installed 7.01. I thought that this would never be possible. I will share the loader for G7 once i have finished all tests.

It quite big .. i dont know if it will fit into uncompressed rd.gz and I dont know if you compress with gzip if it works. AQC107.7z