Bug #2305
closed
PBI db stored on var does not survive reboot
Added by Phillip Davis over 12 years ago.
Updated over 12 years ago.
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?
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.
Pull request submitted 18 Apr 2012 to do as JimP suggests. Now the PBI db survives reboot. This should resolve this bug ticket.
- Status changed from New to Feedback
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@test02.homedomain]/root(1): pbi_info
touch: /var/db/pbi/.hashdirty: Read-only file system
blinkled-0.1-i386
Rebooted:
[2.1-BETA0][root@test02.homedomain]/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@test02.homedomain]/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.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF
Updated by 
Updated by