freebsd
Package upgrade doesn't ensure the base system is installed while processing scripts
As currently generated packages produced by ports have no dependency on package base packages. This has the unfortunate consequence that pkg will uninstall/reinstall packages while most of the base system is currently not present. In the most extreme case not even libc or the runtime loader are present while scripts or triggers attempt to run.
To make matters worse the otherwise idle little Atom board with "only" 4GiB RAM + 2GiB swap ran out of memory while attempting to upgrade FreeBSD-src. I was left with a completely broken system without libc or rtld and had to recover with pkg-static while manually setting OSVERSION and ABI on the command line. I know this is about the worst moment during the upgrade to crash for any reason, but having to recover like this is beyond most users.
IMO pkg shouldn't require >4GiB RAM to upgrade a system with < 1000 packages. It would also be nice to have a meta package with the previously installed packages tucked away somewhere to simplify reconstructing which packages where installed when you can't scroll back far enough or can't copy and and paste.
4GiB RAM + 2GiB swap ran out of memory
This is a separate issue, unrelated to your summary line.
Please see:
- 287722 – Website: system requirements: memory/RAM: UFS and ZFS (closed)
- 287719, which I summarised as bsdinstall: system requirements: memory/RAM: UFS and ZFS (before a change of summary)
- pkg upgrade, ZFS, swap on, vm.pageout_oom_seq in particular:
vm.pageout_oom_seq=120
287722 for documentation was not accepted, so please either:
- join the discussion on the freebsd-pkg list, https://lists.freebsd.org/subscription/freebsd-pkg; or
- (my preference) make a post in the FreeBSD subreddit, https://www.reddit.com/r/freebsd/.
Thank you.
installed packages
pkg prime-origins | sort -u > /var/tmp/pkg-prime-origins.txt
… while attempting to upgrade
A major upgrade (from 14 to 15), or a minor upgrade?
… I was left with a completely broken system … had to recover … having to recover like this is beyond most users. …
- #2441