Am Wed, 24 May 2017 14:15:07 +0200 "Hartmann, O." <o.hartm...@walstatt.org> schrieb:
> 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 > > 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. > > > _______________________________________________ > > email@example.com mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscr...@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).
Description: OpenPGP digital signature