Jump to content
XPEnology Community

Peter Suh

Member
  • Posts

    2,638
  • Joined

  • Last visited

  • Days Won

    139

Everything posted by Peter Suh

  1. In a recovery action, essentially nothing happens. Does the recovery happen over and over again? If so, please upload the junior log like you did yesterday.
  2. Please check the parts that were problematic yesterday. Is the /root directory really full? And above all, back up your DSM settings separately. If full backup is not possible, at least perform a selective backup of only packages using hyperbackup. I make these backups every day on Google Drive. It can be used for recovery if the DSM of the system partition is initialized due to an unexpected accident. I think you should focus more on preparing in advance rather than upgrading.
  3. Although no work was done on the first volume disk, it is a little strange that the disk is not visible. Is the number of disks displayed as ll /sys/block in tinycore linux always 4? If you don't see 4, you may need to recheck the cable connection. The last method I would like to suggest is DS3622xs+ is going back to DSM 7.2.0-64570. Do you keep the original loader separately? If not, you can rebuild it. I think it would be a good idea to go back to the original version, 64570, correct the problems, and try upgrading again. If you rebuild the loader, recovery may be requested due to a smallfixversion mismatch, but this process is normal. It should only be requested once.
  4. Currently, only Junior is available, so there doesn't seem to be a way to clean up /root directly. I think you should follow the latter method by dividing the group into groups and trying to upgrade with only one volume. However, migration should be possible with only sata1. Never attempt NEW Install. Installed packages will be corrupted.
  5. There is no need to despair too much. Your data disk is still safe. Are there separate backups? This is a message I also experienced some time ago. This was a case where there were too many files in the /root path of the already installed DSM system partition. When updating DSM, use this /root path. You need to access the /root path of the system partition and organize its contents. Of your two volumes, which disk is /root located on? I think you need to try installing the two groups of volumes separately. The remaining groups will be automatically migrated even if they are equipped later. Would you like to try this method?
  6. Without proper mapping, the disk may disappear and become invisible, especially on Non Device-Tree based models such as DS3622xs+. However, since you can see all disks, I think your settings are fine. I know that rr is handled using a slightly different disk mapping method, but I don't know the details. I'm not sure exactly how rr can help since all disks are already well recognized.
  7. Assemble args: -u 0074c5b5:808d4c6e:3017a5a8:c86610be /dev/sda1 /dev/sdc1 /dev/sdd1 /dev/sde1 mdadm: /dev/md0 has been started with 3 drives (out of 12). Partition Version=8 Checking ext4 rootfs on /dev/md0 return value: 0 sdc, part of md0, has obsolete partition layout 8. Detected data partition on sda. Must not be fresh installation. ForceNewestLayout: Skipped Mounting /dev/md0 /tmpRoot I saw the log you provided. Are there only 4 discs in total? It is also strange that disk mdadm started on only 3 of the 12 disks. The sdc that is part of md0 has the deprecated partition layout 8. Data partition detected by SDA. Do not do a fresh install. It looks like the system partitions between disks are mixed up. If DS3622xs+ does not recognize all disks In order to recognize all disks, it would be a good idea to first complete the DSM version upgrade to the Device-Tree-based DS920+. After the system partition's mdadm is stabilized, it would not be a bad idea to change the model again and migrate.
  8. @wjz304 This motherboard uses dual IGC NIC, but the cable is not connected to the second NIC. It is reported that junior did not appear at all, Is this possible?
  9. My thoughts are a bit different. proxmox uses img directly as a loader, but creates it as a Sata disk as if using SATA dom. Here, TCRP's ATA mode operates. Synology's original bootloader is known to be SATA DOM, not USB. I am not directly involved in the TTG group, so I do not know the exact mechanism of redpill.ko. However, based on the results of analysis and experience so far, it seems that the part that activates this SATA DOM in redpill is still unstable. Rather, USB mode shows more stability as a result. I don't know if USB mode is also internally connected to SATA DOM emulation again. Currently, TTG members are not active. Is there anyone who can explain this part clearly?
  10. Junior is used for both new installations and migrations. Junior determines whether a new installation or migration is possible by comparing the DSM version installed on the disk system partition with the DSM version to be installed.
  11. I tried building the DS3622xs+ loader in SATA mode on my ESXI 7.0 Update 3 system. I expected a 10 second timeout from my boot-wait and automount addons, but that wasn't the case. The loader's three FAT partitions were successfully mounted on time. The log below is part of Junior's linuxrc.syno.log. Ran "boot-wait.sh" for thethorgroup.boot-wait->on_boot->modules - exit=0 :: Executing "on_boot" custom scripts ... [ OK ] ... :: Executing "on_patches" "patches" custom scripts ... Running "install.sh" for automount->on_patches->patches Found synoboot / synoboot1 / synoboot2 Ran "install.sh" for automount->on_patches->patches - exit=0 Running "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches Ran "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches - exit=0 :: Executing "on_patches" custom scripts ... [ OK ] The cause seems to lie elsewhere. Is it possible to access port 7681 through a web browser? This method is called a TTYD connection. Log in as root without a password. If connection to Junior is successful, can you send me the command log as below? cat /var/log/*rc*
  12. I'm sorry. I found the cause of the error and took action. Please try again.
  13. Are you by any chance building a loader on a VM like Proxmox? The Pat file corruption message is directly related to the failure to mount three partitions on the loader disk. This occurs especially frequently in SATA mode used by VMs. If it is Proxmox, there is also a way to convert it to USB mode instead of SATA mode. Please tell me exactly what your situation is.
  14. I was mistaken. A tgz file should have been used here, not a gz file. Only the sha256 content should not be changed. The tgz file must have been recompressed and uploaded with new content. The content has already been taken action. Please withdraw your Pull Request.
  15. I'm sorry. I found the cause of the error and took action. Please try again.
  16. Do not use the build command directly. The menu method below corresponds to the above error. Please use the menu. ./menu.sh
  17. Do not use the build command directly. The menu method below corresponds to the above error. Please use the menu. ./menu.sh
  18. I modified it once more and finally succeeded. https://github.com/PeterSuh-Q3/arpl-modules/blob/main/src/4.x/drivers/scsi/mvsas/mv_init.c#L703 like you patched MARVELL_EXT should have been used, not MARVELL. I confirmed that pocopico's script was also patched in that way. https://github.com/pocopico/redpill-modules/blob/master/src.old/mvsas/5.x/mv_init.c#L674
  19. @IG-88 I heard that in June 2020, at @djkjd's request, the mvsas module of DSM 6 was patched as follows. @djkjd recently requested a patch for the mvsas module in REDPILL DSM 7 as well. https://github.com/PeterSuh-Q3/tinycore-redpill/issues/15 I thought I patched it the same way you did it, It says that the module does not work in DSM 7. The final patch is as follows. https://github.com/PeterSuh-Q3/arpl-modules/blob/main/src/4.x/drivers/scsi/mvsas/mv_init.c#L703 This patch has two changes as shown below. https://github.com/PeterSuh-Q3/arpl-modules/commit/4d8c6a6d20f41e4bbdec2da85dabe357da338894 https://github.com/PeterSuh-Q3/arpl-modules/commit/980d929536888c27ff46d6b6ae82f7c841457f61 What part went wrong? Or is the Debian patching method you shared correct? https://lists.debian.org/debian-kernel/2013/09/msg00184.html + { + .vendor = PCI_VENDOR_ID_MARVELL_EXT, +.device=0x9485, + .subvendor = PCI_ANY_ID, +.subdevice=0x9485, + .class = 0; + .class_mask = 0; + .driver_data = chip_9485, + },
  20. Your question feels like a feeling of déjà vu. Didn't I already give a similar answer? I think I made SHR by combining PCIE type ASUS Hyper M.2 adapter with MOBO's M.2? However, no one can guarantee stability when doing this.
  21. That's strange. I also tested it with the same RR v23.11.10 USB stick. Is the situation different between baremetal and VM? I will try it again.
  22. P@ssw0rd is already announced in many guides and texts. Changing this part now will cause confusion to users. If you want to change the settings personally, I can guide you on how to change and fix them within tc. Do you want it this way?
  23. If so, I will no longer try to access the Tcrp loader build menu from the serial port console. Instead, I will finish implementing the DSM Force re-install function.
  24. I think it would be not bad idea to add force_junior to the grub menu like rr. This is possible within Friend, and we will also add the Force DSM re-install function to grub.
×
×
  • Create New...