Project

General

Profile

Actions

Bug #2305

closed

PBI db stored on var does not survive reboot

Added by Phillip Davis over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Package System
Target version:
Start date:
03/21/2012
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:

Description

On FreeBSD 8.3 the PBI system stores its database in /var/db/pbi - this is where it remembers what FreeBSD packages are installed. On nanobsd this is a RAMdisk and does not survive a reboot. So PBI's "memory" is lost, but the actual PBI packages are happily in /usr/pbi.
If the system has been rebooted since the package was installed, then the removal code cannot trace the location of the PBI package files. So package deletion does not cleanup the files.
So far, the only real effect I can see is that disk space is used by files in /usr/pbi/... that are no longer needed. If the package is reinstalled, the old files are simply overlayed by the re-installation.
Perhaps the PBI db should be moved somewhere that survives reboot?
Or perhaps this issue has no really important downstream effects and can just be ignored?

Actions #1

Updated by Jim Pingle over 9 years ago

We do this for NanoBSD in /etc/rc:

elif [ "$PLATFORM" = "nanobsd" ] ; then
        # Ensure that packages can be persistent across reboots
        /bin/mkdir -p /root/var/db/pkg
        /bin/rm -rf /var/db/pkg
        /bin/ln -s /root/var/db/pkg/ /var/db/pkg

Could do something similar for that pbi directory.

Actions #2

Updated by Phillip Davis over 9 years ago

Pull request submitted 18 Apr 2012 to do as JimP suggests. Now the PBI db survives reboot. This should resolve this bug ticket.

Actions #3

Updated by Jim Pingle over 9 years ago

Merged, thanks!

FYI- If you put something like "Fixes #2305" or "Ticket #2305" in the commit message, redmine will pick it up and show the commit on this page.

It was merged in ef82d62b8f90080c282feb92c5785d9de2be26c1

Actions #4

Updated by Jim Pingle over 9 years ago

  • Status changed from New to Feedback
Actions #5

Updated by Phillip Davis over 9 years ago

Just did a quick test to verify this on nanobsd:
2.1-BETA0 (i386)
built on Fri Jul 27 15:20:29 EDT 2012

Installed blinkled:
[2.1-BETA0][]/root(1): pbi_info
touch: /var/db/pbi/.hashdirty: Read-only file system
blinkled-0.1-i386

Rebooted:
[2.1-BETA0][]/root(1): pbi_info
touch: /var/db/pbi/.hashdirty: Read-only file system
blinkled-0.1-i386

blinkled is still listed - good

Removed blinkled:
[2.1-BETA0][]/root(6): pbi_info
touch: /var/db/pbi/.hashdirty: Read-only file system

no PBIs listed any more - good

Note: pbi_info complains when the file-system is read-only - but an info command should just be reading. I guess it wants to lock the PBI database for a moment while it reports. A bit dumb when the db mountpoint is already read-only. There doesn't seem to be a way to tell it to just look and not touch! But it doesn't cause any harm.

I think this can be closed.

Actions #6

Updated by Jim Pingle over 9 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF