Patching Stable

z662

z662

I am currently tracking the Stable branch and am running into an issue when trying to upgrade/patch it.

I am attempting to use these instructions here: https://www.freebsd.org/doc/handbook/makeworld.html

But receive a build error when doing make buildworld. I have attached a snippet of the error below.

Please let me know if more information is needed. Thanks

Code: 
rm -f a.out firewire.o fwohci.o dconsole.o dcons.o fwcrom.o firewire.o.tmp fwohci.o.tmp dconsole.o.tmp dcons.o.tmp fwcrom.o.tmp
rm -f libfirewire.a
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> sys/boot/i386/loader (cleandir)
rm -f vers.c loader loader.bin loader.help loader.sym /usr/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o vers.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf32_obj.o reloc_elf32.o load_elf64.o load_elf64_obj.o reloc_elf64.o disk.o part.o crc32.o bcache.o isapnp.o pnp.o interp_forth.o beastie.4th.8.gz brand.4th.8.gz check-password.4th.8.gz color.4th.8.gz delay.4th.8.gz loader.conf.5.gz loader.4th.8.gz menu.4th.8.gz menusets.4th.8.gz version.4th.8.gz loader.8.gz zfsloader.8.gz beastie.4th.8.cat.gz brand.4th.8.cat.gz check-password.4th.8.cat.gz color.4th.8.cat.gz delay.4th.8.cat.gz loader.conf.5.cat.gz loader.4th.8.cat.gz menu.4th.8.cat.gz menusets.4th.8.cat.gz version.4th.8.cat.gz loader.8.cat.gz zfsloader.8.cat.gz machine
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> sys/boot/i386/pxeldr (cleandir)
rm -f pxeboot pxeboot.tmp loader pxeldr pxeldr.o pxeboot.8.gz pxeboot.8.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> sys/boot/i386/zfsboot (cleandir)
rm -f zfsboot zfsboot1 zfsldr.out zfsldr.o zfsboot2 zfsboot.ld zfsboot.ldr zfsboot.bin zfsboot.out  zfsboot.o zfsboot.s zfsboot.s.tmp sio.o cons.o drv.o util.o machine zfsboot.8.gz zfsboot.8.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> sys/boot/i386/gptzfsboot (cleandir)
rm -f gptzfsboot gptldr.bin gptldr.out gptldr.o gptzfsboot.bin gptzfsboot.out zfsboot.o sio.o cons.o  drv.o gpt.o util.o machine gptzfsboot.8.gz gptzfsboot.8.cat.gz
===> sys/boot/i386/zfsloader (cleandir)
rm -f vers.c zfsloader zfsloader.bin loader.help zfsloader.sym /usr/src/sys/boot/i386/zfsloader/../btx/lib/crt0.o main.o conf.o vers.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf32_obj.o reloc_elf32.o load_elf64.o load_elf64_obj.o reloc_elf64.o disk.o part.o crc32.o bcache.o isapnp.o pnp.o interp_forth.o beastie.4th.8.gz brand.4th.8.gz check-password.4th.8.gz color.4th.8.gz delay.4th.8.gz loader.conf.5.gz loader.4th.8.gz menu.4th.8.gz menusets.4th.8.gz version.4th.8.gz loader.8.gz zfsloader.8.gz beastie.4th.8.cat.gz brand.4th.8.cat.gz check-password.4th.8.cat.gz color.4th.8.cat.gz delay.4th.8.cat.gz loader.conf.5.cat.gz loader.4th.8.cat.gz menu.4th.8.cat.gz menusets.4th.8.cat.gz version.4th.8.cat.gz loader.8.cat.gz zfsloader.8.cat.gz machine
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin (cleandir)
make[3]: "/usr/src/usr.bin/Makefile" line 228: Malformed conditional (${MK_EE} != "no")
make[3]: "/usr/src/usr.bin/Makefile" line 232: Malformed conditional (${MK_FILE} != "no")
make[3]: "/usr/src/usr.bin/Makefile" line 236: Malformed conditional (${MK_FINGER} != "no")
make[3]: "/usr/src/usr.bin/Makefile" line 240: Malformed conditional (${MK_FTP} != "no")
make[3]: "/usr/src/usr.bin/Makefile" line 262: Malformed conditional (${MK_ISCSI} != "no")
make[3]: "/usr/src/usr.bin/Makefile" line 346: Malformed conditional (${MK_TALK} != "no")
make[3]: "/usr/src/usr.bin/Makefile" line 364: Malformed conditional (${MK_TFTP} != "no")
make[3]: Fatal errors encountered -- cannot continue
make[3]: stopped in /usr/src/usr.bin
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
brad@mercury:/usr/src$
 
