Date: Wed, 24 May 2017 19:27:34 +0200 From: "O. Hartmann" <o.hartmann@walstatt.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "Hartmann, O." <ohartmann@walstatt.org>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: ino64: desastrous update - recommendations not working!!! Message-ID: <20170524192734.67a84527@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170524141507.32490c2a@hermann> References: <20170524124219.3410c416@hermann> <20170524113108.GK1622@kib.kiev.ua> <20170524141507.32490c2a@hermann>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/4+3DjX6aWzM+U5.TkY0/Z6W Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Wed, 24 May 2017 14:15:07 +0200 "Hartmann, O." <o.hartmann@walstatt.org> schrieb: > On Wed, 24 May 2017 14:31:08 +0300 > Konstantin Belousov <kostikbel@gmail.com> wrote: >=20 > > On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote: =20 > > > 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. > > >=20 > > > Procedure: > > >=20 > > > 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 =20 > > 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. =20 >=20 > 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. >=20 > > =20 > > >=20 > > > In this case, I can boot without problems the old kernel and the > > > system works again. > > >=20 > > > But, depending on the entry revision from which I started the 22nd, > > > or 23rd of May ino64-deal, there is a more harsh failure! =20 > > I do not understand what are you trying to say there. =20 >=20 > 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. >=20 > 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. >=20 > I think David Wolfskill made a point about this in a recent commit to > the list. >=20 > > =20 > > >=20 > > > According to the above recommendation of updating, BUMMER! doesn't > > > occur at that point and the shell /bin/sh starts as expected. > > > Performing=20 > > >=20 > > > mergemaster -Fp > > >=20 > > > also performs well without any questions or installations so far, > > > but then > > >=20 > > > make installworld > > >=20 > > > 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. > > >=20 > > > How can I fix this emergency case with the tools aboard? > > >=20 > > > 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=3D > > > and sibblings. > > >=20 > > > Yes, now what is to do ... :-( > > >=20 > > > Help appreciated and thanks in advance for those reading so far. =20 > >=20 > > I put a statically built stat(1) binary there: > > https://www.kib.kiev.ua/kib/stat-ino64-static > >=20 > > 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. = =20 >=20 > 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. >=20 > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" =20 >=20 Stefan Esser was so kind and pushed me towards COMPAT_FREEBSD11 options req= uisite 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! --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/4+3DjX6aWzM+U5.TkY0/Z6W Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWSXChgAKCRDS528fyFhY lPhJAgCp0kcFawDFTzACIzTKaaY8BGL33KIV9jj2r6LRPHegaUK77IFNXu6VR+jg sWtO7c09Boh0kIOt975hBnpa/jWRAf9hrTUmjJYCRrRuv8dfnq7T/u+Ky6+zwH1k LxT6A0UneePBp7m2JMAHQ+4rzbEctgWZx5MWuQcLInu6YC2A+M4o =T8Dd -----END PGP SIGNATURE----- --Sig_/4+3DjX6aWzM+U5.TkY0/Z6W--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170524192734.67a84527>