missing features in Linux firmware, ever heard of this?

[xmiinc]

I loved my LG N4B1 so much, I bought a second one! (I know...not cutting edge, buts its been really reliable).

But there is a small problem.

I bought the new one for rsync and at the moment I can't set it up as a client. Here's why--I know this is a general forum, but have you ever heard of this kind of thing?--While the fw for the two machines is the same, the new unit has a different feature set. Specifically, I'm
missing the Rsync, Time Machine, and NFS features in fw4284 (supposedly?) Both machines were updated with the same tar.bz2, but one of the units has these features and the other doesn't. I can't explain this, same drives-same capacity-same formatting...other than to
say one machine went through a progression of firmwares
4241->4261->4284 and the new unit directly from 2734->4284. Am I maybe dealing with delta updates here?

Any suggestions?

Cheers,
Tom

 

[bnborg]

I would re-install the "firmware", possibly using the CD from the "old" N4B1 and then upgrading it to 4284.

Mine was messed up and I re-installed. When I brought it back up and re-established the RAID, all my copied files were back!

 

[xmiinc]

Thanks, yeh I ended up doing that already last night. The N4B1 site has an 'Initialize Drive' iso that takes you back to factory defaults and removes any previous firmware. One then starts from scratch with the installer cd. I then took each fw upgrade and cycled through it...took me hours...but in the end...no love. Still 3 fewer attributes on the web admin page of the newly-purchased NAS than the old one. Strange huh? And they are the same unit: both manufactured in Feb 2009.

The *only* difference between them now is something that happened last summer, where the (old) NAS went off-line due to a bug that had been identified by LG that prevented the log file from auto-erasing previous entries. When the file went out-of-bounds, it crashed the system with a '00_32' error. LG had a recovery disk that patched the then-current firmware, eliminating the bug. But the one they posted didn't work for me. So I went to a Korean LG contact I had, and he provided me with a 'version 2' of the recovery disk that DID work for me. And things went smoothly from there with two subsequent fw updates since then.

And yes, I have sent an email to my LG contact on this problem, so far no reply.

So, I don't know if its reasonable to assume that a 'special' recovery disk might have made the difference in enabling these features? I don't intend to apply a fix to a non-existent problem to find out, though.

But I DO strongly suspect the features are part of the installer script, but commented out. What I really need is some terminal/console Linux guru to inspect the fw installer file and tell me what to uncomment in there!

Thanks again, Tom

I would re-install the "firmware", possibly using the CD from the "old" N4B1 and then upgrading it to 4284.

Mine was messed up and I re-installed. When I brought it back up and re-established the RAID, all my copied files were back!

 

[bnborg]

I used to consider myself a guru but now I think I've forgotton more than I ever knew. None the less, as I delve into it I start to remember a few things.

In Unix/Linux, the system is started using scripts in the directory /etc/init.d. The primary one is rcS. It starts other scripts. From rcS:

#================================================
# Service on/off (samba/afpd/ftp/dyndns/daapd)
#================================================
usermod -g root admin
usermod -u 0 -o admin
/etc/sss_script/share/query_share.sh config
/etc/init.d/quota start
/etc/init.d/services start​

Note, the usermod lines were originally commented with #. Uncommenting them enables root access. /etc/init.d/services has the following:

/etc/init.d/servers start
​

And then /etc/init.d/servers has:

cd /etc/sss_script/services
. ./service.conf > /dev/null 2>&1
​

Thus we find out that /etc/sss_script/services/service.conf is where these are set:

appletalk=off
ftp=on
ftp_port=21
dyndns=off
daap=on
daap_update=force
dlna=off
printer=off
hibernation=on
hibernation_minutes=30
ups=off
ups_shutdown_time=0
ups_poweroff=on
rsync=off
nfs=on
​

I don't know if this helps but at least it might give you a start. This is a curious problem. Maybe a memory problem could cause it. Have you tried the self diagnosis, that is available under Information/Logs in the web interface?

 

[xmiinc]

Thanks, bnborg!
This may indeed give me a start, as I did a bit of script editing last summer (following very specific instructions in an attempt to enable telnet and install some web services) so I have the tools to do this. If I find these entries, and they're off, then we might be on to something here! Thanks again! Well check back in to post my progress. Tom

 

[bnborg]

That's a good reference. The one I had found wasn't for the N4B1 but it had the concept of mounting the NAS' drive offline and editing rcS.

Note, if you use any text editors under Windows, you need to run them through a utility such as dos2unix to strip the carriage returns.

 

[xmiinc]

Still can't get the unit to display the additional services.

Tried many different things in the past 24hrs. At first I extracted the dir tree using Pacifist and edited appropriate files with vi. Trouble was I couldn't re-tar it in exactly the same structure. Why? There were about a dozen numbered directories in root-level on the original installer tar that couldn't be extracted that therefore couldn't be put back in a mod'd archive. Each directory-name started with a sequence of integers, btw 1 and 31, followed by a space and numbers beginning with '2001 dev' up to '2008 dev' in seemingly random order. They seemed to be dates, but over 8 years? Maybe they had something to do with previous updates?

