installworld fails

[Kevin Oberman]

On Tue, Jan 20, 2015 at 8:28 AM, Konstantin Belousov <kostikbel at gmail.com>
wrote:

> On Tue, Jan 20, 2015 at 05:01:39PM +0100, Johan Hendriks wrote:
> > Thanks, Your solution did work, thank you very much.
> >
> >
> > I do the same routine as always.
> > The buildworld and build kernel went fine.
> >
> > cd /usr/src/
> > make cleanworld
> > make buildworld
> > make kernel
> > mergemaster -p
> > make installworld
> > mergemaster -iU
> I doubt it, really.  Installation procedure installs libc before libthr.
> Your libc was built from sources before r277317, while libthr was at
> r277317 or after.
>
> Also, as I said, the mere complain about libthr during installworld is
> a red mark, since no install-time tools are multithreaded, AFAIK.
>

Also, a minor, but occasionally significant deviation from the recommended
procedure is that you need to do "mergemaster -p" before the "make kernel".
If you check the man page on mergemaster you will note that it is intended
to be run even before buildworld, but it's pretty unlikely that a
buildworld will fail because of it. There was one update back four or five
years ago that depended on a user or group to do the kernel and lots of
reports of a broken kernel install came in. Rare, but very annoying. Also,
I prefer F to U and use -P as an aded safety factor. As was pointed out to
me a wile back, -U has an inherent race that can bite you in a couple of
ways. Again, unlikely to bite you, but not impossible.There is a warning in
the man page for mergemaster..

Also, a reboot to single user between "make kernel" and "make installworld"
is a really, really good idea. If you installworld and your kernel is bad
(and this happens once in a while), you have a real mess on your hands.
With remote systems with no OOB access to the console skipping the reboot
this is almost a necessity, but make sure that you have done an identical
upgrade on a local system before trying it

Finally, buildworld does a cleanworld, so a separate "make cleanworld" is a
waste of time. There are cases when the clean (in either way) is
inadequate, so I do "rm -r /usr/obj/*" and add "-DNO_CLEAN" to both
buildworld and kernel (or buildkernel). If you have multiple CPUs, -jN
(where 'N' is a bit greater than the number of cores) is a big time saver
in buildworld and buidlkernel.

Yes, this stuff is a bit paranoid, but costs little, so I recommend it.
Several years of engineering a critical high performance (currently up to
340 Gbps) international network makes me very conservative. Making a
mistake that cuts off the data flow from the Large Hadron Collider in
Europe to the US is a really bad idea. ;-) At 100 Gbps, it only takes a
very short hit to blow away a .9999 reliability and my organization wanted
5 9s.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com