Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jun 2019 14:32:24 -0500
From:      Karl Denninger <karl@denninger.net>
To:        mike tancsa <mike@sentex.net>, freebsd-embedded@freebsd.org
Subject:   Re: NanoBSD cust_pkgng problem....
Message-ID:  <9e6fdc85-801b-1a4b-ce20-d1ab6a40c28c@denninger.net>
In-Reply-To: <efaf35f3-adbe-1d6d-a17d-7ad80eec2902@sentex.net>
References:  <27515540-54ef-6e7e-1b87-9be875b54c22@denninger.net> <efaf35f3-adbe-1d6d-a17d-7ad80eec2902@sentex.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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@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.

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9e6fdc85-801b-1a4b-ce20-d1ab6a40c28c>