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

Am Wed, 24 May 2017 14:15:07 +0200
"Hartmann, O." <o.hartmann_at_walstatt.org> schrieb:

> 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"  
> 

Stefan Esser was so kind and pushed me towards COMPAT_FREEBSD11 options requisite in the
kernel. It was missing in kernel configs of mine or I had COMPAT_FREEBSD10 already set
and confused with the version 11.

Mea culpa!

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).