Which stable branch? There are several, 8-STABLE, 9-STABLE and 10-STABLE.
 
I don't have either of those files. Should they have been created when installing or did I miss a prerequisite step?

I also looked in /usr/src/etc and /usr/local/etc/.
 
z662 said:
I don't have either of those files. Should they have been created when installing or did I miss a prerequisite step?

I also looked in /usr/src/etc and /usr/local/etc/
Click to expand...
No, the files are not required and do not exist by default. They are manually added by the user to add preferences and settings to make(1) when compiling source. The question was asked because some people will put settings in either of those files that can cause problems when compiling world or kernel sources.

Your problem may be fixed just by updating STABLE to a newer revision and trying again. STABLE doesn't normally have problems, but they do pop up once in a while and usually are quite promptly fixed.

Additionally if your interested, wblock@ has I much simpler guide that would work just as well for updating STABLE if your not trying to do anything fancy or non-standard. It's what I use most of the time myself and works quite well.
 
I think the issue is on my end as I have ensured I had the latest svn revision. I just wanted to be able to patch some of the security issues that were announced. I will check out his guide - thanks
 
His guide is definitely more reader-friendly but I am still going to have issues getting past the buildworld step. Does anyone know why my system would be failing like this? It has been like this for about a week or two.
 
svn up while in /usr/src/

Code: 
brad@mercury:/usr/src$ sudo svn up
Password:
Updating '.':
At revision 281661.
brad@mercury:/usr/src$
 
From my understanding it is not necessary to apply patches if the update from the svn repository is done. Of course the revision should be similar or greater than the version number mentioned in the advisory. Then the update already includes the patches. Please correct me if I am wrong.
 
chrbr said:
From my understanding it is not necessary to apply patches if the update from the svn repository is done. Of course the revision should be similar or greater than the version number mentioned in the advisory. Then the update already includes the patches. Please correct me if I am wrong.
Click to expand...
That is correct. The fix and revision the fix is included in if available will be mentioned in the relevant errata notice.

In this case you should be able to do the following:
  1. Make sure you have a backup (mandatory), then run # rm -rf /usr/src/*
  2. # svn up /usr/src
  3. Follow the instructions in the guide I referenced to update.
You will then be updated to the latest STABLE revision with included security fixes. :)
 
Yesterday, I updated a 10-STABLE system last updated in January, and had similar problems. Eventually, I ended up doing the make toolchain separately, then still had to rebuild some individual utilities like yacc(1). I don't know exactly what the problem was, this kind of thing is not normal for STABLE.
 
Dear wblock@,
I am not the original user who has asked, but I think it is very important to know how to proceed in such a situation, at least when I speak just for myself :). Should the "hard way" as described in the handbook work as a fall back solution?
 
I do not think this was a problem with technique. When there are changes that require manual intervention, they are supposed to be noted in /usr/src/UPDATING. The yacc(1) problem was not in there, although it was mentioned in a mailing list. That problem has not happened on other machines. There is no one way to anticipate or fix these type of problems, they are very rare. kpa's question was exactly what I would have asked, looking for user-induced problems in /etc/make.conf or /etc/src.conf. But that was not the problem here, so I just searched on the error message.
 
Thanks for all of the replies/insight into this topic. I just deleted out my svn repo from /usr/src and plan to checkout the repository again and attempt to pickup where I left off. I guess my only question is now whether or not I really need to worry about rebuilding world and the kernel since all security advisories will be patched by just doing an svn up. I was under the impression I had to rebuild...so that is good to hear. Just wondering if it is even worth building world again. I guess that would depend on how many changes I just grabbed with the latest source code revisions and which things would be affected by not rebuilding world. Is that correct? My system is a few months old, so it is probably a good idea to do so but I will gladly stand corrected and not update if it really just necessary for my needs.
 
Always do a full rebuild with make buildworld buildkernel when updating, the world and kernel must be in sync or you run into some very weird problems that are next to impossible to diagnose. If you're doing an update to an older installation or you have have changed the options in /etc/make.conf or /etc/src.conf you should do rm -rf /usr/obj/* before launching the build.

It may seem alot of work for just minor updates but it's the price you pay for tracking a development branch of FreeBSD.
 
z662 said:
I guess my only question is now whether or not I really need to worry about rebuilding world and the kernel since all security advisories will be patched by just doing an svn up.
Click to expand...

That is not correct. Updating the source with svn up does not update the compiled kernel or binaries. All it does is get the latest version of the source. A full build and install is still needed to compile the source into binaries.
 
You must log in or register to reply here.
Back
Top