Project

General

Profile

Bug #4328

Some symlinks not updated by full update

Added by Doktor Notor over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
High
Category:
Upgrade
Target version:
Start date:
01/28/2015
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.2
Affected Architecture:
All

Description

Forum thread: https://forum.pfsense.org/index.php?topic=87336.msg481876#msg481876

On upgrade, there are loads of /usr/lib linker symlinks not updated and pointing to obsoleted nonexistent libs on full installs, breaking things on the way. Some examples:

/usr/lib/libcrypto.so -> /lib/libcrypto.so.6
$ ls -l /lib/libcrypto.so.6
ls: /lib/libcrypto.so.6: No such file or directory

/usr/lib/libmd.so -> /lib/libmd.so.5
$ ls -l  /lib/libmd.so.5
ls: /lib/libmd.so.5: No such file or directory

$ ls -l /usr/lib/libusb.so*
lrwxr-xr-x  1 root  wheel     11 Jan 24 06:00 /usr/lib/libusb.so -> libusb.so.2
-r--r--r--  1 root  wheel  65068 Jan 22 22:07 /usr/lib/libusb.so.3

/usr/lib/libufs.so -> /lib/libufs.so.5
$ ls -l /lib/libufs.so.5
ls: /lib/libufs.so.5: No such file or directory

No such issue exists on nanobsd.

Associated revisions

Revision 830ceadf (diff)
Added by Renato Botelho over 4 years ago

Remove -U from mtree call used to restore files permissions, this is replacing symlink targets by the old values. Ticket #4328

Revision b6c04ed8 (diff)
Added by Renato Botelho over 4 years ago

Remove -U from mtree call used to restore files permissions, this is replacing symlink targets by the old values. Ticket #4328

Revision 02acc7af (diff)
Added by Renato Botelho over 4 years ago

Detect when broken rc.firmware is running, fix it and restart. This should fix #4328

Revision 3f5e998c (diff)
Added by Renato Botelho over 4 years ago

Detect when broken rc.firmware is running, fix it and restart. This should fix #4328

History

#1 Updated by Renato Botelho over 4 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

I pushed a fix for this on tools

#2 Updated by Renato Botelho over 4 years ago

  • Affected Version changed from All to 2.2

#3 Updated by Doktor Notor over 4 years ago

Thanks. I assume the only way to test this is to wait for 2.2.1 :)

#4 Updated by Jim Thompson over 4 years ago

Likely, (or build from source) but 2.2.1 likely not that far away, either.

#5 Updated by Kill Bill over 4 years ago

Well, all I can say is that this is definitely not fixed. Tested with 2.2.1-DEVELOPMENT-i386-20150213-1429 snapshot.

$ ls -l /usr/lib/libusb.so*
lrwxr-xr-x  1 root  wheel     11 Feb 13 22:51 /usr/lib/libusb.so -> libusb.so.2
-r--r--r--  1 root  wheel  65068 Feb 13 21:56 /usr/lib/libusb.so.3

$ ls -l /usr/lib/libufs.so*
lrwxr-xr-x  1 root  wheel  16 Feb 13 22:51 /usr/lib/libufs.so -> /lib/libufs.so.5
$ ls -l /lib/libufs.so.5
ls: /lib/libufs.so.5: No such file or directory

$ ls -l /usr/lib/libcrypto.so*
lrwxr-xr-x  1 root  wheel  19 Feb 13 22:51 /usr/lib/libcrypto.so -> /lib/libcrypto.so.6
$ ls -l /lib/libcrypto.so.6
ls: /lib/libcrypto.so.6: No such file or directory

#6 Updated by Kill Bill over 4 years ago

Still broken. Really, I feel somehow the point gets missed here - is there actually some upgrade script to clean up the stale mess? Fixing it on newer builds will not clean up the mess on current installs.

#7 Updated by Chris Buechler over 4 years ago

  • Subject changed from pfSense.obsoletedfiles - badly broken upgrade handling on FULL installs to Incorrect lib symlinks in full update files
  • Status changed from Feedback to Confirmed
  • Assignee set to Renato Botelho

The symlinks in the full update files are pointing to the wrong file for some of those, which appears to be the source of the remaining issue. They just need to be corrected and existing installs will be fine post-upgrade.

#8 Updated by Chris Buechler over 4 years ago

  • % Done changed from 100 to 50

#9 Updated by Renato Botelho over 4 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 50 to 100

It was probably caused by a problem on builder. I checked latest snapshot and all symlinks are valid.

#10 Updated by Kill Bill over 4 years ago

$ cat /etc/version.buildtime
Wed Mar 11 05:59:00 CDT 2015

$ ls -l /usr/lib/libusb.so*
lrwxr-xr-x  1 root  wheel     11 Mar 11 15:35 /usr/lib/libusb.so -> libusb.so.2
-r--r--r--  1 root  wheel  65068 Mar 11 12:15 /usr/lib/libusb.so.3

$ ls -l /usr/lib/libufs.so*
lrwxr-xr-x  1 root  wheel  16 Mar 11 15:35 /usr/lib/libufs.so -> /lib/libufs.so.5
$ ls -l /lib/libufs.so.5
ls: /lib/libufs.so.5: No such file or directory

$ ls -l /usr/lib/libcrypto.so*
lrwxr-xr-x  1 root  wheel  19 Mar 11 15:35 /usr/lib/libcrypto.so -> /lib/libcrypto.so.6
$ ls -l /lib/libcrypto.so.6
ls: /lib/libcrypto.so.6: No such file or directory

This might be fixed on a fresh install, it definitely is not fixed on upgraded system -- which is the whole point of this bug.

#11 Updated by Chris Buechler over 4 years ago

  • Subject changed from Incorrect lib symlinks in full update files to Some symlinks not updated by full update
  • Status changed from Feedback to Confirmed

I was looking at something wrong last night, the symlinks within the update files are correct, they're just not overwriting what's there already.

#12 Updated by Chris Buechler over 4 years ago

  • Status changed from Confirmed to Feedback
  • Assignee changed from Renato Botelho to Chris Buechler

to me for testing

#15 Updated by Chris Buechler over 4 years ago

most recent snapshot didn't quite catch that commit, new ones building now.

#16 Updated by Chris Buechler over 4 years ago

  • Status changed from Feedback to Resolved

that definitely fixed the remaining issue, both 32 and 64 bit.

#17 Updated by Kill Bill over 4 years ago

Chris Buechler wrote:

that definitely fixed the remaining issue, both 32 and 64 bit.

Confirmed. Thanks. ;)

Also available in: Atom PDF