Jump to content
XPEnology Community

RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

i think mine was not working until i fixed the kernel cmd line setting the correct mac1

 

one of the ./rploader.sh command update the mac1 in user_config.json with a synology mac address, i have replaced this value with the real mac address of my nic which is not the integrated one but an intel pro 1000 dual port

Link to comment
Share on other sites

as i sayd u have to update the grub bootloader config and put the correct mac address in grub.conf

 

mkdir -p /tmp/synoboot1

cd /dev

mount -t vfat synoboot1 /tmp/synoboot1   (warning mount /dev/synoboot1 doesnt wotk! u must cd in dev to get it working)

 

vi /tmp/synoboot1/boot/grub/grub.cfg

replace all mac1=XXXXXXXXXXXX with the mac address of your ethernet card w/o the ":" maybe all uppercase

save it

 

umount /tmp/synoboot1

 

reboot

 

Link to comment
Share on other sites

I made an image and trying to boot from a flash drive after selecting RedPll (USB, Verbose) I get "Error: symbol grub_calloc not found"
 
Anyone can help me?
 
 
My server is HP MicroServer Gen 8

I use 3615 build for barametal install on Gen8 with xeon 1265, tinycore redpill, work perfect.


Отправлено с моего iPhone используя Tapatalk
Link to comment
Share on other sites

I decided to try switching to redpill bromolow with redpill apollolake, assembled the bootloader, the network card did not start, assembled everything with the drivers, and everything is fine under ds918+ and without firewood, but for some reason it does not offer migration, the mode is not installed and offers to install. I thought it was because disks 1-4 are ssd cache. I tried to delete the ssd cache and created 4 pools without volumes, after that I tried again, but nothing changed. Then I thought it might be because the vid/pid is the same and I assembled on another usb, but again the same problem. All 11 disks are initialized. What could be the problem?

Link to comment
Share on other sites

@IG-88

 

Not sure if this would help anyone here on this end, but part of the problem I was having and some others were having when we would get the "file corruption" error trying to install DS3617xs on 6.2.4 or 7.0.1 is the following

 

Feb 11 07:57:53 updater: updater.c:7045 ==== Start flash update ====
Feb 11 07:57:53 updater: updater.c:7049 This is X86 platform
Feb 11 07:57:53 updater: boot/boot_lock.c(228): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:2)
Feb 11 07:57:53 updater: updater.c:6510 Failed to mount boot partition
Feb 11 07:57:53 updater: updater.c:3134 No need to reset reason for v.42218
Feb 11 07:57:53 updater: updater.c:7652 Failed to accomplish the update! (errno = 21)
Feb 11 07:57:53 install.cgi: ninstaller.c:1546 Executing [/tmpData/upd@te/updater -v /tmpData > /dev/null 2>&1] error[21]
Feb 11 07:58:00 install.cgi: ninstaller.c:123 Mount partion /dev/md0 /tmpRoot
Feb 11 07:58:00 install.cgi: ninstaller.c:1515 Moving updater for configuration upgrade...cmd=[/bin/mv -f /tmpData/upd@te/updater /tmpRoot/.updater > /dev/null 2>&1]
Feb 11 07:58:01 install.cgi: ninstaller.c:152 umount partition /tmpRoot
Feb 11 07:58:01 install.cgi: ErrFHOSTCleanPatchDirFile: After updating /tmpData/upd@te...cmd=[/bin/rm -rf /tmpData/upd@te > /dev/null 2>&1]
Feb 11 07:58:01 install.cgi: ErrFHOSTCleanPatchDirFile: Remove /tmpData/upd@te.pat...
Feb 11 07:58:01 install.cgi: ErrFHOSTDoUpgrade(1794): child process failed, retv=-21
Feb 11 07:58:01 install.cgi: ninstaller.c:1811(ErrFHOSTDoUpgrade) err=[-1]
Feb 11 07:58:01 install.cgi: ninstaller.c:1815(ErrFHOSTDoUpgrade) retv=[-21]
Feb 11 07:58:01 install.cgi: install.c:409 Upgrade by the manual patch fail.
Feb 11 07:58:01 install.cgi: install.c:678 Upgrade by the uploaded patch /tmpData/@autoupdate/upload.pat fail.
Jan  1 00:00:00 install.cgi: ninstaller.c:152 umount partition /tmpData
Feb 11 07:57:53 updater: boot/boot_lock.c(228): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:2)
Feb 11 07:57:53 updater: updater.c:6510 Failed to mount boot partition

 

And when trying to mount it manually I would get the following

mount: can't find /dev/synoboot2 in /etc/fstab

Link to comment
Share on other sites

1 час назад, chemistry сказал:

Hi!

Is there a guide how to use redpill for a baremetal Ugrade from DSM6 to 7?

Or any guide at all?

 

Thx!

 

The migration process takes place according to the algorithm laid down by the creators of the DSM OS.
Thus, the task is only to create a DSM 7.0.1 bootloader to initiate the migration.
It can be done according to the manual described here ->https://xpenology.club/install-dsm-7-on-baremetal-or-vm/

 

 

Link to comment
Share on other sites

6 hours ago, Dvalin21 said:

@IG-88

 

Not sure if this would help anyone here on this end, but part of the problem I was having and some others were having when we would get the "file corruption" error trying to install DS3617xs on 6.2.4 or 7.0.1 is the following

 

