RN 102 : OS not loading after update from 6.4.x to 6.5.2 - Could not properly extract root image

[McLukic]

Dear Community Members,

After having a lot of issues with AD intergation on my company's several ReadyNASes, I found out that upgrading to OS 6.5.1 and later fixed a lot of things. So I gradually updated all of our devices.

One device however wouldn't perform the update : Although I initiated the update via the Web UI, after the reboot the OS would still be 6.4.x. But the device remained up and running.

I should have inspected all the log files before... but I decided to give a last try yesterday. Bad idea !

Now the system is unreachable through SSH or the Web UI. It now gets an address by DHCP whereas before it was set up to have a fixed IP.

I telnet'ed into tech support console and found following message in the initrd.log :

Could not properly extract root image!

And also before that, in some othe rlog file, there were old messages corresponding to the times where I tried to update but without losing the access afterwards, and the messages were about "firmware update file mismatch" or something like that.

I managed to mount md0 and found that all data was still there.

Tried to download the 6.5.2 image file, create a an /etc/.flash_update and do a rn_shutdown -r, but I have not gained anything : Web UI and SSH still unavailable. Of course, the shares are not accessible either.

Can someone tell me how I can restart the device without factory resetting ?

Thank you !

[mdgm-ntgr · Accepted solution]

It seems one of your files could not be overwritten.

tar: can't remove old file ./etc/frontview/samba/smb.conf.defaults: Operation not permitted

I changed it so that that file could be overwritten and it should now be fixed.

Your system is rebooting.

[mdgm-ntgr]

Your 4GB root partition is likely full. One needs to find what's filling it and deal with that before one can successfully update the firmware in such a situation.

[McLukic]

Hi,

Thank you for your answer. By root partition I suppose you mean the /dev/md0 filesystem ?

I logged in tech support mode and can do some tests.

It seems the root partition is not full, more than 3GB are avaliable :

# df -h
Filesystem                Size      Used Available Use% Mounted on
udev                     10.0M         0     10.0M   0% /dev
/dev/md0                  3.7G    391.2M      3.1G  11% /mnt

here is the initrd log :

cat var/log/frontview/initrd.log
[2015/11/11 05:52:08] Factory default initiated by Frontview!
[2015/11/11 05:52:25] Defaulting to X-RAID2 mode, RAID level 1
[2015/11/11 05:53:12] Factory default initiated on ReadyNASOS 6.4.0 (ReadyNASOS).
[2015/11/12 00:38:20] Updated from ReadyNASOS 6.4.0 (ReadyNASOS) to 6.4.0 (ReadyNASOS).
[2016/09/05 14:33:47] Update image checksum mismatch (68f727c38eb779e1f906f7228c5e8289/a76365896a20bca43e583103e6963b6e)!
[2016/09/05 14:54:02] Update image checksum mismatch (68f727c38eb779e1f906f7228c5e8289/61e145194e9ff06f9d07b3550471bf6c)!
[2016/09/15 02:06:04] Update image checksum mismatch (68f727c38eb779e1f906f7228c5e8289/f0e03da7b672fd59237a36ff0457d6c9)!
[2016/09/15 02:22:36] Update image checksum mismatch (f4fcd05fdb724eddf453948c4f0fe7be/19d07d76d0b5ea31347b4dddeb553269)!
[2016/09/20 14:41:53] Update image checksum mismatch (34b8b991c91124a8a652ba22387d5910/c91293df64d6f70321dcbe8d294b6dc6)!
[2016/09/20 14:49:08] Update image checksum mismatch (34b8b991c91124a8a652ba22387d5910/9fa872a62ed907d8f75b9ce42adedf81)!
[2016/10/12 09:24:01] Could not properly extract root image!
[2016/10/12 09:24:01] Updated from ReadyNASOS 6.4.0 (ReadyNASOS) to 6.5.2 (ReadyNASOS).
[2016/10/13 02:17:04] Could not properly extract root image!
[2016/10/13 02:17:04] Updated from ReadyNASOS 6.5.2 (ReadyNASOS) to 6.5.2 (ReadyNASOS).
[2016/10/13 07:49:19] Could not find update image!

The last line comes from yesterday's attempt to manually d/l the firmware img file and create an etc/.flash_update file pointing to it.

Here the last lines of fwbroker.log :

Oct 12 2016 17:21:05 INFO:START_DOWNLOAD_DEMON: complete=59531264
Oct 12 2016 17:21:06 INFO:START_DOWNLOAD_DEMON: write firmware file to the disk bytes=59531264
Oct 12 2016 17:21:06 INFO:START_DOWNLOAD_DEMON: Checking file for md5...
Oct 12 2016 17:21:06 INFO:CHECK_MD5_SUM: local=34b8b991c91124a8a652ba22387d5910 remote=34b8b991c91124a8a652ba22387d5910
Oct 12 2016 17:21:06 INFO:CHECK_MD5_SUM: MD5 OK! Create link in /etc/.flash_update -> .flash_update_file
Oct 12 2016 17:21:06 INFO:retrieve update information: version=6.5.2, size=59531264, descr=ReadyNASOS Update, url=https://kb.netgear.com/app/answers/detail/a_id/31116
Oct 12 2016 17:21:06 INFO: GETFW: READY, REBOOT IN TIMEOUT
Oct 12 2016 17:21:07 INFO: request method POST
Oct 12 2016 17:21:07 INFO: dpv_=dpv_1476285466000, njl_id_=njl_id_2444, type=FirmwareProgress
Oct 12 2016 17:21:07 INFO:retrieve update information: version=6.5.2, size=59531264, descr=ReadyNASOS Update, url=https://kb.netgear.com/app/answers/detail/a_id/31116
Oct 12 2016 17:21:07 INFO:PROGRESS: SUCCESS

Is there anything more I should check ?

Thank you very much 

[mdgm-ntgr]

What about the following?:

# df -i

[McLukic]

Hi,

df -i
df: invalid option -- i
BusyBox v1.24.1 (2016-04-26 16:42:47 PDT) multi-call binary.

Usage: df [-PkmhT] [FILESYSTEM]

[mdgm-ntgr]

I have sent you a PM.

[mdgm-ntgr · Accepted solution]

It seems one of your files could not be overwritten.

tar: can't remove old file ./etc/frontview/samba/smb.conf.defaults: Operation not permitted

I changed it so that that file could be overwritten and it should now be fixed.

Your system is rebooting.

[McLukic]

Hi,

Thanks a lot. I just have to reset the network settings but everything seems to be fully functional.

I remember that in the past, one of our IT guys wanted to mess with the idmap settings and changed the smb.conf and other files. He wanted this to be persistent across FW updates and I did chattr -i on (at least) this file... 

Can you just let me know where you found out that the culprit was smb.conf.defaults, and how you removed the immutable attribute ? I know that plain "chattr" does not work (at least not directly) in the session accessible via telnet.

And also one more question : are the next updates supposed to work without issues ? (provided we don't set -i on system files, of course...)

Anyway, thank you for having fixed my mistake.

Best regards,

[mdgm-ntgr]

I went to extract the firmware update manually and it complained about that file

# chattr -i filename

will change it so a file can be overwritten

# chattr +i filename

will change it so a file cannot be overwritten.