# Patching Stable



## z662 (Apr 17, 2015)

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


```
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$
```


----------



## SirDice (Apr 17, 2015)

Which stable branch? There are several, 8-STABLE, 9-STABLE and 10-STABLE.


----------



## z662 (Apr 17, 2015)

Sorry - 10-STABLE


----------



## kpa (Apr 17, 2015)

Post your /etc/make.conf and /etc/src.conf.


----------



## z662 (Apr 17, 2015)

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/.


----------



## protocelt (Apr 17, 2015)

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/


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.


----------



## z662 (Apr 17, 2015)

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


----------



## z662 (Apr 17, 2015)

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.


----------



## protocelt (Apr 17, 2015)

What method are you using to update your source tree?


----------



## z662 (Apr 17, 2015)

`svn up` while in /usr/src/


```
brad@mercury:/usr/src$ sudo svn up
Password:
Updating '.':
At revision 281661.
brad@mercury:/usr/src$
```


----------



## chrbr (Apr 17, 2015)

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.


----------



## protocelt (Apr 17, 2015)

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.


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:

Make sure you have a backup (mandatory), then run `# rm -rf /usr/src/*`
`# svn up /usr/src`
Follow the instructions in the guide I referenced to update.
You will then be updated to the latest STABLE revision with included security fixes.


----------



## wblock@ (Apr 17, 2015)

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.


----------



## chrbr (Apr 17, 2015)

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?


----------



## wblock@ (Apr 17, 2015)

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.


----------



## chrbr (Apr 18, 2015)

Dear wblock@,
thank you for the clarification. I have a lot to learn and I will follow this thread to see the progress of fixing the issue on z662's system.


----------



## z662 (Apr 18, 2015)

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.


----------



## kpa (Apr 18, 2015)

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 (Apr 18, 2015)

After deleting the old repository it has successfully rebuilt.  Thanks everyone.


----------



## wblock@ (Apr 19, 2015)

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`.



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.


----------

