Jump to content
XPEnology Community

TinyCore RedPill Loader (TCRP)


pocopico

Recommended Posts

11 hours ago, loveburn said:

yes, supported , and if your 8700T have a built-in UHD630 also support the transcoding

Yes the i7 has the HD630.  Did you have do anything special for /dev/dri driver?   If so, what did you do?

Also, what DS and loader did you use?  Mine is DS3622xs+ and using TCRP+F.  

Thanks.

Link to comment
Share on other sites

5 часов назад, Bacon сказал:

Yes the i7 has the HD630.  Did you have do anything special for /dev/dri driver?   If so, what did you do?

Also, what DS and loader did you use?  Mine is DS3622xs+ and using TCRP+F.  

Thanks.

For my platform I am not use additional drivers for use native transcoding... It's works perfectly after DSM install on bare metal with real serial number..... I am use arpil and tcrp (I have 2 USB flash disks) platform ds918+ only 

Edited by loveburn
Link to comment
Share on other sites

7 hours ago, Bacon said:

Yes the i7 has the HD630.  Did you have do anything special for /dev/dri driver?   If so, what did you do?

Also, what DS and loader did you use?  Mine is DS3622xs+ and using TCRP+F.  

Thanks.

 

I have Dell 7040MT with i7-6700/HD530 and transcoding work OOTB on bare metal (DS918+, ARPL, DSM 7.1.1-42962 Update 1) with real serial number and mac.

You must have a real serial and mac BEFORE installing DSM, if you change them after installation, transcoding won't work, I haven't found a solution for this.

 

You can't use DS3622xs+ for HW transcoding: 

 

 

Edited by oswaldini
Link to comment
Share on other sites

9 hours ago, oswaldini said:

 

I have Dell 7040MT with i7-6700/HD530 and transcoding work OOTB on bare metal (DS918+, ARPL, DSM 7.1.1-42962 Update 1) with real serial number and mac.

You must have a real serial and mac BEFORE installing DSM, if you change them after installation, transcoding won't work, I haven't found a solution for this.

 

You can't use DS3622xs+ for HW transcoding: 

 

 

Thanks...this was what I wanted to confirm.  The link is helpful.

Thanks @loveburn for confirming also.

 

I'll migrate to DS920+.  

Link to comment
Share on other sites

17 hours ago, Bacon said:

Thanks...this was what I wanted to confirm.  The link is helpful.

Thanks @loveburn for confirming also.

 

I'll migrate to DS920+.  

You meant DS918+ ? :)

 

 

Migration may not work - /dev/dri will not be created and transcoding will not work. You need to back up your settings and data, format the disks, and restore data and settings from a backup after reinstalling DSM on clean disks.

Link to comment
Share on other sites

Hi, 
I have TCRP installed since some time, but had only version DSM 7.0
Today I've upgraded it to DSM 7.1.0-46661 (from file) as found information on this forum that 1st I should install the upgrade from GUI and then run postupdate script.
Problem is that when I try to run postupdate, script answers with error:
Error : Platform not found. 

My platform is DS3615xs  / bromolow-7.1.0-46661
Version: 0.9.2.9
Hardware; Microserver N54L
DiskStation model: DS3615sx 
platform prior update was: bromolow-7.0.1-42218 
and that version is still displayed as my platform

Isn't my platform supported by TCRP?  or what?

What to do ? 

Thanks. 

 

Edited by amikot
some more data added
Link to comment
Share on other sites

16 hours ago, amikot said:

Hi, 
I have TCRP installed since some time, but had only version DSM 7.0
Today I've upgraded it to DSM 7.1.0-46661 (from file) as found information on this forum that 1st I should install the upgrade from GUI and then run postupdate script.
Problem is that when I try to run postupdate, script answers with error:
Error : Platform not found. 

My platform is DS3615xs  / bromolow-7.1.0-46661
Version: 0.9.2.9
Hardware; Microserver N54L
DiskStation model: DS3615sx 
platform prior update was: bromolow-7.0.1-42218 
and that version is still displayed as my platform

Isn't my platform supported by TCRP?  or what?

What to do ? 

Thanks. 

 

 

You can use the 

 

./rploader.sh postupdate ds3615xs-7.1.0-46661

 

Edited by pocopico
Link to comment
Share on other sites

I have a bearmetal setup which has 2 LAN ports using the same network chip.

I've set `netif_num=2 mac1=****** mac2=******`, but only mac1 is working. The second LAN port still stay the original MAC inside DSM.

But here is the interesting part: I created a bond using these two ports and deleted the bond. Then the mac1 and mac2 are both working.

But after reboot, mac2 returns to the original value.

Link to comment
Share on other sites

22 minutes ago, alenthelong said:

I have xpenology on buffalo TS5400D, running DS3615XS , DSM 6.2.3-25423. Can I update to DSM7 ? any one help.

Many thanks

 

 

A migration to DS3622xs+ should be possible. I suggest you try building TCRP withfriend on a new USB stick and with a single new disk on it first and test the functionality.

 

Then when you have finalized the loader testing and you feel comfortable with that, you can put all your old disks back in and run through the migration. 

  • Like 1
Link to comment
Share on other sites

hello,

 

just setup this on my ESXI and everything works expect one thing.

 

on the other virtual machine with june´s loader and 918+ Image i have running 4+4 HDDs on LSI 2308 and 2 HDDs on onboard Sata controller in Supermicro X10 board.

now i went to 3622xs+ with redpill and it find the 2 HDDs from onboard Sata and 3 HDDs from LSI controller?! so what can cause the system to not recognize 5 HDDs on same controller?

 

 

also with 918+ on redpill  - only 3 out of 8 HDDs are recognized

 

 

the "fdisk -L" on DSM shows me all drives?!

 

Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
Disk /dev/sdj: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors
Disk /dev/sdl: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors
Disk /dev/sdn: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Disk /dev/sdo: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Disk /dev/sdp: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Disk /dev/sdq: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Disk /dev/sdr: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sds: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdt: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdu: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
 

 

Edited by norman666
Link to comment
Share on other sites

On 10/22/2022 at 5:45 AM, oswaldini said:

You meant DS918+ ? :)

 

 

Migration may not work - /dev/dri will not be created and transcoding will not work. You need to back up your settings and data, format the disks, and restore data and settings from a backup after reinstalling DSM on clean disks.

I was still in the trial phase so didn't need to migrate anything.  I was able to install DS920+ and verify HW transcoding with Plex.  

 

Although with DS920+, been getting odd behaviors with the OS.  Copying many large files would timeout 3/5 times.  Doesn't seem as solid as my current DS918+ 6.2.3.  Might try something else if this keeps up.  Thanks

Link to comment
Share on other sites

I just successfully installed 920+ 7.0.1 42218, but had to overcome several obstacles. I am recording a pared down version here, to maybe help others in the future.

 

First tried to install 918+ 7.0.1 ... but was unable due to "bad ports" (DUMMY sata ports). These ports occupy the first index, so they prevent a successful install, and ./rploader.sh satamap can't help here. (To determine that I run 'dmesg | grep -i dummy', and lspci -nnq)

 

So I moved onto 920+. I kept getting to somewhere between 55 and 65% when it would go to recovery loop. I checked the logs and found

cat /var/log/linux*

Failed to AssertFileKeyValueEqual
  value1: /etc.defaults/VERSION:smallfixnumber -> 3
  value2: /tmpRoot/.syno/patch/VERSION:smallfixnumber => 5

 

Then I read in somewhere on this forum that a person got passed this error by unplugging the Ethernet wire server during installation. The reason is because the server was trying to download an update during mid-install. So I waited until it reached 55% (ie I waited until just after it finished uploading the pat file), and then I unplugged the Ethernet wire. I waited a while, plugged the wire back in, and found that the installation proceeded to completion.

 

Hope this helps someone

Edited by SirCapt
Link to comment
Share on other sites

@pocopicosorr for mentioning direct again, but I ran in an issue today with Friend 0.3:

 

First I went through smallupdate 2 of 42962 on my 3622.

 

After reboot Friend recognized the update made an update from 0.2->0.3 and restarted. The System went up again but one of my 2 HBA (2008) was gone. So the system told me critical Status.

 

Redid the whole thing with Friend an without, more then 10 Times, after completely Discharge the whole Server powered off. The HBAs both were back.

 

