TinyCore RedPill Loader Build Support Tool ( M-Shell )

[nemesis122]

Can Confirm the same in Virtualbox ater creating the loader is booting but no Webinterface or syno is loading also not  in the synology assistant complete new install 

tinycore-redpill.v1.0.1.0.m-shell.vmdk.gz

DSM 7.1.42962 Modell 3622xs++

 

 

 

Edited December 19, 2023 by nemesis122

[Strykax]

9 hours ago, Peter Suh said:

 

Tinycore linux only helps build the DSM bootloader that boots through the Friend kernel and has no direct relationship with the DSM kernel.

 

A total of three Linux kernels are used from loader build to DSM booting.

No. 1 Tinycore Linux Kernel
No. 2 Friend Linux Kernel
No. 3 DSM Synology Custom Linux Kernel

 

No. 1 loader build -> No. 2 Friend kernel loading -> No. 3 DSM Syno kernel loading

Kernel loading proceeds in the same order as above.

 

This update to kernel version 6 is not limited to Tinycore.

The Friend kernel has also been upgraded from kernel 5 to kernel 6 starting from version 0.1.0.
After the kernel version upgrade, there was a change in the logic for finding and guiding IP addresses in version 0.1.0a.

Even in versions prior to 0.1.0, there was a problem with the guide to the detected IP address being inaccurate.
This is an area that still needs to be improved.

 

It has become difficult to rely on the IP address displayed in the Friend kernel console and the IP address found at find.synology.com.

So, the way to accurately detect the IP address after recovery is to record the MAC address assigned to the NIC in the router and assign a static IP.

This is a way to avoid the IP address constantly changing during recovery.

Hi Peter,

 

Thanks for the reply, the IP is a static from the router and does not change. 

 

IP is pingable and Synology assistant finds it, but times out when I try a recovery.

 

I also tried building SA6400 (realise probably not going to work on my CPU) as an experiment and that started migrating but failed part way through.

 

I have previously had migration fail due to lack of space on the DSM system partition which is why I then tried to use mdadm to mount it and check free space. This works in Tinycore 12 but not 14. Will try a few more things, but suggestions on how best to progress much appreciated.

[Peter Suh]

3 hours ago, nemesis122 said:

Can Confirm the same in Virtualbox ater creating the loader is booting but no Webinterface or syno is loading also not  in the synology assistant complete new install 

tinycore-redpill.v1.0.1.0.m-shell.vmdk.gz

DSM 7.1.42962 Modell 3622xs++

 

 

 

 

Do you have any more questions about this inquiry about scalability?
Can I close the issue?
https://github.com/PeterSuh-Q3/tinycore-redpill/issues/17

[nemesis122]

Hi Peter I have to test and let you know but as i would test last time on my gen8 the loader was booting and then the message " the kernel must loading first " i will try again an dlet you know thank you 

[Biocef]

Hi,

Since TCRP 0.9.2.7 there is a mac address issue.

Redpill is not able to spoof the mac addresse.

This is still present, even with the latest version of m-Shell.
Do you have any idea of what causes this is ?

 

 

[Peter Suh]

1 hour ago, Biocef said:

Hi,

Since TCRP 0.9.2.7 there is a mac address issue.

Redpill is not able to spoof the mac addresse.

This is still present, even with the latest version of m-Shell.
Do you have any idea of what causes this is ?

 

 

 

I already know about this problem and would like to improve it.
I remember seeing a revision history for this problem in some intermediate version of rr.
However, I am just worried because the repo I can refer to has been closed.
I will try to improve this area with his help.

[Trabalhador Anonimo]

Last update to tinycore-redpill.v1.0.1.0.m-shell makes my network cards to stop responding to network. The NIC led blink up to last screen. After QR code shows up, all NIS go down, stop blink, stop to respond to ping and nothing come up on Advanced IP scanner nor find.synology.com.

I´ll try to rebuild the loadr with 1.0.0.0 version. Hope to work!!!!

Edited December 26, 2023 by Trabalhador Anonimo

[Trabalhador Anonimo]

Is there a way to prevent Upgrade from Tinycore Linux version 12.0 (kernel 5.10.3) to 14.0 (kernel 6.1.2)?
Kernel 14 does not like my NIC R8169!!!

[Trabalhador Anonimo]

what is this new new message in pink below the screen?

[Trabalhador Anonimo]

This is insane, but I forgot to turnoff this box and when I came back it was connected. I reboot and wait and wait and wait... It took about 4 minutes to let the web interface came up, after the screen on the post up there came up.

 

[Peter Suh]

1 hour ago, Trabalhador Anonimo said:

This is insane, but I forgot to turnoff this box and when I came back it was connected. I reboot and wait and wait and wait... It took about 4 minutes to let the web interface came up, after the screen on the post up there came up.

 

 

The first time you install DSM 7.2.1 Update 0, it probably won't take more than 4 minutes.

 

Friend automatically changes to the latest version, Update 3, and automatically performs Ramdisk Patch. (Yellow text will stand out.)

 

In this state, the process of upgrading from Update 0 to Update 3 takes time.

 

This process involves reinstalling the Synology package, which takes the longest time and also causes network disconnection.

[Peter Suh]

On 12/21/2023 at 10:00 PM, Biocef said:

Hi,

Since TCRP 0.9.2.7 there is a mac address issue.

Redpill is not able to spoof the mac addresse.

This is still present, even with the latest version of m-Shell.
Do you have any idea of what causes this is ?

 

 

 

Today I researched how to spoof Mac address in Mshell.
Although spoofing was already successful on Friend, there was an issue where it could not continue to DSM.
Mac spoofing was handled within DSM with the command below.
I confirmed that the Mac and IP addresses were renewed normally.

 

sudo -i
/sbin/ip link set dev eth0 address 00:E2:69:75:ED:28
/etc/rc.network restart

I plan to inject this script in the form of a new addon.
I decided to name it force_dhcp.

I will announce this feature when it is released.

 

Edited December 27, 2023 by Peter Suh

[apriliars3]

1 hour ago, Peter Suh said:

 

