This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
The title says it all. I upgraded and now I cannot compile virtualbox 5.1 using the linux linux-4.4.190-x86_64 kernel.
I know the postings say do not, but is there anyway to go back in conjunction with a factory reset? Happy to lose it all and start over as I really need the VMs working.
I thought about pasting the source image in the root partiion, replacing the current one and forcing a factory reset--which would in theory push the 6.9 image. of course now i cannot find where the image is stored, but i saw it before...
I just tested this on a virtual NAS. It is not necessary to modify the time. Instead of modifying the length, delete one byte after the header to make up for the one added in the header. To verify everything is aligned, go to 0x4000 and verify that the ASCII data csums.md5 starts exactly at 0x4000.
I called the "update" 6.10.8. The file name doesn't matter, BTW, just how it identifies itself in the file header.
I did not see any immediate issues with access, but @funglenn did see Samba issues, so consider that this downgrade may cause you to have to factory default to fix issues caused by downgrading Samba, and act accordingly.
You can do it via USB recovery. But if your drives are still installed, it may see the newer OS on them when you re-boot and update the flash to the version on them. If you have the drives out and then put the them back in after reverting, it will definately see the newer version and update the flash. So, you need to remove the partitions from the drives (losing all data) before you put them in, and start all over.
The "trick" to updating a legacy NAS to OS6 is to edit the header of the .img file with a hex editor to tell the OS the file is a 4.2.x update rather than 6.x. I have not tried to see if you can do the same with an OS6 NAS. The version number the update process checks is in plain text at the beginning of the file, and the md5sum follows it. I am pretty sure the md5sum doesn't include that version number and you can pull the same trick to downgrade an OS6 NAS. Note that the size= value is the entire length of the file, so if you are adding a digit to tell your NAS the 6.9.6 file is 6.11.0, you'll have to bump the size by one. I have no idea if it uses the time= parameter for anything, so you may need to bump it, too.
The method of updating via SSH may also work:
Via SSH, copy the firmware .img file to the /root directory
then do
# echo /root/name_of_image_file > /etc/.flash_update
then reboot the NAS
If you find you are having problems after the downgrade with a method that doesn't already do one, you may need to factory default. So, be sure you have a backup before you try anything.
Sounds like another experiment to put on my to do list.
Yes, I realize your unit is not a legacy system. I just mentioned that that method worked on them and likely would also on a non-legacy system.
USB recovery can be tricky, many have to trym a lot of different USB drives before it works. Editing the update file would be faster. If the NAS doesn't like the file, it will simply reject it.
I tried the USB Key now. I was able to get it recognized, it said USB recovery on the panel. Took the firmware and shutdown. Upon boot it said updating firmware but still booted into 6.10. but since it went through the motions, unsure it was the USB stick or file.
I am not sure how to do the file mod you mentioned. I think i would like to go to 6.9.4 so i can easily do custom kernel stuff but unsure how to do it. Any other page that discusses it?
THANK YOU! i used a hex editor and changed the version and padded the time as well.
As expected, the machine would not boot properly--the GUI would not load due to the changes in apache. However after a factory reset, it all came back up nicely as 6.9.4
now to wait for the resync and get back to work! i love this forum!
I just tested this on a virtual NAS. It is not necessary to modify the time. Instead of modifying the length, delete one byte after the header to make up for the one added in the header. To verify everything is aligned, go to 0x4000 and verify that the ASCII data csums.md5 starts exactly at 0x4000.
I called the "update" 6.10.8. The file name doesn't matter, BTW, just how it identifies itself in the file header.
I did not see any immediate issues with access, but @funglenn did see Samba issues, so consider that this downgrade may cause you to have to factory default to fix issues caused by downgrading Samba, and act accordingly.
thanks. after a full factory reset back at 6.9.6. I find it to be faster than the 6.10 for the GUI--which is strange as Apache states that the 2.4 upgrade is supposed to be not only security related but also provide for a faster experience. However most importantly, I had lamented the loss of a few apps like GateOne and Tauitulli for Plex.
However funny enough i tried to revert the virtual NAS image from 6.6.0 to 6.3.x and it refused work, even using the tricks that I used for the real Readynas 516.... go figure....
Going back that far, there may be additional checks. I don't think the legacy NAS conversion process on which I based this existed back that far, and maybe the change is even to support that (though it's still unofficial). I think 6.6.x was the current version when I first did it.
Actually the VM does use a syslinux boot loader though obviously it doesn't need the custom boot loader code for the various hardware used (LEDs, reset button etc.)
Watching it boot, it appears it uses the standard boot code. I can see it check for a display and some other things, then it goes on when it doesn't find them. It ultimately identifies itself as a VM in the GUI where other NAS have their model number.
