Bug #5598
closed
Updating 2.3 Nano fails from the webgui
100%
Description
Updating to a newer snapshot in the Nano install of 2.3 never completes from the webgui. It will update fine from the console however.
In the Package installation window it fetches all the required packages and check the integrity but never proceeds past that. There are no messages on the console.
The system log does not show anything.
Testing using 1GB 32bit Nano install.
Files
Updated by
Updated by Phillip Davis almost 9 years ago
The webGUI displays the text that is coming in /tmp/webgui-log.txt
/tmp/webgui-log.sock exists
But this message appears in among the progress output:
pkg: No such event pipe: /tmp/webgui-log.sock
It seems to have downloaded the various packages OK and put the downloaded files into /tmp/nanobsd_upgrade... - which is a mount point for the other slice /dev/ufs/pfsense1 :
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ufs/pfsense0 1890014 493005 1245807 28% /
devfs 1 1 0 100% /dev
/dev/ufs/cf 50527 2733 43752 6% /cf
/dev/md0 39196 452 35612 1% /tmp
/dev/md1 59036 22148 32168 41% /var
devfs 1 1 0 100% /var/dhcpd/dev
/dev/ufs/pfsense1 1890014 534556 1204257 31% /tmp/nanobsd_upgrade
/var/run/pfSense-upgrade.pid has the PID of the upgrade process and that process exists:
root 18362 0.0 0.1 16996 2660 - I 11:12AM 0:00.05 /bin/sh /usr/local/sbin/pfSense-upgrade -y -l /tmp/webgui-log.txt -p /tmp/webgui-log.sock
pfSense-upgrade script function fetch_upgrade_packages() never returns. It just seems to be hung/stuck waiting for ???
Here is the content of /tmp/webgui-log.txt :- WARNING **
Duplicate slice required!!
Before start upgrade process, current mounted nanobsd partition
needs to be cloned to secondary partition, where update will happen
Cleaning secondary partition... done.
Duplicating current slice... done.
Restoring slice label... done.
Mounting second partition to run upgrade... done.
Unlocking package pfSense-kernel-pfSense... done.
Downloading upgrade packages...
pkg: No such event pipe: /tmp/webgui-log.sock
Checking for upgrades (6 candidates): ...... done
Processing candidates (6 candidates): ...... done
The following 5 package(s) will be affected (of 0 checked):
Installed packages to be UPGRADED:
pfSense-rc: 2.3.a.20151207.1541 -> 2.3.a.20151208.1928 [pfSense-core]
pfSense-kernel-pfSense: 2.3.a.20151207.1541 -> 2.3.a.20151208.1928 [pfSense-core]
pfSense-default-config-serial: 2.3.a.20151207.1541 -> 2.3.a.20151208.1928 [pfSense-core]
pfSense-base-nanobsd: 2.3.a.20151207.1541 -> 2.3.a.20151208.1928 [pfSense-core]
pfSense: 2.3.a.20151207.1704 -> 2.3.a.20151208.1059 [pfSense]
The operation will free 5 KiB.
41 MiB to be downloaded.
Fetching pfSense-rc-2.3.a.20151208.1928.txz: . done
Fetching pfSense-kernel-pfSense-2.3.a.20151208.1928.txz: .......... done
Fetching pfSense-default-config-serial-2.3.a.20151208.1928.txz: . done
Fetching pfSense-base-nanobsd-2.3.a.20151208.1928.txz: .......... done
Fetching pfSense-2.3.a.20151208.1059.txz: . done
Checking integrity... done (0 conflicting)
Updated by Chris Buechler almost 9 years ago
- Status changed from New to Confirmed
- Affected Architecture All added
- Affected Architecture deleted (
i386)
Updated by Phillip Davis almost 9 years ago
- WARNING **
Duplicate slice required!!
Before start upgrade process, current mounted nanobsd partition
needs to be cloned to secondary partition, where update will happen
I changed the wording of that on my system, on the active slice, (and submitted a PR just yesterday). But the old wording is being displayed. I think the other slice will have the script with the old wording. That makes me think that the process might be running the pfSense-upgrade script from the non-active slice before the duplicate slice happens? Or? If that is so, it could be not a good thing - the other slice could contain some older version that does who knows what.
I just did the update from console menu 12. That showed me the new wording, so it is running from somewhere good (or the previous hung upgrade had successfully done the duplicate slice and so the script on the other slice now already had the new wording).
Sorry, I might have totally confused things with this post - but maybe it will trigger some helpful thought about the sequence of events and how it can get stuck.
Updated by Renato Botelho almost 9 years ago
I need to confirm, but I'd guess the issue happen on nanobsd when '-p /path/socket' parameter is used.
Updated by Renato Botelho almost 9 years ago
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Applied in changeset b3b10d30794a60ed9a781cc3c8e0d29b774bf86e.
Updated by Phillip Davis almost 9 years ago
Much better, I did a successful upgrade from the webGUI. Sample output attached.
There is a point where there is some output from tar:
tar: Failed to set default locale
It is no big deal, but that line was the last line of output for a couple of minutes while the tar was running. The word "Failed" is a bit worrying for the mere mortal user :) So maybe something could be done to make a locale setting happen and avoid this bit of output.
Updated by Phillip Davis almost 9 years ago
This all looks good.
I just did an upgrade from the webGUI and all was good. I even had one of the downloads time out (due to the fact that there were lots of other things downloading and clogging up my slow internet) and it happily retried and succeeded in the end without any manual intervention. I have attached the output as an example.