But I got still a Problem: Friend doenst Start my System properly, so I have to go with SATA Boot, manually. Via Console in ESXi.

 

Since Friend is the default value for unattended Start I will have to look for manual override and choose SATA Boot at every Startup.

 

Can I change that permanently to SATA or is Friend alway pre selected?

 

Thanks, in advance 

Link to comment
Share on other sites

13 minutes ago, Kaneske said:

Can I change that permanently to SATA or is Friend alway pre selected?

 

Yes you can. You can stop at TCRP Friend by pressing ctrl-c before boot timeout and edit grub.cfg.

 

vi /mnt/tcrp-p1/boot/grub/grub.cfg 

 

and set the default to your selection.

 

But what is the issue with TCRP Friend ? I didnt get that ? 

 

If you boot via TRCP friend only one HBA is visible instead of two ? Are both LSI 2008 ? 

 

 

Link to comment
Share on other sites

6 minutes ago, Kaneske said:

Yes that’s the case. Only one of the HBA is detected. Friend says 2 HBA in Debug screen (one is the VMWare one) and so I get the damaged pool…

 

TCRP Friend is there only to perform a series of actions and align to what DSM will expect. Since the HBA modules are loaded by DSM and thats after TCRP Friend boot, I doubt that your issue is related to TCRP friend. 

 

 

Link to comment
Share on other sites

Please don’t misunderstand me, I believe Friend does it’s job well. But today it happened again. I rebooted the System for getting it to default SATA, it went into Friend (yes i was to slow) and didn’t show up on my fixed IP. It had an random one in my Network. But was reachable as „recoverable“. In a Loop. I could do a recover routine, reboot…friend or SATA, no chance to get it up.

 

Rebuilt the whole Loader without friend. Started and directly after another recover attempt, I went into TCRP and ran the postinstall. 
 

The the System was up again on my fixed IP. And guess…one HBA dead.

 

Only shutdown, PowerOFF with disconnection from grid for a Minute and reboot of Hypervisor and VM brought it back into my System.

 

Its resyncing now. One Drive was (not anymore) faulty, Hotswapping brought it healthy back.

 

So either something is wrong with my HBA or this naughty -2 Update.

 

But why doesn’t Friend get me over the recovery Loop, when it was caused by missing postinstall-fix?

 

Did I do something wrong? 

Edited by Kaneske
Link to comment
Share on other sites

12 hours ago, Kaneske said:

Please don’t misunderstand me, I believe Friend does it’s job well. But today it happened again. I rebooted the System for getting it to default SATA, it went into Friend (yes i was to slow) and didn’t show up on my fixed IP. It had an random one in my Network. But was reachable as „recoverable“. In a Loop. I could do a recover routine, reboot…friend or SATA, no chance to get it up.

 

Rebuilt the whole Loader without friend. Started and directly after another recover attempt, I went into TCRP and ran the postinstall. 
 

The the System was up again on my fixed IP. And guess…one HBA dead.

 

Only shutdown, PowerOFF with disconnection from grid for a Minute and reboot of Hypervisor and VM brought it back into my System.

 

Its resyncing now. One Drive was (not anymore) faulty, Hotswapping brought it healthy back.

 

So either something is wrong with my HBA or this naughty -2 Update.

 

But why doesn’t Friend get me over the recovery Loop, when it was caused by missing postinstall-fix?

 

Did I do something wrong? 

 

Well TCRP uses a different kernel patching and ramdisk method and different kernel and ramdisk files. You could have performed recovery and the TCRP Friend should have detected the new kernel and ramdisk and patch them for you and continue boot. Second TCRP Friend boot after recovery should work properly.

 

So to sum up. You can choose SATA or TCRP Friend but the two options do not use the same kernel and ramdisk files. Thats something you should be aware of. 

Edited by pocopico
Link to comment
Share on other sites

Im currently running 7.1.0.42661 U1 on bare metal Using redpill, current stable release. Standard setup with no extra NIC card or HDD controllers.

 

Can i upgrade to the latest DSM 7.1.1.42962 via the DSM GUI? Is there still a need to run any rploader commands for this upgrade? 

Link to comment
Share on other sites

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...