On Wed, 24 May 2017 14:31:08 +0300
Konstantin Belousov <kostik...@gmail.com> wrote:
> On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote:
> > On almost every CURRENT that has been updated according to UPDATING
> > entry 2017-05-23 regarding ino64, the recommended update process
> > ends up in a desaster or, if the old environemnt/kernel is intact,
> > itr doesn't work.
> > Procedure:
> > make -jX buildworld buildkernel [successful]
> > make installkernel [successful]
> > reboot
> > Booting single user mode as recommended withnthe newly installed
> > kernel BUMMER!
> > When it comes to the point to type in the full path
> > of /bin/sh, /bin/sh immediately fails with SIGNAL 12
> Signal 12 is SIGSYS, which strongly suggest that your 'new' kernel is
> not new, it does not implement some of the syscalls called by new
It is(!) new as it has been installed from sources checked out
recently, rebuilt world and rebuilt world after I completely
The most striking evidence would be the revision number right now, but
I don't have the luxury of time at the moment to play with the harhsly
> > In this case, I can boot without problems the old kernel and the
> > system works again.
> > But, depending on the entry revision from which I started the 22nd,
> > or 23rd of May ino64-deal, there is a more harsh failure!
> I do not understand what are you trying to say there.
Well, that is easy. On our development and testing facilities, I do
in most cases daily updates. Some notebooks or systems I/we have to
rely a bit more on, I do this after two or more days after a successful
update of the others.
What I want to say - and did say - is: boxes which I have updated
recently, 22nd, 23rd May the last time, do break on installworld after
they booted successfully the new kernel and gave me a single-user
console, while the notebooks, for instance, which has been updated
CURRENT the last time on Thursday last week, only fail in getting a
login due to the /bin/sh SIGSYS issue.
I think David Wolfskill made a point about this in a recent commit to
> > According to the above recommendation of updating, BUMMER! doesn't
> > occur at that point and the shell /bin/sh starts as expected.
> > Performing
> > mergemaster -Fp
> > also performs well without any questions or installations so far,
> > but then
> > make installworld
> > BUMMER! again and this time with fatal consequences! The
> > installation fails in libexec/rtld-elf or something like that in the
> > source/object tree after copying libexec/ld-elf.so.1. I
> > see /libexec/ld-elf.so.1 successfully copied with the security copy
> > marked with appendix .old being of a conclusive date and time.
> > The installworld bails out, leaves the tree in a mixture of old and
> > new binaries and now, thanks, the whole system ist wrecked.
> > When trying to reboot such a half-ready installation in single user
> > mode, I can't even get an shell enymore.
> > How can I fix this emergency case with the tools aboard?
> > Since there is no compiler or build infrastructure any more on the
> > USB bootimage, I can not simply installworld and installkernel -
> > the boot image is useless - on this list I had such a discussion in
> > March. For short: I have the intact and complete /usr/obj tree and
> > I think it would be a great deal to be able to simply boot via USB
> > memstick and perform installworld with propper settings of DESTDIR=
> > and sibblings.
> > Yes, now what is to do ... :-(
> > Help appreciated and thanks in advance for those reading so far.
> I put a statically built stat(1) binary there:
> You might use it as a test for the right kernel: after you boot with
> supposedly new kernel but old world, try to run the binary. If
> running results in SIGSYS (12), you have configuration issue to solve.
I'll try. And report. But I'm out of the lab until Monday :-( I have
boxes at home I'd like to update, last update of those was the day
before yesterday, but I do not dare until the issue is identified
correctly. As David Wolfskill stated in his headline, it is probably
not ino64 messing up - as I interprete his question mark.
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"