Date: Tue, 22 Oct 2002 11:57:44 -0700 From: Kent Stewart <kstewart@owt.com> To: pippo@bellnet.ca Cc: freebsd-questions@FreeBSD.ORG Subject: Re: mergemaster problem Message-ID: <3DB59FA8.8030303@owt.com> References: <5.1.0.14.2.20021022115618.00a901b0@mail.host45.com> <5.1.0.14.2.20021022131427.00a9a448@pop51.bellnet.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
pippo@bellnet.ca wrote: > At 10:01 AM 10/22/2002 -0700, you wrote: > I must say, as I often have remarked, that the handbook is rather foggy > - you often have to read a whole slew of things that are urelated before > you get to the main point - I was trying to follow the manual, step by > step - but it sure doesn't seem to work quite that way. :(( Part of the problem with the Handbook is that it covers most of the versions. > I did vipw with the restored backed-up files and now I have passwd and > will probably be ok. > So, as I understand it, I should just run make buildwold from /usr/src, > then build the new kernel and then do make installworld, then update the > files not updated by make world etc, etc. as in the handbook. > That, then, will upgrade my system to 4.7. Right? After you have installed the kernel, installed the world, and run mergemaster, you have the current release. Many people don't reboot into single user mode. I always do that. I want to know the kernel works before I do the installworld. I could probably exit from single user mode after I ran mergemaster but I do a reboot at that point. If I have added some new devices, I want the kernel to see them. > As I need no changes to the programs I have installed (they're all > up-to-date with portupgrade), I should just verify that the /etc/group, > passwd and master.passwd files are conforming to the newer version. And > this, as I understand, can be done by the mergemaster. I don't use mergemaster to update master.passwd but I do copy the header info from the location in /usr/tmp and insert it into the files I modify by hand. Once you have rebooted and are running the new version, you can run mergemaster again and it will tell you what files it wants to update. Some of that is results from a comparison of the cvs header information. You can make mergemaster ignore that file by updating the header information. I use information from mergemaster to update them manually. It tells you where all of the files are located and that makes it really easy to upgrade a file manually. If you have port programs that depend on system libraries, you need to rebuild the ports so they link to the new version. This is not always important. The port lsof is an exception that comes to mind. It knows when you have updated the system and not rebuilt lsof. It tells you about this everytime you run it. If they fix a security related buffer overflow problem in one of the system libraries, you need to update all ports that use that library. I haven't seen announcents that cover this kind of problem. I don't know if this is a problem. I know I have gone more than a release on some of my ports. Whether I should have rebuilt some of them was something I do not know. Some people do level upgrades by doing clean installs. They wipe the disks and reinstall everything. I use cvsup to follow RELENG_4 and know I have some old stuff still available. Portupgrade makes some of this really simple. It is sort of the mergemaster of the port world. I do a portsdb -uU after every cvsup of ports-all. There are programs that tell you what is out of date on your system. I just finished checking 4 machines and making sure they were all running the latest versions of the ports. I didn't rebuild everything. Keeping your ports current is important. The question is one of timing and I don't have an answer to that. I have started building packages as part of the make install. Checking the date in /usr/ports/packages/All will tell me which ports I haven't updated for a long time. The ones I use very often are also updated often. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB59FA8.8030303>