From owner-freebsd-current@freebsd.org Wed May 24 12:15:12 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 C79A4D78A2E for ; Wed, 24 May 2017 12:15:12 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 43E021682 for ; Wed, 24 May 2017 12:15:11 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from hermann ([87.138.105.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M2ts6-1e3pAA0rva-00sgxN; Wed, 24 May 2017 14:15:08 +0200 Date: Wed, 24 May 2017 14:15:07 +0200 From: "Hartmann, O." To: Konstantin Belousov Cc: "Hartmann, O." , FreeBSD CURRENT Subject: Re: ino64: desastrous update - recommendations not working!!! Message-ID: <20170524141507.32490c2a@hermann> In-Reply-To: <20170524113108.GK1622@kib.kiev.ua> References: <20170524124219.3410c416@hermann> <20170524113108.GK1622@kib.kiev.ua> Organization: walstatt.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ze5muvFZ3FBKmxsk8kat7QjWbPYPe1UnYWJ+369pbQL3h1rD919 lrZshG82+NsiBaVtiqgUkGgRso/8vyLLMOjMZNd0kZyr1YmxmCTcztjFqHBm2jRlID9HYCt TuAN2YKLDxRf/MR9bvSAefq/ik2qG2qxRD9+l4S0UE69MeTqAwCCZt13crLS4Uw3ykz+WKM KpCylDcecPRhdbIdIS2hQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:eSLb5gjwgvo=:E3IfW+EjSxmGXex25DVKVp 1CBXZ5TGCak82xX36sMtIyTHd9OftbMy0EJA7BDn5voYftYbz33wc3Arb4q66ujAsLDmaxVw8 mqTsUgpfmCc5ZA3m8g6UJSj7bWmfRyvCTWCh7SiDkQeVNPkRXGAOM1iD66t2AXBOpoZfONNhx 2nbr4kR426uadNmSm5FhpqrZ3mc+na1ZKQfx0852FOKcXhJpXDAoqI01nBg911lKlitwE3Tfd giUuh/7dpAzpUpTMRV9bVHyETWcAUlOsrrQ6SWfbZvs/B9GhpCfOGs9KhHFE20Hb68oLqAJFc kYu5kfs/zz4tK2oVRkdb/TLpJ1WQ057GjYHOOJXgqsZKEUveGIS0My0bEvkvg7Q3ArLaDVFVS K/77rYN5a+GHXuY9rrmhqbeAVLp1B9dOxXLnvZa4zD4NkagxjPRHOrptqVWJOpJXUeyD4vp3T UHQrVezBCHWVB0Db6aMJhZOnaX4PdzkdfQOql/eZZKgmkIb4YJvdpVAl6elIoQbXTc1dl39IA 9YZr09axIq/SRfh41QD96ZTMk5KNPfZIboXIsIlhK3NoKTIhoBrPO86Szc2ypCXhRcmQjT6uv QzgpUYQe25x0O+UOqfaqHsGpmXrBGdGeaxYpxsOHbLAYbsT7yr0n/TosXqC0jKFv6rWJjogPL duj/ZY4HY/eGlM/EMC13X4HJiomcIk47SZdvgMDzEqwa9W0lQgcEhrX5iQXi+efjhT8RrgFLR 9bAehWi/CDkVW4c/Y8Gut18uBPXfaenIOqKLLfbpwmKDhyTHqw7UvQohMw9D9c/jQcuHJwgr/ lcNtnAzor08kbS9C42OKrUOrAO6CFPXlZOAy+g+zirg/54o4v9P4AmeolW1rK7mLX8qQvOPqv ypXUNyXGwA8vg94XSMOg== X-Mailman-Approved-At: Wed, 24 May 2017 13:46:14 +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 12:15:12 -0000 On Wed, 24 May 2017 14:31:08 +0300 Konstantin Belousov 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"