Closer inspection had directory trees and filenames that made me think they were related to hardware and interface layers, with names like 'mem' and 'lp0'.

Then I had to figure out how to compress the directories back into an archive and not a folder in the archive (did you know '% sudo tar cjf filename.tar.bz2 .' will generate the error "Can't add archive to itself" but generate a perfectly usable archive anyway?) But never could enable the services.

Then I started from scratch, taking a different approach, using a new unzip'd tar, I just uncommented telnet and added root permissions. That worked. So I do have telnet access now, but its Read-only and can't be forced into write. But I can see that rsync, nfs, and timemachine are off. I don't know how/if I can edit directories within the tar without extracting the tree first? And I can't change them on a running machine.

What next? Any ideas?

 

[xmiinc]

Hey, just discovered I *can* use HexFiend to do all the line edits I want, without exposing the tar to the OSX filesystem. Neat! just waiting for a clean version of the latest installer to dl...

Will report results...

 

[xmiinc]

OK, learning something here...I can edit the rcS file and sbin/telnetd to enable telnet, but if I edit services.conf by itself, it either doesn't bring up the services I expect to see, or it fails completely with an "Invalid file" error.

So, my tools are OK, but it seems I'm missing something in the script that would make these services materialize on the web menu. I suspect services.conf is simply where user-choices on those services are written to when the services are available, but it doesn't have a hand in actually making them available. Judging from my success with the telnet daemon, I should probably be looking for something similar for rsync/nfs/timemachine?

Thoughts?

Hey, just discovered I *can* use HexFiend to do all the line edits I want, without exposing the tar to the OSX filesystem. Neat! just waiting for a clean version of the latest installer to dl...

Will report results...

 

[bnborg]

You could try to start some of the services when you telnet in. It all originates in /etc/init.d. All of the files there are shell scripts. All except rcS take "start" or "stop" as parameters. Some also take a "restart" or "reload". Most will give you a usage message if invoked without parameters.

Some of the scripts, such as samba, deal with just one service. Others like servers and services deal with multiple services. Some are started by rcS and some start other scripts. Anyway if you can figure out which script starts which service(s), you can try invoking them directly.

Looking at /etc/init.d/servers, I do see the problem with trying to edit service.conf directly. I think it is re-initialized every bootup:

# restore service folder structure
tar xjf /boot/home.tar.bz2 -C /

This is done in the /etc/sss_script/services directory. The servers script also echos lines into services.conf. But most are set somewhere else.

Yesterday I was copying a lot of files to the N4B1 "directly" my mounting the drive to back up on the eSata port of the NAS. I then telnetted to the box and used cp. I used nohup first so I could logoff and let it continue overnight.

But it seemed like it would get "bogged down" and stop doing anything. In telnet I could do ps or top to see running processes, and there were all these httpd's and smbd's taking up a lot of memory. So I traced where these were started and stopped and where they were configured. I took a while but I found them. I edited them with vi and restarted them but some were still "hanging on". So I rebooted the NAS and sure enough the number of processes was less.

So it is possible to change things, I tell you. But your problem has me baffled. I mentioned memory because I thought if there was a lack of resources, maybe that was preventing some of the services from running. From my N4B1:

root@LG-NAS:~> cat /proc/meminfo
MemTotal: 126164 kB
MemFree: 13988 kB
Buffers: 34288 kB
Cached: 34688 kB
SwapCached: 296 kB
Active: 25544 kB
Inactive: 52588 kB
SwapTotal: 256952 kB
SwapFree: 255872 kB
Dirty: 44 kB
Writeback: 0 kB
AnonPages: 9104 kB
Mapped: 9888 kB
Slab: 15024 kB
SReclaimable: 7240 kB
SUnreclaim: 7784 kB
PageTables: 676 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 320032 kB
Committed_AS: 68384 kB
VmallocTotal: 385024 kB
VmallocUsed: 17572 kB
VmallocChunk: 360444 kB

root@LG-NAS:~> cat /proc/vmstat
nr_free_pages 3497
nr_inactive 13151
nr_active 6386
nr_anon_pages 2276
nr_mapped 2473
nr_file_pages 17322
nr_dirty 0
nr_writeback 0
nr_slab_reclaimable 1810
nr_slab_unreclaimable 1948
nr_page_table_pages 169
nr_unstable 0
nr_bounce 0
nr_vmscan_write 35509
pgpgin 125321044
pgpgout 456988
pswpin 15275
pswpout 31110
pgalloc_dma 37856126
pgalloc_normal 0
pgfree 37859624
pgactivate 507050
pgdeactivate 547936
pgfault 31076083
pgmajfault 21565
pgrefill_dma 28444889
pgrefill_normal 0
pgsteal_dma 31346472
pgsteal_normal 0
pgscan_kswapd_dma 4303424
pgscan_kswapd_normal 0
pgscan_direct_dma 27521728
pgscan_direct_normal 0
pginodesteal 10
slabs_scanned 2816
kswapd_steal 4225601
kswapd_inodesteal 0
pageoutrun 69041
allocstall 429720
pgrotated 35334​

