[SCRIPT] create-autorun.sh

[OneCD]

Ah, cool. Thanks Kurt.

[kevinw]

(Edit: I've just realised this is my first post here so "Hi"!)

I'm reasonably sure this is me getting something wrong as I have no idea what I'm doing but here goes anyway!

First of all thank you for the thread which I've read from start to finish.

I've followed the instructions in the initial post and all of the requisite files are on my TS670 Pro. The NAS recognises I have an autorun.sh as control panel/system/hardware can see it and show me its content. The box is ticked to say 'run user defined processes' but it doesn't run on boot - there's no entry in the log. If I log in to the device via PuTTY and run the file myself everything works exactly as it should (all I'm trying to do is connect an NFS share on another NAS to a shared folder on the QNAP) - the remote share is mounted and the log file is updated.

I'm at a bit of a loss now. Does anyone have any ideas please?

Edit 2: Following the qpkg instructions in this post seems to have solved it for me. I have absolutely no idea why which is a little disconcerting but the bottom line is it works!

Thanks.

[kkeonline]

@OneCD Thanks for the script
The script can detect partition and install autorun link to it
I call autorun.sh directly from ssh command and it working
but when I reboot the autorun.sh did not call by the system

Edit:
I forgot to enable autorun from control panel as tell in your note, that why it not call at reboot

For those with QTS 4.3.x, you'll also need to let QTS know that it should permit the autorun.sh script to execute. Navigate to Control Panel -> System -> Hardware, then enable the option "Run user defined processes during startup".

[z3d0_]

Hi @OneCD, for the TS-128 I had to edit the line

Code: Select all

mount -t ubifs ubi2:config "$DOM_mount_point"

with

Code: Select all

mount -t ext4 /dev/mmcblk0p7 "$DOM_mount_point"

and then it worked. Thanks for your script!

[OneCD]

for the TS-128 I had to edit the line

Code: Select all

mount -t ubifs ubi2:config "$DOM_mount_point"

with

Code: Select all

mount -t ext4 /dev/mmcblk0p7 "$DOM_mount_point"

Thank you for posting your solution!

Can you check this setting on your NAS?

Code: Select all

getcfg -f /etc/platform.conf 'CONFIG STORAGE' 'FS_TYPE'

[z3d0_]

Code: Select all

[~] # getcfg -f /etc/platform.conf 'CONFIG STORAGE' 'FS_TYPE'
ubifs

The error I got was the following:

Code: Select all

[~] # ./create-autorun.sh 

---| Details |-------------------------------------------------------
 * script version                   : 2017.02.12.01
 * NAS model                        : TS-X28 (TS-128)
 * QTS version                      : 4.3.3 #20170901
 * default volume                   : /share/CE_CACHEDEV1_DATA

---| Log |-----------------------------------------------------------
 √ DOM partition found              : /dev/mtd6
mount: unknown filesystem type 'ubifs'
 X Unable to mount the UBIFS DOM partition!

---| Result |--------------------------------------------------------
 X Autorun installation failed!  

[OneCD]

Well, that’s weird.

Looks like your platform.conf has the wrong filesystem type in it.

[schumaku]

Well, that’s weird.

Very logical somebody or some script logic made the conclusion that "Platform = ARM_AL" is Annapurna Labs - what does translate to "CONFIG STORAGE" FS_TYPE = ubifs ...

[OneCD]

How should this be fixed, Kurt?

[schumaku]

How should this be fixed, Kurt?

Temporary fix would be checking for TAS-x28/TS-x68 and make an exception handling.

[OneCD]

Here's a new version for testing. Share and enjoy!

edit: attachment removed

[schumaku]

Hm, nope - it's really ext4 on these NAS .... look here:

[~] # /bin/mount -t ext4 /dev/mmcblk0p7 /tmp/config
[~] # umount /tmp/config

[~] # /bin/mount -t ext2 /dev/mmcblk0p7 /tmp/config
mount: wrong fs type, bad option, bad superblock on /dev/mmcblk0p7,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

The QNAPedia does also refer to xt4 for these models: https://wiki.qnap.com/wiki/Running_Your ... at_Startup

Pushed this issue to QNAP to review FWIW.

[OneCD]

I was hoping EXT2 would have worked there. So, QNAP really used EXT4 on the DOM?

[schumaku]

Yeah, was under the impression that ext4 must be a type in the QNAPedia - and figured out it's not for these two model lines.

[OneCD]

Ah, "typo" ... the irony.

That new version will try EXT4 regardless of model if the first mount command fails.