× NETGEAR will be terminating ReadyCLOUD service by July 1st, 2023. For more details click here.
Orbi WiFi 7 RBE973
Reply

How to update RAIDiator 4.2.28 Virtual Machine to 4.2.31

Sandshark
Sensei

How to update RAIDiator 4.2.28 Virtual Machine to 4.2.31

I use a RAIDiator 4.2 Virtualbox virtual machine to help answer questions that come from here. ( See RAIDiator-x86-4-2-28-VirtualBox-image-notsupported).  In that thread, Chirpa stated that "Firmware upgrades via FrontView won't work, would have to copy new root.tlz to boot flash then do an OS re-install."  I can confirm that's the case.  It will appear to be updating, but will fail and come up with 4.2.28 again.  And while there are probably few differences from 4.2.28 to 4.2.31 that would ever make a difference in my usage, I decided to figure out just how to do that, and I succeeded.  If anyone is still out there developing apps for 4.2, this could be helpful.  I won't go through the trial-failure-try again cycle it took to figure this out, just what did ultimately work.  Once I got there, it was that typical Homer Simpson "Doh" moment.

 

I did the work in a Windows 10 environment, but the basics of the process could be performed in another OS, including Linux, if you have suitable tools..

 

The first thing you need to do is extract the contents of the 4.2.31 update file.  After unzipping, the file with no extension is a tarball with a 4000(Hex) byte header.  I used a hex editor to remove the header (UltraEdit is my tool of choice for such things, but it is a paid program).  Basically, you remove everything down to the first file name csums.md5, then save with the extension .tar.  Next, use your tool of choice (mine is 7Zip) to extract the contents of the .tar file.

 

Before you do anything else, make a copy of the entire VM folder, just in case you mess up and need to go back.

 

Next, you need to be able to work with the RAIDiator-x86-4.2.28-disk1.vmdk file, which serves as the "flash memory" of the virtual NAS.  I converted it to a .vhd using VMDK2VHD (Google it, it's available from several sites).  Then, Windows 10 can mount the .vhd as a drive (right-click and mount).  Before you do that and go any farther, though, I recommend that you change Disk1 in your VM to use the converted .vhd and verify is still boots.

 

Using a .vhd file is easier, but another way (maybe more useful for those working outside Windows) would be to mount the .vhdk as an additional drive in a Windows or other virtual machine.  VirtualBox will complain that it has already registered that drive's UUID, so you have to change it.  Go to your VirtualBox installation folder in a command window and execute vboxmanage internalcommands sethduuid "<fully qualified path to the Disk1 .vhdk>", which will change the UUID to a different random one.  After you have mounted it in the Windows VM, you'll need to change the UUID again so the NAS VM will not complain, and you may have to remove and re-attach the file to the NAS VM (I didn't go far enough down this path to see).

 

The "flash memory" is DOS formatted, so you don't need to have any special tools to view or change the content if you have mounted it in Windows using one of these methods.  So, now that it's a virtual drive on your Windows machine or VM, it's time to do the magic.  You need to delete the old root.tlz and put in the new one from the update file.  (That's the OS in an .lzma file, BTW.)  You also need to edit csums.md5 and replace the hash code for root.tlz with the one in the cums.md5 from 4.2.31.  As always when working with Linux files in a Windows environment, use an editor that doesn't mess with the formatting (again, I use UltraEdit).  Don't just copy csums.md5 or any other files from the update into the flash image -- I think they are actually from OS6, not OS4.2, so the ones from OS4.2 will make your VM not boot.  Next, you need to edit syslinux.cfg and change default Normal to default OSReinstall.  Note that this is likely case sensitive.

 

Now, just unmount the .vmdk or .vhd from Windows and boot the NAS VM (note above instructions on re-assigning UUID again if you used that method).  If you've set up RAIDar to be able to see the VM, you should see it shows the NAS status as "Updating".  Then, the VM will go offline.  I think that's where it's supposed to re-boot, but it doesn't.  Which is good, because it would just update again.  So, forcibly shut down (not reboot) the VM with Virtualbox.  If you don't have RAIDar up to see the NAS status, make sure you wait long enough for an update.  Unfortunately, there is no indication of what's going on on the VM's display.

 

Now, using the same process to edit the contents of the "flash", go back and change the default in syslinux.cfg back to Normal.  Boot the VM, and you are running OS4.2.31.  Note that like all OS re-installs, network configuration is changed to DHCP and the admin password is reset.  It turns out it is reset to "password", not the typical "netgear1" for OS4.2.  I'm not sure if Netgear finally changed that or if it's because the boot kernel and initrd.gz in flash are actually from OS6.  This took me a bit to figure out (I ultimately just guessed correctly that it happened), so remember it.

 

Note that before I figured this process out, I tried replacing the disk2 .vmdk with an empty one to force a Factory Default.  It seemed to work, but no volume was created and none could be created (at least via Frontview).  I suspect that's either because of the OS6/OS4.2 hybrid system or a safeguard Netgear has in the OS to prevent a VM's use as a real NAS with suitably large virtual drives.  The OS definately recognizes that it's running in VirtualBox (just as it recognizes it's running on real ReadyNAS hardware from the motherboard bios, most likely).  So, don't try that.  If you have never had a 4.2 VM, make sure you have one running 4.2.28 before moving to the update.

Message 1 of 3
Sandshark
Sensei

Re: How to update RAIDiator 4.2.28 Virtual Machine to 4.2.31

An odd thing I just discovered.  After the update, the NAS VM was reporting a hostname based on the MAC address, as is the default.  But in Frontview, it still showed what I had named it.  Changing it, then changing it back, fixed it only temporarilly.  Rebooting brought it back to the MAC based name.

 

So, I took a look at /etc/hosts and /etc/hostname.  At boot, hosts contained both IP addresses (for the two virtual NICs) and the hostname twice on  each line.  After I edited the hostname.in Frontview, it contained only the IP for the first interface and the hostname once.  etc/hostname also contains the right name.  I have no clue why it is picking up the wrong hostname at boot nor why it is over-writing /etc/hosts every time.   etc/hostname does not seem to do a thing.  I changed the content, and it had zero effect but was not overwritten at boot.

Message 2 of 3
Sandshark
Sensei

Re: How to update RAIDiator 4.2.28 Virtual Machine to 4.2.31

There is an alternative to creating the .vdi with VBoxManage instead of VMDK2VDI (good for those not using Windows). 

vboxmanage clonehd "virtualdisk.vmdk" "new-virtualdisk.vdi" --format vdi

Thatt creates the .vdi with a new UUID every time.  So, you could even make two copies, one set to the default OS re-install and the other normal.  Then just swap between them in the VirtualBox settings. 

 

You can leave off the --format vdi and make a .vmdk clone if you prefer to work with that format.

 

I also wanted to add that Windows' creation of a Volume Information folder and Recyle Bin when you mount the virtual drive does no harm.

Message 3 of 3
Discussion stats
  • 2 replies
  • 1659 views
  • 3 kudos
  • 1 in conversation
Announcements