Update stuck (Update: FreeNAS-9.10.1-U4 has already been applied. Please Reboot the system to avail)

[drinny]

I was able to resolve by using the CLI updater and the 9.10.2 tar image. YMMV.

If you've already attempted to install and failed. Reboot (or find and kill the failed update process), delete the boot record for your failed 9.10.2.

Then as root:

cd /var/tmp
wget http://download.freenas.org/9.10/STABLE/9.10.2/FreeNAS-9.10.2.tar
freenas-update FreeNAS-9.10.2.tar


THANK YOU! I've been refreshing the bug tracking page and this thread all day without any updates of a fix.

I did what you suggested and it worked like a champ. Thanks again!

 

[jlpellet]

Thanks for the info but for me it hung at 20% same as GUI.

I was able to resolve by using the CLI updater and the 9.10.2 tar image. YMMV.

If you've already attempted to install and failed. Reboot (or find and kill the failed update process), delete the boot record for your failed 9.10.2.

 

[drinny]

Thanks for the info but for me it hung at 20% same as GUI.

How long did you give it before you gave up? If you run "freenas-update -v FreeNAS-9.10.2.tar", you should see some more output as the script runs.

I logged into another ssh session while the update was running and watched the update process via top. From the automatic GUI update, the process would sit at 0.0% CPU utilization shortly after running. But manually downloading the tar file above and doing the update from the CLI, the process was constantly active so I could see it was still working on something.

I didn't time how long it took, but it was a while. Maybe 20-30 minutes or so from start to finish where it finally dropped me back at a command prompt.

 

[xenu]

Just wanted to add that the solution provided by "NamoMitK" worked for me. Thanks!
I held off updating because of the problems reported so this was my initial 9.10.2 update.
The update process from the CLI took about 5 minutes. After it was done I did a reboot and it rebooted twice before it was done. So far everything seems to work fine though I only use FreeNAS for NFS4 with Kerberos & CIFS shares.

 

[jlpellet]

From the CLI, it stuck at the same 20% as the GUI for over 30 minutes. I tried last night from the GUI & it stayed at the same 20% for over 30 minutes but I let it run overnight & it completed successfully in ~2 hours. I did not watch it but the system was rebooted to 10.2 overnight.

How long did you give it before you gave up? If you run "freenas-update -v FreeNAS-9.10.2.tar", you should see some more output as the script runs.

 

[raidflex]

Seems like updates are not being tested enough before release. This has happened in the past with failed updates not too long ago. In the past I do not remember experiencing so many issues with updates.

 

[Robopaul]

From the CLI, it stuck at the same 20% as the GUI for over 30 minutes. I tried last night from the GUI & it stayed at the same 20% for over 30 minutes but I let it run overnight & it completed successfully in ~2 hours. I did not watch it but the system was rebooted to 10.2 overnight.

Same here...
... tried to update to 9.10.2, GUI update stucked at 20%, manually activated new boot, booted with error, rolled back to 9.10.1-U4 and booted again. Next try with Update via GUI - stuck again at 20%
I kept it running allone for some time (maybe 2 hours), looked in forum here for solving proposals, looked back to my server - and FreeNAS was already running at 9.10.2 (update was completed and server rebooted and running again).

 

[travanx]

Just went through this problem and ended up fresh installing and restoring config.

 

[melloa]

Waiting on update on shell ... GUI froze at 20% and shell is already stuck at 20% also:


[root@bennas /var/tmp]# wget http://download.freenas.org/9.10/STABLE/9.10.2/Free
NAS-9.10.2.tar
--2016-12-23 01:44:39-- http://download.freenas.org/9.10/STABLE/9.10.2/FreeNAS-
9.10.2.tar
Resolving download.freenas.org (download.freenas.org)... 89.207.133.46
Connecting to download.freenas.org (download.freenas.org)|89.207.133.46|:80... c
onnected.
HTTP request sent, awaiting response... 200 OK
Length: 414834866 (396M) [application/octet-stream]
Saving to: ‘FreeNAS-9.10.2.tar’

FreeNAS-9.10.2.tar 100%[===================>] 395.62M 17.3MB/s in 35s

2016-12-23 01:45:15 (11.1 MB/s) - ‘FreeNAS-9.10.2.tar’ saved [414834866/41483486
6]

