Date: Fri, 29 May 2026 09:18:21 -0700 From: Mark Millard <marklmi@yahoo.com> To: Manfred Koch <md-koch@t-online.de>, freebsd-pkgbase@FreeBSD.org Subject: Re: different outcome freebsd-version -kru Message-ID: <2a4ceb2c-5be3-4c05-a5ce-f28a3a21d1e3@yahoo.com> In-Reply-To: <571b67f5-4867-4f74-955e-c38ea42a3c5f@t-online.de> References: <07c33cf7-8a08-4f09-9084-419eaa29e1ec@t-online.de> <cf36d9e5-c9a4-4688-b28c-447a427554bc@yahoo.com> <0018e700-40f3-4e60-9b14-bf649f3102b1@t-online.de> <8ABC7D71-7FFA-4B50-9868-78436322B503@yahoo.com> <b32553fa-83a4-4f0a-b9d5-dc038691fd17@t-online.de> <b0e825dd-7244-440d-b438-0b9f41f4762e@yahoo.com> <83237af5-f8db-479f-992a-1fa9f1b5878e@t-online.de> <d475e3a7-26ba-42b8-9173-b0926db16e04@yahoo.com> <571b67f5-4867-4f74-955e-c38ea42a3c5f@t-online.de>
index | next in thread | previous in thread | raw e-mail
On 5/29/26 06:58, Manfred Koch wrote: > Hi, > > There are the following outcomes in numbers > > # ls -C1 /boot/kernel*/ 1717 I missed a character for my intent, sorry: # ls -dC1 /boot/kernel*/ My guess, given the 1717, is that you have something like: /boot/kernel/ /boot/kernel.old/ If so, you can delete the /boot/kernel.old directory tree. > # find -s /boot/ -name \*.pkgsave -print 860> # find -s / -name \*.pkgsave -print 2434 You probably want to explicitly inspect and deal with various text files found by: # find -s /etc/ /boot/ -name -name \*.pkgsave -print that you know you modified the contents of: merging back in any of your non-default material from the *.pkgsave files that you still want. Other examples could include such files for the root login directory (where ever you have it) and /.* files. Then you likely should reboot to use the updated normal files. There are a few files that are not text that need use of a program to regenerate them, such as using pwd_mkdb . Likely the files in question are configuration files, like: /boot/loader.conf /etc/group /etc/master.passwd # pwd_mkdb -p /etc/master.passwd /etc/hosts /etc/sysctl.conf /etc/ssh/sshd_config service sshd restart /root/.profile (or where ever your root logs into) /root/.shrc (or where ever your root logs into) /.profile /.shrc /etc/shells /etc/defaults/rc.conf /etc/kyua/kyua.conf /etc/mail/* (I do not use this so I'm unsure of the details) /etc/periodic/... (???) and, potentially, many others. If you know of other configuration files or the like that are not in those directory trees: them too. If you are worried about specific file history being available for reference, you should probably rename any such *.pkgsave files, given what I suggest below would otherwise delete them. Another thing to check is if there are examples of port-package issues found by the likes of: # find -s /usr/local/ -name \*.pkgsave -print # find -s /usr/local/ -name \*.pkgnew -print If yes, there are analogous things to do in /usr/local/etc/ . Once you know things are okay for such, you likely would want to do something to delete the *.pkgsave files, like: # find -s / -name \*.pkgsave -delete > # find -s / -name .pkgtemp.\* -print show nothing I had also listed: # find -s / -name \*.pkgnew -print so I'm guessing: nothing found by that. These would be new defaults and likely should not be ignored, even for non-configuration files. Hopefully you simply do that have that issue to deal with. > > Should I dare to delete the *.pkgsave files? Likely only after doing the kind of thing that I suggest above. > Manfred > > On 5/28/26 19:45, Mark Millard wrote: >> On 5/28/26 08:50, Manfred Koch wrote: >>> Hi Mark, >>> >>> I installed the >>> >>> FreeBSD-set-kernels-15.0 and rebooted. >>> freebsd-version -kru shows: >>> 15.0-RELEASE-p9 >>> 15.0-RELEASE-p9 >>> 15.0-RELEASE-p9 >> Cool. >> >> There may be old files/directories to clean up. What does: >> >> # ls -C1 /boot/kernel*/ >> >> show: more than 1? >> >> What does: >> >> # find -s /boot/ -name \*.pkgsave -print >> >> show: any? >> >> Given the odd history/prior results, you might want to check each of: >> >> # find -s / -name \*.pkgsave -print >> >> # find -s / -name \*.pkgnew -print >> >> # find -s / -name .pkgtemp.\* -print >> >> (I'd be surprised if the last shows any examples.) >> >> For that sequence, the first takes longer but the others use cached >> information and so are normally faster. >> >> *.pkgnew files are from upgrades and have new material to consider >> relative to the original file (say merging into or regenerating or >> replacing). Once taken care of, generally a *.pkgnew file can be deleted. >> >> *.pkgsave file are from installs and and have the old material that was >> replaced by the install. Again you may need to consider merging or >> regenerating or replacing content. Once taken care of, generally a >> *.pkgsave file can be deleted. >> >>> You saved me a fresh installation, Super! >>> >>> I appreciate your distinguished help >>> Manfred >>> >>> On 5/28/26 02:03, Mark Millard wrote: >>>> On 5/27/26 12:28, Manfred Koch wrote: >>>>> On 5/26/26 22:58, Mark Millard wrote: >>>>> >>>>>> pkg info FreeBSD-kernel\* >>>>> Hi, >>>>> >>>>> here are the outputs from the commands: >>>>> >>>>> pkg info FreeBSD-kernel\* >>>>> FreeBSD-kernel-man-15.0 >>>> The above (and below) indicates that you got a partial pkgbase install >>>> (some pkgbase pkackages) but without any kernels (or related modules >>>> that those pkgbase packages also provide). The created a mixed system >>>> with older, non-packaged kernels. >>>> >>>> I expect that you will be able to simply install the kernel(s) (with >>>> the >>>> modules that go with them) that you want from 15.0-RELEASE-p9, given >>>> what already has worked to get what you have . It may rename any old >>>> kernels and modules in /boot/kernel*/ that match by name to have a >>>> .pkgsave at the end of the name. Those you should be able to delete >>>> once >>>> things are known to be working alright. I doubt that it would instead >>>> create the new files as instead having a .pkgnew added to the end of >>>> the intended name. >>>> >>>> Another thing to possibly report would be the output from: >>>> >>>> # pkg info FreeBSD-set-\* >>>> >>>> If that ends up without and FreeBSD-set-* being listed, then my below >>>> guess would be wrong. >>>> >>>> My guess is that you have an installation based on use of such sets. >>>> If so, continuing do use them to get the kernel(s) (and modules) as >>>> well >>>> would be: >>>> >>>> # pkg install FreeBSD-set-kernels-15.0 >>>> >>>> (Such pkg sets just reference other pkgbase packages, so it should lead >>>> to the kernel pkg's being installed.) >>>> >>>> I do not know if you would want the debug information too: >>>> >>>> # pkg install FreeBSD-set-kernels-dbg-15.0 >>>> >>>> Once you have new kernels, if such works, you get to reboot and see >>>> what >>>> happens. So you may want to have emergency copies of things you know >>>> the >>>> status of before you start this process. >>>> >>>> I will note that I do not have a 15.0-RELEASE context myself. The >>>> closest is stable/15 based instead of releng/15.0 based and is >>>> definitely newer in various respects. And my installation has all the >>>> pgkbase packages for stable/15 as of when it was last updated, even >>>> ones >>>> not used by bsdinstall. >>>> >>>>> pkg info -d FreeBSD-clibs\* >>>>> FreeBSD-clibs-15.0: >>>>> FreeBSD-clibs-dev-15.0p9: >>>>> FreeBSD-clibs-15.0 >>>>> FreeBSD-clibs-15.0 (libc.so.7) >>>>> FreeBSD-clibs-15.0 (libgcc_s.so.1) >>>>> gcc13-13.3.0_3 (libgcc_s.so.1) >>>>> gcc14-14.2.0_4 (libgcc_s.so.1) >>>> Note: Ignore the gcc* examples. it is a known issue with file name >>>> matching for libgcc_s.so.1 being insufficient information to actually >>>> make them a match for the system's libgcc_s.so.1 : false positive. >>>> >>>>> FreeBSD-clibs-15.0 (libsys.so.7) >>>>> FreeBSD-clibs-15.0 (libthr.so.3) >>>>> FreeBSD-clibs-lib32-15.0: >>>>> FreeBSD-clibs-15.0 >>>>> >>>>> pkg check -s -a >>>>> >>>>> Checking all packages: 100% >>>> The above only checked that what was installed via pkg is still valid. >>>> It would not report things that pkg did not itself install from >>>> packages. Still, the 100% without problem reports is good news. >>>> >>>>> Additionally I have altered FreeBSD-base.conf consistent to "latest" >>>>> but that doesn't change nothing in uname -a. >>>> latest vs. quarterly is a port-package issue, not a sys†em or >>>> base-package issue. uname provides system information, not ports >>>> information. >>>> >>>>> Could be a mixed System >>>>> >>>>> Thanks a lot for your effort >>>>> Manfred >>>>> >>>>> >>>>> >>>>> >>> >> > > -- === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a4ceb2c-5be3-4c05-a5ce-f28a3a21d1e3>