Entware-ng indeed starts/stops the (executable) scripts in /opt/etc/init.d/, but you can't simply move the scripts from /ffp/start/ to that directory.

You'll have to exchange the she-bang. An FFP script starts with #!/ffp/bin/sh, an Entware-ng script should start with #!/bin/sh . Further in Entware-ng a script ending with '.sh', is sourced, which means that it will run in the context of the calling script. That has a speed advantage, but if the script crashes, it will also take down the calling script, stopping the Entware-ng startup. So you'd better remove the extension.

Anyone having issues with the January batch of entware-ng updates (11th, I think)? I can't use bash as my shell anymore, just exits straight way. Have switched to ash for the user shell (/opt/bin/sh), and if I try to launch bash from there:

Guys, does anyone know why bash exits every time when I try to start it? It issues the "exit" command every time and I'm back to busybox. Is there any way to change the default shell in Entware-ng from busybox to bash?

As you can see it uses pselect6 to wait for keystrokes. And you see me typing 'exit', and bash exits.

Don't know how to handle this. Maybe I have to create a libc for kernel 2.6.15, so that libc will contain a stub for pselect6. But if bash calls pselect6 directly, that won't help. (And it would be bad practice, from the bash maintainers)

Quote:

Is there any way to change the default shell in Entware-ng from busybox to bash?

As you can see it uses pselect6 to wait for keystrokes. And you see me typing 'exit', and bash exits.

Don't know how to handle this. Maybe I have to create a libc for kernel 2.6.15, so that libc will contain a stub for pselect6. But if bash calls pselect6 directly, that won't help. (And it would be bad practice, from the bash maintainers)

NSA310 actually uses kernel 2.6.31.8....Yes, got the same result here, it complains about this pselect6 function. Maybe this should be reported to the Entware-ng maintaners....?

EDIT: a quick tour at the bash source code revealed that bash itself doesn't use that function. The function is being used by the readline library, bundled with bash. Tried to compile bash without the readline library support and the built product was usable, but not pleasant at all. Without the library, bash doesn't have the ability to edit the command line and also the command line history function... So, in any case, a libc rebuild will be required.

EDIT2: maybe recompiling the c libraries won't be necessary after all. It seems that pselect code, using by the bundled readline library, is optional and not definite.From bash-4.4.12/lib/input.c:

Yet, the configure script says there is pselect support. Not sure where it gets that info from, I presume it's /opt/include, but it doesn't make any sense to add support for something, included in the headers, but not included in the lib binaries. So, the problem was to prevent the configure script from finding it. After editing it (removed pselect from line 9807 in ./configure), the built product was usable, the only difference was it's huge size, but it's normal, considering a native compilation was made. Maybe I should try to rebuild the package, using the Entware-ng toolchain...

pselect() is a function in libc, which is available. pselect6 is a function in the kernel. Normally pselect() should do a call to pselect6, but when it detects it does not exist, it can call pselect5 (I think), which does about the same, but has some race conditions (google for 'man pselect6' for details).

Quote:

the only difference was it's huge size, but it's normal, considering a native compilation was made

Native compilation has nothing to do with the size. Assuming the same compiler version, native or cross, the binary should have the same size.I think you have to strip your binary. ('strip bash').

pselect() is a function in libc, which is available. pselect6 is a function in the kernel. Normally pselect() should do a call to pselect6, but when it detects it does not exist, it can call pselect5 (I think), which does about the same, but has some race conditions (google for 'man pselect6' for details).

So, you're suggesting the kernel part of that chain is missing (at least in the NSA310's kernel)... It makes sense to build the binaries from the Entware-ng repo, using the headers I currently have, otherwise why would anyone offer them in a first place. I haven't had such problem with ffp, but that's probably because of the different (as lib itself and versions) C libs it uses.Anyway, that looks to me as a pretty much clumsily made thing, because there is obviously not any check if all the links in the chain are in place before requesting that functionality.

Quote:

Native compilation has nothing to do with the size. Assuming the same compiler version, native or cross, the binary should have the same size.I think you have to strip your binary. ('strip bash').

Tried that and now the binary is almost as big as the binary that comes with Entware-ng. Thanks for the tip!

So, you're suggesting the kernel part of that chain is missing (at least in the NSA310's kernel)...

Not only on the 310 kernel, but also on the 325. So I guess it's on all NSA3xx boxes.

Quote:

pretty much clumsily

I'm not sure where to put the blame. Entware-ng officially only supports kernel 2.6.32 and up. You can't even run stock Entware-ng on your NAS, because it errors out with 'Fatal, kernel too old'.To bypass that, I have rebuild Entware-ng libc targeting 2.6.24. That is supposed to mean that libc will implement all relevant kernel calls up to now (or up to the date of the libc sources), but tests for the functionality added between 2.6.24 and now. If the functionality is not present, it will emulate it, or call an older implementation.That seems to work. This libc libraries have been bearing Entware-ng on the ZyXEL nas for 2 years.

