Date: Mon, 17 Sep 2001 21:14:21 -0500 From: "Stephen Hilton" <nospam@hiltonbsd.com> To: "Freebsd Stable" <freebsd-stable@FreeBSD.ORG> Cc: "Kevin Oberman" <oberman@es.net> Subject: RE: Problems getting STABLE running on a VAIO 505TL Message-ID: <KPEMJADBBBFPDEDOIOMBEEBKCPAA.nospam@hiltonbsd.com> In-Reply-To: <200109172240.f8HMe0R31074@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Several other caveats, Read /usr/src/UPDATING thoroughly Read the FreeBSD Handbook chapter on makeworld http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html Make sure you have the correct updated cvsup software (1,000,000,000 second bug) http://people.freebsd.org/~jdp/s1g/ Don't miss the step of "adopting" your current source tree before cvsupping to a later release. This means running your cvsup the very first time with your current release tag. An example would be: You have installed from a FreeBSD 4.2 CD set, you now want to cvsup/buildworld to a 4.3-stable source. Your first cvsup session would use the tag "RELENG_4_2_0_RELEASE" to adopt your 4.2 release source tree. Your second cvsup would use the tag "RELENG_4" to come up to 4.3 stable (or 4.4 stable, wherever the 4.X tree is at). Make sure you have an easily accessed backup copy of your existing /etc directory # mkdir /var/myetc/ # cd /etc/ # cp -Rp * /var/myetc/ It is a good idea to have some of your system information on hand (just incase) Example for an IDE HD based system: # cd /tmp # disklabel -r ad0 > mybox.txt # fdisk >> mybox.txt # cat /etc/fstab >> mybox.txt # mount >> mybox.txt # cat /etc/rc.conf >> mybox.txt Then copy this information to your printer or floppy for future reference if necessary. Make sure your /etc/group file has not had necessary groups removed: The solution is to examine /usr/src/etc/group and compare its list of groups with your own. If they are any groups in the new file that are not in your file then copy them over. Similarly, you should rename any groups in /etc/group which have the same GID but a different name to those in /usr/src/etc/group. Examine your /etc/make.conf file and confirm that all overrides from the /etc/defaults/make.conf file are correct for the system you are building for. If you don't have a /etc/make.conf file you have not read and followed the handbook directions. Clean out /usr/obj/ # cd /usr/obj/ # chflags -R noschg * # rm -rf * # ls -la (to confirm everything in /usr/obj/ was deleted) When running mergemaster the safe answer is usually "i" to install the new file, you can always go back to your /etc backup (see step above) and reconcile any differences (some common user edited files that can change are inetd.conf, syslog.conf, services, hosts, named.conf). If possible do run the installworld/mergemaster steps in single user mode. This also allows you to reboot using your newly created kernel from the make kernel step, and confirm that you have a working bootable kernel. If mergemaster wants to recreate your /dev entries do it! If something goes wrong during the buildworld process: # cd /usr/src # make cleandir Then try the buildworld again. If you still have problems, record the errors and search the freebsd-stable and freebsd-questions lists before crying help. It is not a bad idea to be familiar with using a fixit floppy or CD-ROM, mounting your existing partitions, setting your path, etc... on your system before needing to use them if a problem does occur. > To explain why /usr/src/UPDATING has the order it does: > cvsup (well, that has to be first since you can't build from updated > sources without the updated sources.) > make buildworld (This is the single most complex step in the rebuild. > And, it has NO impact on the running system. It must > precede either a buildkernel or installworld.) > make kernel (This simply is a short way of entering "make buildkernel > && make installkernel". You do this so you can make sure > that you have a bootable kernel built on the new system > sources and objects. But the new executables are not yet > installed, making it easy to fall back to the old system > should the new kernel fail to boot.) > Reboot to single-user mode (This is a safety think. Installing new > system over the existing one usually > works, but it's far from safe!) > make installworld (You KNOW that the new kernel works and that all of > the new binaries built, so it's time to take the > first step that is really hard to back out of if > there are problems.) > mergemaster (This is really a "cleanup" item, although it is a very > important one.) > Reboot to normal (You're done!) > > Building and installing the kernel after installing world is risky, > especially if changes in userland cause the old kernel to not work > well with it. It gets especially ugly if building the kernel should > fail! > > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?KPEMJADBBBFPDEDOIOMBEEBKCPAA.nospam>