Today I researched how to spoof Mac address in Mshell.
Although spoofing was already successful on Friend, there was an issue where it could not continue to DSM.
Mac spoofing was handled within DSM with the command below.
I confirmed that the Mac and IP addresses were renewed normally.

 

sudo -i
/sbin/ip link set dev eth0 address 00:E2:69:75:ED:28
/etc/rc.network restart

I plan to inject this script in the form of a new addon.
I decided to name it force_dhcp.

I will announce this feature when it is released.

 

 

I have serial and mac genuine with DSM, but other loaders with fake mac not permitted to take all services Synology with my account. This released is for this? I am using now your M-shell without problems with mac. 

[Peter Suh]

31 minutes ago, apriliars3 said:

 

I have serial and mac genuine with DSM, but other loaders with fake mac not permitted to take all services Synology with my account. This released is for this? I am using now your M-shell without problems with mac. 

 

Anyway, it is true that MAC spoofing is messy.
Because explicit MAC spoofing was not done, virtual MAC could not be used properly.
If you want to keep a Real Mac, spoof a Real Mac.
Replacing the MAC address with the same value from the original MAC address is meaningless because there is no change,

but I decided to do spoofing through this mac-spoof addon anyway.

https://github.com/PeterSuh-Q3/redpill-load/blob/master/bundled-exts.json#L11

https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/mac-spoof/src/install.sh

The test was conducted successfully.
MAC spoofing is processed as desired.
The official announcement will be made tomorrow.

[Peter Suh]

[NOTICE]

Deploy virtual MAC address spoofing Addon mac-spoof

 

This does not apply to users who only use real MAC addresses.

 

Currently, the FRIEND kernel shows the process of spoofing a real MAC address with a virtual MAC address using a yellow message.

So, when MAC spoofing processing is completed, a new DHCP IP address is assigned to the newly changed virtual MAC address.

During this process, the spoofing status must continue to be transmitted at the Junior stage of installing DSM and at the OS_ON_LOAD point when DSM installation is completed and the OS is loaded.

 

However, there are cases where this spoofing is released and a strange state where neither real MAC nor virtual MAC persists.
(In the DSM control panel, the real MAC is displayed, but the IP already assigned to the virtual MAC is used, etc.)

So, even within DSM, ADDON, which fixes explicit MAC spoofing, was added to MSHELL.

 

To use this addon, you must re-enter the mshell TCRP loader build menu and build again.

The command below on the right is a way to re-check whether the mac-spoof addon is properly installed.

The green message is the process of spoofing from the real MAC address to the virtual MAC address.

For this spoofed virtual MAC address, an IP address of 192.168.35.104 was assigned by the DHCP server (router).

 

In Junior mode where DSM is installed, the mac-spoof addon runs and the IP is well fixed through virtual MAC spoofing.

MAC spoofing in Junior mode ensures that the virtual MAC address is checked on the DSM control panel even after OS_ON_LOAD, when DSM installation is completed.

 

[Orphée]

Hello,

 

@Peter Suh would it be possible to have SataPortMap / DiskIdxMap manual edit available even with Friend mode ?

 

 

 

 

 

Usually on my Proxmox Q35 machine I set SataPortMap=18 DiskIdxMap=1000.

 

And I don't know why but loader disk is detected in Storage Manager on DVA3221 loader. Whereas it does not happen on SA6400.

 

Thanks

Edited December 30, 2023 by Orphée

[Peter Suh]

Hello,
 
@Peter Suh would it be possible to have SataPortMap / DiskIdxMap manual edit available even with Friend mode ?
 

 

 

 

 
Usually on my Proxmox Q35 machine I set SataPortMap=18 DiskIdxMap=1000.
 
And I don't know why but loader disk is detected in Storage Manager on DVA3221 loader. Whereas it does not happen on SA6400.
 
Thanks

sa6400 and dva3221 have completely different disk mapping methods. sa6400 is a device-tree method with automatic mapping.

I will also create an option to not initialize sataportmap in the tinycore menu loader build in the virtual system. For beginners, I think it is still safe not to use this sataportmap value.


Sent from my iPhone using Tapatalk

[Peter Suh]

11 hours ago, Orphée said:

Hello,

 

@Peter Suh would it be possible to have SataPortMap / DiskIdxMap manual edit available even with Friend mode ?

 

 

 

 

 

Usually on my Proxmox Q35 machine I set SataPortMap=18 DiskIdxMap=1000.

 

And I don't know why but loader disk is detected in Storage Manager on DVA3221 loader. Whereas it does not happen on SA6400.

 

Thanks

 

It was just released.

 

[Orphée]

It does not seems to work well.

 

Running "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches
Still waiting for boot device (waited 1 of 10 seconds)
Still waiting for boot device (waited 2 of 10 seconds)
Still waiting for boot device (waited 3 of 10 seconds)
Still waiting for boot device (waited 4 of 10 seconds)
Still waiting for boot device (waited 5 of 10 seconds)
Still waiting for boot device (waited 6 of 10 seconds)
Still waiting for boot device (waited 7 of 10 seconds)
Still waiting for boot device (waited 8 of 10 seconds)
Still waiting for boot device (waited 9 of 10 seconds)
Still waiting for boot device (waited 10 of 10 seconds)
ERROR: Timeout waiting for /dev/synoboot device to appear.
Most likely your vid/pid configuration is not correct, or you don't have drivers needed for your USB/SATA controller

========== BEGIN DUMP OF ALL PARTITIONS DETECTED ===========
/dev/sda1                  2048         4982527         4980480  fd  
/dev/sda2               4982528         9176831         4194304  fd  
/dev/sda3               9437184      7813832351      7804395168  fd  


/dev/sdb1                  2048         4982527         4980480  fd  
/dev/sdb2               4982528         9176831         4194304  fd  
/dev/sdb3               9437184      7813832351      7804395168  fd  


/dev/sdc1                  2048         4982527         4980480  fd  
/dev/sdc2               4982528         9176831         4194304  fd  
/dev/sdc3               9437184      7813832351      7804395168  fd  


/dev/sdd1                  2048         4982527         4980480  fd  
/dev/sdd2               4982528         9176831         4194304  fd  
/dev/sdd3               9437184      7813832351      7804395168  fd  


