Re: Of /var/db/entropy-file and booting kernels
> On May 7, 2020, at 11:34 AM, Martin Husemann wrote: > > It should do everything correctly, nothing special needed for 9.0 or newer. Confirmed. I was also able to roll my own with LVM. Having a writable /dev on arm64 really helps :D
Re: library cleanup after a system upgrade
Riccardo Mottola writes: > I would check if the .so.x file has a corresponding symlink, if it has, > it is latest version, else it is old. That's not true. There is a symlink e.g. from .so.1 to .so.1.1. Maybe you mean "the libfoo.so symlink does not point to it". In general deleting these has some risk and unless you are really tight on disk space, little benefit.
Re: Of /var/db/entropy-file and booting kernels
On Thu, May 07, 2020 at 10:58:03AM -0400, Eric S. Hvozda wrote: > Do you still need to handcraft the partitioning as suggested in > https://wiki.netbsd.org/users/spz/moderndisk/ or does sysinst do the > correct things as of v9.0? It should do everything correctly, nothing special needed for 9.0 or newer. Martin
Re: library cleanup after a system upgrade
On Thu, May 07, 2020 at 06:04:25PM +0200, Riccardo Mottola wrote: > this is quit clear and makes sense to me. I wondered if there existed a > ready script for 2) to share... > > I would check if the .so.x file has a corresponding symlink, if it has, > it is latest version, else it is old. That is not needed (old minor versions are removed, only old major versions stay around and also keep a symlink). I dimly remember a perl script that used ldd and walked through all binaries and libs (including pkgsrc) to find all still referenced .so, and then generated a list of the actually obsolete ones. But this is a minor space saver only. > FreeBSD does it with upgrade: > 1) update system > 2) updat all packages > 3 re-run update to cleanup In NetBSD we have a strict focus on binary compatibility, so usually it is not required to update everything - and sometimes it is a pain to update old stuff. But binary compatibility only helps if you keep the old libs around. Martin
Re: Of /var/db/entropy-file and booting kernels
>> On May 7, 2020, at 4:26 AM, Martin Husemann wrote: >> >> On Wed, May 06, 2020 at 05:55:08PM -0400, Eric S. Hvozda wrote: >> It is know what installing boot blocks on the devices to supporting a >> raid set with GPT is useless (i.e. does not work due to lack of >> support) > > Missing context here. What machine are you trying to boot and what NetBSD > version? Whoops! My bad. An earlier draft of my post included it, but apparently didn’t make the final post: amd64 v9.9.56 > On amd64: with EFI booting from GPT raid sets works for me > (unfortunately not with biosboot, though this should be fixable). Of course, par for the course, I need biosboot. My target host is a Dell PE830, to the best of my knowledge it does not speak UEFI. With the prior posts on this topic, I was able to a functional host and using the PR added a mount of my boot partition and added random_file= with the proper path to rc.conf. I’ll have to model the UEFI setup on VMWare Fusion so I’ll be ready for it when the customer “upgrades” (the PE830 dates to 2005). Do you still need to handcraft the partitioning as suggested in https://wiki.netbsd.org/users/spz/moderndisk/ or does sysinst do the correct things as of v9.0?
Re: library cleanup after a system upgrade
In article <20200506223952.hyjgwirjwfddd...@pumpkin.pr0.tips>, Timo Buhrmester wrote: >> What happens to the "old libraries" ? I think they are left in so >> binaries continue to run. >> Just the new ones are symlinked to current. > >Some get removed with postinstall obsolete, some don't. I've never >really figured out what's going on, but occasionally I'll explode >the sets to a temporary directory, and do a find/diff dance to >identify leftover stuff. > >..and then it usually turns out that I forgot to recompile any >local programs that still needed them :) /usr/src/lib/checkoldver /usr/lib | xargs rm -f christos
Re: library cleanup after a system upgrade
Hi Martin, Martin Husemann wrote: > There are multiple cases and they are treated differently: > > 1) there were neither major nor minor version changes between the releases > -> the library is overwritten with the new version during the update > 2) the major version was bumped > -> new version is installed, old version stays around as 3rd party > software in your installation could still refer to it. > There are scripts for finding all references and actually > obsolete libs, but this is typically a later (and partly > manual) step after you have updated all pkgs too. > 3) the minor version was bumped > -> symlinks are fixed to point at the newer version, older > version is removed by postinstall this is quit clear and makes sense to me. I wondered if there existed a ready script for 2) to share... I would check if the .so.x file has a corresponding symlink, if it has, it is latest version, else it is old. But I know how to code, but not at scripting.. so maybe there is some cleanup script or so. FreeBSD does it with upgrade: 1) update system 2) updat all packages 3 re-run update to cleanup Thanks, Riccardo
Re: library cleanup after a system upgrade
Martin Husemann wrote: > 2) the major version was bumped > -> new version is installed, old version stays around as 3rd party >software in your installation could still refer to it. >There are scripts for finding all references and actually >obsolete libs, but this is typically a later (and partly >manual) step after you have updated all pkgs too. Re manual step... From /usr/sbin/postinstall - this comment speaks about an embedded awk script that does this work: # The implementation supports removing obsolete major libraries # if the awk variable AllLibs is set, although there is no way to # enable that in the enclosing shell function as this time. We should probably use an environment variable to supply that assignment on the awk invocation (-v AllLibs=1) so that you don't have to copy and edit it. POSTINSTALL_OBSOLETE_MAJOR_VERIONS_YES_I_KNOW_WHAT_I_AM_DOING or something. -uwe
Re: library cleanup after a system upgrade
Martin Husemann writes: > On Thu, May 07, 2020 at 12:39:53AM +0200, Timo Buhrmester wrote: >> > What happens to the "old libraries" ? I think they are left in so >> > binaries continue to run. >> > Just the new ones are symlinked to current. >> >> Some get removed with postinstall obsolete, some don't. > > There are multiple cases and they are treated differently: > > 1) there were neither major nor minor version changes between the releases > -> the library is overwritten with the new version during the update > 2) the major version was bumped > -> new version is installed, old version stays around as 3rd party > software in your installation could still refer to it. > There are scripts for finding all references and actually > obsolete libs, but this is typically a later (and partly > manual) step after you have updated all pkgs too. 100% right, but note that "3rd party" here means "programs not part of the netbsd base system", and includes "things built from pkgsrc". > 3) the minor version was bumped > -> symlinks are fixed to point at the newer version, older > version is removed by postinstall So, if you want to find old libs to delete, basically go to /lib and /usr/lib, and list *.so by ctime. You'll find most are from your last update, and some are from long ago. For each, look at the other versions that are there and their ctimes. Then, you can remove the old ones. Of course if there are programs linked against it, they will break. My ctimes are messed up from a dump/restore to change from regular disk to ssd, but here is a "ls -ltr /usr/lib/libssl.so*": -r--r--r-- 1 root wheel 197155 Jan 6 2004 /usr/lib/libssl.so.2.1 lrwxr-xr-x 1 root wheel 13 Jan 6 2004 /usr/lib/libssl.so.2 -> libssl.so.2.1 -r--r--r-- 1 root wheel 202885 Oct 18 2004 /usr/lib/libssl.so.3.0 lrwxr-xr-x 1 root wheel 13 Nov 1 2004 /usr/lib/libssl.so.3 -> libssl.so.3.0 -r--r--r-- 1 root wheel 265119 Jan 28 2009 /usr/lib/libssl.so.4.0 lrwxr-xr-x 1 root wheel 13 Jan 28 2009 /usr/lib/libssl.so.4 -> libssl.so.4.0 -r--r--r-- 1 root wheel 309887 Nov 17 2014 /usr/lib/libssl.so.6.0 lrwxr-xr-x 1 root wheel 13 Nov 17 2014 /usr/lib/libssl.so.6 -> libssl.so.6.0 -r--r--r-- 1 root wheel 448395 Oct 27 2018 /usr/lib/libssl.so.10.6 lrwxr-xr-x 1 root wheel 14 Oct 27 2018 /usr/lib/libssl.so.10 -> libssl.so.10.6 -r--r--r-- 1 root wheel 528248 Jul 22 2019 /usr/lib/libssl.so.12.0 lrwxr-xr-x 1 root wheel 14 Jul 22 2019 /usr/lib/libssl.so.12 -> libssl.so.12.0 lrwxr-xr-x 1 root wheel 14 Jul 22 2019 /usr/lib/libssl.so -> libssl.so.12.0 on a sytem currently on 8. Doing "ls -ltrc" instead gives me: lrwxr-xr-x 1 root wheel 13 May 13 2018 /usr/lib/libssl.so.2 -> libssl.so.2.1 lrwxr-xr-x 1 root wheel 13 May 13 2018 /usr/lib/libssl.so.3 -> libssl.so.3.0 lrwxr-xr-x 1 root wheel 13 May 13 2018 /usr/lib/libssl.so.4 -> libssl.so.4.0 lrwxr-xr-x 1 root wheel 13 May 13 2018 /usr/lib/libssl.so.6 -> libssl.so.6.0 -r--r--r-- 1 root wheel 197155 May 13 2018 /usr/lib/libssl.so.2.1 -r--r--r-- 1 root wheel 202885 May 13 2018 /usr/lib/libssl.so.3.0 -r--r--r-- 1 root wheel 265119 May 13 2018 /usr/lib/libssl.so.4.0 -r--r--r-- 1 root wheel 309887 May 13 2018 /usr/lib/libssl.so.6.0 lrwxr-xr-x 1 root wheel 14 Dec 11 2018 /usr/lib/libssl.so.10 -> libssl.so.10.6 -r--r--r-- 1 root wheel 448395 Dec 11 2018 /usr/lib/libssl.so.10.6 lrwxr-xr-x 1 root wheel 14 Feb 21 19:53 /usr/lib/libssl.so -> libssl.so.12.0 lrwxr-xr-x 1 root wheel 14 Feb 21 19:53 /usr/lib/libssl.so.12 -> libssl.so.12.0 -r--r--r-- 1 root wheel 528248 Feb 21 19:53 /usr/lib/libssl.so.12.0 (Note that mod date here and last system update are not necessarily the same, as full builds do not always rebuild things when using update builds.)
PERL vars
I am trying to re-implement a large PERL prog I wrote about 10yrs ago. It has custom vars that you can set in a *rc file. IS THERE a way to track these vars down, and set them in the config file?
Re: library cleanup after a system upgrade
On Thu, May 07, 2020 at 12:39:53AM +0200, Timo Buhrmester wrote: > > What happens to the "old libraries" ? I think they are left in so > > binaries continue to run. > > Just the new ones are symlinked to current. > > Some get removed with postinstall obsolete, some don't. There are multiple cases and they are treated differently: 1) there were neither major nor minor version changes between the releases -> the library is overwritten with the new version during the update 2) the major version was bumped -> new version is installed, old version stays around as 3rd party software in your installation could still refer to it. There are scripts for finding all references and actually obsolete libs, but this is typically a later (and partly manual) step after you have updated all pkgs too. 3) the minor version was bumped -> symlinks are fixed to point at the newer version, older version is removed by postinstall Martin
Re: Of /var/db/entropy-file and booting kernels
On Wed, May 06, 2020 at 05:55:08PM -0400, Eric S. Hvozda wrote: > It is know what installing boot blocks on the devices to supporting a > raid set with GPT is useless (i.e. does not work due to lack of > support) Missing context here. What machine are you trying to boot and what NetBSD version? On amd64: with EFI booting from GPT raid sets works for me (unfortunately not with biosboot, though this should be fixable). Martin
Linux Skype on NetBSD
Hi All, Did anybody try on NetBSD 9.0 and amd64 SkypeForLinux ? Does it run with linux compatibility with access to audio & video? just wondering, since it is quite usable on a semi-decent laptop running Devuan, but I know therewere pulseaudio problems etc etc in the past. Riccardo
