NanoBSD cust_pkgng problem....

Warner Losh imp at bsdimp.com
Thu Jun 20 19:35:45 UTC 2019


On Thu, Jun 20, 2019, 12:32 PM Karl Denninger <karl at denninger.net> wrote:

> On 6/20/2019 13:44, mike tancsa wrote:
> > On 6/20/2019 2:16 PM, Karl Denninger wrote:
> >> I'm trying to rebuild 12-STABLE with current code with the following for
> >> the PCEngines systems.
> >>
> >>
> >> Failed to install the following 1 package(s):
> >> /_.p/isc-dhcp44-server-4.4.1_4.txz
> >
> > Thats so strange. I saw that too.  I did change defaults.sh
> >
> >
> >  # Early customize commands.
> >  NANO_EARLY_CUSTOMIZE=""
> > @@ -776,6 +776,7 @@
> >         fi
> >
> >         # Mount packages into chroot
> > +       mount -t devfs devfs ${NANO_WORLDDIR}/dev
> >         mkdir -p ${NANO_WORLDDIR}/_.p
> >         mount -t nullfs -o noatime -o ro ${NANO_PACKAGE_DIR}
> > ${NANO_WORLDDIR}/_.p
> >
> > @@ -802,7 +803,7 @@
> >         )
> >
> >         CR0 "${PKGCMD} info"
> > -
> > +       umount ${NANO_WORLDDIR}/dev
> >         trap - 1 2 15 EXIT
> >         umount ${NANO_WORLDDIR}/_.p
> >         rm -rf ${NANO_WORLDDIR}/_.p
> >
> >
> > to get rid of the dev/null complaints.  I thought the pkg might be
> > borked somehow in the poudriere build, so I rebuilt it and then it all
> > worked. But I am not sure if that was just a fluke.  I havent seen the
> > issue since... But it was the same isc package that my build was borking
> > on as well.
> >
> >     ---Mike
>
> I'm not building via poudriere; the packages are being grabbed from the
> base 12-STABLE repo.
>
> repo.conf in the package directory contains:
>
> FreeBSD: {
>   url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
>   mirror_type: "srv",
>   signature_type: "fingerprints",
>   fingerprints: "/usr/share/keys/pkg",
>   enabled: yes
> }
>
> Adding "-d" to the pkg commands executed in the hope of getting an error
> return that will actually mean something doesn't tell me anything useful...
>
> Installing indexinfo-0.3.1...
> the most recent version of indexinfo-0.3.1 is already installed
> DBG(1)[95581]> release an exclusive lock on a database
> + CR 'env BATCH=YES ASSUME_ALWAYS_YES=YES PKG_DBDIR=/var/db/pkg
> SIGNATURE_TYPE=n
> one /usr/sbin/pkg -d add /_.p/isc-dhcp44-server-4.4.1_4.txz'
> + chroot /work/Crochet-work-AMD/obj/_.w /bin/sh -exc 'env BATCH=YES
> ASSUME_ALWAY
> S_YES=YES PKG_DBDIR=/var/db/pkg SIGNATURE_TYPE=none /usr/sbin/pkg -d add
> /_.p/is
> c-dhcp44-server-4.4.1_4.txz'
> + env 'BATCH=YES' 'ASSUME_ALWAYS_YES=YES' 'PKG_DBDIR=/var/db/pkg'
> 'SIGNATURE_TYP
> E=none' /usr/sbin/pkg -d add /_.p/isc-dhcp44-server-4.4.1_4.txz
> DBG(1)[95582]> pkg initialized
> DBG(1)[95582]> want to get an exclusive lock on a database
> Installing isc-dhcp44-server-4.4.1_4...
> pkg: Cannot open /dev/null:No such file or directory
> DBG(1)[95582]> release an exclusive lock on a database
>
> Failed to install the following 1 package(s):
> /_.p/isc-dhcp44-server-4.4.1_4.txz
> + umount /work/Crochet-work-AMD/obj/_.w/_.p
> + rm -rf /work/Crochet-work-AMD/obj/_.w/_.p
> + echo 'NANO RM -rf /work/Crochet-work-AMD/obj/_.w/_.p'
> NANO RM -rf /work/Crochet-work-AMD/obj/_.w/_.p
> + uname -r
> + command rm -x -rf /work/Crochet-work-AMD/obj/_.w/_.p
>
> Using "CR0" instead of "CR" in the defaults.sh script ignores the error
> return and continues but when I look in the resulting build the binaries
> *are not* there, so the package in fact did not install (that is,
> whatever it is that's going on, it prevents anything from actually being
> unpacked and stored.)
>
> The "-d" switch tells me nothing and a "tar tvf" on the two targets
> shows what appears to be a valid package; the target in question doesn't
> appear on a facial basis to be corrupt.
>
> root at NewFS:/work/PKG-AMD64-12 # ls -al pkg/ssm*
> -rw-r--r--  1 root  wheel  20412 Jun 20 13:08 pkg/ssmtp-2.64_3.txz
> root at NewFS:/work/PKG-AMD64-12 # tar tvf pkg/ssmtp*
> -rw-r--r--  0 root   wheel    1612 Dec 31  1969 +COMPACT_MANIFEST
> -rw-r--r--  0 root   wheel    3206 Dec 31  1969 +MANIFEST
> -rw-r--r--  0 root   wheel     218 May 17 10:11
> /usr/local/share/licenses/ssmtp-2.64_3/catalog.mk
> -rw-r--r--  0 root   wheel      93 May 17 10:11
> /usr/local/share/licenses/ssmtp-2.64_3/LICENSE
> -rw-r--r--  0 root   wheel     758 May 17 10:11
> /usr/local/share/licenses/ssmtp-2.64_3/GPLv2+
> -r-xr-sr-x  0 root   ssmtp   44008 May 17 10:11 /usr/local/sbin/ssmtp
> -rw-r-----  0 root   ssmtp     200 May 17 10:11
> /usr/local/etc/ssmtp/revaliases.sample
> -rw-r-----  0 root   ssmtp    1286 May 17 10:11
> /usr/local/etc/ssmtp/ssmtp.conf.sample
> -r--r--r--  0 root   wheel    1097 May 17 10:11
> /usr/local/man/man5/ssmtp.conf.5.gz
> -r--r--r--  0 root   wheel    2714 May 17 10:11
> /usr/local/man/man8/ssmtp.8.gz
> drwxr-x---  0 root   ssmtp       0 May 17 10:11 /usr/local/etc/ssmtp/
> root at NewFS:/work/PKG-AMD64-12 #
>
> This worked perfectly well a few months ago when I last built this
> specific release, and it's only these two packages (the ISC dhcp server
> and ssmpt) that blow it up.  Everything else -- including all the
> dependencies -- install fine -- its just these two *specific* packages
> that, if either is included, blows up the build.
>
> I suppose I could set up another poudiere jail and build the required
> packages from source if I absolutely must include pkg itself (I have to
> for ARM32 targets since that's not a supported architecture with the
> package system), but.... that shouldn't be in play here as we *are*
> talking about AMD64, which is allegedly fully supported and further,
> ought to be current and working for everyone who uses pkg rather than
> ports......
>
> Update: If I use -
>
> root at NewFS:/work/PKG-AMD64-12 # more repo.conf
> FreeBSD: {
>   url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly"
> #  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
>   mirror_type: "srv",
>   signature_type: "fingerprints",
>   fingerprints: "/usr/share/keys/pkg",
>   enabled: yes
> }
>
> It works.
>
> This implies that "latest" is borked, although exactly why I don't
> know.  The "pkg" package itself in quarterly, however, is different --
> 1.10.5_5 for the quarterlies .vs. 1.11.1.  Given that the other packages
> appear to be valid it looks like the pkg command *itself* in "latest" is
> causing the problem.
>

Pkg now needs /dev/null. So the right fix is to fix nanobsd as outlined
earlier in this thread.

Warner

-- 
> Karl Denninger
> karl at denninger.net <mailto:karl at denninger.net>
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
> _______________________________________________
> freebsd-embedded at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-embedded
> To unsubscribe, send any mail to "freebsd-embedded-unsubscribe at freebsd.org
> "
>


More information about the freebsd-embedded mailing list