/dev/sde1                  2048          147455          145408  83  
/dev/sde2                147456          301055          153600  83  
/dev/sde3                301056         3147775         2846720  83  


========== END OF DUMP OF ALL PARTITIONS DETECTED ==========
Force the creation of synoboot, synoboot1 and synoboot2 nodes...
Confirmed a valid-looking /dev/synoboot device
Ran "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches - exit=0

 

 

SynologyNVR> fdisk -l
fdisk: device has more than 2^32 sectors, can't use all of them
Disk /dev/sda: 2048 GB, 2199023255040 bytes, 4294967295 sectors
267349 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sda1    0,0,1       1023,254,63          1 4294967295 4294967295 2047G ee EFI GPT
fdisk: device has more than 2^32 sectors, can't use all of them
Disk /dev/sdb: 2048 GB, 2199023255040 bytes, 4294967295 sectors
267349 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdb1    0,0,1       1023,254,63          1 4294967295 4294967295 2047G ee EFI GPT
fdisk: device has more than 2^32 sectors, can't use all of them
Disk /dev/sdc: 2048 GB, 2199023255040 bytes, 4294967295 sectors
267349 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdc1    0,0,1       1023,254,63          1 4294967295 4294967295 2047G ee EFI GPT
fdisk: device has more than 2^32 sectors, can't use all of them
Disk /dev/sdd: 2048 GB, 2199023255040 bytes, 4294967295 sectors
267349 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdd1    0,0,1       1023,254,63          1 4294967295 4294967295 2047G ee EFI GPT
Disk /dev/sde: 1540 MB, 1614807040 bytes, 3153920 sectors
196 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sde1 *  0,32,33     9,45,36           2048     147455     145408 71.0M 83 Linux
/dev/sde2    9,45,37     18,188,42       147456     301055     153600 75.0M 83 Linux
/dev/sde3    18,188,43   195,239,44      301056    3147775    2846720 1390M 83 Linux
Disk /dev/md0: 2431 MB, 2549940224 bytes, 4980352 sectors
622544 cylinders, 2 heads, 4 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Disk /dev/md0 doesn't contain a valid partition table
Disk /dev/md1: 2047 MB, 2147418112 bytes, 4194176 sectors
524272 cylinders, 2 heads, 4 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Disk /dev/md1 doesn't contain a valid partition table
SynologyNVR>

 

fdisk above seems OK, disk 1 to 4 seems to be my 4 RDM disks and disk 5 is the loader.

 

But :

 

 

It detects errors on disk 7 and 8, whereas on fdisk -l above, there should not have disks in 7 and 8...

 

As soon as I edit the SATA command line (e) to remove SataPortMap and DiskIdxMap values, it starts OK.

 

There must be something different from ARPL/RR loader handling these values.

 

And my "SAN manager" package is broken, I try to repair it but it fails...
did not catch why yet.

 

Edit : Switched loader from SATA mode to USB by modifying/adding args value in proxmox VM conf :

args: -device 'nec-usb-xhci,id=usb-bus0,multifunction=on' -drive 'file=/var/lib/vz/dump/DVA3221-m-shell.img,media=disk,format=raw,if=none,id=drive-disk-bootloader' -device 'usb-storage,bus=usb-bus0.0,port=1,drive=drive-disk-bootloader,id=usb-disk-bootloader,bootindex=999,removable=on'

 

I also changed SataPortMap=16 instead of 18 as only 6 slots are detected...

 

It fixed the boot...

 

But SAN Manager package still broken

 

2024/01/01 04:32:04 Failed to stop ScsiTarget[0x0000 file_get_section.c:83]
2024/01/01 04:32:23 Failed to start package, pkg=[ScsiTarget] context=[{"action":"repair","beta":false,"betaIncoming":false,"error":{"code":272,"description":"Failed to run script, script=[start]"},"finished":false,"installReboot":false,"installing":true,"language":"fre","last_stage":"prepare_start","package":"ScsiTarget","packageName":"SAN Manager","pid":5743,"scripts":[{"code":0,"message":"","type":"prestop"},{"code":0,"message":"","type":"preupgrade"},{"code":0,"message":"","type":"preuninst"},{"code":0,"message":"","type":"postuninst"},{"code":0,"message":"","type":"preinst"},{"code":0,"message":"","type":"postinst"},{"code":0,"message":"","type":"postupgrade"},{"code":0,"message":"","type":"prestart"},{"code":1,"message":"","type":"start"}],"spk":"/volume1/@tmp/synopkg/download.APns21/@SYNOPKG_DOWNLOAD_ScsiTarget","stage":"start_failed","status":"repairing","success":false,"username":"xxxx","version":"1.0.10-0314"}]
2024/01/01 04:32:23 Failed to start ScsiTarget[0x0000 file_get_section.c:83]

 

Service fails to start :

