Project

General

Profile

Actions

Bug #5598

closed

Updating 2.3 Nano fails from the webgui

Added by Steve Wheeler over 8 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
Upgrade
Target version:
Start date:
12/04/2015
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.3
Affected Architecture:
All

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

pfsenseupgrade20151210.txt (3.47 KB) pfsenseupgrade20151210.txt Phillip Davis, 12/10/2015 09:25 AM
pfsenseupgrade20160105.txt (20.2 KB) pfsenseupgrade20160105.txt Phillip Davis, 01/05/2016 01:09 AM
Actions #1

Updated by Jim Thompson over 8 years ago

  • Assignee set to Renato Botelho
Actions #2

Updated by Jim Thompson over 8 years ago

  • Category set to Upgrade
Actions #3

Updated by Phillip Davis over 8 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)

Actions #4

Updated by Chris Buechler over 8 years ago

  • Status changed from New to Confirmed
  • Affected Architecture All added
  • Affected Architecture deleted (i386)
Actions #5

Updated by Phillip Davis over 8 years ago

I noticed another thing. There was text emitted:
  • 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.

Actions #6

Updated by Renato Botelho over 8 years ago

I need to confirm, but I'd guess the issue happen on nanobsd when '-p /path/socket' parameter is used.

Actions #7

Updated by Renato Botelho over 8 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions #8

Updated by Phillip Davis over 8 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.

Actions #9

Updated by Phillip Davis about 8 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.

Actions #10

Updated by Chris Buechler about 8 years ago

  • Status changed from Feedback to Resolved

works

Actions

Also available in: Atom PDF