TinyCore RedPill Loader (TCRP)

[alirz1]

looks like this place is dead. But i just wanted to say, i tried a new build, on a c completely different hardware, different loaders,( pocopcos and petersuh's mshell.)

and im running into the exact same symptoms as my above post on this new hardware. im just dumbfounded and no idea whats going on. in DSM, control panel, or other tabs freeze before opening, package center wont properly open, the app icons in package cetner wont load and all show the same "S" icon.

i even tried connecting to different routers and internet connection, no firewalls or VPNs in place here etc. 

Im lost.

 

 

EDIT: Well wouldnt you know!!!!!!!

 

 

Edited June 1 by alirz1

[alirz1]

previously we could could mount /dev/synoboot and edit the grub.cfg there if i wanted to change the MAC or serial of the box. However i notice that in the loader entry created by mshell, the default boot entry entry does not specify the parameters to set the serial, mac etc.... 

How can i do that? Do i need to rebuild the loader?

[Peter Suh]

On 6/1/2024 at 5:31 AM, alirz1 said:

@Peter Suh So i did a new build, and this time im using your mshell based loader from your github. Previously i have used pocopico's loader.

Its a HP 800 G4 , intel i7 8700 based system with 16gb ram. Two brand new WD 8TB HDDs. Im noticing that DSM is extremely sluggish. Tabs take over a minute to load, the package centner wont load properly etc. The build itself was fine, no errors or anything.

While thats vague information for you im just wondering has anyone encountered a strange sluggishness. I have an exact same other system but running regular tinycore loader and that one runs fine.

Should i perhaps rebuild it?

 

This seems to be the top process showing in the TOP command....:  /usr/sbin/scaler.sh

the script seems to be related to cpu frequencies?

 

 

You must use the top command on Synology or use the resource manager to find programs causing overload.

 

/usr/sbin/scaler.sh Are you overloading top?

 

Can you capture and show me the evidence?

[alirz1]

7 hours ago, Peter Suh said:

 

 

You must use the top command on Synology or use the resource manager to find programs causing overload.

 

/usr/sbin/scaler.sh Are you overloading top?

 

Can you capture and show me the evidence?

Well it turns out it's an issue on synology end as per my reddit link above. Thanks.

[Alekc]

@pocopico @Peter Suh Hello,

 

I'm planning to upgrade the server from an i5 8400 to a 12400.

 

To make the HDD transfer from the old server to the new one smooth, I conducted an experiment. I installed a absolutly new HDD into the new server and tried to run it and check all functions, such as HW transcoding and AME codecs, but I failed every time (Synology can't get a license for AME and asks to contact the support team).

 

I have already checked several loaders (TCRP, ARC, and RR) with different versions. I have also tried different models (SA6400 and DS918) with valid SN+MAC pairs. Additionally, I tried different DSM versions, 7.1 and 7.2.

 

Could you please advise where I went wrong and what I should check?

 

Because at the same time, I have an old server where all functions work fine with the same SN+MAC pair but with a very old Pocopico's loader (DSM 7.1).

[alirz1]

Funny I came to post similar question. I wanted to know how to change the Mac and serial after I had a working setup.

i want to use a real sun+ Mac pair to be able to use AME. Because I’m also running that on an older setup and it’s working fine.

i have a second build I would like to do the same but based on what you’re saying is that for you ame is not activating even with a valid sn and Mac combo?

[Zitt]

On 3/6/2024 at 5:38 AM, Hackaro1 said:

Hi all, @Peter Suh

 

a friend of mine trying to build his 1st Xpenology had a problem with DS3622XS model and ACPI daemon. It was installed the DSM 7.2.1-69057 Update 3 on my pc with DS3622xs+ via your M Shell for tinycore-redpill v.1.0.1.0.

 

Everything's fine except for the power off via power button.

Checking acpid.service:

root@ALAMO_Test_1:~# systemctl status acpid.service -l
● acpid.service - ACPI Daemon
   Loaded: loaded (/usr/lib/systemd/system/acpid.service; static; vendor preset: disabled)
   Active: active (running) since Wed 2024-01-31 18:02:25 CET; 9min ago
 Main PID: 25027 (acpid)
   CGroup: /system.slice/acpid.service
           └─25027 /usr/sbin/acpid -f

Jan 31 18:02:25 ALAMO_Test_1 systemd[1]: Started ACPI Daemon.
Jan 31 18:02:25 ALAMO_Test_1 systemd[1]: Starting ACPI Daemon...
Jan 31 18:02:25 ALAMO_Test_1 acpid[25027]: cannot open input layer
Jan 31 18:02:25 ALAMO_Test_1 acpid[25027]: inotify_add_watch() failed: No such file or directory (2)
Jan 31 18:02:25 ALAMO_Test_1 acpid[25027]: starting up with netlink and the input layer
Jan 31 18:02:25 ALAMO_Test_1 acpid[25027]: 1 rule loaded
Jan 31 18:02:25 ALAMO_Test_1 acpid[25027]: waiting for events: event logging is off

 

any hint? Thanks in advance!

Did this ever get resolved?
I'm having the same problem with the same message on DVA3221 under 7.2.1-69057 and Proxmox 8.2.4.

[Zitt]

22 hours ago, Zitt said:

Did this ever get resolved?
I'm having the same problem with the same message on DVA3221 under 7.2.1-69057 and Proxmox 8.2.4.

 

This is how I hacked a fix... your mileage may vary. Use at your own risk. Not responsible for damage. ect. 
First; I use M-Shell by @Peter Suh. I went into the loader

and added the module

cd ~/redpill-load
./ext_manager.sh add https://raw.githubusercontent.com/pocopico/rp-ext/master/redpill-acpid/rpext-index.json

No idea if this is necessary, correct,  or required. 

Rebuild the loader and reboot into Xpenology.

This didn't work out of the box for me after several boots on the DVA3221 under 7.2.1-69057 update 4 and Proxmox 8.2.4 so I assume the extension doesn't work of the DVA3221 or the later version of DSM. 

I booted into Xpenology nas and logged in as a user with command line permissions. You can either use 

sudo qm terminal <VMID>

or a terminal connected appropriately. You WILL need root access thru either sudo or equivalent. All of the commands are done as root on the Xpenology commandline. I usually sudo bash to get a shell with root access. 

 

First verify that you have the button.ko module installed in 

ls /lib/modules/button.ko

If present; make sure the module is NOT loaded by doing:

lsmod | grep -i button

you should get no return. If you see something returned stop - this post likely won't help you.

 

Test and verify you can install the module:

insmod /lib/modules/button.ko

Which should return something like this:

[  873.839485] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[  873.840609] ACPI: Power Button [PWRF]

If not stop here; not sure what to do next.

Confirm the module is still loaded by the previous command:

lsmod | grep -i button

which should now return something like this:

button                  5097  0

If so;

cd /etc/systemd/system/
touch button.service

cat << EOF >> button.service
[Unit]
Description=Load Button(acpi) module
Before=multi-user.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/sbin/insmod /lib/modules/button.ko

[Install]
WantedBy=acpid.service
EOF

rmmod /lib/modules/button.ko

The first two lines should be obvious.

The cat << EOF line creates the button.service file with the unit contents.

Basically; we are telling system.d that acpid.service needs button.service before the multi-user.target. The ExecStart line uses insmod to load the button.ko.

 

The last line rmmod command remove the previous loaded module we tested above. That line SHOULD NOT be in the unit file. Its executed after the button.service file is created and should return:

[ 1450.396725] Module [button] is removed.

Now it's time to test/start the systemd service:

systemctl start button.service

which should return lines similar to our test:

[ 1513.065819] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
[ 1513.066865] ACPI: Power Button [PWRF]

If it passes; then enable the service for all future boots:

systemctl enable button.service

 

At this point; you should be able to power off the virtual machine in Proxmox using the shutdown button in the web interface:

 

If you are connected via the serial terminal; you'll see the system start the shutdown and the VM will eventually power off in Proxmox.

 

Power back up the virtual machine. wait for boot and reconnect your terminal. 

Once you have a login; proceed to log in as user then as root like we did above.

Verify that button.service loaded automatically by looking at

dmesg | grep -i button

which you should see something like this:
 

[  120.186709] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[  120.187636] ACPI: Power Button [PWRF]

next: verify the service ran:

$ systemctl status button.service
â— button.service - Load Button(acpi) module
   Loaded: loaded (/etc/systemd/system/button.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Tue 2024-07-30 21:16:14 CDT; 1min 14s ago
 Main PID: 13046 (code=exited, status=0/SUCCESS)

 

Finally; Confirm that acpid.service loaded properly on this boot:

$ systemctl status acpid.service
â— acpid.service - ACPI Daemon
   Loaded: loaded (/usr/lib/systemd/system/acpid.service; static; vendor preset: disabled)
   Active: active (running) since Tue 2024-07-30 21:16:32 CDT; 2min 21s ago
 Main PID: 23028 (acpid)
   CGroup: /system.slice/acpid.service
           └─23028 /usr/sbin/acpid -f

 

At this point; you can test again with the shutdown button to confirm everything is working properly.

Hope this helps someone!

 

Edited July 31 by Zitt

[zhuugo]

i got the same error event if i created more space on the usbkey with gparted.

 

tc@box:~$ df -h /mnt/*
Filesystem      Size  Used Avail Use% Mounted on
/dev/sde1        48M   13M   36M  26% /mnt/sde1
/dev/sde2        75M     0   75M   0% /mnt/sde2
/dev/sde3        15G  696M   14G   5% /mnt/sde3
 

 

It come from  the code in  ./rploader.sh
 

if [ $(df -h /${local_cache} | grep mnt | awk '{print $4}' | sed -e 's/M//g' -e 's/G//g' | cut -c 1-3) -le 370 ]; then
echo "No adequate space on ${local_cache} to download file into cache folder, clean up the space and restart"
exit 99
 

I had 14G free but it still did not work  because "df -h //mnt/sde3/auxfiles | grep mnt | awk '{print $4}' |sed -e s/M//g -e s/G//g | cut -c 1-3" = 14 and that is smaller then 370.

 

Maybe someone can fix that   to bypass if like me yours usbkey is resize the you can use "|| true" or multiply the result by 1024

 

 

[zhuugo]

I just ran into same error with the ./rploader.sh backuploader

 

same probleme , and same bypass
 

[foxbat]

Hello,

Thank you for your work!

 

Any news for 7.2.2-72803 update?

 

 

[foxbat]

After update (1.0.4.2) it's working. Thank you!

 

[Captainfingerbang]

I purchased this:

StarTech.com 1-Port USB 3.2 Gen 2x2 (20Gbps) PCIe Card - USB-C SuperSpeed PCI Express 3.0 x4 Host Controller Card - USB Type-C PCIe Add-On Adapter Card - Expansion Card - Windows & Linux (PEXUSB321C)

 

It is based on ASMedia ASM3242, and i purchased it because someone around here or another place told me that ARC Loader/DSM will support this.

 

I'm using ARC loader because of the "ARC PATCH" mainly...

Does anyone know if latest ARC LOADER supports USB - 3.2 Gen 2x2 (20gbps) AKA ASMedia ASM3242 on 7.2.1 or 7.2.2? 

 

 

 

 

 

 

P.S. 

Hardware - I have 2 Xpen boxes but the one this is for is X570 Taichi + 5900x using Sa6400 model -32gb ddr4

[Cornelius_drebbel]

del

Edited September 29 by Cornelius_drebbel

[hansel]

Just updated TCRP to 0.10.0.0 and wanted to upgrade my HP Microserver from DSM 7.1.x to DSM 7.2.x

I could not choose to build to 7.2.2 from TCRP WEBUI so I choose highest available , 7.2.1-69057. 

 

Build was successful. 

Then after rebooting it asked to update DSM and I accidentally choose the newest, 7.2.2-72806.

 

 

Now after upgrading it keeps asking to recover my disks. Over and over again...

Now what? How can I downgrade to corresponding 7.2.1-xxx pat file?

Edited Friday at 05:24 PM by hansel

[Peter Suh]

21 hours ago, hansel said:

Just updated TCRP to 0.10.0.0 and wanted to upgrade my HP Microserver from DSM 7.1.x to DSM 7.2.x

I could not choose to build to 7.2.2 from TCRP WEBUI so I choose highest available , 7.2.1-69057. 

 

Build was successful. 

Then after rebooting it asked to update DSM and I accidentally choose the newest, 7.2.2-72806.

 

 

Now after upgrading it keeps asking to recover my disks. Over and over again...

Now what? How can I downgrade to corresponding 7.2.1-xxx pat file?

 

Switch to my tcrp-mshell , there is a link to the latest version on my profile.

 

It is a loader that supports 7.2.2 without any problems and is a successor to pocopico's TCRP.

[hansel]

That worked! 7.2.2-72806 is running on all disks. Thank you for that note @Peter Suh

When my machine rebooted after installation I saw a "postupdate.." in the grub menu. Do I need to run it?

[Peter Suh]

6 hours ago, hansel said:

That worked! 7.2.2-72806 is running on all disks. Thank you for that note @Peter Suh

When my machine rebooted after installation I saw a "postupdate.." in the grub menu. Do I need to run it?

 

The situation where postupdate is needed should not normally occur in mshell.

 

Your situation is a bit special because it is a recovery loop, so you may need to look into it carefully.

 

In a recovery loop, you need postupdate, but

 

I have not verified that postupdate works for 7.2.1 -> 7.2.2 update errors.

 

Are you still experiencing recovery loops?