[root@bennas /var/tmp]# freenas-update FreeNAS-9.10.2.tar
Status: Installing base-os
Total Progress: [########________________________________] 20.00%

----------- EDIT --------------

From the open ticket: Bug #19695

It didn't freeze, it simply takes a long time. Make sure you have sufficient free space. (zfs gets horrifically slow when free space gets low, and most thumb drives are slow themselves. And yes, this was an exceptionally large update.)

 

[Ericloewe]

Waiting on update on shell ... GUI froze at 20% and shell is already stuck at 20% also:


[root@bennas /var/tmp]# wget http://download.freenas.org/9.10/STABLE/9.10.2/Free
NAS-9.10.2.tar
--2016-12-23 01:44:39-- http://download.freenas.org/9.10/STABLE/9.10.2/FreeNAS-
9.10.2.tar
Resolving download.freenas.org (download.freenas.org)... 89.207.133.46
Connecting to download.freenas.org (download.freenas.org)|89.207.133.46|:80... c
onnected.
HTTP request sent, awaiting response... 200 OK
Length: 414834866 (396M) [application/octet-stream]
Saving to: ‘FreeNAS-9.10.2.tar’

FreeNAS-9.10.2.tar 100%[===================>] 395.62M 17.3MB/s in 35s

2016-12-23 01:45:15 (11.1 MB/s) - ‘FreeNAS-9.10.2.tar’ saved [414834866/41483486
6]

[root@bennas /var/tmp]# freenas-update FreeNAS-9.10.2.tar
Status: Installing base-os
Total Progress: [########________________________________] 20.00%

----------- EDIT --------------

From the open ticket: Bug #19695

It didn't freeze, it simply takes a long time. Make sure you have sufficient free space. (zfs gets horrifically slow when free space gets low, and most thumb drives are slow themselves. And yes, this was an exceptionally large update.)

Same thing happened here, took even longer than it used to at 60-70% full.

 

[melloa]

Same thing happened here, took even longer than it used to at 60-70% full.

Not sure why. A fresh install could take 20 ... 30 minutes on a slow usb drive. Why the update took several hours? My main NAS on SSD was must faster I should say, but is there a way to alert users, so they won't panic and stop the update midway? I did and messed up one of my boxes and had to go back to another boot environment, delete the broken one, etc.

 

[tworhythms]

I can also confirm that leaving the update (learned this the third time around) for about 1.5 hours (updated from the GUI) will succeed. It would be a great idea if there was a way to inform users that it could take that long. Normal updates before this took a fraction of the time.

My system consists of a 16GB USB (Enterprise) Boot Drive (Dell R710 w/32GB ECC RAM) and pool capacity is at around 45% (12TB total).

 

[rogerh]

When I tried the update a second time it worked in 16 minutes, on pretty slow hardware. But several things didn't work properly so I've gone back to 9.10.1-U4.

 

[sef]

Why the update took several hours?

This particular update was extra large, and that's a lot of it. Installation takes a new filesystem, and writes the files to it; an upgrade, on the other hand, ends up removing files first and then writing them. It works out to a lot more I/O being done, and more time. Also, if the system dataset is on the same media as the boot pools, then that's doing all that I/O with one device, which even with the mostly-lacking seek time penalties, is still going to make it slower. And, of course, the system is still in use which means even more I/O happening on it.

 

[RedRover]

From the CLI, it stuck at the same 20% as the GUI for over 30 minutes. I tried last night from the GUI & it stayed at the same 20% for over 30 minutes but I let it run overnight & it completed successfully in ~2 hours. I did not watch it but the system was rebooted to 10.2 overnight.

Thanks for the feedback. I did the same as you and left the upgrade to do its own thing. 2 hours later and it was completed. :)

 

[Wallybanger]

I'm attempting the 9.10.2 update from U4 for the second time. It's hung at base-os 1/5 again. If it doesn't work this time I'll be sticking with U4 until this problem gets corrected.

 

[sef]

If it doesn't work this time I'll be sticking with U4 until this problem gets corrected.
View attachment 15123

Due to the way updates work, if it doesn't work in this one, it will never work with any later one -- you'll have to do an ISO update or use the command-line (which is what I recommend).

 

[Wallybanger]

Due to the way updates work, if it doesn't work in this one, it will never work with any later one -- you'll have to do an ISO update or use the command-line (which is what I recommend).

Maybe I'm just not waiting long enough considering some of the guys are saying the update is taking 2hrs. I'll wait and see but if it doesn't work, would that not be something that iXsystems should fix?

 

[Ericloewe]

Maybe I'm just not waiting long enough considering some of the guys are saying the update is taking 2hrs. I'll wait and see but if it doesn't work, would that not be something that iXsystems should fix?

It is working, it just takes forever and a day. USB devices are a pain in the ass.

 

[sef]

I don't know why it's not working. Best guess I have is that something about how the Web UI does the update is causing a failure at some point, but not getting caught as an exception. But I don't know what that is, or why the exception isn't being caught.

I haven't had the problem happen when using the CLI, and that's how I do all my debugging for the update process.

In order to fit the described behaviour, the system needs to install some, but not all, of the packages, and then somehow has to make the new BE active -- which is something that only happens in the successful case, unless I missed a code path that I've kept looking for -- and then reboot. Now, if it rebooted without making the new BE active, that would be more explicable (to me), but it's that one step happening that flummoxes me.

I'm going to assume that the size of the update is resulting in a timeout of some sort, resulting in ... something hand-wavy.