shibby Posted January 13 #1501 Posted January 13 i can confirm that SA6400 in USB Mode under Proxmox works flawlessly. 1 Quote
zelezaka Posted January 14 #1502 Posted January 14 On 1/13/2025 at 2:43 AM, Peter Suh said: Your attached logs indicate that a kernel panic is occurring. Be careful when using SA6400 as a bootloader. All three loaders, ARC/RR/MSHELL, share jim3ma's lkm, so you'll get similar results no matter which loader you use. The recommended loader type for SA6400 is USB, not SATA. This is the method that jim3ma recommended from the beginning. In SATA type, the boot of the loader is random. Sometimes it works and sometimes it causes KP. So you have to change it to USB type instead of SATA type bootloader that can be easily uploaded on Proxmox. vi /etc/pve/qemu-server/100.conf args: -drive 'if=none,id=synoboot,format=raw,file=/var/lib/vz/template/iso/tinycore-redpill.v1.1.0.1.m-shell.img' -device 'qemu-xhci,addr=0x18' -device 'usb-storage,drive=synoboot,bootindex=5' You don't need to specify anything for the boot sequence. Please change it from SATA type to USB type like this. SA6400 VM works, finally with hw transcoding on iGPU of n305, thank you once again. 1 Quote
Alexey Koznov Posted January 22 #1503 Posted January 22 Good day everyone! @Peter Suh thanks for your great work with tinycore-redpill project! I'm currently buildling an updated version of NAS using AMD 9-Bay NAS Ryzen 7 8845HS based Motherboard and cannot do proper mapping of drives inside XPEnology. This motherboard has 2xSFF-8643 ports (1-4 and 5-8 SATA ports) and separate SATA port. When I connected 6x3.5 sata drives with cables 1-4 and 5-6 using SFF-8643 to SATA cable in mapping of loader it shows this picture: Automatic sata_remap creates this configuration: Here is mapping of Drive in DSM with SFF cable and Sata port cable (in red wrong mapping): In DSM mapping looks like this: With that I've got couple questions: 1. Is there any way to change mapping from 33-36 to 5-8? I've tried to do mapping with options: sata_remap=0\\>32:1\\>33:2\\>34:3\\>35:32\\>4:33\\>5:34\\>6:35\\>7 But that doesn't change anything. 2. It is possible to disable auto-change of NICs? When builder loads it shows interface in order - 4 NIC 2.5GB + 2 NIC Mellanox ConnectX-4: eth0 (igc) A8:B8:E0:06:95:FD eth1 (igc) A8:B8:E0:06:95:FE eth2 (igc) A8:B8:E0:06:95:FF eth3 (igc) A8:B8:E0:06:96:00 eth4 (mlx5_core) B8:83:03:A1:DE:C0 eth5 (mlx5_core) B8:83:03:A1:DE:C1 After loader downloads files it start remapping to this order: 3. Can we add drivers for Mellanox ConnectX-6 cards inside system? I have some ConnectX-6 cards with 100G interfaces and planned to do some testing with big fast cache drives. 4. After loading to DSM it is showing only 4x2.5 gigabit ports, but not 2 additional Mellanox card 25G interfaces. Where should I look to fix the issue with showing all 6 nic ports? Quote
Alexey Koznov Posted January 22 #1504 Posted January 22 2 hours ago, Alexey Koznov said: Good day everyone! @Peter Suh thanks for your great work with tinycore-redpill project! I'm currently buildling an updated version of NAS using AMD 9-Bay NAS Ryzen 7 8845HS based Motherboard and cannot do proper mapping of drives inside XPEnology. This motherboard has 2xSFF-8643 ports (1-4 and 5-8 SATA ports) and separate SATA port. When I connected 6x3.5 sata drives with cables 1-4 and 5-6 using SFF-8643 to SATA cable in mapping of loader it shows this picture: Automatic sata_remap creates this configuration: Here is mapping of Drive in DSM with SFF cable and Sata port cable (in red wrong mapping): In DSM mapping looks like this: With that I've got couple questions: 1. Is there any way to change mapping from 33-36 to 5-8? I've tried to do mapping with options: sata_remap=0\\>32:1\\>33:2\\>34:3\\>35:32\\>4:33\\>5:34\\>6:35\\>7 But that doesn't change anything. 2. It is possible to disable auto-change of NICs? When builder loads it shows interface in order - 4 NIC 2.5GB + 2 NIC Mellanox ConnectX-4: eth0 (igc) A8:B8:E0:06:95:FD eth1 (igc) A8:B8:E0:06:95:FE eth2 (igc) A8:B8:E0:06:95:FF eth3 (igc) A8:B8:E0:06:96:00 eth4 (mlx5_core) B8:83:03:A1:DE:C0 eth5 (mlx5_core) B8:83:03:A1:DE:C1 After loader downloads files it start remapping to this order: 3. Can we add drivers for Mellanox ConnectX-6 cards inside system? I have some ConnectX-6 cards with 100G interfaces and planned to do some testing with big fast cache drives. 4. After loading to DSM it is showing only 4x2.5 gigabit ports, but not 2 additional Mellanox card 25G interfaces. Where should I look to fix the issue with showing all 6 nic ports? Okay, I've reinstalled system using DS1621xs+ package and adapted config with removing sata_remap and enabled SataPortMap to "52" and DiskIdxMap to "0000" (thanks https://github.com/PeterSuh-Q3/tinycore-redpill/issues/78 case). Now it shows everything in needed order (I've disconnected 2x2.5 drives): and NICs are detected as well: 1 Quote
gericb Posted January 23 #1505 Posted January 23 (edited) On 1/6/2025 at 7:06 PM, Peter Suh said: You need to select the contents of /dev/md0 and blow it away. Below is a /dev/md0 clean script from RR. It is designed to clean up only the updates and installations. You can save a little bit of space, such as reinstalling DSM. After cleaning up, I only took up about 1.4G. sudo -i mkdir -p /mnt/md0 mount /dev/md0 /mnt/md0/ rm -rf /mnt/md0/@autoupdate/* rm -rf /mnt/md0/upd@te/* rm -rf /mnt/md0/.log.junior/* umount /mnt/md0/ rm -rf /mnt/md0/ @Peter Suh So is this something we either can have as a menu option, or automatically somewhere along the way, as I gather you're saying it does in RR? It's been a while since I did it. but I feel I cleaned out more than just this, back when I initially after all this time, had this problem, in order to reclaim enough space for the current DSM build to install. Thanks Edited January 23 by gericb Quote
Peter Suh Posted January 24 Author #1506 Posted January 24 1 hour ago, gericb said: @Peter Suh So is this something we either can have as a menu option, or automatically somewhere along the way, as I gather you're saying it does in RR? It's been a while since I did it. but I feel I cleaned out more than just this, back when I initially after all this time, had this problem, in order to reclaim enough space for the current DSM build to install. Thanks There are already many users who actually tried this method and solved it. Please judge after actually applying it. This script is not implemented as a feature of MSHELL. This is a command that can be processed after logging in by connecting to port TTYD 7681 (root account, no password) in a web browser. Quote
gericb Posted January 24 #1507 Posted January 24 14 hours ago, Peter Suh said: There are already many users who actually tried this method and solved it. Please judge after actually applying it. This script is not implemented as a feature of MSHELL. This is a command that can be processed after logging in by connecting to port TTYD 7681 (root account, no password) in a web browser. Oh I have already long ago resolved the issue when I had it, after some initial fumbling through it all, the problem was solved and I was able to upgrade. I was just suggesting maybe a possible way to make it a proactive process somewhere along the way in building the loader or feature in MSHELL, etc. Your previous comment had me thinking that in the RR loader, something like this was already implemented. I don't have an issue doing it manually, but for those of us with the smaller ~2GB system volume, it's a ticking bomb waiting to go off eventually somewhere in the future, time and time again as things slowly fill up. Since doing a backup and restore just to rebuild DSM starting with 7.x isn't a desirable/viable option, this functionality would help keep things running smoothly. Anyway, figured I'd just inquire. Thanks for your reply. 😉 Quote
Peter Suh Posted January 24 Author #1508 Posted January 24 37 minutes ago, gericb said: Oh I have already long ago resolved the issue when I had it, after some initial fumbling through it all, the problem was solved and I was able to upgrade. I was just suggesting maybe a possible way to make it a proactive process somewhere along the way in building the loader or feature in MSHELL, etc. Your previous comment had me thinking that in the RR loader, something like this was already implemented. I don't have an issue doing it manually, but for those of us with the smaller ~2GB system volume, it's a ticking bomb waiting to go off eventually somewhere in the future, time and time again as things slowly fill up. Since doing a backup and restore just to rebuild DSM starting with 7.x isn't a desirable/viable option, this functionality would help keep things running smoothly. Anyway, figured I'd just inquire. Thanks for your reply. 😉 It would have been nice if you had suggested from the beginning that this feature should be implemented in mshell as well. ^^ I'll look into implementing a feature similar to RR. Thanks for the suggestion. 1 Quote
Peter Suh Posted January 24 Author #1509 Posted January 24 1 hour ago, gericb said: Oh I have already long ago resolved the issue when I had it, after some initial fumbling through it all, the problem was solved and I was able to upgrade. I was just suggesting maybe a possible way to make it a proactive process somewhere along the way in building the loader or feature in MSHELL, etc. Your previous comment had me thinking that in the RR loader, something like this was already implemented. I don't have an issue doing it manually, but for those of us with the smaller ~2GB system volume, it's a ticking bomb waiting to go off eventually somewhere in the future, time and time again as things slowly fill up. Since doing a backup and restore just to rebuild DSM starting with 7.x isn't a desirable/viable option, this functionality would help keep things running smoothly. Anyway, figured I'd just inquire. Thanks for your reply. 😉 Sorry, I didn't notify you even though I applied it 4 months ago. https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/misc/releases/install_rd.sh The function test result is normal. Likewise, you need to log in to TTYD as root and process it. 1 Quote
gericb Posted January 24 #1510 Posted January 24 6 hours ago, Peter Suh said: It would have been nice if you had suggested from the beginning that this feature should be implemented in mshell as well. ^^ I'll look into implementing a feature similar to RR. Thanks for the suggestion. Hehe, didn't want to seem pushy or anything. You already have so much you are working on to always make your Friend/MSHELL so functional, reliable, feature rich...but YES, that would be awesome if you could work your magic and craft a similar feature. 🙇♂️ 1 Quote
mgrobins Posted January 26 #1511 Posted January 26 Hi Peter - congrats on making MShell such a successful tool. I recall when you were first developing it working with you to enhance some aspects by troubleshooting and it (and you) helped me enormously. I'm now building a new server. My existing one I was never able to get the ports and drives recognised fully. It was always lacking some sata or HBA port drives. I went back to HBA only but that limited my total number of drives. I'm now looking at things again and I have a 9305-16i this time which means I need to be able to map more drives than syno products ship with again. 2 questions: 1. How is the port mapping done now and is it working reliably on common hardware for combining sata and HBA? 2. MShell is over top of TRP. What is your view of TRP for allowing updates to DSM and full functionality? MShell helps me get it all going, but i'm unsure if long term I will be stuck having to risk data updating DSM (like a year or 2 years from now). I'm not liking my other options though like TrueNAS... DSM is so easy in comparison. Quote
Peter Suh Posted January 27 Author #1512 Posted January 27 2 hours ago, mgrobins said: Hi Peter - congrats on making MShell such a successful tool. I recall when you were first developing it working with you to enhance some aspects by troubleshooting and it (and you) helped me enormously. I'm now building a new server. My existing one I was never able to get the ports and drives recognised fully. It was always lacking some sata or HBA port drives. I went back to HBA only but that limited my total number of drives. I'm now looking at things again and I have a 9305-16i this time which means I need to be able to map more drives than syno products ship with again. 2 questions: 1. How is the port mapping done now and is it working reliably on common hardware for combining sata and HBA? 2. MShell is over top of TRP. What is your view of TRP for allowing updates to DSM and full functionality? MShell helps me get it all going, but i'm unsure if long term I will be stuck having to risk data updating DSM (like a year or 2 years from now). I'm not liking my other options though like TrueNAS... DSM is so easy in comparison. 1. I think the most advantageous model for port mapping is SA6400 of Epyc7002 using Kernel 5. It supports the most advanced method of flexibly mapping SATA ports and HBA ports through Device-Tree method. I know that this compatibility gets better as the kernel version gets higher, but most of Synology's models are Kernel 4 or Kernel 3, and only SA6400 is based on Kernel 5. I am currently using all XPEs converted to SA6400. Recently, it has been confirmed that transcoding is not a problem on all CPUs after Intel 4th generation. However, there has not been much feedback from users about the MPT3SAS module mainly used by HBA. Since there is almost no feedback, I can only guess that it is being used well without any issues. 2. Since mshell is a successor to pocopico's TCRP, there are some more advanced parts. mshell implements a feature that TCRP does not have, which is the autorecover addon. https://github.com/PeterSuh-Q3/tcrp-addons/tree/main/autorecover If TCRP adopts this addon, it will be the same as mshell, but it seems that pocopico has no plans to do so. This is because he has stopped developing it. The main function of this addon is to cover the part where the Jot mode, like TCRP, does not have the ability to skip changes between smallfix versions in Jun mode. When the DSM version was updated to Update 0 and smallfixes were performed, TCRP has been manually processing postupdate to handle this. You can think of this as automating this postupdate. All of the bootloaders RR/ARC/MSHELL developed so far must release a version that has been redeveloped to respond to changes in major versions other than smallfixes. I don't know if the next version will be DSM 7.2.3 or DSM 7.3. When a new major version is announced by Sirology, our three developers have been releasing a new version within a few days. I understand why users are anxious. Up until now, XPE developers have been MIA without notice. In fact, the Jun loader that supported DSM 6 was like that for a long time. I think the TTG group that led the REDPILL project is also MIA. We three developers will make sure that they won't be MIA, but I can't guarantee it. However, there is a big difference between the Jun loader and REDPILL. The Jun loader was not like that, but the REDPILL project is open source on GitHub. The advantage is that anyone can become a new developer with a new loader. ARPL's fabio and TCRP's pocopico also stepped down from loader development due to busy work, but I think they were able to leave lightly because they knew the advantages of open source. 1 Quote
mgrobins Posted January 27 #1513 Posted January 27 Thank you, that gives me a lot more confidence. I admit I have had years of not updating a NAS in my home environment but that was when I had no desire to do more than store information locally accessed. An interest in external access, and more apps or VM based activity on the NAS = more security risk and need for bug fixes etc. I'm interested in using my new build to manage cameras I will have installed at my property and the ability of Surveillance Centre to function or have licence expansion with Xpenology is going to be a key part of that. Alternate for me is that I put security into another small device that i hide somewhere in the house lol. Then my server in server room (Which is not in basement or somewhere hidable) can simply be for work, media etc. I'll likely run up the DSM on my server just to know it can work. RR is new to me and your MSHell incorporating TCRP to continue its growth also was an unknown. Jun popico was barely present when I last chatted with you. I've not done linux scripting or real coding for many years and am not skilled enough to assist else I would be delighted to take this on alongside yourself and other devs to continue the evolution of the xpenology fork from DSM. 1 Quote
Nailor Posted January 27 #1514 Posted January 27 Greetings @Peter Suh! I am very pleased to use your loader for my servers. These are four identical HP Microserver N34L machines. For some reason, your loader is the only one, out of many I’ve tried, that allows setting the model to DS1522+ (which uses an AMD processor family). This, in turn, enables successful virtualization on these servers. Other loaders freeze during the boot process when attempting to set this model. However, I have encountered an issue that has become a hindrance. Until recently, all four servers were running the TCRP JOD 1.1.0.0 version of the loader (using a USB flash drive as the boot medium). I needed to change the MAC address of one of the servers, which led me to access the loader to rebuild it. During the process of booting into TinyCoreLinux, the loader was automatically updated. It updated to TCRP JOD 1.1.0.1. After booting with the updated loader, the disk numbering changed—what was previously disk number 5 is now disk number 6. Additionally, in the DSM interface where disks are displayed, one disk is now missing (only five disks are shown). I tried using your Sata Remap tool. I tried setting values in SataPortMap. I also tried entering values in DiskIdxMap. I experimented with several combinations, but nothing seems to change. The sata_remap tool shows: 0\\>0:1\\>1:2\\>2:3\\>3:5\\>4. However, this does not resolve the issue. I have two questions: Is it possible to disable automatic updates when booting into TinyCoreLinux? (I don’t always remember the actual MAC address, so I cannot always block internet access for the device.) Is it possible to downgrade to version 1.1.0.0 directly from TinyCoreLinux? I don’t have physical access to the server and cannot remove the USB flash drive, but I can remotely access it via the Remote Access Card. Quote
Peter Suh Posted January 30 Author #1515 Posted January 30 On 1/27/2025 at 10:50 PM, Nailor said: Greetings @Peter Suh! I am very pleased to use your loader for my servers. These are four identical HP Microserver N34L machines. For some reason, your loader is the only one, out of many I’ve tried, that allows setting the model to DS1522+ (which uses an AMD processor family). This, in turn, enables successful virtualization on these servers. Other loaders freeze during the boot process when attempting to set this model. However, I have encountered an issue that has become a hindrance. Until recently, all four servers were running the TCRP JOD 1.1.0.0 version of the loader (using a USB flash drive as the boot medium). I needed to change the MAC address of one of the servers, which led me to access the loader to rebuild it. During the process of booting into TinyCoreLinux, the loader was automatically updated. It updated to TCRP JOD 1.1.0.1. After booting with the updated loader, the disk numbering changed—what was previously disk number 5 is now disk number 6. Additionally, in the DSM interface where disks are displayed, one disk is now missing (only five disks are shown). I tried using your Sata Remap tool. I tried setting values in SataPortMap. I also tried entering values in DiskIdxMap. I experimented with several combinations, but nothing seems to change. The sata_remap tool shows: 0\\>0:1\\>1:2\\>2:3\\>3:5\\>4. However, this does not resolve the issue. I have two questions: Is it possible to disable automatic updates when booting into TinyCoreLinux? (I don’t always remember the actual MAC address, so I cannot always block internet access for the device.) Is it possible to downgrade to version 1.1.0.0 directly from TinyCoreLinux? I don’t have physical access to the server and cannot remove the USB flash drive, but I can remotely access it via the Remote Access Card. About 3 weeks ago, I modified mshell's disks addon by referring to rr's disks addon. Coincidentally, the time when mshell's version changed from 1.1.0.0 to 1.1.0.1 is the same, but the change in the mshell main script version and the change in the disks addon are not related. The reason your disks disappeared seems to be because this disks addon contained a bug when it was modified. I also had a risk of losing one of my main disks when I migrated to SA6400 (epyc7002) that uses Device-Tree like DS1522+ (r1000). It seems that there was instability in the modification made 3 weeks ago, so I restored most of the situation from 3 weeks ago. https://github.com/PeterSuh-Q3/tcrp-addons/commits/main/disks/releases/install.sh The mshell version was updated to 1.2.0.0 yesterday, so you don't have to worry about it. The disks addon does not have separate version control, but the final version has been rolled back to the stable version from 3 weeks ago, so please rebuild only the loader. 1 Quote
Nailor Posted January 31 #1516 Posted January 31 В 30.01.2025 в 14:32, Peter Suh сказал: The mshell version was updated to 1.2.0.0 yesterday, so you don't have to worry about it. The disks addon does not have separate version control, but the final version has been rolled back to the stable version from 3 weeks ago, so please rebuild only the loader. Ok, so I updated the bootloader and rebuilt it. Now DSM won't boot at all. I see this picture, the cursor is blinking, but the machine does not request an IP address. Quote
Peter Suh Posted February 1 Author #1517 Posted February 1 5 hours ago, Nailor said: Ok, so I updated the bootloader and rebuilt it. Now DSM won't boot at all. I see this picture, the cursor is blinking, but the machine does not request an IP address. I thought you were using baremetal, but it's a VM? Is there a reason you need JOT mode if you're using a VM? Is the KVM server installed directly on the N34L? Quote
Peter Suh Posted February 1 Author #1518 Posted February 1 5 hours ago, Nailor said: Ok, so I updated the bootloader and rebuilt it. Now DSM won't boot at all. I see this picture, the cursor is blinking, but the machine does not request an IP address. I tested it by building it under the same conditions as you. The VM environment is not KVM, but VMWARE FUSION for MacOS. It seems that there is a problem with the newly built 25.1.28 version of lkm. As you can see, I think we need to find out why Kernel Panic occurs. Usually, kp is closely related to lkm. And in your case, I understand that you are not directly operating a KVM server, but are simply using KVM to connect to bare metal. (In fact, I have never used KVM.) I will infer that it is bare metal since the machine type is displayed as "Physical" in the mshell monitor window. Then, FRIEND mode cannot be used and JOT should be maintained. I will analyze the cause of the KP error and get back to you. Quote
Peter Suh Posted February 1 Author #1519 Posted February 1 6 hours ago, Nailor said: Ok, so I updated the bootloader and rebuilt it. Now DSM won't boot at all. I see this picture, the cursor is blinking, but the machine does not request an IP address. I think I found the cause. The module signature is missing from the command line. You can also see that this part is written abnormally in the GRUB boot menu. It should be DS1522+ instead of r1000. I will release a bug-fixed v1.2.0.0 version soon. Quote
Peter Suh Posted February 1 Author #1520 Posted February 1 7 hours ago, Nailor said: Ok, so I updated the bootloader and rebuilt it. Now DSM won't boot at all. I see this picture, the cursor is blinking, but the machine does not request an IP address. Jot's bootentry issue has been resolved. Please try rebuilding the loader. Quote
Nailor Posted February 1 #1521 Posted February 1 (edited) 9 часов назад, Peter Suh сказал: I thought you were using baremetal, but it's a VM? Is there a reason you need JOT mode if you're using a VM? Is the KVM server installed directly on the N34L? No, it is barmetal N34L installation. This is what the remote access window to the server looks like. For some reason, the developers of HP named this window that way. But this is a server monitor, not a virtual machine. 6 часов назад, Peter Suh сказал: Jot's bootentry issue has been resolved. Please try rebuilding the loader. So I updated the bootloader and rebuilt it. Now DSM works correctly. Disks are named in the correct order. 8 часов назад, Peter Suh сказал: I think I found the cause. The module signature is missing from the command line. You can also see that this part is written abnormally in the GRUB boot menu. It should be DS1522+ instead of r1000. I will release a bug-fixed v1.2.0.0 version soon. You really found a solution and did it very quickly! Thank you so much! The server was down for only one night. ) But perhaps the best solution would be to have the ability to roll back to an earlier version of the bootloader in TinyCoreLinux? After all, if I have rebuilt the bootloader, I have no way to return to a working state except by removing the flash drive, writing the old version of the bootloader, and then rebuilding the bootloader without allowing it to access the internet. And if I absolutely need to get the server running, I will have to use this exact method. At the same time, a backup is made every time the bootloader is rebuilt, but it's unclear how to use it. I am also surprised that you mention the FRIEND and JOT modes—I don't have the option to choose them myself. When building the bootloader, it selects them automatically, and I haven't seen any option to choose them. It surprises me that you mention this, as for me, it's just a default option that is set without my knowledge. Once again, thank you! Edited February 1 by Nailor 1 Quote
Peter Suh Posted February 1 Author #1522 Posted February 1 52 minutes ago, Nailor said: You really found a solution and did it very quickly! Thank you so much! The server was down for only one night. ) But perhaps the best solution would be to have the ability to roll back to an earlier version of the bootloader in TinyCoreLinux? After all, if I have rebuilt the bootloader, I have no way to return to a working state except by removing the flash drive, writing the old version of the bootloader, and then rebuilding the bootloader without allowing it to access the internet. And if I absolutely need to get the server running, I will have to use this exact method. At the same time, a backup is made every time the bootloader is rebuilt, but it's unclear how to use it. I am also surprised that you mention the FRIEND and JOT modes—I don't have the option to choose them myself. When building the bootloader, it selects them automatically, and I haven't seen any option to choose them. It surprises me that you mention this, as for me, it's just a default option that is set without my knowledge. Here's what I said a while ago about my stance on how to manage mshell's versions. In reality, it's hard to do this, and I'm a bit skeptical about whether it's worth the effort to build it. Quote
Trabalhador Anonimo Posted February 1 #1523 Posted February 1 Hi there, What I do when I need to change the boot loader is to keep the old flash drive (who is running perfect) for a few days. If there is a problem, go back to old one. I always have 2 usb drivers: the one who is running and the one to rebuild the loader. Quote
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.