Feb 11 07:57:53 updater: updater.c:7045 ==== Start flash update ====
Feb 11 07:57:53 updater: updater.c:7049 This is X86 platform
Feb 11 07:57:53 updater: boot/boot_lock.c(228): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:2)
Feb 11 07:57:53 updater: updater.c:6510 Failed to mount boot partition
Feb 11 07:57:53 updater: updater.c:3134 No need to reset reason for v.42218
Feb 11 07:57:53 updater: updater.c:7652 Failed to accomplish the update! (errno = 21)
Feb 11 07:57:53 install.cgi: ninstaller.c:1546 Executing [/tmpData/upd@te/updater -v /tmpData > /dev/null 2>&1] error[21]
...
Feb 11 07:57:53 updater: boot/boot_lock.c(228): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:2)
Feb 11 07:57:53 updater: updater.c:6510 Failed to mount boot partition

 

And when trying to mount it manually I would get the following

mount: can't find /dev/synoboot2 in /etc/fstab

 

with 6.2.3 jun's patch in the extra.lzma does not match anymore, its not fatal as it still install's and runs but there is a small part missing and that gives problems when updating, i think its this one:

https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/

if the fix is applied before the update to 6.2.4/7.0 (or even 6.2.3 update3) everything should work as expected

 

 

  • Thanks 2
Link to comment
Share on other sites

19 minutes ago, idle said:

The migration process takes place according to the algorithm laid down by the creators of the DSM OS.

 

its not that simple, there are differences of having a real dsm system and using a (hacked) loader

you can start the update process of dsm with the old loader still plugged in, then the new kernel for booting next time ends on the old loader and next boot is unsuccessful (old loader, new kernel, hack does not match) and you swap the loader to the new one, but the kernel on the new loader is not necessarily the same as the one you have on disk now, in a original system you dont swap the usb device used as bootloader while a update is started

 

also major difference is drivers, as long as you only use "native" drivers already in the dsm base system as it comes from synology there is no problem but when relying on other drivers (either jun's or my extended extra.lzma) you need to make sure you have drivers for your "non standard" hardware in the new loader (including firmware for the driver if needed), the original repill loader builder comes with just no additional drivers so if starting with that you need to take care of it yourself, tinycore is a massive improvement but might not (yet) cover all cases, there might be few cases where a driver in my extra.lzma was newer or present that does not in tinycore (i guess tinycore will cover 99% of the cases right now)

example: jun's 1.04b 918+ with no added drivers, system has 4 disks onboard sata and 8 disk on lsi sas conroller, with the vanilla redpill loader the mpt2sas.ko driver would be missing in 7.0 and you would only see 4 out of 12 disks, raid with the 12 disks will be shown as broken (tinycore would cover that scenario)

 

on a original synology system you dont need to care about the loader or driver, the update would apply and there no nee to fuss about much what could go wrong, were with a xpenology system you have that fuss with every update and need to make sure its not breaking anything, thats the reason you usually look here in the forum if a new update has been tested (and there a a lot of people not doing this and coming here wanting to know what to do as the system comes not up anymore after a "simple" update)

 

  • Thanks 1
Link to comment
Share on other sites

3 hours ago, IG-88 said:

 

with 6.2.3 jun's patch in the extra.lzma does not match anymore, its not fatal as it still install's and runs but there is a small part missing and that gives problems when updating, i think its this one:

https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/

if the fix is applied before the update to 6.2.4/7.0 (or even 6.2.3 update3) everything should work as expected

 

 

Will share this with the tinycore forum as many of us are having the issue.  Thank you sir!!!

Link to comment
Share on other sites

Hi Everyone,

 

First all of all thanks for all the work !

 

I searched a bit but i'm not sure: does updating a baremetal gen8 with 1265v2 CPU to dsm 7 unlock some hardware acceleration ? or by adding a GPU (i know before it wouldnt work) ?

I don't think so but, we never know !

 

Thank you again !

Link to comment
Share on other sites

On 1/28/2022 at 11:38 AM, MastaG said:

I'm running DS3615xs DSM 7.0.1-42218 on my MicroServer Gen8 G1610T.

I've compiled it from source a while ago and I remember it took me some trouble to figure out how to add a repository for the ethernet drivers.

 

Anyways it has been running rock solid up until now, surveillance station, docker + portainer and even a Windows 10 VM and I'm very happy with it.

 

Now I believe update DSM 7.0.1-42218 Update 1 and 2 are out now.

What's the best way to build a new image (which includes the ethernet driver)?

 

I would hang tight until we have confirmations that it works or take drives out and test with a junk disk and existing 7.0.1 loader to see if latest updates 1 and 2 work. That's usually the only way to know have to test, test, test lol. This experiment helped me learn proxmox very quickly and that eventually led to getting baremetal working after playing with sataportmaps / diskmaps in the vm and gaining confidence while trying to repeat working builds on junk disk. Short Story try it in the VM. The Auto command at the end of your build script should discover your ethernet card and download the driver to my understanding.

 

Link to comment
Share on other sites

Le 16/01/2022 à 05:44, dodo-dk a dit :

Thank you very much @buggy25200

I have updated DS3617xs to Update 2 too with your howto, it works.

Only the ACPI - Powerbutton shutdown doesn't work. 

When I start the script /etc/acpi/powerbtn.sh in DSM it shuts down, but from Proxmox it doesn't.

 

On DS3615xs and DS918+ it works.

 

I updated the repository https://github.com/jimmyGALLAND/redpill-ext/raw/master/acpid/rpext-index.json

It works now.

  • Thanks 4
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...