Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
On 2021-10-15, cho...@jtan.com wrote: > Bingo. I was even told about it in the email I ignored (there's > nothing wrong with *69): :) Been there done that. (If I am anywhere near tight on space in /usr I usually try to upgrade with the "untar on running system" method with a root shell open so I have some hope of fixing it..) And I have a number of systems where I have a gap in partition letters after growfs'ing /usr into what was previously the partition after it on disk. > Time to reinstall on a bigger disc. Thanks for the pointer, that > saves me some perplexed digging around. Good files to kill if you need to quickly make some breathing space (but of course will come back after reinstalling all sets): /usr/lib/lib[a-bd-z]*.a /usr/share/man Unless you are doing installs directly under /usr (usually self built software), removing everything reported by "sysclean | grep ^/usr" should be safe. It takes care of libraries needed for installed packages so you can try cleaning, making sure you have xbase and base sets fully unpacked, update packages, then run sysclean again and it will probably allow you to free up some more shared libraries. > btw Some of the space used on /usr will be old libraries (it's at > least as old as 6.8, clearly), but for the record it looks like the > minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), > 240MB for /usr/X11R6 and <75MB for everything else if the box isn't > doing a great deal. FWIW I usually try to give /usr at least 5GB. Maybe slight overkill but it's such a pain to shuffle partitions I'd rather waste a bit of space than have to do that again. The other place I often run out is / on systems where I run current as I often have a few different kernels lying around from trying to bisect when a problem was introduced. -- Please keep replies on the mailing list.
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Oh and it's also worth noting that despite that massive cock-up, the box is still (now) running just fine on this frankenhybrid and serving its git repositories and running its crons, all entirely hands-off and automated: # uname -a && uptime OpenBSD smoke.datum 7.0 GENERIC#224 amd64 4:29AM up 10:49, 2 users, load averages: 0.05, 0.02, 0.01 That's how engineering works. Take that, devops. Matthew
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Stuart Henderson writes: > On 2021-10-14, cho...@jtan.com wrote: > > Turns out, one of my less important boxes was still on 6.8. Whoops. > > > > After two sysupgrades, this is the result of pkg_add -u: > > > > quirks-4.53 signed on 2021-10-12T20:12:39Z > > Can't install cairo-1.16.0 because of libraries > >|library pixman-1.40.0 not found > > That file is in xserv70.tgz so you shouldn't be having that problem unless the > untar failed. Does the file exist (should be in /usr/X11R6/lib)? Are you ok > for > disk space in /usr/X11R6? Bingo. I was even told about it in the email I ignored (there's nothing wrong with *69): Installing base70.tgz91% |*** | 275 MB00:01 ETAtar: Failed write to file ./usr/share/relink/kernel.tgz: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libc.so.96.1.a: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libcrypto.so.47.0.a: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-CARP-MIB.txt: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-PF-MIB.txt: No space left on device Installing base70.tgz99% |* | 301 MB00:00 ETAtar: Failed write to file ./usr/share/zoneinfo/CST6CDT: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Paris: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Zaporozhye: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Pacific/Fiji: No space left on device Installing base70.tgz 100% |**| 302 MB00:14 Installation of base70.tgz failed. Continue anyway? [no] no Time to reinstall on a bigger disc. Thanks for the pointer, that saves me some perplexed digging around. Matthew btw Some of the space used on /usr will be old libraries (it's at least as old as 6.8, clearly), but for the record it looks like the minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), 240MB for /usr/X11R6 and <75MB for everything else if the box isn't doing a great deal.
pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Turns out, one of my less important boxes was still on 6.8. Whoops. After two sysupgrades, this is the result of pkg_add -u: quirks-4.53 signed on 2021-10-12T20:12:39Z Can't install cairo-1.16.0 because of libraries |library pixman-1.40.0 not found | /usr/X11R6/lib/libpixman-1.so.38.4 (system): bad major Direct dependencies for cairo-1.16.0->1.16.0 resolve to png-1.6.37 glib2-2.68.4 lzo2-2.10p2 Full dependency tree is libiconv-1.16p0 png-1.6.37 lzo2-2.10p2 pcre-8.44 libffi-3.3p1 sqlite3-3.35.5p0 gettext-runtime-0.21p1 xz-5.2.5 python-3.8.12 glib2-2.68.4 bzip2-1.0.8p0 Can't install texlive_base-2020p0 because of libraries Direct dependencies for texlive_base-2020p0->2020p0 resolve to harfbuzz-2.9.1 cairo-1.16.0 graphite2-1.3.14 libiconv-1.16p0 png-1.6.37 ghostscript-9.07p7 clisp-2.49p5 dvi2tty-5.3.1p0 detex-2.8.1 gd-2.3.2 texlive_texmf-buildset-2020p0 psutils-2.06 libpaper-1.1.28 ps2eps-1.68p0 zziplib-0.13.62p1 desktop-file-utils-0.26 lcdf-typetools-2.108p0 texlive_mktexlsr-2020p0 icu4c-69.1p0v0 t1utils-1.42 texlive_synctex-2020p0 Full dependency tree is detex-2.8.1 pcre-8.44 libevent-2.1.11 jbig2dec-0.11 libiconv-1.16p0 png-1.6.37 icu4c-69.1p0v0 gnutls-3.7.2 texlive_mktexlsr-2020p0 libnettle-3.7.3 avahi-libs-0.8p1 texlive_synctex-2020p0 libunistring-0.9.7 psutils-2.06 ghostscript-fonts-8.11p3 texlive_texmf-buildset-2020p0 zziplib-0.13.62p1 ijs-0.35p3 dvi2tty-5.3.1p0 libunbound-1.13.2 gd-2.3.2 graphite2-1.3.14 cairo-1.16.0 p11-kit-0.24.0 libffi-3.3p1 zstd-1.5.0 desktop-file-utils-0.26 libidn2-2.3.0p0 libtasn1-4.17.0 clisp-2.49p5 cups-libs-2.3.3.2p1 harfbuzz-2.9.1 xz-5.2.5 gettext-runtime-0.21p1 dbus-1.12.20p1v0 sqlite3-3.35.5p0 tiff-4.3.0 gmp-6.2.1p0 ps2eps-1.68p0 ffcall-1.10p5 libpaper-1.1.28 giflib-5.1.6 p5-IPC-Run3-0.048p0 lz4-1.9.3p0 lzo2-2.10p2 libsigsegv-2.12 ghostscript-9.07p7 lcdf-typetools-2.108p0 libwebp-1.2.1 t1utils-1.42 lcms2-2.12 bzip2-1.0.8p0 glib2-2.68.4 python-3.8.12 jpeg-2.1.1v0 Couldn't find updates for cairo-1.16.0 texlive_base-2020p0 Couldn't install cairo-1.16.0 texlive_base-2020p0 This will not be difficult to fix; remove and reinstall will probably do it. If this is the result of me skipping pkg_add -u on the 6.9 hop then there's nothing to see here but I've done the same thing a few times before without incident (I expect problems if I skip base releases, not so much with ports) so if this problem's unexpected, well, here it is. In other news, quite a few other headless hands-off servers' upgrades were absolutely seamless. Thank-you! Matthew
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
On 2021-10-14, cho...@jtan.com wrote: > Turns out, one of my less important boxes was still on 6.8. Whoops. > > After two sysupgrades, this is the result of pkg_add -u: > > quirks-4.53 signed on 2021-10-12T20:12:39Z > Can't install cairo-1.16.0 because of libraries >|library pixman-1.40.0 not found That file is in xserv70.tgz so you shouldn't be having that problem unless the untar failed. Does the file exist (should be in /usr/X11R6/lib)? Are you ok for disk space in /usr/X11R6? > This will not be difficult to fix; remove and reinstall will probably > do it. If this is the result of me skipping pkg_add -u on the 6.9 > hop then there's nothing to see here but I've done the same thing > a few times before without incident (I expect problems if I skip > base releases, not so much with ports) so if this problem's unexpected, > well, here it is. I've done a few from 6.8 direct to 7.0 (skipping base and package updates) and probably some from earlier, it's rare (read: I don't remember it happening) that I have any problems attributed to skipping versions. Not recommended unless you know how to fix things if they do arise, but still..
