RE: 4.7 Upgrade issue - Daniel Bye
I upgraded my system several times before, are you saying that one is unable to run successfuly 'make installworld' until the new kernel is booted? has anyone even try to look at the error? -Original Message- From: Daniel Bye Sent: Wednesday, February 26, 2003 10:16 AM To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: 4.7 Upgrade issue On Wed, Feb 26, 2003 at 04:59:53PM +0200, Willie Viljoen wrote: On Wednesday 26 February 2003 16:50, someone, possibly Daniel Bye, typed: Yes, but how is that so different from installing a new world for an old kernel? The problem with a new world on an old kernel is that libraries in your world may have changed with the upgrade. If a library that interfaces directly with some feature in the kernel is changed, and is expecting the change to be present in the kernel, you will almost certainly have trouble with it. Agreed, but in this context, I think we are talking about running the disparate kernel and world, in either event, only as long as it takes to get both parts, the new kernel and the new world, installed. Surely, an old world on a new kernel will have the exact same problems (or the exact opposite problems?), in that newly-built programs such as ps and top may have been altered to take account of new kernel memory structures etc, which won't be available until the new kernel is installed and booted. Anyone who is up to using buildworld should have enough understanding to know that you have to build and install both parts for your system to work properly. When you have built a new kernel, you must reboot to start using it. After running make installworld with the new kernel, you have the new world installed as well. Your new kernel will only be running for a few minutes with the old world, until the new one is fully installed. That is exactly how it should be. The tried and trusted method, that works for me, and is the official method listed in the UPDATING file: cd /usr/src/sys/i386/conf vi YOURCONFIG cd /usr/src/ make buildworld kernel KERNCONF=YOURCONFIG The kernel target is a combination of buildkernel and installkernel. These targets are built in order and rely on the previous target making it. Thus, buildworld must succeed for buildkernel to begin, and after buildkernel has worked, installkernel will run. Once this is completed, continue with: shutdown now You will now have dropped to single user mode, then, pick /bin/sh for your shell (this is easier to use in single user than csh), and run: cd /usr/src mergemaster -p make installworld mergemaster reboot You will now have a properly functioning and fully upgraded system. But even then, there will be some disparity between the running kernel and the running world, no? This will only be resolved once all steps are complete, whichever particular sequence of events you follow. Dan -- Daniel Bye PGP Key: ftp://ftp.slightlystrange.org/pgpkey/dan.asc PGP Key fingerprint: 3D73 AF47 D448 C5CA 88B4 0DCF 849C 1C33 3C48 2CDC _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Get your FREE email, calendar, file storage, bookmarks, and other great services at http://www.doneasy.com ! doneasy.com Where timesaving is priceless! -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: 4.7 Upgrade issue - Daniel Bye
On Wed, Feb 26, 2003 at 03:13:30PM +, rew wrote: I upgraded my system several times before, are you saying that one is unable to run successfuly 'make installworld' until the new kernel is booted? I am saying that according to the authors of the handbook, there is a particular order to follow when upgrading your system. Any deviation away from this procedure is likely to lead to problems. has anyone even try to look at the error? Yes, and the suggestions have been to follow the procedure in the handbook or the UPDATING file, as the buildworld process is carefully crafted to be done in that order. -Original Message- From: Daniel Bye Sent: Wednesday, February 26, 2003 10:16 AM To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: 4.7 Upgrade issue On Wed, Feb 26, 2003 at 04:59:53PM +0200, Willie Viljoen wrote: On Wednesday 26 February 2003 16:50, someone, possibly Daniel Bye, typed: Yes, but how is that so different from installing a new world for an old kernel? The problem with a new world on an old kernel is that libraries in your world may have changed with the upgrade. If a library that interfaces directly with some feature in the kernel is changed, and is expecting the change to be present in the kernel, you will almost certainly have trouble with it. Agreed, but in this context, I think we are talking about running the disparate kernel and world, in either event, only as long as it takes to get both parts, the new kernel and the new world, installed. Surely, an old world on a new kernel will have the exact same problems (or the exact opposite problems?), in that newly-built programs such as ps and top may have been altered to take account of new kernel memory structures etc, which won't be available until the new kernel is installed and booted. Anyone who is up to using buildworld should have enough understanding to know that you have to build and install both parts for your system to work properly. When you have built a new kernel, you must reboot to start using it. After running make installworld with the new kernel, you have the new world installed as well. Your new kernel will only be running for a few minutes with the old world, until the new one is fully installed. That is exactly how it should be. The tried and trusted method, that works for me, and is the official method listed in the UPDATING file: cd /usr/src/sys/i386/conf vi YOURCONFIG cd /usr/src/ make buildworld kernel KERNCONF=YOURCONFIG The kernel target is a combination of buildkernel and installkernel. These targets are built in order and rely on the previous target making it. Thus, buildworld must succeed for buildkernel to begin, and after buildkernel has worked, installkernel will run. Once this is completed, continue with: shutdown now You will now have dropped to single user mode, then, pick /bin/sh for your shell (this is easier to use in single user than csh), and run: cd /usr/src mergemaster -p make installworld mergemaster reboot You will now have a properly functioning and fully upgraded system. But even then, there will be some disparity between the running kernel and the running world, no? This will only be resolved once all steps are complete, whichever particular sequence of events you follow. Dan -- Daniel Bye PGP Key: ftp://ftp.slightlystrange.org/pgpkey/dan.asc PGP Key fingerprint: 3D73 AF47 D448 C5CA 88B4 0DCF 849C 1C33 3C48 2CDC _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Get your FREE email, calendar, file storage, bookmarks, and other great services at http://www.doneasy.com ! doneasy.com Where timesaving is priceless! -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Daniel Bye PGP Key: ftp://ftp.slightlystrange.org/pgpkey/dan.asc PGP Key fingerprint: 3D73 AF47 D448 C5CA 88B4 0DCF 849C 1C33 3C48 2CDC _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: 4.7 Upgrade issue - Daniel Bye
At 03:46 PM 2.26.2003 +, Daniel Bye wrote: On Wed, Feb 26, 2003 at 03:13:30PM +, rew wrote: I upgraded my system several times before, are you saying that one is unable to run successfuly 'make installworld' until the new kernel is booted? I am saying that according to the authors of the handbook, there is a particular order to follow when upgrading your system. Any deviation away from this procedure is likely to lead to problems. Lot snipped out You do NOT have to boot the new kernel before running make installworld HOWEVER, it is recommended that you do boot the new kernel before proceding just to test it. If there is a problem with the new kernel, you can still revert back to the old and start over. Best regards, Jack L. Stone, Administrator SageOne Net http://www.sage-one.net [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: 4.7 Upgrade issue - Daniel Bye
On Wed, Feb 26, 2003 at 03:46:35PM +, Daniel Bye wrote: Yes, and the suggestions have been to follow the procedure in the handbook or the UPDATING file, as the buildworld process is carefully crafted to be done in that order. I'm trying to minimize the amount that has to be done in single-user mode (I don't have console access; I have to trust my hosting company's tech support for that part). Is there any serious reason that mergemaster needs to be run in single-user mode? Ideally, I'm trying to get something that needs no operator intervention during single-user mode. Currently, if mergemaster can be run just before booting into single-user mode, the operator needs to type one command (upgrade, a shell script in /root/bin which runs the fsck, mount, swapon, cd, make installworld, and fastboot commands). Thanks, Jim Trigg -- Jim Trigg, Lord High Everything Else O- /\ \ / ASCII RIBBON CAMPAIGN Hostmaster, Huie Kin family websiteXHELP CURE HTML MAIL Verger, All Saints Church - Sharon Chapel / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: 4.7 Upgrade issue - Daniel Bye
In [EMAIL PROTECTED], Jim Trigg [EMAIL PROTECTED] typed: On Wed, Feb 26, 2003 at 03:46:35PM +, Daniel Bye wrote: Yes, and the suggestions have been to follow the procedure in the handbook or the UPDATING file, as the buildworld process is carefully crafted to be done in that order. I'm trying to minimize the amount that has to be done in single-user mode (I don't have console access; I have to trust my hosting company's tech support for that part). Is there any serious reason that mergemaster needs to be run in single-user mode? No, there isn't. Ideally, I'm trying to get something that needs no operator intervention during single-user mode. Currently, if mergemaster can be run just before booting into single-user mode, the operator needs to type one command (upgrade, a shell script in /root/bin which runs the fsck, mount, swapon, cd, make installworld, and fastboot commands). If you really want, you can reboot multiuser on the new kernel, and run make installworld there. It's not tested, but I've done it successfully. I regularly boot multi-user, then drop back to single user to do installs from NFS-mounted /usr/src and /usr/obj. In fact, that's recommended at one place in the handbook. mike -- Mike Meyer [EMAIL PROTECTED] 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.7 Upgrade issue - Daniel Bye
In [EMAIL PROTECTED], Bill Moran [EMAIL PROTECTED] typed: And _always_ back up /etc before running mergemaster. It only has to save you from a stupid mistake 1 time to be worth it! (I know) This has worked so well for me, I'm going to suggest it to everyone here. Don't back up /etc. Store the files you modify in a source code control system. Use rcs, as that's part of the base system. Use cvs if you prefer it. Personally, I use perforce. That means you have backups of all the files you've changed. It also means you can get change histories for the files. It beats the dickens out of umpteen files called foo-back, foo-old, and etc. It works better than dated backups as well. mike -- Mike Meyer [EMAIL PROTECTED] 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
