TinyCore RedPill Loader Build Support Tool ( M-Shell )

[Peter Suh]

1 hour ago, 007revad said:

Does /tmpRoot/etc.defaults/synoinfo.conf get recreated at each boot?

 

If yes, does it then get copied to /etc.defaults/synoinfo.conf ?

 

I haven't used echo 'drive_db_test_url="127.0.0.1"' >> /etc.defaults/synoinfo.conf since v2.2.45

 

synosetkeyvalue /etc.defaults/synoinfo.conf drive_db_test_url "127.0.0.1" should only create the key if it's missing.

 

For now, I've supplemented the script to check for existence as follows without discarding it.

 

grep -q '^drive_db_test_url=' /tmpRoot/etc.defaults/synoinfo.conf || echo 'drive_db_test_url="127.0.0.1"' >> /tmpRoot/etc.defaults/synoinfo.conf

 

[Peter Suh]

2 hours ago, 007revad said:

Does /tmpRoot/etc.defaults/synoinfo.conf get recreated at each boot?

 

If yes, does it then get copied to /etc.defaults/synoinfo.conf ?

 

I haven't used echo 'drive_db_test_url="127.0.0.1"' >> /etc.defaults/synoinfo.conf since v2.2.45

 

synosetkeyvalue /etc.defaults/synoinfo.conf drive_db_test_url "127.0.0.1" should only create the key if it's missing.

 

I removed the duplicates and rebooted 2 times.
I confirmed that only 1 is maintained as expected.
Thank you.

 

 

[ReadyAS]

Hi All, could you explain me please, why I have the network connection to the device just for about half a minute (during the starting of the system and some seconds after)?

After that there is not possible to ping or whatever.

[Peter Suh]

1 hour ago, ReadyAS said:

Hi All, could you explain me please, why I have the network connection to the device just for about half a minute (during the starting of the system and some seconds after)?

After that there is not possible to ping or whatever.

 

Do not 100% trust the IP address shown on this FRIEND kernel screen.

 

After 30 seconds, the IP address may change again for various reasons.

 

This screen may not track and display the changed IP address.

 

If you see two LEDs on the rear port of the NIC, it is recommended to double-check the reassigned address on the router.

[ReadyAS]

53 minutes ago, Peter Suh said:

 

Do not 100% trust the IP address shown on this FRIEND kernel screen.

 

After 30 seconds, the IP address may change again for various reasons.

 

This screen may not track and display the changed IP address.

 

If you see two LEDs on the rear port of the NIC, it is recommended to double-check the reassigned address on the router.

Two LEDs on the rear port of the NIC are blinking, but on the router I do no see any new device.

[Trabalhador Anonimo]

Use Advanced IP scanner to verify your network.

 

[ReadyAS]

20 hours ago, Trabalhador Anonimo said:

Use Advanced IP scanner to verify your network.

 

Thanks for the link to helpful tool, however I'm sure the connection is down some some/dozen seconds after finishing booting the system.

I have used ArcLoader and everything is correct now. I have loaded the same 7.2.2-72806 version of Synology Software (for model DS3622xs+).

Very strange.

Could somebody explain and help to solve the problem please?

Edited October 4 by ReadyAS

[Peter Suh]

3 hours ago, ReadyAS said:

Thanks for the link to helpful tool, however I'm sure the connection is down some some/dozen seconds after finishing booting the system.

I have used ArcLoader and everything is correct now. I have loaded the same 7.2.2-72806 version of Synology Software (for model DS3622xs+).

Very strange.

Could somebody explain and help to solve the problem please?

 

What are your hardware specs?

 

They should probably be listed on the top of the FRIEND console that you captured with your first question.

 

MSI MOBOs are known to have the worst compatibility.

[ReadyAS]

6 hours ago, Peter Suh said:

 

What are your hardware specs?

 

They should probably be listed on the top of the FRIEND console that you captured with your first question.

 

MSI MOBOs are known to have the worst compatibility.

[Peter Suh]

On 10/5/2024 at 3:14 PM, ReadyAS said:

 

I looked for success stories of Netgear ReadyNAS 628X and DSM7, but I don't think there are any yet.
This is the only trace of this inquiry.
https://xpenology.com/forum/topic/56934-converting-a-netgear-readynas-to-xpenology/?do=findComment&comment=439939

 

There is a story that DSM 6.2.3 is compatible,
but DSM 6.2.3 was a different loader before Redpill.
It is JUN loader, which is also the parent of Redpill.
The modules (drivers) of this loader included more modules than the current Redpill.

 

It may not be of much help, but
I would like to check your H/W compatibility using the lspci -tvnnq command. It is also possible on tinycore Linux where the menu is visible,

and you can use this command by stopping the loading with Ctrl+C within 7 seconds of the Friend Kernel booting.

Edited October 6 by Peter Suh

[ReadyAS]

20 hours ago, Peter Suh said:

 

I looked for success stories of Netgear ReadyNAS 628X and DSM7, but I don't think there are any yet.

[...]

Thank you for your answer @Peter Suh. I can not check the hardware now, but as I wrote before, the newest DSM7 (7.2.2-72806) works fine on that hardware (Readynas 628X) when I use the Arc Loader to load it. 

[gericb]

I might have died and gone to heaven, if there could be any possibility to run DSM on this device.  Probably not, but it would be way better than the janky ASUStor OS. 😍

 

https://www.jeffgeerling.com/blog/2023/first-look-asustors-new-12-bay-all-m2-nvme-ssd-nas

[shibby]

i tought is not possible to passtrough Onboard Intel Sata Controller to VM with Xpenology but... It works flawlessly

 

 

 

And result

 

[Peter Suh]

[NOTICE]

 

GitHub ACTION-COOL loader auto-build feature distribution (using issues)

 

I just found out today that

This feature has been used in RR for a long time.

I have improved the loader auto-build feature to make it easier to use.

(It's the same as RR.)

 

You must have a GitHub account.

https://github.com/

Create an account with Sign Up and then log in with Sign In.

 

https://github.com/PeterSuh-Q3/tinycore-redpill/issues

This is using the GitHub ACTION-COOL build bot.

 

 

The title of the issue is

custom DS920+

The content of the body is

{"model":"DS920+","version":"7.2.2-72806"}

 

You must write it in the form of a JSON body like this.

 

Change the model and version, but if the spelling is even slightly wrong, the build will not be done properly.

 

 

Save the issue

and go to the Action side, it will be displayed as an orange icon and the loader build will proceed.

 

If you want to see the details, you can click on the workflow in progress.

If the loader build is successful, the workflow will turn green.

If you select Summary,

the artifact results are saved in the form of a zip file at the very bottom.

 

 

In this zip, the img file and vmdk are recompressed together in tgz format.

Currently, the Mac address and serial are randomly generated,

 

but I will modify this part again and distribute it again so that it can receive input values.

 

The core content of this function is

Originally, you need to burn the official img of the TCRP-mshell loader to USB,

enter ./menu.sh, select the model, version, serial, MAC address, etc., and go through manual build to complete the loader,

 

but this function is a function that allows you to receive an already completed loader from GitHub, bake it, and use it.

Since the Grub boot menu is generated in the same way as when you manually build it,

you can also build the loader created in this way by entering the menu for manual build again.

Edited October 30 by Peter Suh

[Peter Suh]

13 hours ago, Peter Suh said:

[NOTICE]

 

GitHub ACTION-COOL loader auto-build feature distribution (using issues)

 

I just found out today that

This feature has been used in RR for a long time.

I have improved the loader auto-build feature to make it easier to use.

(It's the same as RR.)

 

You must have a GitHub account.

https://github.com/

Create an account with Sign Up and then log in with Sign In.

 

https://github.com/PeterSuh-Q3/tinycore-redpill/issues

This is using the GitHub ACTION-COOL build bot.

 

 

The title of the issue is

custom DS920+

The content of the body is

{"model":"DS920+","version":"7.2.2-72806"}

 

You must write it in the form of a JSON body like this.

 

Change the model and version, but if the spelling is even slightly wrong, the build will not be done properly.

 

 

Save the issue

and go to the Action side, it will be displayed as an orange icon and the loader build will proceed.

 

If you want to see the details, you can click on the workflow in progress.

If the loader build is successful, the workflow will turn green.

If you select Summary,

the artifact results are saved in the form of a zip file at the very bottom.

 

 

In this zip, the img file and vmdk are recompressed together in tgz format.

Currently, the Mac address and serial are randomly generated,

 

but I will modify this part again and distribute it again so that it can receive input values.

 

The core content of this function is

Originally, you need to burn the official img of the TCRP-mshell loader to USB,

enter ./menu.sh, select the model, version, serial, MAC address, etc., and go through manual build to complete the loader,

 

but this function is a function that allows you to receive an already completed loader from GitHub, bake it, and use it.

Since the Grub boot menu is generated in the same way as when you manually build it,

you can also build the loader created in this way by entering the menu for manual build again.

 

 

[Additional Notice]

 

If you have a separate serial & MAC address, please enter it in the following format. (Mac addresses are supported up to 4 mac4.)

 

{"model":"DS920+","version":"7.2.2-72806","mac1":"112233445566","mac2":"77889900aabb","sn":"1111222233333"}

 

If the MAC address and serial are omitted, they will be randomly generated.

[fishton]

Hi Peter

 

hope you are doing good.

 

I am currently running TinyCore with an image built in January 24 with DSM 7.2.1-69057 Update 5 running fine.

 

I am not too sure how should I upgrade to DSM 7.2.2. 

 

I restarted the NAS and found out that TinyCore friend was updated ... but I am afraid this is not sufficient to get a new bootloader for this DSM 7.2.2

 

is there any guidance somewhere I could follow not to break anything ?

 

should I do "Rebuild image" ? but from there I don't really know what to do

 

thanks for your help

[Trabalhador Anonimo]

On 10/3/2024 at 5:16 PM, ReadyAS said:

Hi All, could you explain me please, why I have the network connection to the device just for about half a minute (during the starting of the system and some seconds after)?

After that there is not possible to ping or whatever.

 

I had the same problem when go to last 7.2.2. My main NIC (on board) shutdown as soon as QR code shows up and never got back. Using RR i do not have this problem.

 

[Trabalhador Anonimo]

M-shell loader is not loading realtek NIC card on 7.2.2-72806 with m-shell 1.0.5.0. Is there an extra module to be load?

Edited November 1 by Trabalhador Anonimo

[midiman007]

@Peter Suh I just got a message from my box that Version: 7.2.2-72806 is available to update.

 

I am using your auto repill is it safe to do so. I do not want to hose the box.

[Trabalhador Anonimo]

As Realtek is not working, I got one USB 3 to RJ45 to replace for a while.

[Peter Suh]

11 hours ago, fishton said:

Hi Peter

 

hope you are doing good.

 

I am currently running TinyCore with an image built in January 24 with DSM 7.2.1-69057 Update 5 running fine.

 

I am not too sure how should I upgrade to DSM 7.2.2. 

 

I restarted the NAS and found out that TinyCore friend was updated ... but I am afraid this is not sufficient to get a new bootloader for this DSM 7.2.2

 

is there any guidance somewhere I could follow not to break anything ?

 

should I do "Rebuild image" ? but from there I don't really know what to do

 

thanks for your help

 

The TinyCore friend's updates are managed and operated independently from TCRP-mshell (Tinycore loader builder), so you don't have to worry about this part.

 

In the case of TCRP, unlike ARPL(rr), you must rebuild the loader when the micro of DSM changes from 7.2.1 to 7.2.2.

 

A micro means a situation where the third number of ${major}.${minor}.${micro} changes from micro 1 to 2, etc.

 

After rebuilding the mshell loader, DSM will request migration to version 7.2.2 at the next reboot.

 

At that time, just follow the request.

[Peter Suh]

3 hours ago, Trabalhador Anonimo said:

M-shell loader is not loading realtek NIC card on 7.2.2-72806 with m-shell 1.0.5.0. Is there an extra module to be load?

 

NIC of realtek chipset is too variable and too hard to stabilize.

I know that @wjz304 is working hard on this part for rr.

However, realtek chipset works sometimes and not sometimes in rr.

 

Recently, as per mshell user request, for SA6400 7.2 (epyc7002)

I used the integrated module (all nic chipset modules) of rr final version 24.10.1 about 3 weeks ago.

 

https://github.com/PeterSuh-Q3/tcrp-modules/blob/main/all-modules/releases/epyc7002-7.2-5.10.55.tgz

 

Would you like to test if the Realtek chipset works on the SA6400?

[Peter Suh]

3 hours ago, midiman007 said:

@Peter Suh I just got a message from my box that Version: 7.2.2-72806 is available to update.

 

I am using your auto repill is it safe to do so. I do not want to hose the box.

 

I am not a native English speaker. I don't understand your metaphorical expressions.

 

What does auto REDPILL mean?

[Trabalhador Anonimo]

29 minutes ago, Peter Suh said:

 

NIC of realtek chipset is too variable and too hard to stabilize.

I know that @wjz304 is working hard on this part for rr.

However, realtek chipset works sometimes and not sometimes in rr.

 

Recently, as per mshell user request, for SA6400 7.2 (epyc7002)

I used the integrated module (all nic chipset modules) of rr final version 24.10.1 about 3 weeks ago.

 

https://github.com/PeterSuh-Q3/tcrp-modules/blob/main/all-modules/releases/epyc7002-7.2-5.10.55.tgz

 

Would you like to test if the Realtek chipset works on the SA6400?

 

To do that I have to rebuild a loader? I only have this NICs on my working server. It is to risk, don´t you think?

[Peter Suh]

8 minutes ago, Trabalhador Anonimo said:

 

To do that I have to rebuild a loader? I only have this NICs on my working server. It is to risk, don´t you think?

 

I don't quite understand what you mean by risky,
but if this is the only server you have,
and you already have rr stabilized, then you wouldn't bother trying anything else.

Edited November 2 by Peter Suh