I have no idea what most of these mean, but I would think you should see something similar. Maybe it will help.

By the way, I should mention busybox. This binary, in /bin, is what actually handles almost all of the commands. You can enter busybox by itself to see what all it does. Most of the commands will take the --help parameter.

 

[xmiinc]

Thanks, bnborg...had to deal with some health-related issues, which is why I've been incommunicado for the past week. But now I'm back at this...for comparison's sake, here are the stats I come up with:

[admin@NASrsync:/ ] $ cat /proc/meminfo
MemTotal: 126164 kB
MemFree: 52224 kB
Buffers: 35564 kB
Cached: 23724 kB
SwapCached: 0 kB
Active: 49380 kB
Inactive: 18088 kB
SwapTotal: 256952 kB
SwapFree: 256952 kB
Dirty: 68 kB
Writeback: 0 kB
AnonPages: 8208 kB
Mapped: 8220 kB
Slab: 4364 kB
SReclaimable: 1828 kB
SUnreclaim: 2536 kB
PageTables: 580 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 320032 kB
Committed_AS: 53480 kB
VmallocTotal: 385024 kB
VmallocUsed: 17572 kB
VmallocChunk: 360444 kB

...roughly the same as your's (btw, I didn't realize you were on the N4B1 too!)

Below is where things diverge a bit, as you can see I have no stats at all below pgmajfault. Like you, I don't know if that's significant, but if anything above or below jumps out at you, please let me know!

[admin@NASrsync:/ ] $ cat /proc/vmstat
nr_free_pages 13056
nr_inactive 4521
nr_active 12346
nr_anon_pages 2052
nr_mapped 2055
nr_file_pages 14822
nr_dirty 0
nr_writeback 0
nr_slab_reclaimable 456
nr_slab_unreclaimable 639
nr_page_table_pages 145
nr_unstable 0
nr_bounce 0
nr_vmscan_write 0
pgpgin 38226
pgpgout 1862936
pswpin 0
pswpout 0
pgalloc_dma 14073554
pgalloc_normal 0
pgfree 14086613
pgactivate 11171
pgdeactivate 0
pgfault 67113392
pgmajfault 269
pgrefill_dma 0
pgrefill_normal 0
pgsteal_dma 0
pgsteal_normal 0
pgscan_kswapd_dma 0
pgscan_kswapd_normal 0
pgscan_direct_dma 0
pgscan_direct_normal 0
pginodesteal 0
slabs_scanned 0
kswapd_steal 0
kswapd_inodesteal 0
pageoutrun 0
allocstall 0
pgrotated 0

 

[xmiinc]

Is there any significance to the 'rsyncd.conf' reference here in the script when the actual /etc directory doesn't contain that .conf?

d /etc/sss_script/share/rsync..SYS_PASSWD="/etc/passwd".DEFAULT_CONF="/etc/rsyncd.conf".DEFAULT_CONF_BACKUP="/etc/rsyncd.bak".DEFAULT_SECRETS="/etc/rsyncd.secrets".DEFAULT_SECRETS_BACKUP="/etc/rsyncd.sec_bak"..kill_rsync_daemon().{.while [ true ].do..id=`ps | grep "/usr/local/bin/rsync --daemon"

 

[xmiinc]

I tried your suggestion of examining busybox, but I'm up against the limits of my unix knowledge...I don't know how to invoke or what to do beyond that. Simply typing /bin/busybox ls just gives identical output as ls. Perhaps that *is* busybox doing its thing? But how do I distinguish between busybox output and normal output? Thx

 

[xmiinc]

Solved!

I wish I could say it was because of some fancy hacking, but...doubtful. Instead, after contacting LG and preparing to ship the NAS out to them, I logged into the web interface one more time, hoping the serial number might be there (it wasn't). But while I was there, the interface came up with the short-form menu options, as is my habit, I hit the long-form button and...incredibly, considering the time I put into troubleshooting this...all the services appeared! (In two weeks time since upgrading the firmware I could've sworn I'd done this at least once? Oh well.)

Ironically, my last email to a contact I have at LG contained a 'hunch' on my part that perhaps 'the services were there...' but that the php page wasn't picking up the 'function return' from the service initialization. That would certainly appear to be the case.

What a long, strange, trip its been...at least I boned up on my telnet skills! And thanks, bnborg, for all your suggestions!