Peter Suh Posted October 1 Author Share #1376 Posted October 1 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 Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 1 Author Share #1377 Posted October 1 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. 1 Quote Link to comment Share on other sites More sharing options...
ReadyAS Posted October 3 Share #1378 Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 3 Author Share #1379 Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
ReadyAS Posted October 3 Share #1380 Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
Trabalhador Anonimo Posted October 4 Share #1381 Posted October 4 Use Advanced IP scanner to verify your network. 1 1 Quote Link to comment Share on other sites More sharing options...
ReadyAS Posted October 4 Share #1382 Posted October 4 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 4 Author Share #1383 Posted October 4 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. Quote Link to comment Share on other sites More sharing options...
ReadyAS Posted October 5 Share #1384 Posted October 5 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. Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted October 6 Author Share #1385 Posted October 6 (edited) 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 Quote Link to comment Share on other sites More sharing options...
ReadyAS Posted October 7 Share #1386 Posted October 7 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. 2 Quote Link to comment Share on other sites More sharing options...
gericb Posted October 7 Share #1387 Posted October 7 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 1 Quote Link to comment Share on other sites More sharing options...
shibby Posted October 10 Share #1388 Posted October 10 i tought is not possible to passtrough Onboard Intel Sata Controller to VM with Xpenology but... It works flawlessly And result 1 Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted Wednesday at 03:04 PM Author Share #1389 Posted Wednesday at 03:04 PM (edited) [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 Wednesday at 03:07 PM by Peter Suh 1 Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted Thursday at 04:07 AM Author Share #1390 Posted Thursday at 04:07 AM 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. 2 1 Quote Link to comment Share on other sites More sharing options...
fishton Posted Friday at 01:02 PM Share #1391 Posted Friday at 01:02 PM 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 Quote Link to comment Share on other sites More sharing options...
Trabalhador Anonimo Posted Friday at 05:41 PM Share #1392 Posted Friday at 05:41 PM 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. Quote Link to comment Share on other sites More sharing options...
Trabalhador Anonimo Posted Friday at 08:24 PM Share #1393 Posted Friday at 08:24 PM (edited) 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 Friday at 08:27 PM by Trabalhador Anonimo Quote Link to comment Share on other sites More sharing options...
midiman007 Posted Friday at 08:27 PM Share #1394 Posted Friday at 08:27 PM @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. Quote Link to comment Share on other sites More sharing options...
Trabalhador Anonimo Posted Friday at 10:44 PM Share #1395 Posted Friday at 10:44 PM As Realtek is not working, I got one USB 3 to RJ45 to replace for a while. Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted yesterday at 12:12 AM Author Share #1396 Posted yesterday at 12:12 AM 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. Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted yesterday at 12:23 AM Author Share #1397 Posted yesterday at 12:23 AM 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? Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted yesterday at 12:26 AM Author Share #1398 Posted yesterday at 12:26 AM 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? Quote Link to comment Share on other sites More sharing options...
Trabalhador Anonimo Posted yesterday at 12:54 AM Share #1399 Posted yesterday at 12:54 AM 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? Quote Link to comment Share on other sites More sharing options...
Peter Suh Posted yesterday at 01:01 AM Author Share #1400 Posted yesterday at 01:01 AM (edited) 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 yesterday at 01:02 AM by Peter Suh Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.