OPNsense Forum
Archive => 15.1 Legacy Series => Topic started by: chol on June 07, 2015, 08:38:35 pm
-
#1 A new install of the LibreSSL snapshot 15.1.9 cannot be upgraded by console option 12 nor by console option 8 (shell) by "opnsense-update -r 15.1.11" nor through GUI update any more I have an other upgraded LibreSSL 15.1.11 install. Did you change something here, the "_1" may be a hint?
#2 is there a factual differentiation between an update and an upgrade throughout your tools and console/GUI options?
#3 is there an upgrade path from LibreSSL snapshots to latest 15.1.11.3 ? If not why?
#4 How to get LibreSSL into a new fresh OpenSSL-15.1.11.x?
-
Hi Christian,
#1 A new install of the LibreSSL snapshot 15.1.9 cannot be upgraded by console option 12 nor by console option 8 (shell) by "opnsense-update -r 15.1.11" nor through GUI update any more I have an other upgraded LibreSSL 15.1.11 install. Did you change something here, the "_1" may be a hint?
"_1" was the revision trick we had to do previously (FreeBSD designates this to the ports revision and pkgng knows what to do with it), but that changed with 15.1.10. It doesn't matter for upgrades.
I just tested this on the old LibreSSL 15.1.9 ISO/amd64 snapshot and it works. What is your setup? Image, arch, networking setup (maybe it can't connect to the server).
#2 is there a factual differentiation between an update and an upgrade throughout your tools and console/GUI options?
Both are the same now, with the only exception of having fewer potential hiccups with a console upgrade (GUI upgrading the GUI is tricky as it turned out).
#3 is there an upgrade path from LibreSSL snapshots to latest 15.1.11.3 ? If not why?
There is, as I said just tested this.
#4 How to get LibreSSL into a new fresh OpenSSL-15.1.11.x?
There is GUI support coming up for changing OpenSSL/LibreSSL via an installed system through the firmware pages in time for 15.7.
Cheers,
Franco
-
"_1" was the revision trick we had to do previously (FreeBSD designates this to the ports revision and pkgng knows what to do with it), but that changed with 15.1.10. It doesn't matter for upgrades.
I just tested this on the old LibreSSL 15.1.9 ISO/amd64 snapshot and it works. What is your setup? Image, arch, networking setup (maybe it can't connect to the server).
OPNsense-LibreSSL-15.1.9-amd64 : just a fresh & crisp install from the snapshot repository 2 days ago (6. juni). I was asking because I considered the possibility that you might want to cut the upgrade path for the experimental 15.1.9 SSL images, so I was unsure. And, I needed the actual GUI changes, so I installed an 15.1.11 OpenSSL image.
#2 is there a factual differentiation between an update and an upgrade throughout your tools and console/GUI options?
Both are the same now, with the only exception of having fewer potential hiccups with a console upgrade (GUI upgrading the GUI is tricky as it turned out).
There are actually three pathways and three slightly different naming conventions involved!
I was referring to the naming in the shell tools/program "opnsense-update" in contrast to the OPNsense console menu item "12) Upgrade from console", in contrast to the GUI menu item "System⇒Firmware⇒Auto Update"
So your answer seems to indicate that the shell tool "opnsense-update" and the OPNsense console menu item "12) Upgrade are the same and stand in opposition to the slightly trickier GUI auto-update sftware-mechanics, right?
#3 is there an upgrade path from LibreSSL snapshots to latest 15.1.11.3 ? If not why?
There is, as I said just tested this.
Fine, must have been my user-error then, did test it multiple times / multiple ways (console, shell, WebGUI) yesterday, though.
#4 How to get LibreSSL into a new fresh OpenSSL-15.1.11.x?
There is GUI support coming up for changing OpenSSL/LibreSSL via an installed system through the firmware pages in time for 15.7.
Good to know, actually I remember you did mention something alike but nothing definitive. Thanks for the clarification, again!
Thank you!
-
So your answer seems to indicate that the shell tool "opnsense-update" and the OPNsense console menu item "12) Upgrade are the same and stand in opposition to the slightly trickier GUI auto-update sftware-mechanics, right?
The shell tool is just a nifty way of hiding the complexity. Right now, opnsense-update only does base/kernel, but will also do packages after the next update. This makes option "12" essentially the same as opnsense-update. The different code paths serve different scenarios, came with different challenges on top of a (I'm going to say it) unique mix of packages/base/kernel. It's only natural that these solutions differ and converge eventually. Designing this in one step always makes one miss something important along the way. pkgng/ports in FreeBSD evolve the same way, quite successfully so. We should keep up with them. :)
Short answer: terminology and code will improve and converge into something that is easily understood with each major release. For 15.1 we didn't have opnsense-update, for 15.7 it can do a full update cycle, extremely reliable. It will be interesting to see how 16.1 will look like.
Any idea how to debug your not being able to upgrade the old LibreSSL snapshots?
-
Short answer: terminology and code will improve and converge into something that is easily understood with each major release. For 15.1 we didn't have opnsense-update, for 15.7 it can do a full update cycle, extremely reliable. It will be interesting to see how 16.1 will look like.
Any idea how to debug your not being able to upgrade the old LibreSSL snapshots?
Thanks for that answer. Sometimes different names do indicate into different contexts, sometimes they eventually turn out to converge on the same context. I see it from the perspective of terminology, which does make a lot of sense, doctors wouldn't be able to work safely for the patients without it, especially internationally on different continents and cultures.
LibreSSL - I did install an OPNsense OpenSSL 15.1.11 image and updated from there. I did not intend to debug, but to know if the _1 name change after update of the LibreSSL image would indicate something, and particularly a cut in the upgrade path of the LibreSSL images from 15.1.9 up to 15.1.11, I only was curious.
-
Any idea how to debug your not being able to upgrade the old LibreSSL snapshots?
O.K.:
For the quick approach I did an other install of the same OPNsens_15.1.9_1-LibreSSL-amd64 image from two days ago into a virtual machine (Vbox)
Look the screenshots with error messages, please.
P.S.
the upgrade from console got me the 15.1.9 LibreSSL
and
% opnsense-update -kr 15.1.11_backports && reboot failed
% pkg upgrade -y
got an error "writesystem is full"
VM has 1GB RAM , 2GB HDD
-
Well, the file system is full, that prevents upgrades from being applied. Can you please provide output for:
# df -h
-
Making the disk bigger (10GB) would probably solve this.
-
O.k. the 3rd install delivers exactly what I got 10 days ago: Console menu item 12) Upgrade from console got me a LibreSSL 15.1.11.3 system. Eventually!
Look up the new screenshots please.
Thank you for the repo fix.
-
The console command
# pkg info | grep -i libre
gets me
"libressl-2.1.6_1"
---
# pkg info | grep -i openssl
gets me
"php56-openssl"
.. so it seems both are installed, and in the future one would have the OPNsense GUI option to change the SSL library used?
-
The OPNsense_OpenSSL_15.1.11.3 install shows:
# pkg info | grep -i openssl
openssl-1.0.1_19
and
# pkg info | grep -i libre
shows nothing.
So I have two installs with each having libressl OR openssl !!
O.K. I know more now, thank you again, Franco :)
-
Franco, out of your perspective, would you say?
Going from 15.1.9 to 15.1.11 would be an upgrade or an update?
And from 15.1.11 to 15.1.11.3 would be called what, update ?
And from 15.1.x to 15.7 would be -at least- called an upgrade?
-
Yes, OpenSSL and LibreSSL are mutually exclusive. LibreSSL is a drop-in replacement writing the same files, advertising itself as "OpenSSL" in file names. The APIs differ marginally, mostly due to cleanups and pruning done by LibreSSL. The reason why we "have both" is that OpenSSL has more hardware acceleration support than LibreSSL, otherwise they are interchangeable from a functional perspective. LibreSSL, however, has a tighter grasp on clear coding and already has had fever bugs and CVEs assigned since the fork.
I'm currently trying to convince pkgng to move from OpenSSL to LibreSSL and back, debugging parts, but I think it is very much doable this week.
As far as upgrade/update goes: for me both terms have always had the same meaning. Upgrade has more of a hardware vibe, but since we are talking about software that doesn't apply. What do you think? :)
-
"grade" seems to imply level up or down (grade A is higher than grade B, etc..)
"date" seems to imply fetching the newest stuff but not necessarily leveling up/down
In your version naming logic, is
.. going from 15.1.9 to 15.1.11 an upgrade or an update?
And from 15.1.11 to 15.1.11.3 would be called what, update ?
And from 15.1.x to 15.7 would be -at least- called an upgrade?
What is your version naming logic, and does it reflect in names/functionalities of tools/script sets? What would you say (that is the important say, not mine)?
---
Another ERROR:
O.k. I did start my LibreSSL 15.1.9 install from two days ago. This on real hardware, an old Intel Atom box.
And tried to use console menu option 12) Upgrade from console, like I did just minutes ago with my VirtualBox VM quick install of LibreSSL
got the error :
/usr/local/sbin/pkg: Shared object has no run-time symbol table
Shell =>
# opnsense-update
Fetching kernel-15.1.9-amd64.txz ... fetch: http://pkg.opnsense.org/sets/kernel-15.1.9-amd64.txz: Not Found
Seems to be a different behaviour:
The VM install tries to querry a "OPNsense reporitory catalogue" first. Did you change the update tools?
-
O.k.
From the console menu item 8 Shell =>
# opnsense-update -kr 15.1.11
did the trick and fetched and applied the 15.1.11 kernel.
* A reboot of the default kernel from the bootup menu delivered the 15.1.9 kernel and #pkg upgrade failed:
/usr/local/sbin/pkg: Shared object has no run-time symbol table
* A reboot of the old kernel from the bootup menu
delivers the same .. ??
-
Don't force the upgrade to 15.1.11 on an old installation, especially only upgrading the kernel through "-k" is dangerous... see `man opnsense-update' for details. The old 15.1.9 sets have been removed so it's normal you are getting this error on fetch. I haven't previously seen the error you have with pkg or know why 12) stops working for you while it seems to work fine each time I try. Anybody else getting these?
-
Found this:
* similar bug:
https://forums.freebsd.org/threads/bin-sh-shared-object-has-no-run-time-symbol-table.43007/
* might be a disc error, says:
https://forums.freebsd.org/threads/error-when-starting-sshd.36657/
* "Shared object has no run-time symbol table" usually means FreeBSD can't
find a library file you linked the code against, says :
http://lists.grdata.com/pipermail/rtg/2004-December/001375.html
Seems to be a corrupted pkg or a corrupted library file..
-
Hmm, can you do a quick:
# ldd /usr/sbin/pkg
# ldd /usr/local/sbin/pkg
-
Hmm, can you do a quick:
# ldd /usr/sbin/pkg
# ldd /usr/local/sbin/pkg
# ldd /usr/sbin/pkg
Gives a list of 14 libraries (lib[..].so.#) with a => director to their positions in the root tree, each with a hex (0x80[..]) numberal
# ldd /usr/local/sbin/pkg
gives nothing
-
That means the "real" pkg binary is trashed. Can you remove it and bootstrap again (meaning run "pkg" manually, let it download itself by confirming)?
There seems to be a systematic theme in your installations we haven't seen elsewhere, although I really don't know what differs in your case.
-
O.k. Thank you for the help.
I did not anticipate it could be a trashed pkg - so you may understand my initial question about differences and possible changes in repository and image, neighter did I see the _1 in the kernel namestring before, sorry for that.
running
# /usr/sbin/pkg
or
# /usr/local/sbin/pkg
gives error: "runtime library has no shared object"
# portsnap fetch
says "command not found"
---
SOLVED:
#cd /usr/sbin
# fetch http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/pkg-1.5.3.txz
#tar -C / -xvzf pkg-1.5.3.txz
# exit
Console menu item 12) Upgrade from console runs seamlessly now!!
*** Welcome to OPNsense 15.1.11.3-d007whatever (amd64) on OPNsense ***
Thank you!! :)
chol..
-
Hi Christian,
that's good news. :) BTW, you can also take the package(s) that we provide:
https://pkg.opnsense.org/FreeBSD:10:amd64/latest/Latest/pkg.txz
Have fun,
Franco