Re: 4.3 -> RELENG_4
> If the scenerio I described above seems to fit, yes. Sounds like things > are going well. If you want to be REAL paranoid, you could try rebuilding > your kernel with IFPW_DEFAULT_ACCEPT (or whatever that option is) and make > sure you have network connectivity before continuing. > > I wouldn't bother if it were me. It sounds like things are going well. > The main thing you're looking for is that the new kernel actually BOOTs. > Drop to single-user mode and do the installworld. I went ahead and did installworld. The IPFW problem dissapeared immediatly. All I had to do was add the smmsp user as per UPDATING, and it went slick from there. Small issues were: - a depricated line in sshd_config, which I manually commented out - sig 11 on nmbd, for which I will upgrade samba (should fix it) All in all, I am very exited as my amanda box now uname -a with FreeBSD-4.8RC, and is back in full production. I have began syncing source on my mission critical boxes, and plan on starting the upgrade on them next week. I did mergemaster on amanda box, but must of did something wrong as afterwards, my /etc/master.passwd file was missing. Copied it back from backup and all is well. mergemaster didn't seem to touch anything except for it, so next time I will likely just do the manual thing. Thanks for all of your help, which gave me the confidence to proceed in this delicate manner. However, I should of known that with the stability of Free that I really had nothing to worry about from the beginning! Steve > > -- > Bill Moran > Potential Technologies > http://www.potentialtech.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
ccounts wrote: Ok, everything went reasonably well with cvsup upgrade, buildworld, buildkernel. After installkernel, everything appears to load perfectly, until I try to send data to the box. IPFW barfs on a SIG 11. What exactly do you mean by this? When you transmit files across the network, you get a sig 11? Or when you try to start the IPFW program at the command line, it sig 11s? The former would worry me. The latter wouldn't. The ipfw firewall code is built into the kernel, but the ipfw command line program that is used to create/manipulate ipfw rules is part of buildworld. It's not unusual for programs that interface directly with the kernel not to work when you're mid-way through the process (i.e. new kernel but old world). I'm guessing what's happening is that the ipfw program can't communicate to ipfw in the kernel and when your startup scrips try to run it, it sig 11s. Thus you end up with ipfw running with no rules, set to deny by default, thus you get no network capbility. Assuming that it is loading ok at boot, can I properly assume that this will be repaired when I installworld? If the scenerio I described above seems to fit, yes. Sounds like things are going well. If you want to be REAL paranoid, you could try rebuilding your kernel with IFPW_DEFAULT_ACCEPT (or whatever that option is) and make sure you have network connectivity before continuing. I wouldn't bother if it were me. It sounds like things are going well. The main thing you're looking for is that the new kernel actually BOOTs. Drop to single-user mode and do the installworld. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
Ok, everything went reasonably well with cvsup upgrade, buildworld, buildkernel. After installkernel, everything appears to load perfectly, until I try to send data to the box. IPFW barfs on a SIG 11. Assuming that it is loading ok at boot, can I properly assume that this will be repaired when I installworld? What I don't understand is that the kernel I built was the exact same kernel config I rebuilt the old way a month ago. It was then I added ipfw support with: forward verbose verbose_limit=xx and everything was ok. Anyone know why IPFW would just crap out? What part of the changes would affect the way IPFW operates. In your opinion, is it safe to installworld, or should this be further investigated first? Tks. Steve Bertrand To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
At 2003-03-06T18:52:07Z, IAccounts <[EMAIL PROTECTED]> writes: > I apreciate very much the overwhelming support for this OS (and open > source in general). I have personally been MS free for just over one year > now and will never go back thanks to the assistance I get from everyone > here! That's one of the things I love about FreeBSD in particular. People (particularly manager types) have a hard time believing how excellent and quick mailing-list based tech support can be. -- Kirk Strauser In Googlis non est, ergo non est. pgp0.pgp Description: PGP signature
Re: 4.3 -> RELENG_4
> IAccounts wrote: > >>I may be wrong, but ... > >>Do this order: > >>make buildworld > >>make buildkernel > >>make installkernel > >>reboot > >>make installworld > > > > I am going to attempt the above in order as stated. I have read UPDATING, > > have the handbook open. One thing I am confused about: The next line after > > my new text states that this should give me a new config. My understanding > > is that buildworld will build the system, but not install it. Am I correct > > in saying that if the world is not installed, then the new config will not > > be installed either? > > I apologize, I'm forgetting things and giving you half-correct information > all over the place. > First off ... the handbook is your authoritative reference on this, if > anything I say conflicts with the handbook, I'm most likely wrong. > > buildworld builds everything except the kernel and puts it all in /usr/obj, > thus there are no changes to your running system. > buildkernel is similar (it builds the kernel and puts it in /usr/obj) but > it uses the utilities that are in /usr/obj instead of your running sytem, > that's why you must always buildworld first. > At this point, nothing on your running system has changed. You can buildworld > and buildkernel on a live system without affecting its operation. > When you installkernel, it copies /kernel to /kernel.old, then installs the > kernel it built with buildkernel as /kernel. It also installs kernel modules > in the /modules directory. At this point your system has changed ... but getting > it back to where it was involves copying /kernel.old to /kernel and /modules.old > to /modules ... not too hard. > The changes don't take effect until you reboot, though. If, apon reboot, things > don't look good, you can backtrack easily by booting the kernel.old and doing > the copying described above. > If everything looks good, you do installworld. Installworld copys a lot of stuff > to it's proper place. I have no idea what all files are altered, but there are > LOTs of them. Reverting an installworld is a LOT of work! But it is doable ... > I've done it, so don't think that all is lost if something goes wrong, it's just > that it's probably easier to reinstall the system and restore from backup. > > There's a step that I left out: mergemaster. Mergemaster creates a temporary copy > of the files that belong in /etc. (make a backup of /etc before running mergemaster) > and then allows you to selectively install whatever files you need. It goes through > each file that should be in /etc, compares it to what is currently in /etc and tells > you whether it needs updated or not. > This is the most difficult and easiest step to screw up. If you install the new > /etc/passwd, for example, you'll lose any users you've added, so you'll probably want > to merge that file in. Some other examples are /etc/printcap, /etc/group, > /etc/hosts. > On the other hand, there are some startup scripts in /etc that you almost always > want to update, such as /etc/rc, and everything in /etc/defaults. This is why it's > so important to backup /etc before using mergemaster, so you can easily back out of > a mistake. Using mergemaster is important! Don't skip this step. > > Hope this helps clear up some of the confusion I created. > First, there are no apologies neccisary, and you did not create confusion, you actually helped me clear most of it up. Another member suggested that a #make buildworld will actually allow me to use the new config before installworld, so that is what I am going to attempt. When I first submitted my q to the list, I was looking for any and all ideas/opinions out there. I am attempting to perform tasks that are clearly spelled out in a different order in the handbook, and your advice was very useful. If it wasn't for your first couple of responses, I would not have learned that I can install just 'parts' of the new source by going into /usr/src/usr.sbin and just make/installing it. I will certainly have use for this in the near future. Also, I don't feel that anybody should have to apologize for giving a response that they afterwards feel was 'wrong' or 'not right'. I know for a fact that I am guilty of spitting out a response in these lists and others quickly, sometimes before I even totally realize what the user is asking. I'm sure that you have work to do otherwise and spent just the amount of time helping out here as you can. Sometimes words get jumbled and things seem confusing, but for me, it seems straight as I'm typing, but sometimes when I go back and read it, it doesn't seem right. Your responses are always very good. I follow your threads and you seem to put a lot of time in. I apreciate very much the overwhelming support for this OS (and open source in general). I have personally been MS free for just over one year now and will never go back thanks to the assistance I get from everyone here! Regards, Steve > -- > Bill Moran > Potential Technolo
Re: 4.3 -> RELENG_4
IAccounts wrote: I may be wrong, but ... Do this order: make buildworld make buildkernel make installkernel reboot make installworld I am going to attempt the above in order as stated. I have read UPDATING, have the handbook open. One thing I am confused about: The next line after my new text states that this should give me a new config. My understanding is that buildworld will build the system, but not install it. Am I correct in saying that if the world is not installed, then the new config will not be installed either? I apologize, I'm forgetting things and giving you half-correct information all over the place. First off ... the handbook is your authoritative reference on this, if anything I say conflicts with the handbook, I'm most likely wrong. buildworld builds everything except the kernel and puts it all in /usr/obj, thus there are no changes to your running system. buildkernel is similar (it builds the kernel and puts it in /usr/obj) but it uses the utilities that are in /usr/obj instead of your running sytem, that's why you must always buildworld first. At this point, nothing on your running system has changed. You can buildworld and buildkernel on a live system without affecting its operation. When you installkernel, it copies /kernel to /kernel.old, then installs the kernel it built with buildkernel as /kernel. It also installs kernel modules in the /modules directory. At this point your system has changed ... but getting it back to where it was involves copying /kernel.old to /kernel and /modules.old to /modules ... not too hard. The changes don't take effect until you reboot, though. If, apon reboot, things don't look good, you can backtrack easily by booting the kernel.old and doing the copying described above. If everything looks good, you do installworld. Installworld copys a lot of stuff to it's proper place. I have no idea what all files are altered, but there are LOTs of them. Reverting an installworld is a LOT of work! But it is doable ... I've done it, so don't think that all is lost if something goes wrong, it's just that it's probably easier to reinstall the system and restore from backup. There's a step that I left out: mergemaster. Mergemaster creates a temporary copy of the files that belong in /etc. (make a backup of /etc before running mergemaster) and then allows you to selectively install whatever files you need. It goes through each file that should be in /etc, compares it to what is currently in /etc and tells you whether it needs updated or not. This is the most difficult and easiest step to screw up. If you install the new /etc/passwd, for example, you'll lose any users you've added, so you'll probably want to merge that file in. Some other examples are /etc/printcap, /etc/group, /etc/hosts. On the other hand, there are some startup scripts in /etc that you almost always want to update, such as /etc/rc, and everything in /etc/defaults. This is why it's so important to backup /etc before using mergemaster, so you can easily back out of a mistake. Using mergemaster is important! Don't skip this step. Hope this helps clear up some of the confusion I created. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
> > I am going to attempt the above in order as stated. I have read UPDATING, > > have the handbook open. One thing I am confused about: The next line after > > my new text states that this should give me a new config. My understanding > > is that buildworld will build the system, but not install it. Am I correct > > in saying that if the world is not installed, then the new config will not > > be installed either? > > The magic of the "buildkernel" target is that it uses the programs just > build by "buildworld", regardless of whether you've done an installworld. This is great! Tks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
At 2003-03-06T17:04:47Z, IAccounts <[EMAIL PROTECTED]> writes: > I am going to attempt the above in order as stated. I have read UPDATING, > have the handbook open. One thing I am confused about: The next line after > my new text states that this should give me a new config. My understanding > is that buildworld will build the system, but not install it. Am I correct > in saying that if the world is not installed, then the new config will not > be installed either? The magic of the "buildkernel" target is that it uses the programs just build by "buildworld", regardless of whether you've done an installworld. -- Kirk Strauser In Googlis non est, ergo non est. pgp0.pgp Description: PGP signature
Re: 4.3 -> RELENG_4
> > I may be wrong, but ... > Do this order: > make buildworld > make buildkernel > make installkernel > reboot > make installworld I am going to attempt the above in order as stated. I have read UPDATING, have the handbook open. One thing I am confused about: The next line after my new text states that this should give me a new config. My understanding is that buildworld will build the system, but not install it. Am I correct in saying that if the world is not installed, then the new config will not be installed either? Steve > > This should get you an updated config program, while still giving you the > safety of backing out if the new kernel doesn't boot. > > If I'm wrong on this point, please correct me. But I don't see it being > harmful to try. (as nothing actually gets installed until the 'make install*' > stage) > > -- > Bill Moran > Potential Technologies > http://www.potentialtech.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
> > > > Basically: > > > > Update your source with cvsup > > > > read /usr/src/UPDATING and follow any instructions required (I believe > > > > you'll need to manually create the relatively new sendmail users) > > > > Reveiw you kernel config file to see if any options have changed since > > > > 4.3 > > > > make buildkernel > > > > make installkernel > > > > reboot >>> if the reboot doesn't go well, boot kernel.old and copy it to > > > > /kernel to get back to 4.3 > > > > make buildworld > > > > make installworld > > > > Ok, I have cvsup'ped successfully, upon buildkernel I get: > > > > "Error: version of config does not match kernel! > > config version = 400018, version required = 400019 > > > > I understand that I am doing oposite of what the handbook says by > > installing a new kernel first, but is there a way to get around the out of > > date config problem so I can proceed in this 'backwards' approach? > > Not that I know of, and you've just started to uncover problems with > doing things backwards. You really need to do the buildworld > first. You can - in fact, should - leave the installworld until after > the new kernel is booted. Thanks greatly for the advice! I will attempt to do a buildworld now, and I can actually understand why this is. I can also see that I *should* have a backdoor prior to installworld. In the meantime, I did (thankfully) find a 4.3 cd that the previous admin had left (with no label or anything of course) and have installed it onto a scrap unit. It is in cvsup mode right now, updating source. I am going to gamble on the buildworld on my production amanda box first, as this is at least not mission critical, and I can afford to lose this one for a day. Things are looking very hopeful for my first real attempt at upgrade, and the things I am learning about the src structure and the way the FreeBSD source tree works is great! I recently built a cvs server for my own production, but now I actually understand cvs and branching at a whole new level! Tks again for such great user support and for an OS that nothing can even compare to. (Not to put down other BSD variants, because I have not used them) Steve Bertrand To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
In <[EMAIL PROTECTED]>, IAccounts <[EMAIL PROTECTED]> typed: > > > Basically: > > > Update your source with cvsup > > > read /usr/src/UPDATING and follow any instructions required (I believe > > > you'll need to manually create the relatively new sendmail users) > > > Reveiw you kernel config file to see if any options have changed since > > > 4.3 > > > make buildkernel > > > make installkernel > > > reboot >>> if the reboot doesn't go well, boot kernel.old and copy it to > > > /kernel to get back to 4.3 > > > make buildworld > > > make installworld > > Ok, I have cvsup'ped successfully, upon buildkernel I get: > > "Error: version of config does not match kernel! > config version = 400018, version required = 400019 > > I understand that I am doing oposite of what the handbook says by > installing a new kernel first, but is there a way to get around the out of > date config problem so I can proceed in this 'backwards' approach? Not that I know of, and you've just started to uncover problems with doing things backwards. You really need to do the buildworld first. You can - in fact, should - leave the installworld until after the new kernel is booted. http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
IAccounts <[EMAIL PROTECTED]> writes: > > > Basically: > > > Update your source with cvsup > > > read /usr/src/UPDATING and follow any instructions required (I believe > > > you'll need to manually create the relatively new sendmail users) > > > Reveiw you kernel config file to see if any options have changed since > > > 4.3 > > > make buildkernel > > > make installkernel > > > reboot >>> if the reboot doesn't go well, boot kernel.old and copy it to > > > /kernel to get back to 4.3 > > > make buildworld > > > make installworld > > Ok, I have cvsup'ped successfully, upon buildkernel I get: > > "Error: version of config does not match kernel! > config version = 400018, version required = 400019 Yes, you got bad advice there. You need to do a buildworld before the buildkernel. Please read the handbook section on updating, as well as everything it refers you to (including UPDATING), before risking your system with the update. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
IAccounts wrote: Basically: Update your source with cvsup read /usr/src/UPDATING and follow any instructions required (I believe you'll need to manually create the relatively new sendmail users) Reveiw you kernel config file to see if any options have changed since 4.3 make buildkernel make installkernel reboot >>> if the reboot doesn't go well, boot kernel.old and copy it to /kernel to get back to 4.3 make buildworld make installworld Ok, I have cvsup'ped successfully, upon buildkernel I get: "Error: version of config does not match kernel! config version = 400018, version required = 400019 Make sure that /usr/src/usr.sbin/config is in sync with your /usr/src/sys and install a new config binary before trying this again." Doing a: # cd /usr/src/usr.sbin/config # make Fails with "make: dont' know hwo to make config.1. Stop" At this point it looks like everything has compiled, and is in the linking object files stage. I understand that I am doing oposite of what the handbook says by installing a new kernel first, but is there a way to get around the out of date config problem so I can proceed in this 'backwards' approach? I may be wrong, but ... Do this order: make buildworld make buildkernel make installkernel reboot make installworld This should get you an updated config program, while still giving you the safety of backing out if the new kernel doesn't boot. If I'm wrong on this point, please correct me. But I don't see it being harmful to try. (as nothing actually gets installed until the 'make install*' stage) -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
> > Basically: > > Update your source with cvsup > > read /usr/src/UPDATING and follow any instructions required (I believe > > you'll need to manually create the relatively new sendmail users) > > Reveiw you kernel config file to see if any options have changed since > > 4.3 > > make buildkernel > > make installkernel > > reboot >>> if the reboot doesn't go well, boot kernel.old and copy it to > > /kernel to get back to 4.3 > > make buildworld > > make installworld Ok, I have cvsup'ped successfully, upon buildkernel I get: "Error: version of config does not match kernel! config version = 400018, version required = 400019 Make sure that /usr/src/usr.sbin/config is in sync with your /usr/src/sys and install a new config binary before trying this again." Doing a: # cd /usr/src/usr.sbin/config # make Fails with "make: dont' know hwo to make config.1. Stop" At this point it looks like everything has compiled, and is in the linking object files stage. I understand that I am doing oposite of what the handbook says by installing a new kernel first, but is there a way to get around the out of date config problem so I can proceed in this 'backwards' approach? Tks. Steve Bertrand To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
> > Unfortunatly, I have never successfully upgraded a Free box yet, mind you > > I have only tried it on one. > > > > Last year I was dropped into a production environment with all 4.3 > > machines. I have no devel equipment prior to 4.6. The upgrade attempts > > were all only on one box (4.6) and failed due to suspect hardware. > > > > My question is not howto upgrade, but; > > > > 1> Since I have only production equipment to 'test' an upgrade on, I am > > very nervous. At what point of the upgrade procedure is it too late to > > turn back if something does not go right. > > If you install the kernel, then reboot (before installing world) you will > be ensuring that the new kernel you built will boot reliably. This is > the final practical point of return. If you have problems with the new > kernel booting, you can copy /kernel.old back to /kernel and be back to > where you started. If the new kernel is fine, continue with installworld. > Once you've installed world, however, it's an ungodly amount of work to > revert everything. > > > 2> I keep amanda tape backups of every file system on all machines. If > > something goes critically wrong, can the system be rebooted at least to > > the point where I can pull data back off tapes? > > As long as your system is bootable, yes. Do you have FreeBSD 4.3 CDs? > If so, you can easily do a base install, and then restore from backup to > get back up and running as you were. (should things happen to go > terribly wrong) > > I've very seldom had any problems upgrading using cvsup. You will hit a > few (minor) gotchas ... read /usr/src/UPDATING and you won't have any > problems with them. > > Basically: > Update your source with cvsup > read /usr/src/UPDATING and follow any instructions required (I believe > you'll need to manually create the relatively new sendmail users) > Reveiw you kernel config file to see if any options have changed since > 4.3 > make buildkernel > make installkernel > reboot >>> if the reboot doesn't go well, boot kernel.old and copy it to > /kernel to get back to 4.3 > make buildworld > make installworld > > Going from 4.3 -> 4.7 may cause some problems with some ports. The solution > is generally to uninstall the port and rebuild it. Update your ports tree > first. > > Schedule yourself a nice chunk of time to do the first machine, then you'll > be able to better predict the time required for the rest. > Thanks for the goldmine of info! Unfortunatly, my boxes are sooo old :o) that cvsup appears to be out of date, as I get 'Protocol negotiation failed'. Catch 22 I guess, so I found on http://people.freebsd.org/~jdp/s1g (I think this is John Poelstra's site?) That I have to upgrade my cvsup. I will do this then let you know how the upgrade went. Thanks again. > -- > Bill Moran > Potential Technologies > http://www.potentialtech.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: 4.3 -> RELENG_4
IAccounts wrote: Unfortunatly, I have never successfully upgraded a Free box yet, mind you I have only tried it on one. Last year I was dropped into a production environment with all 4.3 machines. I have no devel equipment prior to 4.6. The upgrade attempts were all only on one box (4.6) and failed due to suspect hardware. My question is not howto upgrade, but; 1> Since I have only production equipment to 'test' an upgrade on, I am very nervous. At what point of the upgrade procedure is it too late to turn back if something does not go right. If you install the kernel, then reboot (before installing world) you will be ensuring that the new kernel you built will boot reliably. This is the final practical point of return. If you have problems with the new kernel booting, you can copy /kernel.old back to /kernel and be back to where you started. If the new kernel is fine, continue with installworld. Once you've installed world, however, it's an ungodly amount of work to revert everything. 2> I keep amanda tape backups of every file system on all machines. If something goes critically wrong, can the system be rebooted at least to the point where I can pull data back off tapes? As long as your system is bootable, yes. Do you have FreeBSD 4.3 CDs? If so, you can easily do a base install, and then restore from backup to get back up and running as you were. (should things happen to go terribly wrong) I've very seldom had any problems upgrading using cvsup. You will hit a few (minor) gotchas ... read /usr/src/UPDATING and you won't have any problems with them. Basically: Update your source with cvsup read /usr/src/UPDATING and follow any instructions required (I believe you'll need to manually create the relatively new sendmail users) Reveiw you kernel config file to see if any options have changed since 4.3 make buildkernel make installkernel reboot >>> if the reboot doesn't go well, boot kernel.old and copy it to /kernel to get back to 4.3 make buildworld make installworld Going from 4.3 -> 4.7 may cause some problems with some ports. The solution is generally to uninstall the port and rebuild it. Update your ports tree first. Schedule yourself a nice chunk of time to do the first machine, then you'll be able to better predict the time required for the rest. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
4.3 -> RELENG_4
Unfortunatly, I have never successfully upgraded a Free box yet, mind you I have only tried it on one. Last year I was dropped into a production environment with all 4.3 machines. I have no devel equipment prior to 4.6. The upgrade attempts were all only on one box (4.6) and failed due to suspect hardware. My question is not howto upgrade, but; 1> Since I have only production equipment to 'test' an upgrade on, I am very nervous. At what point of the upgrade procedure is it too late to turn back if something does not go right. 2> I keep amanda tape backups of every file system on all machines. If something goes critically wrong, can the system be rebooted at least to the point where I can pull data back off tapes? Tks for all help! Steve Bertrand To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