Libc doesn't need to check for the existence of pselect6, because it's targeting 2.6.24 and up. That function is supposed to exist, as it's introduced in 2.6.16.

I can imagine ZyXEL somehow excluded pselect6. (But why?). That would explain the current problem. But why does it show up now? The libc package isn't changed, only bash is. And maybe some other libraries. Normally a binary never calls the kernel directly, but only wrapper functions in libc. I can't imagine libc::pselect() isn't used before, it's a very common function to wait for I/O. But maybe the passed parameters are changed, triggering this bug.

Quote:

I haven't had such problem with ffp, but that's probably because of the different (as lib itself and versions) C libs it uses.

Indeed. Can't remember the details now, but FFP0.7/arm targets a much older kernel. 2.6.12, or something like that. (And it uses uClibc, not glibc like Entware-ng)

Not only on the 310 kernel, but also on the 325. So I guess it's on all NSA3xx boxes.

Except maybe the NAS326, which uses much newer kernel (3.x.x). Speaking of which: what happens if the current Entware-ng zypkg finds kernel, which is 2.6.32 and up (like what would happen on NAS326)? Does it still install those down-versioned libs or installs the stock one?

Quote:

I'm not sure where to put the blame. Entware-ng officially only supports kernel 2.6.32 and up. You can't even run stock Entware-ng on your NAS, because it errors out with 'Fatal, kernel too old'.To bypass that, I have rebuild Entware-ng libc targeting 2.6.24. That is supposed to mean that libc will implement all relevant kernel calls up to now (or up to the date of the libc sources), but tests for the functionality added between 2.6.24 and now. If the functionality is not present, it will emulate it, or call an older implementation.That seems to work. This libc libraries have been bearing Entware-ng on the ZyXEL nas for 2 years.

Libc doesn't need to check for the existence of pselect6, because it's targeting 2.6.24 and up. That function is supposed to exist, as it's introduced in 2.6.16.

I can imagine ZyXEL somehow excluded pselect6. (But why?). That would explain the current problem. But why does it show up now? The libc package isn't changed, only bash is. And maybe some other libraries. Normally a binary never calls the kernel directly, but only wrapper functions in libc. I can't imagine libc::pselect() isn't used before, it's a very common function to wait for I/O. But maybe the passed parameters are changed, triggering this bug.

I think it was a matter of time such bugs to occur, considering the use of down-versioned libs for the older kernels. How about if I change the kernel with a newer one, I found some interesting posts like this one.

Speaking of which: what happens if the current Entware-ng zypkg finds kernel, which is 2.6.32 and up (like what would happen on NAS326)? Does it still install those down-versioned libs or installs the stock one?

By design it won't install the down-versioned libs on kernel >=2.6.32. In case of the 326 it will install the armv7 version of Entware-ng, for which I didn't compile those libs anyway.

Quote:

How about if I change the kernel with a newer one, I found some interesting posts like this one.

Well, if you are able/willing to change the kernel, you can get problems from the other side. The firmware which can no longer run on the kernel. So you'd need to install Debian or something like that, in which case you don't need Entware-ng anyway.

BTW I'm reading this ATM. Wow, answer like this one sounds to me like a "If you want that, then do it yourself!". If those two are devs, then I must be Santa Claus or the Easter rabbit.

Imho, zyxmon answer was/is correct. Entware-ng uses kernel 2.6.32 sources and compatible glibc, so some of their binaries uses syscalls and glibc functions not available in device using kernel older than 2.6.32. This includes pselect6,ppoll,epoll_pwait kernel syscalls and corresponding glibc functions.

There is no magic here and Zyxel is not sabotaging kernel sources in this case. Although man pages of pselect6 states:

Quote:

pselect() was added to Linux in kernel 2.6.16. Prior to this, pselect() was emulated in glibc (but see BUGS).

So, glibc recompilation with stubs using 2.6.15 or even 2.6.31.8 kernel headers will not help to run binaries, which uses at least pselect6,ppoll or epoll_pwait. The only way is to recompile affected binaries itself, because they might have (might not have as well) fallback mechanism avoiding using these kernel syscalls and corresponding glibc functions and will match available your current glibc functions.

So, glibc recompilation with stubs using 2.6.15 or even 2.6.31.8 kernel headers will not help to run binaries, which uses at least pselect6,ppoll or epoll_pwait. The only way is to recompile affected binaries itself, because they might have (might not have as well) fallback mechanism avoiding using these kernel syscalls and corresponding glibc functions and will match available your current glibc functions.

So, the solution would be something like what I suggested here (EDIT2)?

Yes, but for best result @Mijzelf should implement this in the patched libs, used for the older kernels. Compiling the latest source, targeting the kernel 2.6.24.EDIT: or just update the patched libs to the latest version 2.26.

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum