Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
On Sun, Dec 01, 2002 at 11:11:29AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel C. Sobral [EMAIL PROTECTED] writes: : There I go reply to all... sigh : : IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the : *latest* version in the 3.x series. I sure hope we adopt the same policy : here. ru@ has stepped up to the plate to support more. He's gone through and made sure that all the way back to 4.0-release is upgradable (at least at each release point), going to support it through the first branchpoint. You as a committer aren't required to do extra work to make this work, except to not remove things he's done to make this work. It is unclear what should happen when a piece of thirdparty software is upgraded. However, core ruled a long time ago that ru@ can take reasonable measures to make sure that it works. ru@ has kept it up for a while now, so it looks like he's in it for the long run. This is only for native builds. Anything that is needed for cross building isn't included in this 'upgrade' path. It is there just to make our user's life easier. Also, core didn't want the work arounds to get too gross, but so far all the ones I've l ooked at were relatively inobtrusive. Um, why? I can even cross-build any of our supported arches on the 4.0-RELEASE i386 box. This happens almost automatically, as part of the cross-arch work tasks. Cross-releases have some issues, and the Alpha box (of any useful sort) would help me a lot in polishing this. I've asked donations@ about this when they were offered a bunch of Alpha boxes last month, but haven't heard from them back. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg47933/pgp0.pgp Description: PGP signature
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
On Sun, Dec 01, 2002 at 05:03:03PM +0200, Ruslan Ermilov wrote:
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.312
diff -u -r1.312 Makefile.inc1
--- Makefile.inc1 14 Nov 2002 19:24:50 - 1.312
+++ Makefile.inc1 1 Dec 2002 14:34:40 -
@@ -521,7 +521,8 @@
#
installkernel reinstallkernel:
cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \
- ${CROSSENV} ${MAKE} KERNEL=${INSTKERNNAME} ${.TARGET:S/kernel$//}
+ ${CROSSENV} PATH=${TMPPATH} \
+ ${MAKE} KERNEL=${INSTKERNNAME} ${.TARGET:S/kernel$//}
Please indent the last line either 4 spaces or a tab. It is a continued
line.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
On Mon, Dec 02, 2002 at 12:28:50AM -0800, David O'Brien wrote:
On Sun, Dec 01, 2002 at 05:03:03PM +0200, Ruslan Ermilov wrote:
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.312
diff -u -r1.312 Makefile.inc1
--- Makefile.inc1 14 Nov 2002 19:24:50 - 1.312
+++ Makefile.inc1 1 Dec 2002 14:34:40 -
@@ -521,7 +521,8 @@
#
installkernel reinstallkernel:
cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \
- ${CROSSENV} ${MAKE} KERNEL=${INSTKERNNAME} ${.TARGET:S/kernel$//}
+ ${CROSSENV} PATH=${TMPPATH} \
+ ${MAKE} KERNEL=${INSTKERNNAME} ${.TARGET:S/kernel$//}
Please indent the last line either 4 spaces or a tab. It is a continued
line.
It's already indented, and we don't indent multiple times like this:
\
\
\
We indent like this:
\
\
\
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg47937/pgp0.pgp
Description: PGP signature
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
On Sun, 1 Dec 2002, Daniel C. Sobral wrote: IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the *latest* version in the 3.x series. I sure hope we adopt the same policy here. While I can't put a lot of time into supporting ru's efforts, and I agree that the policy should be that we only officially support updating from the latest RELENG_4, I think his work is noble, and I think we all agree that any effort in this direction is laudable. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
On Sun, 1 Dec 2002, Ruslan Ermilov wrote: [ current@ Cc:'ed because it'll be useful to a number of upgraders. dougb@ Cc:'ed to be aware of possible mergemaster(8) problems. Thanks. 1. smmsp user was missing from /etc/passwd and /etc/group 2. installed 4.0 kernel did not have the sigaction(2) syscall I've attempted to overcome 1) as suggested by UPDATING, by running the ``mergemaster -p'' (from src/usr.sbin/mergemaster/). This did not work well because mergemaster(8) attempted to use stat(1) which is not present in 4.0. I'm not sure how to solve this problem non-invasively. One way to deal with it would be to include the instructions to install stat(1) if needed in UPDATING, but then if the upgrade fails for whatever reason, the user would be left with a bogus 5.x stat(1) binary on their system. However, if someone wants to include that step in UPDATING, I have no objection. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
Doug Barton wrote: On Sun, 1 Dec 2002, Daniel C. Sobral wrote: IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the *latest* version in the 3.x series. I sure hope we adopt the same policy here. While I can't put a lot of time into supporting ru's efforts, and I agree that the policy should be that we only officially support updating from the latest RELENG_4, I think his work is noble, and I think we all agree that any effort in this direction is laudable. I agree. It's reasonable to say you don't guarantee that it will work. It's unreasonable to go out of your way to make sure that it will *not* work. Personally, I want all the changes ru's been doing lately; he does good work, and it's elitist to force people to download gigabytes of intermediate release CDROMs to get to the -CURRENT release via an upgrade rather than a reinstall. The only thing you gain is trading in the people complaining about it not working as expected for people complaining that it's not working at all. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
On Mon, Dec 02, 2002 at 01:15:39AM -0800, Doug Barton wrote: On Sun, 1 Dec 2002, Daniel C. Sobral wrote: IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the *latest* version in the 3.x series. I sure hope we adopt the same policy here. While I can't put a lot of time into supporting ru's efforts, and I agree that the policy should be that we only officially support updating from the latest RELENG_4, I think his work is noble, and I think we all agree that any effort in this direction is laudable. Having been actually working on this, I can say that the effort in supporting 4.0 - 5.0 path is minimal, taking into consideration the following facts: 1. We're required to support 4.0-RELEASE - RELENG_4 upgrades. 2. We're required to support RELENG_4 - 5.0-RELEASE upgrades. 3. It's desirable to support upgrades within 5.0-CURRENT. 4. First day 5.0-CURRENT is identical to 4.0-RELEASE. In 95% (maybe more) of cases, when I commit something titled Boostrapping aid for 4.0-RELEASE, it should be equally appicable to upgrades from 4.0 to RELENG_4. A few recent examples: : ru 2002/11/13 03:50:40 PST : : Modified files: : usr.sbin/crunch/crunchide exec_elf32.c : gnu/usr.bin/cc/cc_tools auto-host.h : lib/libncurses Makefile : Log: : Bootstrapping aid for 4.0-RELEASE. : : Revision ChangesPath : 1.11 +3 -0 src/gnu/usr.bin/cc/cc_tools/auto-host.h : 1.64 +4 -0 src/lib/libncurses/Makefile : 1.6 +6 -0 src/usr.sbin/crunch/crunchide/exec_elf32.c When/if libncurses is MFC'ed, this change will be required to upgrade from 4.0-RELEASE. Similarly for crunchide(1). cc_tools is an exception -- we aren't likely to bring GCC 3.x to RELENG_4. OTOH, the change to auto-host.h is also of a help when upgrading from pre-stdbool.h 5.0-CURRENT systems: : /* Define if you have a working stdbool.h header file. */ : +#if (__FreeBSD_version = 440003 __FreeBSD_version 50) || \ : +__FreeBSD_version = 500014 : #define HAVE_STDBOOL_H 1 : +#endif Another one: : ru 2002/12/01 05:38:25 PST : : Modified files: : usr.bin/make job.c : Log: : Bootstrapping aid from pre-kqueue(2) systems, e.g. 4.0-RELEASE. : : Submitted by: jmallett : Approved by:re (bmah) : : Revision ChangesPath : 1.48 +2 -0 src/usr.bin/make/job.c When/if this change is merged, it'll be needed to upgrade from 4.0 to RELENG_4. Quoting Marcel in his writing to me, On Sun, Jun 02, 2002 at 12:03:24PM -0700, Marcel Moolenaar wrote: Yes. I liked you reasoning in another mail where you said that -current starts at the branch-point and that is what we need to support. The additional advantage of this is that it has a stabilizing effect on -stable. One will not easily MFC something if it breaks the upgrade path, which means that there's a higher chance that if the MFC happens anyway, more thought has gone into it. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg47948/pgp0.pgp Description: PGP signature
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
Doug Barton wrote: On Sun, 1 Dec 2002, Ruslan Ermilov wrote: I've attempted to overcome 1) as suggested by UPDATING, by running the ``mergemaster -p'' (from src/usr.sbin/mergemaster/). This did not work well because mergemaster(8) attempted to use stat(1) which is not present in 4.0. I'm not sure how to solve this problem non-invasively. One way to deal with it would be to include the instructions to install stat(1) if needed in UPDATING, but then if the upgrade fails for whatever reason, the user would be left with a bogus 5.x stat(1) binary on their system. However, if someone wants to include that step in UPDATING, I have no objection. What arguments and information did it use? Most of the stuff stat(1) outputs can be gotten at another way... e.g. by awk'ing 'ls' output, or tar'ing to a tempfile and tvf'ing the archive to get the information, etc.. Makes me want to ask the question: how did you end up with a mergemaster(8) that needed stat(1), when the 4.x version of mergemaster that you were supposed to have been running uses a back-ticked perl command? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
On Mon, 2 Dec 2002, Terry Lambert wrote: Doug Barton wrote: On Sun, 1 Dec 2002, Ruslan Ermilov wrote: I've attempted to overcome 1) as suggested by UPDATING, by running the ``mergemaster -p'' (from src/usr.sbin/mergemaster/). This did not work well because mergemaster(8) attempted to use stat(1) which is not present in 4.0. I'm not sure how to solve this problem non-invasively. One way to deal with it would be to include the instructions to install stat(1) if needed in UPDATING, but then if the upgrade fails for whatever reason, the user would be left with a bogus 5.x stat(1) binary on their system. However, if someone wants to include that step in UPDATING, I have no objection. What arguments and information did it use? Most of the stuff stat(1) outputs can be gotten at another way... e.g. by awk'ing 'ls' output, or tar'ing to a tempfile and tvf'ing the archive to get the information, etc.. I need to find the mode of a file, convert it to octal, and munge the user's umask value. While there were a lot of complicated solutions possible, stat(1) makes this quite easy, and since all I had to do was a minimal port from netbsd, it was the easy way to go; with (arguably) some nice side effects. Makes me want to ask the question: how did you end up with a mergemaster(8) that needed stat(1), when the 4.x version of mergemaster that you were supposed to have been running uses a back-ticked perl command? The 4.0-vintage mm doesn't have the -p mode to do just the master.passwd and group files that is needed for 5.0. Thus, UPDATING recommends using mm to bootstrap that, but RELENG_4 prior to the smmsp user's introduction upgrading to 5.0 is always going to be a problem for this situation. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
Hi! On Mon, Dec 02, 2002 at 01:19:17AM -0800, Doug Barton wrote: DB I'm not sure how to solve this problem non-invasively. One way to deal DB with it would be to include the instructions to install stat(1) if needed DB in UPDATING, but then if the upgrade fails for whatever reason, the user DB would be left with a bogus 5.x stat(1) binary on their system. However, DB if someone wants to include that step in UPDATING, I have no objection. Could we have in UPDATING precise information about upgrading from RELENG_4 to -CURRENT? Including all the steps, all the tricks etc, all possible troubles etc? -- MfG Kirill No good deed goes unpunished. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
There I go reply to all... sigh IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the *latest* version in the 3.x series. I sure hope we adopt the same policy here. Ruslan Ermilov wrote: [ current@ Cc:'ed because it'll be useful to a number of upgraders. dougb@ Cc:'ed to be aware of possible mergemaster(8) problems. imp@ Cc:'ed to be aware of incorrect UPDATING instruction. peter@ Cc:'ed to LOL about foot-shooting with anti-foot-shooting. re@ Cc:'ed to consider approving the attached patches. ] Hi! Following is the report from my attempt to upgrade 4.0-RELEASE system to 5.0-CURRENT. First, I'd like to say that I succedded in it: FreeBSD 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Mon Mar 20 22:50:22 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Dec 1 13:52:37 GMT 2002 ru@:/usr/obj/ru/mnt/usr/src/sys/GENERIC i386 4.0-RELEASE system was installed on a spare disk by newfs'ing the `a' partition and extracting the `bin' distribution on top of it from the 4.0-RELEASE 1st CD, thanks again to Charlie Brewster [EMAIL PROTECTED] for sending me one. The /etc/make.conf's contents was a mere NOPROFILE=YES. Buildworld was attempted under a non-root account. The installed make(1) did not pass the regression tests, and this required a patch to src/Makefile (attach #1) to survive; the patch allows one to build and use the new make(1) under non-root, without the need to overwrite /usr/bin/make. (This patch, with Warner's suggestion incorporated, is currently considered by re@ for approval.) Other than that, both buildworld and buildkernel of the GENERIC kernel went just fine. The next step was to install the new kernel and modules, as outlined in UPDATING. As a prerequisite step (following the instructions from UPDATING) I've created the /boot/device.hints file, and attempted to installkernel. This failed with ``You must activate /boot/device.hints in loader.conf.'' from kern.post.mk because 4.0 does not have /boot/defaults/loader.conf. (Rather than creating it by hands, I took another approach, see below.) As was documented in rev. 1.219 of UPDATING, after installing a kernel (which I did not yet succeded in), it is highly recommended to install new loader(8), and generally, upgrade /boot. WARNING! The relevant instruction from UPDATING, cd src/sys/boot ; make install will NOT work as is on most of old systems -- if run as is, make(1) will use stuff from /usr/share/mk which may be incompatible with sys/boot/ makefiles. Adding the -m `pwd`/../../share/mk did not help either because now make(1) was attempting to run 4.0's install(1) which does not understand the new -b option (INSTALLFLAGS=-b in sys/boot/i386/loader/Makefile), in particular. Another problem with 4.0 install(1) is that it removes source files by default, while new versions of install(1) (4.3-STABLE and onwards) copy it by default, so if you attempted to run it as is, it will wipe out some already built stuff from /usr/obj, making the next installworld attempt to fail. To overcome this, I needed to use the installworld environment [with an up-to-date src/share/mk/ and install(1)] to install sys/boot/. Fortunately, we have the SUBDIR_OVERRIDE knob in Makefile.inc1 that was helpful here. So, my next attempt was to run, from src/, the following command: make installworld SUBDIR_OVERRIDE=sys/boot This would upgrade /boot, and (as part of the upgrade) install /boot/defaults/loader.conf that is needed for installkernel to proceed (see above). Unfortunately, this has failed to pass the `installcheck' anti-foot-shooting check from Makefile.inc1, which installworld depends on: 1. smmsp user was missing from /etc/passwd and /etc/group 2. installed 4.0 kernel did not have the sigaction(2) syscall I've attempted to overcome 1) as suggested by UPDATING, by running the ``mergemaster -p'' (from src/usr.sbin/mergemaster/). This did not work well because mergemaster(8) attempted to use stat(1) which is not present in 4.0. OK, it was trivial (in my case) to update /etc/master.passwd and /etc/group by hands and run ``pwd_mkdb -p /etc/master.passwd'' afterwards. I couldn't overcome 2) for obvious reason -- I was in the middle of attempting to install a new kernel! Isn't this itself a sort of foot-shooting? :-) The solution was to make the `installcheck' a no-op by: make installworld SUBDIR_OVERRIDE=sys/boot \ -DNO_SENDMAIL DISTDIR= After this, ``make installkernel'' succeeded, but I noticed another glitch. installkernel, as coded in Makefile.inc1, uses user's PATH and hence /usr/bin/install (4.0 version) that deletes source files by default. So, if you attempt to installkernel for the second time, it will fail. The tiny patch to fix this is in attach #2. After rebooting with the new kernel in single user
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
[Cc: to re@ dropped to avoid unnecessary load] On Sun, Dec 01, 2002 at 01:15:00PM -0200, Daniel C. Sobral wrote: There I go reply to all... sigh IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the *latest* version in the 3.x series. I sure hope we adopt the same policy here. This popped up several times already, on various open and closed lists. This time I'll be short. On Thu, Nov 14, 2002 at 08:28:57AM -0700, M. Warner Losh wrote: A long time ago ru said he'd do this and he has been doing this so I think that we should allow him to continue to do this and tell people that want to prematurely tidy up that they can't for a while. Warner (This was about removing some of the bootstrapping stuff needed to upgrade from 4.0-RELEASE ~= first-day 5.0-CURRENT systems.) Ruslan Ermilov wrote: [ current@ Cc:'ed because it'll be useful to a number of upgraders. dougb@ Cc:'ed to be aware of possible mergemaster(8) problems. imp@ Cc:'ed to be aware of incorrect UPDATING instruction. peter@ Cc:'ed to LOL about foot-shooting with anti-foot-shooting. re@ Cc:'ed to consider approving the attached patches. ] Hi! Following is the report from my attempt to upgrade 4.0-RELEASE system to 5.0-CURRENT. First, I'd like to say that I succedded in it: FreeBSD 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Mon Mar 20 22:50:22 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Dec 1 13:52:37 GMT 2002 ru@:/usr/obj/ru/mnt/usr/src/sys/GENERIC i386 Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg47882/pgp0.pgp Description: PGP signature
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
Apparently, On Sun, Dec 01, 2002 at 01:15:00PM -0200, Daniel C. Sobral said words to the effect of; There I go reply to all... sigh IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the *latest* version in the 3.x series. I sure hope we adopt the same policy here. Agree, I don't see any use in supporting upgrades without going through 4.x-STABLE first. Jake Ruslan Ermilov wrote: [ current@ Cc:'ed because it'll be useful to a number of upgraders. dougb@ Cc:'ed to be aware of possible mergemaster(8) problems. imp@ Cc:'ed to be aware of incorrect UPDATING instruction. peter@ Cc:'ed to LOL about foot-shooting with anti-foot-shooting. re@ Cc:'ed to consider approving the attached patches. ] Hi! Following is the report from my attempt to upgrade 4.0-RELEASE system to 5.0-CURRENT. First, I'd like to say that I succedded in it: FreeBSD 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Mon Mar 20 22:50:22 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Dec 1 13:52:37 GMT 2002 ru@:/usr/obj/ru/mnt/usr/src/sys/GENERIC i386 4.0-RELEASE system was installed on a spare disk by newfs'ing the `a' partition and extracting the `bin' distribution on top of it from the 4.0-RELEASE 1st CD, thanks again to Charlie Brewster [EMAIL PROTECTED] for sending me one. The /etc/make.conf's contents was a mere NOPROFILE=YES. Buildworld was attempted under a non-root account. The installed make(1) did not pass the regression tests, and this required a patch to src/Makefile (attach #1) to survive; the patch allows one to build and use the new make(1) under non-root, without the need to overwrite /usr/bin/make. (This patch, with Warner's suggestion incorporated, is currently considered by re@ for approval.) Other than that, both buildworld and buildkernel of the GENERIC kernel went just fine. The next step was to install the new kernel and modules, as outlined in UPDATING. As a prerequisite step (following the instructions from UPDATING) I've created the /boot/device.hints file, and attempted to installkernel. This failed with ``You must activate /boot/device.hints in loader.conf.'' from kern.post.mk because 4.0 does not have /boot/defaults/loader.conf. (Rather than creating it by hands, I took another approach, see below.) As was documented in rev. 1.219 of UPDATING, after installing a kernel (which I did not yet succeded in), it is highly recommended to install new loader(8), and generally, upgrade /boot. WARNING! The relevant instruction from UPDATING, cd src/sys/boot ; make install will NOT work as is on most of old systems -- if run as is, make(1) will use stuff from /usr/share/mk which may be incompatible with sys/boot/ makefiles. Adding the -m `pwd`/../../share/mk did not help either because now make(1) was attempting to run 4.0's install(1) which does not understand the new -b option (INSTALLFLAGS=-b in sys/boot/i386/loader/Makefile), in particular. Another problem with 4.0 install(1) is that it removes source files by default, while new versions of install(1) (4.3-STABLE and onwards) copy it by default, so if you attempted to run it as is, it will wipe out some already built stuff from /usr/obj, making the next installworld attempt to fail. To overcome this, I needed to use the installworld environment [with an up-to-date src/share/mk/ and install(1)] to install sys/boot/. Fortunately, we have the SUBDIR_OVERRIDE knob in Makefile.inc1 that was helpful here. So, my next attempt was to run, from src/, the following command: make installworld SUBDIR_OVERRIDE=sys/boot This would upgrade /boot, and (as part of the upgrade) install /boot/defaults/loader.conf that is needed for installkernel to proceed (see above). Unfortunately, this has failed to pass the `installcheck' anti-foot-shooting check from Makefile.inc1, which installworld depends on: 1. smmsp user was missing from /etc/passwd and /etc/group 2. installed 4.0 kernel did not have the sigaction(2) syscall I've attempted to overcome 1) as suggested by UPDATING, by running the ``mergemaster -p'' (from src/usr.sbin/mergemaster/). This did not work well because mergemaster(8) attempted to use stat(1) which is not present in 4.0. OK, it was trivial (in my case) to update /etc/master.passwd and /etc/group by hands and run ``pwd_mkdb -p /etc/master.passwd'' afterwards. I couldn't overcome 2) for obvious reason -- I was in the middle of attempting to install a new kernel! Isn't this itself a sort of foot-shooting? :-) The solution was to make the `installcheck' a no-op by: make installworld SUBDIR_OVERRIDE=sys/boot \ -DNO_SENDMAIL DISTDIR= After this, ``make installkernel'' succeeded, but I noticed another glitch.
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
On Sun, 1 Dec 2002, Jake Burkholder wrote: Apparently, On Sun, Dec 01, 2002 at 01:15:00PM -0200, Daniel C. Sobral said words to the effect of; There I go reply to all... sigh IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the *latest* version in the 3.x series. I sure hope we adopt the same policy here. Agree, I don't see any use in supporting upgrades without going through 4.x-STABLE first. It's nice that you guys are in agreement on that fact, but perhaps you'd like to do something constructive like to look at and review the patches? Avoiding the install of a new make during a build is highly desirable, even if you don't believe in updating from old RELENG_4. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
In message: [EMAIL PROTECTED] Daniel C. Sobral [EMAIL PROTECTED] writes: : There I go reply to all... sigh : : IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the : *latest* version in the 3.x series. I sure hope we adopt the same policy : here. ru@ has stepped up to the plate to support more. He's gone through and made sure that all the way back to 4.0-release is upgradable (at least at each release point), going to support it through the first branchpoint. You as a committer aren't required to do extra work to make this work, except to not remove things he's done to make this work. It is unclear what should happen when a piece of thirdparty software is upgraded. However, core ruled a long time ago that ru@ can take reasonable measures to make sure that it works. ru@ has kept it up for a while now, so it looks like he's in it for the long run. This is only for native builds. Anything that is needed for cross building isn't included in this 'upgrade' path. It is there just to make our user's life easier. Also, core didn't want the work arounds to get too gross, but so far all the ones I've l ooked at were relatively inobtrusive. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
Hey ru! These patches are only one '/' different from what I build on my 4.3, 4.5 and 4.6.2 systems w/o a new make being installed. All built perfectly! Thanks! Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Patches reviewed [was: Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT]
On Sun, Dec 01, 2002 at 12:12:36PM -0500, Robert Watson wrote: There I go reply to all... sigh IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the *latest* version in the 3.x series. I sure hope we adopt the same policy here. Agree, I don't see any use in supporting upgrades without going through 4.x-STABLE first. It's nice that you guys are in agreement on that fact, but perhaps you'd like to do something constructive like to look at and review the patches? Done. The patches look good. Avoiding the install of a new make during a build is highly desirable, even if you don't believe in updating from old RELENG_4. Agreed (it's so nice to be in agreement :-) A regular buildworld failed even when upgrading a less-than-a-week old -current. The removal of anything we install as part of a build phase is good and not tied to the (version) distance of the upgrade. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
