Date: Sat, 15 Dec 2018 17:42:02 +0100 From: Marius Strobl <marius@freebsd.org> To: Dima Panov <fluffy@FreeBSD.org> Cc: Glen Barber <gjb@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-releng@freebsd.org Subject: Re: svn commit: r341266 - in releng/12.0: . sys/modules/iavf Message-ID: <20181215164202.GF93591@alchemy.franken.de> In-Reply-To: <f0502995-75da-9a73-3a8f-25eb7761d7a5@FreeBSD.org> References: <201811292159.wATLx9Bb099604@repo.freebsd.org> <31493546-f2a6-8ad4-5c6e-5e8d835debeb@FreeBSD.org> <20181206172506.GU93591@alchemy.franken.de> <20181206173003.GE29692@FreeBSD.org> <20181206190802.GV93591@alchemy.franken.de> <f0502995-75da-9a73-3a8f-25eb7761d7a5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 07, 2018 at 01:29:57PM +1000, Dima Panov wrote: > Hello! > > Marius Strobl wrote on 07/12/2018 05:08: > > On Thu, Dec 06, 2018 at 05:30:03PM +0000, Glen Barber wrote: > >> On Thu, Dec 06, 2018 at 06:25:06PM +0100, Marius Strobl wrote: > >>> On Thu, Dec 06, 2018 at 03:58:44PM +1000, Dima Panov wrote: > >>>> Hello! > >>>> > >>>> Marius Strobl wrote on 30/11/2018 07:59: > >>>>> Author: marius > >>>>> Date: Thu Nov 29 21:59:09 2018 > >>>>> New Revision: 341266 > >>>>> URL: https://svnweb.freebsd.org/changeset/base/341266 > >>>>> > >>>>> Log: > >>>>> MFC: r341016, MF12: r341261 > >>>>> > >>>>> - Add a belated UPDATING entry for the ixlv(4) -> iavf(4) rename in r339338. > >>>>> - Likewise, add ixlv.4.gz to OLD_FILES, > >>>>> - and link if_ixlv.ko to if_iavf.ko in order to aid a bit in the transition. > >>>>> > >>>> [cut] > >>>>> > >>>>> Modified: releng/12.0/sys/modules/iavf/Makefile > >>>>> ============================================================================== > >>>>> --- releng/12.0/sys/modules/iavf/Makefile Thu Nov 29 21:20:53 2018 (r341265) > >>>>> +++ releng/12.0/sys/modules/iavf/Makefile Thu Nov 29 21:59:09 2018 (r341266) > >>>>> @@ -15,4 +15,6 @@ SRCS += i40e_common.c i40e_nvm.c i40e_adminq.c > >>>>> # Enable asserts and other debugging facilities > >>>>> # CFLAGS += -DINVARIANTS -DINVARIANTS_SUPPORT -DWITNESS > >>>>> > >>>>> +LINKS= ${KMODDIR}/${KMOD}.ko ${KMODDIR}/if_ixlv.ko > >>>>> + > >>>>> .include <bsd.kmod.mk> > >>>> > >>>> > >>>> And this broke poudriere jail upgrade due to missed kernel modules for > >>>> build purpose > >>>> > >>>> # poudriere jail -u -j fbsd12-test -t 12.0-RC3 > >>>> [skip] > >>>> /usr/src/usr.sbin/newsyslog/newsyslog.c > >>>> To install the downloaded upgrades, run "/usr/sbin/freebsd-update.fixed > >>>> install". > >>>> Installing updates...ln: ///boot/kernel/if_iavf.ko: No such file or > >>>> directory > >>>> chflags: ///boot/kernel/if_ixlv.ko: No such file or directory > >>>> [00:20:27] Error: Fail to upgrade system > >>>> # > >>> > >>> Hrm, apparently this doesn't trip up with a native, i. e. non-poudriere, > >>> environment and I'd assume that the linking of if_igb.ko to if_em.ko that > >>> sys/modules/em/Makefile does ever since r324500 isn't causing problems > >>> with poudriere either. What are poudriere and the "fixed" version of > >>> freebsd-update(8) doing differently than native counterparts and what do > >>> you mean by "missed kernel modules for build purpose"? > >>> > >> > >> FWIW, I did not see this in all of my freebsd-update(8) tests. > > > > So could it be that a subset of the mirrors carries a corrupt index > > of 12.0-RC3? Otherwise I don't see how only some freebsd-update(8) > > runs to 12.0-RC3 fail or how the problem should be specific to > > if_ixlv.ko so far. > > > > > No, mirrors are fine. Bug is repeatable on 4 different machines with > poudrire during jails -RC2 => -RC3 binary upgrade. > On a host installation upgrade is always fine ? /bot/kernel/* is always > present on live systems. > > Upgrade error caused by absent kernel and modules in poudriere jail > installations. The error appears to occur in install_from_index(). Looking at how that function is called, the only explanation I have still is that the index is wrong. That might very well be the index generated by freebsd-update(8) rather than the one obtained from a server, but how freebsd-update(8) gets to the index it eventually feeds to that function including how filtering the index based on components works (or rather how that shouldn't work for links) is beyond me. In any case, I still don't see how this problem should be specific to the if_ixlv.ko link. What happens if you upgrade a 11.2 poudriere jail to 12.0-RC2, does that succeed or trip over if_igb.ko instead? Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181215164202.GF93591>