Wow, In-depth analysis!
You are right, the script is not very coherent, and maybe that's my fault. This part (the reading of USRPKG_DEPS_START) is new for firmware 5, and it's by default not in use. (That file doesn't exist).
I *think* ZyXEL planned to implement the possibility to install 3th party packages, by simply uploading them in the webinterface, and this is a part of the implementation, which is not mature.
That feature never made it, and maybe that is because I already ported MetaRepository to firmware 5 before they had time to finish it. And now we are left with a strange semi-manufactured scriptlet.
Anyway, you asked for a way to run your own scripts, and this is a way. OK, the script has to contain the string '/i-data/'. In most cases that string will already be there, as /i-data/ is the only sane place to put your binaries and other scripts. I guess that's the reason I never stumbled upon this 'feature'.
(To be honest, I only used this for starting my 'optware'
package. When MetaRepository for fw 5.10 was ready, I had more convenient ways to get my scripts run).
The lines I quoted are not in use by the regular packages, nor by the 3th party packages installed through MetaRepository (which are 'regular', from the NAS' point of view). Their startscript /i-data/sysvol/.PKG/<package>/etc/init.d/<package> is called another way.
inside typos like "#ckeck ZYPKG_DEPS format"
Bear with them. The scripts are written by Taiwanese engineers. English is /not/ their native language.
How is possible to modify files in /etc/* or /ram_bin/* in permanent way (i.e. for surviving reboot)?
For /etc/ you can't, unless you are building your own firmware. /etc/ is inside the initramfs, which is embedded in the kernel.
For /ram_bin/ there is a possibility, but you should use it with care. /ram_bin is the mountpoint of an ext2 containing file sysdisk.img, which is mounted read-only. Further the containing partition of sysdisk.img (sda1 on fw 4, md0 on fw 5) is mounted read-only.
The file sysdisk.img itself is extracted from flash. The compressed file is part of a firmware update.
On boot the checksum of sysdisk.img is compared to a stored one, and if it doesn't fit, a fresh copy of sysdisk.img is extracted. This mechanism is used for firmware updates. So if you change anything in /ram_bin/*, it will be reverted on boot.
There is a way out. If you read /etc/init.d/rcS (containing among others the sysdisk.img extraction code), you'll see that the existence of a file /firmware/mnt/sysdisk/mount.sda1.rw.flag will skip the checksum test, and the partition md0 will be mounted rw (on /firmware/mnt/sysdisk/).
So, to be able to edit /ram_bin/*, and let it survive a reboot, you'll have to
Code: Select all
mount -o remount,rw /firmware/mnt/sysdisk/
After reboot you maybe have to remount /ram_bin/ rw. On fw 4.x that wasn't necessary, can't remember the status for fw 5. At least I don't see the mount.sda1.rw.flag flag handled in the mounting of sysdisk.img.
You'll have to remove the mount.sda1.rw.flag before updating the firmware. Theoretically it's possible that a new initramfs won't be compatible with an old sysdisk.img file, leaving you with a non-booting box. (In that case you can still use the 'Univeral stick
' to get early telnet access, but why accept that inconvenience?)
How can I see a messages, sent by scripts to stdout during startup? /var/log is almost empty. Is there such a tool like dmesg?
Not that I'm aware of. AFAIK the stdout messages are only send to, well, stdout. You can see them, but only by looking to console, which is on the serial port.
If you eventually decide to enrich your tutorial with my researches above, I will have no objections.
Well, thanks. I don't think I will use it, as this mechanism is not really a part of the package system, and the package system is complex enough without sidely related stuff.
P.P.S. Are you an ZyXEL developer, Mijzelf?
Seeing your analysis of that script, that's almost an insult. No, I have nothing to do with ZyXEL. My
activities are just a private hobby.