systemctl status pkgctl-ScsiTarget.service -l
● pkgctl-ScsiTarget.service - ScsiTarget's service unit
   Loaded: loaded (/usr/local/lib/systemd/system/pkgctl-ScsiTarget.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2024-01-01 04:39:19 CET; 16s ago
  Process: 32172 ExecStart=/bin/bash -c /usr/syno/sbin/synopkgctl start $SELF && /bin/touch /var/packages/$SELF/enabled (code=exited, status=1/FAILURE)
 Main PID: 32172 (code=exited, status=1/FAILURE)

Jan 01 04:39:19 XXXXXX synopkgctl[32564]: SYNOPKG: Release usr-local-linker for ScsiTarget when 0x0001 (ready)
Jan 01 04:39:19 XXXXXX synopkgctl[32564]: SYNOPKG: Release usr-local-linker for ScsiTarget when 0x0001 (done)
Jan 01 04:39:19 XXXXXX synopkgctl[32174]: plugin_action.c:76 synoplugin: [PRE][package][package_action][MAIN] Plugin Action Start
Jan 01 04:39:19 XXXXXX synopkgctl[32174]: plugin_action.c:76 synoplugin: [PRE][package][package_action][MAIN] Runtime: 0.000s
Jan 01 04:39:19 XXXXXX synopkgctl[32174]: SYNOPKGMGR: Failed to start package, pkg=[ScsiTarget] context=[{"action":"install","beta":false,"betaIncoming":false,"error":{"code":272,"description":"Failed to run script, script=[start]"},"finished":false,"installReboot":false,"installing":true,"language":"fre","last_stage":"prepare_start","package":"ScsiTarget","packageName":"SAN Manager","pid":32174,"scripts":[{"code":0,"message":"","type":"preinst"},{"code":0,"message":"","type":"postinst"},{"code":0,"message":"","type":"prestart"},{"code":1,"message":"","type":"start"}],"spk":"/volume1/@tmp/synopkg/download.OTCxcI/@SYNOPKG_DOWNLOAD_ScsiTarget","stage":"start_failed","status":"installing","success":false,"username":"xxxxxx","version":"1.0.10-0314"}]
Jan 01 04:39:19 XXXXXX systemd[1]: pkgctl-ScsiTarget.service: main process exited, code=exited, status=1/FAILURE
Jan 01 04:39:19 XXXXXX systemd[1]: Failed to start ScsiTarget's service unit.
Jan 01 04:39:19 XXXXXX systemd[1]: Unit pkgctl-ScsiTarget.service entered failed state.
Jan 01 04:39:19 XXXXXX systemd[1]: Triggering OnFailure= dependencies of pkgctl-ScsiTarget.service.
Jan 01 04:39:19 XXXXXX systemd[1]: pkgctl-ScsiTarget.service failed.

 

Edited January 1 by Orphée

[Peter Suh]

8 hours ago, Orphée said:

It does not seems to work well.

 

Running "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches
Still waiting for boot device (waited 1 of 10 seconds)
Still waiting for boot device (waited 2 of 10 seconds)
Still waiting for boot device (waited 3 of 10 seconds)
Still waiting for boot device (waited 4 of 10 seconds)
Still waiting for boot device (waited 5 of 10 seconds)
Still waiting for boot device (waited 6 of 10 seconds)
Still waiting for boot device (waited 7 of 10 seconds)
Still waiting for boot device (waited 8 of 10 seconds)
Still waiting for boot device (waited 9 of 10 seconds)
Still waiting for boot device (waited 10 of 10 seconds)
ERROR: Timeout waiting for /dev/synoboot device to appear.
Most likely your vid/pid configuration is not correct, or you don't have drivers needed for your USB/SATA controller

========== BEGIN DUMP OF ALL PARTITIONS DETECTED ===========
/dev/sda1                  2048         4982527         4980480  fd  
/dev/sda2               4982528         9176831         4194304  fd  
/dev/sda3               9437184      7813832351      7804395168  fd  


/dev/sdb1                  2048         4982527         4980480  fd  
/dev/sdb2               4982528         9176831         4194304  fd  
/dev/sdb3               9437184      7813832351      7804395168  fd  


/dev/sdc1                  2048         4982527         4980480  fd  
/dev/sdc2               4982528         9176831         4194304  fd  
/dev/sdc3               9437184      7813832351      7804395168  fd  


/dev/sdd1                  2048         4982527         4980480  fd  
/dev/sdd2               4982528         9176831         4194304  fd  
/dev/sdd3               9437184      7813832351      7804395168  fd  


/dev/sde1                  2048          147455          145408  83  
/dev/sde2                147456          301055          153600  83  
/dev/sde3                301056         3147775         2846720  83  


========== END OF DUMP OF ALL PARTITIONS DETECTED ==========
Force the creation of synoboot, synoboot1 and synoboot2 nodes...
Confirmed a valid-looking /dev/synoboot device
Ran "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches - exit=0

 

 

SynologyNVR> fdisk -l
fdisk: device has more than 2^32 sectors, can't use all of them
Disk /dev/sda: 2048 GB, 2199023255040 bytes, 4294967295 sectors
267349 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sda1    0,0,1       1023,254,63          1 4294967295 4294967295 2047G ee EFI GPT
fdisk: device has more than 2^32 sectors, can't use all of them
Disk /dev/sdb: 2048 GB, 2199023255040 bytes, 4294967295 sectors
267349 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdb1    0,0,1       1023,254,63          1 4294967295 4294967295 2047G ee EFI GPT
fdisk: device has more than 2^32 sectors, can't use all of them
Disk /dev/sdc: 2048 GB, 2199023255040 bytes, 4294967295 sectors
267349 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdc1    0,0,1       1023,254,63          1 4294967295 4294967295 2047G ee EFI GPT
fdisk: device has more than 2^32 sectors, can't use all of them
Disk /dev/sdd: 2048 GB, 2199023255040 bytes, 4294967295 sectors
267349 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdd1    0,0,1       1023,254,63          1 4294967295 4294967295 2047G ee EFI GPT
Disk /dev/sde: 1540 MB, 1614807040 bytes, 3153920 sectors
196 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sde1 *  0,32,33     9,45,36           2048     147455     145408 71.0M 83 Linux
/dev/sde2    9,45,37     18,188,42       147456     301055     153600 75.0M 83 Linux
/dev/sde3    18,188,43   195,239,44      301056    3147775    2846720 1390M 83 Linux
Disk /dev/md0: 2431 MB, 2549940224 bytes, 4980352 sectors
622544 cylinders, 2 heads, 4 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Disk /dev/md0 doesn't contain a valid partition table
Disk /dev/md1: 2047 MB, 2147418112 bytes, 4194176 sectors
524272 cylinders, 2 heads, 4 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Disk /dev/md1 doesn't contain a valid partition table
SynologyNVR>

 

fdisk above seems OK, disk 1 to 4 seems to be my 4 RDM disks and disk 5 is the loader.

 

But :

 

 

It detects errors on disk 7 and 8, whereas on fdisk -l above, there should not have disks in 7 and 8...

 

As soon as I edit the SATA command line (e) to remove SataPortMap and DiskIdxMap values, it starts OK.

 

There must be something different from ARPL/RR loader handling these values.

 

And my "SAN manager" package is broken, I try to repair it but it fails...
did not catch why yet.

 

Edit : Switched loader from SATA mode to USB by modifying/adding args value in proxmox VM conf :

args: -device 'nec-usb-xhci,id=usb-bus0,multifunction=on' -drive 'file=/var/lib/vz/dump/DVA3221-m-shell.img,media=disk,format=raw,if=none,id=drive-disk-bootloader' -device 'usb-storage,bus=usb-bus0.0,port=1,drive=drive-disk-bootloader,id=usb-disk-bootloader,bootindex=999,removable=on'

 

I also changed SataPortMap=16 instead of 18 as only 6 slots are detected...

 

It fixed the boot...

 

But SAN Manager package still broken

 

2024/01/01 04:32:04 Failed to stop ScsiTarget[0x0000 file_get_section.c:83]
2024/01/01 04:32:23 Failed to start package, pkg=[ScsiTarget] context=[{"action":"repair","beta":false,"betaIncoming":false,"error":{"code":272,"description":"Failed to run script, script=[start]"},"finished":false,"installReboot":false,"installing":true,"language":"fre","last_stage":"prepare_start","package":"ScsiTarget","packageName":"SAN Manager","pid":5743,"scripts":[{"code":0,"message":"","type":"prestop"},{"code":0,"message":"","type":"preupgrade"},{"code":0,"message":"","type":"preuninst"},{"code":0,"message":"","type":"postuninst"},{"code":0,"message":"","type":"preinst"},{"code":0,"message":"","type":"postinst"},{"code":0,"message":"","type":"postupgrade"},{"code":0,"message":"","type":"prestart"},{"code":1,"message":"","type":"start"}],"spk":"/volume1/@tmp/synopkg/download.APns21/@SYNOPKG_DOWNLOAD_ScsiTarget","stage":"start_failed","status":"repairing","success":false,"username":"xxxx","version":"1.0.10-0314"}]
2024/01/01 04:32:23 Failed to start ScsiTarget[0x0000 file_get_section.c:83]

 

Service fails to start :

systemctl status pkgctl-ScsiTarget.service -l
● pkgctl-ScsiTarget.service - ScsiTarget's service unit
   Loaded: loaded (/usr/local/lib/systemd/system/pkgctl-ScsiTarget.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2024-01-01 04:39:19 CET; 16s ago
  Process: 32172 ExecStart=/bin/bash -c /usr/syno/sbin/synopkgctl start $SELF && /bin/touch /var/packages/$SELF/enabled (code=exited, status=1/FAILURE)
 Main PID: 32172 (code=exited, status=1/FAILURE)

Jan 01 04:39:19 XXXXXX synopkgctl[32564]: SYNOPKG: Release usr-local-linker for ScsiTarget when 0x0001 (ready)
Jan 01 04:39:19 XXXXXX synopkgctl[32564]: SYNOPKG: Release usr-local-linker for ScsiTarget when 0x0001 (done)
Jan 01 04:39:19 XXXXXX synopkgctl[32174]: plugin_action.c:76 synoplugin: [PRE][package][package_action][MAIN] Plugin Action Start
Jan 01 04:39:19 XXXXXX synopkgctl[32174]: plugin_action.c:76 synoplugin: [PRE][package][package_action][MAIN] Runtime: 0.000s
Jan 01 04:39:19 XXXXXX synopkgctl[32174]: SYNOPKGMGR: Failed to start package, pkg=[ScsiTarget] context=[{"action":"install","beta":false,"betaIncoming":false,"error":{"code":272,"description":"Failed to run script, script=[start]"},"finished":false,"installReboot":false,"installing":true,"language":"fre","last_stage":"prepare_start","package":"ScsiTarget","packageName":"SAN Manager","pid":32174,"scripts":[{"code":0,"message":"","type":"preinst"},{"code":0,"message":"","type":"postinst"},{"code":0,"message":"","type":"prestart"},{"code":1,"message":"","type":"start"}],"spk":"/volume1/@tmp/synopkg/download.OTCxcI/@SYNOPKG_DOWNLOAD_ScsiTarget","stage":"start_failed","status":"installing","success":false,"username":"xxxxxx","version":"1.0.10-0314"}]
Jan 01 04:39:19 XXXXXX systemd[1]: pkgctl-ScsiTarget.service: main process exited, code=exited, status=1/FAILURE
Jan 01 04:39:19 XXXXXX systemd[1]: Failed to start ScsiTarget's service unit.
Jan 01 04:39:19 XXXXXX systemd[1]: Unit pkgctl-ScsiTarget.service entered failed state.
Jan 01 04:39:19 XXXXXX systemd[1]: Triggering OnFailure= dependencies of pkgctl-ScsiTarget.service.
Jan 01 04:39:19 XXXXXX systemd[1]: pkgctl-ScsiTarget.service failed.

 

 

It is true that the ATA method that emulates the SATA dom loader is still more unstable. In the case of SA6400, kernel panic sometimes occurs.
I think it was a good decision to switch from proxmox to the USB method.

Two users in Korea also recently reported errors in SAN MANAGER.
It is assumed to be related to MAC-SPOOF ADDON.

In the case of the first user, two virtual MACs were used,
In the case of the second user, a real MAC was used.
In the case of both users, they said that Package Center was not working properly.
In the case of the first user, one of the two virtual MACs was adjusted so that the package server could be linked.
In the case of the second user, since it was a real MAC, there was no need to adjust anything,

and he deleted and reinstalled SAN MANAGER repeatedly, but the installation did not proceed properly.

I will further improve MAC-SPOOF ADDON so that it does not work when only real MAC is used.

What type of MAC address do you use in your case?

Edited January 1 by Peter Suh

[Orphée]

How can I disable atuomatic MAC spoof ?

 

I did not set anything myself, the "real" MAC is sent by Proxmox VM settings configuration.

But at boot, I still see :

 

Setting MAC address from [Real MAC Address set in proxmox] to [Same MAC address] on eth0 (virtio_net)

 

I did not add the MAC address myself, it auto registered itself in TCRP config file.

 

 

2024-01-01T12:40:30+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get_user_service[25080]: [HA-ERROR] conf.cc:117: Failed to get key host0: [0x0900 file_get_key_value.c:28]
2024-01-01T12:40:30+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get_user_service[25080]: [HA-ERROR] conf.cc:1516: Failed to get conf host0
2024-01-01T12:40:32+01:00 xxxx synoscgi_SYNO.Core.System.SystemHealth_1_get[28013]: SystemInfo/san_status_info.cpp:50 Failed to load lun info for SAN Manager
2024-01-01T12:40:32+01:00 xxxx synoscgi_SYNO.Core.System.SystemHealth_1_get[28013]: SystemInfo/san_status_info.cpp:66 Failed to load volume info for SAN Manager
2024-01-01T12:40:37+01:00 xxxx synoscgi_SYNO.Entry.Request_1_request[28854]: APIInternalUtil.cpp:200 WebAPI SYNO.Core.ISCSI.LUN is not valid
2024-01-01T12:40:37+01:00 xxxx synoscgi_SYNO.Entry.Request_1_request[28854]: APIInternalUtil.cpp:200 WebAPI SYNO.Core.ISCSI.LUN is not valid
2024-01-01T12:40:37+01:00 xxxx synoscgi_SYNO.Entry.Request_1_request[28854]: APIInternalUtil.cpp:200 WebAPI SYNO.Core.ISCSI.LUN is not valid
2024-01-01T12:40:37+01:00 xxxx synoscgi_SYNO.Core.ISCSI.LUN_1_list[28859]: APIInternalUtil.cpp:200 WebAPI SYNO.Core.ISCSI.LUN is not valid
2024-01-01T12:40:37+01:00 xxxx synoscgi_SYNO.Storage.CGI.Storage_1_load_info[28856]: external/external_get_devices_ids.c:108 fail to get all pci device Ids from /etc.defaults/extensionPorts
2024-01-01T12:40:37+01:00 xxxx synoscgi_SYNO.Storage.CGI.Storage_1_load_info[28856]: external/external_get_devices_ids.c:108 fail to get all pci device Ids from /etc.defaults/extensionPorts
2024-01-01T12:40:37+01:00 xxxx synoscgi_SYNO.Storage.CGI.Storage_1_load_info[28856]: StorageManager.cpp:499 Failed to get m2 card list
2024-01-01T12:40:43+01:00 xxxx synoscgi_SYNO.Entry.Request_1_request[28854]: APIInternalUtil.cpp:200 WebAPI SYNO.Core.ISCSI.LUN is not valid
2024-01-01T12:40:43+01:00 xxxx synoscgi_SYNO.Entry.Request_1_request[28854]: APIInternalUtil.cpp:200 WebAPI SYNO.Core.ISCSI.LUN is not valid
2024-01-01T12:40:43+01:00 xxxx synoscgi_SYNO.Entry.Request_1_request[28854]: APIInternalUtil.cpp:200 WebAPI SYNO.Core.ISCSI.LUN is not valid
2024-01-01T12:40:43+01:00 xxxx synoscgi_SYNO.Core.ISCSI.LUN_1_list[29326]: APIInternalUtil.cpp:200 WebAPI SYNO.Core.ISCSI.LUN is not valid
2024-01-01T12:40:43+01:00 xxxx synoscgi_SYNO.Storage.CGI.Storage_1_load_info[29324]: external/external_get_devices_ids.c:108 fail to get all pci device Ids from /etc.defaults/extensionPorts
2024-01-01T12:40:44+01:00 xxxx synoscgi_SYNO.Storage.CGI.Storage_1_load_info[29324]: external/external_get_devices_ids.c:108 fail to get all pci device Ids from /etc.defaults/extensionPorts
2024-01-01T12:40:44+01:00 xxxx synoscgi_SYNO.Storage.CGI.Storage_1_load_info[29324]: StorageManager.cpp:499 Failed to get m2 card list
2024-01-01T12:40:45+01:00 xxxx synoscgi_SYNO.Core.System_1_info[29402]: external/external_get_devices_ids.c:108 fail to get all pci device Ids from /etc.defaults/extensionPorts
2024-01-01T12:40:45+01:00 xxxx synoscgi_SYNO.Core.System_1_info[29402]: SYNO.Core.System.info.cpp:2133 Failed to enum m2 card list
2024-01-01T12:41:27+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get[971]: [HA-ERROR] conf.cc:117: Failed to get key host0: [0x0900 file_get_key_value.c:28]
2024-01-01T12:41:27+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get[971]: [HA-ERROR] conf.cc:1516: Failed to get conf host0
2024-01-01T12:41:33+01:00 xxxx synoscgi_SYNO.Core.System.SystemHealth_1_get[1769]: SystemInfo/san_status_info.cpp:50 Failed to load lun info for SAN Manager
2024-01-01T12:41:33+01:00 xxxx synoscgi_SYNO.Core.System.SystemHealth_1_get[1769]: SystemInfo/san_status_info.cpp:66 Failed to load volume info for SAN Manager
2024-01-01T12:41:41+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get[2269]: [HA-ERROR] conf.cc:117: Failed to get key host0: [0x0900 file_get_key_value.c:28]
2024-01-01T12:41:41+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get[2269]: [HA-ERROR] conf.cc:1516: Failed to get conf host0
2024-01-01T12:42:17+01:00 xxxx synoscgi_SYNO.Core.Package.Control_1_start[5544]: systemd_start.cpp:25 synosystemd: [pkgctl-ScsiTarget.service] start failed: ret=[1], reason:
Job for pkgctl-ScsiTarget.service failed. See "systemctl status pkgctl-ScsiTarget.service" and "journalctl -xe" for details.
2024-01-01T12:42:17+01:00 xxxx synoscgi_SYNO.Core.Package.Control_1_start[5544]: SYNOPKGMGR: Failed to start ScsiTarget[0x0000 file_get_section.c:83]
2024-01-01T12:42:17+01:00 xxxx synoscgi_SYNO.Core.Package.Control_1_start[5544]: SYNOPKGMGR: Failed to do service control, pkg=[ScsiTarget] start=[1]
2024-01-01T12:42:17+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get[5954]: [HA-ERROR] conf.cc:117: Failed to get key host0: [0x0900 file_get_key_value.c:28]
2024-01-01T12:42:17+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get[5954]: [HA-ERROR] conf.cc:1516: Failed to get conf host0
2024-01-01T12:42:19+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get[6358]: [HA-ERROR] conf.cc:117: Failed to get key host0: [0x0900 file_get_key_value.c:28]
2024-01-01T12:42:19+01:00 xxxx synoscgi_SYNO.Core.Desktop.Initdata_1_get[6358]: [HA-ERROR] conf.cc:1516: Failed to get conf host0
2024-01-01T12:42:34+01:00 xxxx synoscgi_SYNO.Core.System.SystemHealth_1_get[7540]: SystemInfo/san_status_info.cpp:50 Failed to load lun info for SAN Manager
2024-01-01T12:42:34+01:00 xxxx synoscgi_SYNO.Core.System.SystemHealth_1_get[7540]: SystemInfo/san_status_info.cpp:66 Failed to load volume info for SAN Manager

 

 

Jan 01 04:45:36 xxxxxx systemd[1]: Starting ScsiTarget's service unit...
Jan 01 04:45:36 xxxxxx synopkgctl[20304]: plugin_action.c:76 synoplugin: [PRE][package][package_action][MAIN] Plugin Action Start
Jan 01 04:45:36 xxxxxx synopkgctl[20304]: plugin_action.c:76 synoplugin: [PRE][package][package_action][MAIN] Runtime: 0.000s
Jan 01 04:45:36 xxxxxx synopkgctl[20304]: SYNOPKG: install ScsiTarget 1.0.10-0314 Begin start-stop-status prestart
Jan 01 04:45:36 xxxxxx bash[20302]: ======== start ScsiTarget ========
Jan 01 04:45:36 xxxxxx synopkgctl[20304]: SYNOPKG: install ScsiTarget 1.0.10-0314 End start-stop-status prestart ret=[0]
Jan 01 04:45:36 xxxxxx synopkgctl[20311]: SYNOPKG: Acquire indexdb for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:36 xxxxxx appindex[20314]: index_mgr.cpp:203 (Add) Add: /var/packages/ScsiTarget/target/ui/index.conf
Jan 01 04:45:37 xxxxxx synopkgctl[20311]: SYNOPKG: Acquire indexdb for ScsiTarget when 0x0001 (done)
Jan 01 04:45:37 xxxxxx synopkgctl[20311]: SYNOPKG: Acquire snmp for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:37 xxxxxx synopkgctl[20311]: systemd_reload.cpp:17 synosystemd: [snmpd] reloading ...
Jan 01 04:45:37 xxxxxx synopkgctl[20311]: systemd_reload.cpp:21 synosystemd: [snmpd] reloaded.
Jan 01 04:45:37 xxxxxx synopkgctl[20311]: SYNOPKG: Acquire snmp for ScsiTarget when 0x0001 (done)
Jan 01 04:45:37 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire usr-local-linker for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:37 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire usr-local-linker for ScsiTarget when 0x0001 (done)
Jan 01 04:45:37 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire sdk-plugin for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:37 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire sdk-plugin for ScsiTarget when 0x0001 (done)
Jan 01 04:45:37 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire sysnotify for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:38 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire sysnotify for ScsiTarget when 0x0001 (done)
Jan 01 04:45:38 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire pam-config for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:38 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire pam-config for ScsiTarget when 0x0001 (done)
Jan 01 04:45:38 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire syslog-config for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:38 xxxxxx synopkgctl[20348]: systemd_reload.cpp:17 synosystemd: [syslog-ng] reloading ...
Jan 01 04:45:38 xxxxxx synopkgctl[20348]: systemd_reload.cpp:21 synosystemd: [syslog-ng] reloaded.
Jan 01 04:45:38 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire syslog-config for ScsiTarget when 0x0001 (done)
Jan 01 04:45:38 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire synolog for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: systemd_reload.cpp:17 synosystemd: [syslog-ng] reloading ...
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: systemd_reload.cpp:21 synosystemd: [syslog-ng] reloaded.
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire synolog for ScsiTarget when 0x0001 (done)
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire userdata-collector for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire userdata-collector for ScsiTarget when 0x0001 (done)
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire webapi-desc for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: systemd_reload.cpp:17 synosystemd: [synoscgi.service] reloading ...
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: systemd_reload.cpp:21 synosystemd: [synoscgi.service] reloaded.
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire webapi-desc for ScsiTarget when 0x0001 (done)
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire webapi-desc for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire webapi-desc for ScsiTarget when 0x0001 (done)
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire port-config for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:39 xxxxxx synopkgctl[20348]: SYNOPKG: Acquire port-config for ScsiTarget when 0x0001 (done)
Jan 01 04:45:39 xxxxxx synopkgctl[20304]: plugin_action.c:76 synoplugin: [PRE][package][package_start][MAIN] Plugin Action Start
Jan 01 04:45:39 xxxxxx synopkgctl[20304]: plugin_action.c:76 synoplugin: [PRE][package][package_start][MAIN] Runtime: 0.040s
Jan 01 04:45:39 xxxxxx synopkgctl[20304]: SYNOPKG: install ScsiTarget 1.0.10-0314 Begin start-stop-status start
Jan 01 04:45:39 xxxxxx synosystemctl[20621]: systemd_start.cpp:16 synosystemd: [pkg-iscsi] starting ...
Jan 01 04:45:40 xxxxxx synopkgctl[20304]: SYNOPKG: install ScsiTarget 1.0.10-0314 End start-stop-status start ret=[1]
Jan 01 04:45:40 xxxxxx bash[20302]: Failed to execute '/var/packages/ScsiTarget/scripts/start-stop-status start' (err=1)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release port-config for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release port-config for ScsiTarget when 0x0001 (done)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release webapi-desc for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release webapi-desc for ScsiTarget when 0x0001 (done)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release webapi-desc for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: systemd_reload.cpp:17 synosystemd: [synoscgi.service] reloading ...
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: systemd_reload.cpp:21 synosystemd: [synoscgi.service] reloaded.
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release webapi-desc for ScsiTarget when 0x0001 (done)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release userdata-collector for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release userdata-collector for ScsiTarget when 0x0001 (done)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release synolog for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: systemd_reload.cpp:17 synosystemd: [syslog-ng] reloading ...
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: systemd_reload.cpp:21 synosystemd: [syslog-ng] reloaded.
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release synolog for ScsiTarget when 0x0001 (done)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release syslog-config for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: systemd_reload.cpp:17 synosystemd: [syslog-ng] reloading ...
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: systemd_reload.cpp:21 synosystemd: [syslog-ng] reloaded.
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release syslog-config for ScsiTarget when 0x0001 (done)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release pam-config for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release pam-config for ScsiTarget when 0x0001 (done)
Jan 01 04:45:40 xxxxxx synopkgctl[20685]: SYNOPKG: Release sysnotify for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:40 xxxxxx rm[20777]: uid: 0, euid: 0, arguments:["-rf" "/var/cache/texts/ScsiTarget"]
Jan 01 04:45:41 xxxxxx synopkgctl[20685]: SYNOPKG: Release sysnotify for ScsiTarget when 0x0001 (done)
Jan 01 04:45:41 xxxxxx synopkgctl[20685]: SYNOPKG: Release sdk-plugin for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:41 xxxxxx synopkgctl[20685]: SYNOPKG: Release sdk-plugin for ScsiTarget when 0x0001 (done)
Jan 01 04:45:41 xxxxxx synopkgctl[20685]: SYNOPKG: Release usr-local-linker for ScsiTarget when 0x0001 (ready)
Jan 01 04:45:41 xxxxxx synopkgctl[20685]: SYNOPKG: Release usr-local-linker for ScsiTarget when 0x0001 (done)
Jan 01 04:45:41 xxxxxx synopkgctl[20304]: plugin_action.c:76 synoplugin: [PRE][package][package_action][MAIN] Plugin Action Start
Jan 01 04:45:41 xxxxxx synopkgctl[20304]: plugin_action.c:76 synoplugin: [PRE][package][package_action][MAIN] Runtime: 0.001s
Jan 01 04:45:41 xxxxxx synopkgctl[20304]: SYNOPKGMGR: Failed to start package, pkg=[ScsiTarget] context=[{"action":"install","beta":false,"betaIncoming":false,"error":{"code":272,"description":"Failed to run script, script=[start]"},"finished":false,"installReboot":false,"installing":true,"language":"fre","last_stage":"prepare_start","package":"ScsiTarget","packageName":"SAN Manager","pid":20304,"scripts":[{"code":0,"message":"","type":"preinst"},{"code":0,"message":"","type":"postinst"},{"code":0,"message":"","type":"prestart"},{"code":1,"message":"","type":"start"}],"spk":"/volume1/@tmp/synopkg/download.9zayiP/@SYNOPKG_DOWNLOAD_ScsiTarget","stage":"start_failed","status":"installing","success":false,"username":"xxxx","version":"1.0.10-0314"}]
Jan 01 04:45:41 xxxxxx systemd[1]: pkgctl-ScsiTarget.service: main process exited, code=exited, status=1/FAILURE
Jan 01 04:45:41 xxxxxx systemd[1]: Failed to start ScsiTarget's service unit.
Jan 01 04:45:41 xxxxxx systemd[1]: Unit pkgctl-ScsiTarget.service entered failed state.
Jan 01 04:45:41 xxxxxx systemd[1]: Triggering OnFailure= dependencies of pkgctl-ScsiTarget.service.
Jan 01 04:45:41 xxxxxx systemd[1]: pkgctl-ScsiTarget.service failed.

 

 

Edited January 1 by Orphée

[Orphée]

Also, If I may have a little concern.

 

Compared to ARPL where you can install loader from scratch without any monitor with HTTP access or serial console. on TRCP M-shell, It seems at first time you must have access to a monitor.

 

As I have a GTX1650 for DVA3221, the configuration is set as Primary GPU (needed for Surveillance Station) so no virtual screen available on Proxmox.

 

Not a big deal but I have to :

- Disable primary GPU on PCI-e GPU passtrough in proxmox VM settings.

- Start VM with loader configuration menu

- apply all needed configuration in TRCP m-shell GUI

- NOT reboot but SHUTDOWN after loader is (re)built

- Enable again Primary GPU settings in Proxmox VM.

- Start the VM.

 

Whereas on ARPL, I was able to launch "menu.sh" from serial console or access it through HTTP 7681.

 

Again, not a big deal as I manage to do it still

Edited January 1 by Orphée

[Peter Suh]

14 minutes ago, Orphée said:

Also, If I may have a little concern.

 

Compared to ARPL where you can install loader from scratch without any monitor with HTTP access or serial console. on TRCP M-shell, It seems at first time you must have access to a monitor.

 

As I have a GTX1650 for DVA3221, the configuration is set as Primary GPU (needed for Surveillance Station) so no virtual screen available on Proxmox.

 

Not a big deal but I have to :

- Disable primary GPU on PCI-e GPU passtrough in proxmox VM settings.

- Start VM with loader configuration menu

- apply all needed configuration in TRCP m-shell GUI

- NOT reboot but SHUTDOWN after loader is (re)built

- Enable again Primary GPU settings in Proxmox VM.

- Start the VM.

 

Whereas on ARPL, I was able to launch "menu.sh" from serial console or access it through HTTP 7681.

 

Again, not a big deal as I manage to do it still

 

To me, it sounds like they are asking for M-SHELL to have features like ARPL.^^ LOL

Let's consider adding features.

First I have to solve the MAC-SPOOF issue.

[Orphée]

4 minutes ago, Peter Suh said:

 

To me, it sounds like they are asking for M-SHELL to have features like ARPL.^^ LOL

Let's consider adding features.

First I have to solve the MAC-SPOOF issue.

Maybe I missed a way to just connect in SSH and run commands from commandline without GUI ?

[Peter Suh]

11 minutes ago, Orphée said:

Maybe I missed a way to just connect in SSH and run commands from commandline without GUI ?

 

TCRP is also running on SSHD.

Connect with tc / P@ssw0rd

then run ./menu.sh

Have you tried this?