Re: ino64: desastrous update - recommendations not working!!!

On Wed, 24 May 2017 14:31:08 +0300
Konstantin Belousov <kostikbel_at_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
> binaries.

It is(!) new as it has been installed from sources checked out
recently, rebuilt world and rebuilt world after I completely
DELETED(!) /usr/obj.
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
failing wreckeges.

> 
> > 
> > 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
the list.

> 
> > 
> > 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:
> https://www.kib.kiev.ua/kib/stat-ino64-static
> 
> 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.

> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"