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

In message <20170524192734.67a84527_at_thor.intern.walstatt.dynvpn.de>, "O. 
Hartma
nn" writes:
> --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_at_walstatt.org> schrieb:
> 
> > On Wed, 24 May 2017 14:31:08 +0300
> > Konstantin Belousov <kostikbel_at_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_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" =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!

The solution to this is to use an include statement followed by options, 
nooptions, device and nodevice statements, i.e.,

include		GENERIC
ident		MYKERNEL

nooptions ...
options ...
nodevice ...
device ...
...
and so on...

You will automatically get any new options and devices in GENERIC until you 
exclude them in your custom kernel.

Additionally you can nest your kernels such that you might have a site-wide 
config that is included in various other configs, e.g.,

include MYKERNEL
ident   BREAK

makeoptions	DEBUG=-g		#Build kernel with gdb(1) debug symbols
 
options 	KDB			#Enable kernel debugger support.
options 	DDB			#Support DDB
options 	GDB			#Support remote GDB.
and so on...

Of course the problem then becomes keeping track of a proliferation of 
configs and which relate to each other.  ;)


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_cschubert.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.