From owner-freebsd-current@freebsd.org Wed May 24 17:27:45 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8D28D7B228 for ; Wed, 24 May 2017 17:27:45 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28825118E for ; Wed, 24 May 2017 17:27:44 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.134.189]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MId0S-1dFmzn3ugK-002FY6; Wed, 24 May 2017 19:27:36 +0200 Date: Wed, 24 May 2017 19:27:34 +0200 From: "O. Hartmann" To: Konstantin Belousov Cc: "Hartmann, O." , FreeBSD CURRENT 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> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/4+3DjX6aWzM+U5.TkY0/Z6W"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Yc1WUDBUW0JBIwAN5EpD1/Ru9AHhef80J0ZxnmBEawWRuGGIvm+ FlECsOhpAEhOMS7zlAXRz/Yi4mT5I/rGmSjnpPYLC28kOqvIQUzy7Tp0wL87IAV9hw19Caz acNlZIOi/YDX5icXPzu1YR8qyVaAsolsocWh11rKd3aTQRmnW+wzDF77Op2ZNYxMV6Gx8+O XrSs7Xf03SwN/0pjY5eIQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:aD0fug/VR8U=:K1MRn+z7KhxP6GoVysrhBC QGg0rxhsmIoxIvMFqsfzG4BDFHRA0V5oBevbtVFy4pIO0IFYAhefmX9scCHdh2BW+MQCfAbXR Ww0ZVZGZKidQb2PNHwaWxIZJSSGarujXMiypkqvcMo29kxBMFstlS8n34Vs9ebQSub9DqOzvd Eyj/CtzYYINFahtM72BPE1e4X57d0DRm9ijGDL7XcCcVy755NY96l7ipTZMAR7xEpa/NZf0bL ptEGyWnLqTUKxdXs1tvSHEJWtdyB50B5N9mRlVpp85rV4A3M9soZX6BAisLa46k4qQGeTx/u7 0ssPVarDvzHUWFl+gUsEABKXI6azn+FWeTGyWtBfPCN1V+GTyqrQ07FaWVz16cd3ydUA+qPux iq97tPVTbUzz7uPoWwMrLXdnmfXkyT7idtfaEv511dcP78KBJhBfCxOlNGJblhF6n4Y7mj3Xj ubasl5hy2V/YVU79wAJC+di7lbM/HVC/0EkYR1PGSB6tUAd/iEXb9MERSC7bL1nUmya0YFmBd BRHpBQ+N3URlJckn0j63nSQk1AB8ufHzKEjUFSZpwbhVTzdbK7DZssLsagXJOi7FsXXKM5FeB ZXaJl+p/2jvmGjKCebNE6RexahwAD56Jgah6MUg1w3uJsA5Uy+aD0Ymr+rwd1xCgaT3GSCJrG fj++l+PdruCP/Lqk+3gmyzpyqHwnMf0hI/hHEAzHgPY7Tc56lPpCyRMizEHbovYmHy3QhAnwC v+AjqqVthQAOFIT4/zBI/xg5KrVa3RqwxrGRKbfp/7ldRZwAdjLbR1xvDhGbf4MuyhO1yL905 SaEpEL9c9fbzDTdXeILwFvURNrURnMP2jV/LSZmsA3bIRBx+gjAp9A3j7XTFyr+FwrAZyT1 X-Mailman-Approved-At: Wed, 24 May 2017 19:32:42 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 17:27:45 -0000 --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." schrieb: > On Wed, 24 May 2017 14:31:08 +0300 > Konstantin Belousov 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--