Upgrade from 2.3.1 to 2.3.1_5 failed withoit reson alix-borad nanobsd



  • Updating repositories metadata…
    Updating pfSense-core repository catalogue...
    pfSense-core repository is up-to-date.
    Updating pfSense repository catalogue...
    pfSense repository is up-to-date.
    All repositories are up-to-date.
    **** WARNING ****
    Duplicate slice required!!

    Before starting the upgrade process, the currently mounted nanobsd partition
    needs to be cloned to the secondary partition, where the update will happen

    After installation a reboot will be required to switch partition.

    Cleaning secondary partition... done.
    Duplicating current slice... done.
    Restoring slice label... done.
    Testing duplicated partition integrity... done.
    Mounting second partition to run upgrade... done.
    Unlocking package pfSense-kernel-pfSense... done.
    Downloading upgrade packages...
    Updating pfSense-core repository catalogue...
    Unable to update repository pfSense-core
    Updating pfSense repository catalogue...
    Unable to update repository pfSense
    All repositories are up-to-date.
    Checking for upgrades (42 candidates): .......... done
    Processing candidates (42 candidates): .......... done
    The following 41 package(s) will be affected (of 0 checked):

    Installed packages to be UPGRADED:
    php56-zlib: 5.6.21 -> 5.6.22 [pfSense]
    php56-xmlwriter: 5.6.21 -> 5.6.22 [pfSense]
    php56-xmlreader: 5.6.21 -> 5.6.22 [pfSense]
    php56-xml: 5.6.21 -> 5.6.22 [pfSense]
    php56-tokenizer: 5.6.21 -> 5.6.22 [pfSense]
    php56-sysvshm: 5.6.21 -> 5.6.22 [pfSense]
    php56-sysvsem: 5.6.21 -> 5.6.22 [pfSense]
    php56-sysvmsg: 5.6.21 -> 5.6.22 [pfSense]
    php56-sqlite3: 5.6.21 -> 5.6.22 [pfSense]
    php56-sockets: 5.6.21 -> 5.6.22 [pfSense]
    php56-simplexml: 5.6.21 -> 5.6.22 [pfSense]
    php56-shmop: 5.6.21 -> 5.6.22 [pfSense]
    php56-session: 5.6.21 -> 5.6.22 [pfSense]
    php56-readline: 5.6.21 -> 5.6.22 [pfSense]
    php56-posix: 5.6.21 -> 5.6.22 [pfSense]
    php56-pdo_sqlite: 5.6.21 -> 5.6.22 [pfSense]
    php56-pdo: 5.6.21 -> 5.6.22 [pfSense]
    php56-pcntl: 5.6.21 -> 5.6.22 [pfSense]
    php56-openssl: 5.6.21 -> 5.6.22 [pfSense]
    php56-opcache: 5.6.21 -> 5.6.22 [pfSense]
    php56-mcrypt: 5.6.21 -> 5.6.22 [pfSense]
    php56-mbstring: 5.6.21 -> 5.6.22 [pfSense]
    php56-ldap: 5.6.21 -> 5.6.22 [pfSense]
    php56-json: 5.6.21 -> 5.6.22 [pfSense]
    php56-hash: 5.6.21 -> 5.6.22 [pfSense]
    php56-gettext: 5.6.21 -> 5.6.22 [pfSense]
    php56-filter: 5.6.21 -> 5.6.22 [pfSense]
    php56-dom: 5.6.21 -> 5.6.22 [pfSense]
    php56-curl: 5.6.21 -> 5.6.22 [pfSense]
    php56-ctype: 5.6.21 -> 5.6.22 [pfSense]
    php56-bz2: 5.6.21 -> 5.6.22 [pfSense]
    php56-bcmath: 5.6.21 -> 5.6.22 [pfSense]
    php56: 5.6.21 -> 5.6.22 [pfSense]
    pfSense-rc: 2.3.1 -> 2.3.1_5 [pfSense-core]
    pfSense-kernel-pfSense: 2.3.1 -> 2.3.1_5 [pfSense-core]
    pfSense-default-config-serial: 2.3.1 -> 2.3.1_5 [pfSense-core]
    pfSense-base-nanobsd: 2.3.1 -> 2.3.1_5 [pfSense-core]
    pfSense-Status_Monitoring: 1.3_1 -> 1.4.2_1 [pfSense]
    pfSense: 2.3.1 -> 2.3.1_5 [pfSense]
    ntp: 4.2.8p7 -> 4.2.8p8 [pfSense]
    expat: 2.1.0_3 -> 2.1.1_1 [pfSense]

    44 MiB to be downloaded.

    Locking package pfSense-kernel-pfSense… done.
    Failed


  • LAYER 8 Netgate

    https://redmine.pfsense.org/issues/6557

    Tell DNS resolver to listen on All or temporarily run the forwarder or something and upgrade. pfSense will need DNS resolution on 127.0.0.1 to upgrade NanoBSD.

    You'll need to do this one more time to go to 2.3.2 when released in which it is permanently fixed.



  • Hi sjheinz,

    did you solve that problem on your side?

    Just asking as I am having the exact same trouble and either don't get what Derelict suggests as solution or it's just not working.

    • I've checked for the resolv.conf, it's there and has 127.0.0.1 and other working dns entries inside.

    • Tried to either activate DNS forwarder as well as DNS resolver with listen on ALL interfaces.

    • Added those lines to my pfSense-upgrade script which seems to be the fix for 2.3.2 (?!):

    # Make sure resolv.conf is present, otherwise upgrade may fail (bug #6557)
    _exec "cp -f /etc/resolv.conf ${chroot_dir}/etc" "Copying resolv.conf to upgrade partition" mute
    

    with those lines added and the update fails like that:

    >>> Copying resolv.conf to upgrade partition... 
    cp: /tmp/nanobsd_upgrade/etc/resolv.conf and /etc/resolv.conf are identical (not copied).
    

    So resolv.conf is present and identical … also wouldn't make sense to me if that file would be missing as the upgrade script just cloned that file from the active slice as far as I understand the upgrade process.

    It's quite annoying and I would probably stop putting more effort into this and wait for the next major release to write directly on CF card and the just reload my backed up config, because each try takes about 1h on that slow hw ... so I already spent around close to 10h just trying to get it fixed.

    If I remember that right I had that system running before on a pfSense 2.0 RC (close to release) which unfortunately was taken out by power loss and never came back up, both filesystem slices were hardly damaged and as I had a recent copy of the config I didn't bother trying to repair it and did a fresh install on a new CF card which I used this image for pfSense-CE-2.3.1-RELEASE-4g-i386-nanobsd.img.gz ... this all worked very nicely, all configs were imported, nothing I had to do except for fresh install and restore. But that upgrade to 2.3.1_5 is just not working for me.

    Can I download older pfSense releases somewhere? For the time being I might go back to an older release as the 2.3.1 is also quite slow on that Alix board and we'll be going to replace the hardware in the near future anyways or I'll just stay on 2.3.1 and ignore the update until then ...

    .redgoldgreen


  • LAYER 8 Netgate

    The problem is that /etc is a symlink to /var/etc, which is a RAM disk which is not included in the cloned slice that is upgraded. Before the upgrade the duplicate slice is chrooted to. After that, no more /etc/resolv.conf so FreeBSD uses 127.0.0.1 by default.

    This is corrected permanently in 2.3.2, due shortly, but will still require a fix to get there from where you are.

    The easiest thing to do is to temporarily make pfSense listen on localhost for DNS queries.

    If you're feeling randy and want to manually patch /usr/local/sbin/pfSense-Upgrade instead:

    First:

    cp /usr/local/sbin/pfSense-upgrade /root

    That's so you can cp /root/pfSense-upgrade /usr/local/sbin if you have to.

    Edit the /usr/local/sbin/pfSense-upgrade file

    After this line:

    
    _exec "mount /dev/${_update_partition} ${chroot_dir}" "Mounting second partition to run upgrade" mute
    

    Add these lines:

    
           # Make sure resolv.conf is present, otherwise upgrade may fail (bug #6557)
           local _resolv_conf=$(readlink -f /etc/resolv.conf)
           _exec "cp -f ${_resolv_conf} ${chroot_dir}/etc/resolv.conf" \
                   "Copying resolv.conf to upgrade partition" mute ignore_result
    

    As always, if you mess about like this and muck things up, it's on you to fix it with a reinstall/whatever so have a backup config at least.



  • Thanks for your help Derelict, very much appreciated.

    It's not that I want to manually patch it, that was just one of my tries to get the update working.

    Tinkering around a bit more I found out that the DNS forwarder probably worked the whole time, but (I guess) because of restoring my old config it set my CF card read-only, this somehow ended up for me in showing the same error pattern like having no DNS resolution.

    I didn't pay too much attention to this since in pre 2.3.x (?!) there was a button to switch the card from RO to RW … now there is no button but this info "NanoBSD is now always read-write to avoid read-write to read-only mount problems." which somehow let me to ignore the fact that the card was in RO mode.

    So, I opened a shell and set the card writeable by executing "/etc/rc.conf_mount_rw" which set the card according to the webgui into RW mode, still being in RW mode after a reboot of the box.

    Now that I had a working DNS resolution and a writeable card for the upgrade I'll tried it once more to end up here:

    
    [38/39] Upgrading pfSense-base-nanobsd from 2.3.1 to 2.3.1_5...
    ===> Keeping a copy of current version mtree
    [38/39] Extracting pfSense-base-nanobsd-2.3.1_5: 
    pkg: archive_read_extract() errno -1: Lzma library error: Corrupted input data
    [38/39] Extracting pfSense-base-nanobsd-2.3.1_5... done
    [38/39] Deleting files for pfSense-base-nanobsd-2.3.1_5: ..... done
    >>> Locking package pfSense-kernel-pfSense_wrap... done.
    Failed
    
    

    Everything before seems to be fine to me, but if wanted I can post the full output.

    Any idea whats going wrong there? After this the CF card is set again into RO mode by the system!

    Next thing I am going to try is to reset to factory defaults, only set up internet connection and try to update again, hoping that restoring my old config somehow messed up something in the system. As a last resort I could try a different CF card, though I don't think it's faulty … it's a fresh out of the box Sandisk Ultra 4GB.



  • @redgoldgreen:

    Next thing I am going to try is to reset to factory defaults, only set up internet connection and try to update again, hoping that restoring my old config somehow messed up something in the system. As a last resort I could try a different CF card, though I don't think it's faulty … it's a fresh out of the box Sandisk Ultra 4GB.

    In doing so I succeeded with the update to 2.3.1_5, so I'm sure the errors I got trying to upgrade the system were somehow triggered by restoring my config from a 2.0-RC-release. I just have no clue what part of the config might cause this problem but something inside it was definitly responsible for that error:

    pkg: archive_read_extract() errno -1: Lzma library error: Corrupted input data

    Now I have no more trust in restoring my old config on that box and probably go the way of manually setting up everything again.

    Actually I just found out because I was running out of options what else I can do to get the update running, as all info I could find about importing configs said it's no problem and will work even when you switch systems etc. only exception I could find was don't use a newer-version-config on an older-version-system, which I did not. Is that still the case or is this outdated information?

    I guess there were just too many changes in the packages used by pfSense from the version I came from to where I'm going to have that config file simply restored on the recent version.

    Is there any interest in debugging this further? If so, please give me instructions how I could help and what info I should provide.

    Don't think that I had a very exotic configuration on my pfSense, it was a simple NAT router setup with pppoe WAN interface and some OpenVPN settings, nothing very special, so I could image other users might be running into the same problems trying to upgrade.


  • LAYER 8 Netgate

    2.0-RC is ancient. Being an RC config there is no guarantee all the necessary configuration upgrade code was in place. Nor is there any promise that it will be. The problem likely stems from choosing to leave an RC in place instead of finalizing on a RELEASE way back then. It is unrealistic to expect a seamless upgrade to a development snapshot from 5 years ago.

    Instead of upgrading you could save your config, install a nice, fresh, full install, then try to restore your config. Maybe try to restore just parts of it and see which part is failing. That might save you some work.



  • @Derelict:

    2.0-RC is ancient. Being an RC config there is no guarantee all the necessary configuration upgrade code was in place. Nor is there any promise that it will be. The problem likely stems from choosing to leave an RC in place instead of finalizing on a RELEASE way back then. It is unrealistic to expect a seamless upgrade to a development snapshot from 5 years ago.

    Instead of upgrading you could save your config, install a nice, fresh, full install, then try to restore your config. Maybe try to restore just parts of it and see which part is failing. That might save you some work.

    Yes, I know it's quite old, due to both slices failing I can't tell you the exact version of the RC but I think it was like the last one before release, so I probably had hopes restoring the config could probably work fine.

    In regards of getting the system up and running with that config it did work perfect, my whole pre-2.0-config was restored and working on a fresh 2.3.1 install, all it did was to break the update to 2.3.1_5.

    So, I'm good, my problems are solved … I'm on the current stable build/patch and already have everything setup I need running again, was just asking if there is need to dig into that further as here are some threads on the forum about problems upgrading to 2.3.1_5 where I could imagine the problem could also be related to the config files.

    If so just let me know if I could help ...

    Besides all that, you guys are really doing a good job on pfSense, keep up the great work.

    I'll definitly go gold for you guys soon, would also like to buy an appliance but as I am from germany it unfortunately doesn't make any sense regarding shipping cost, taxes, etc.


Log in to reply