pkg: Cannot open /dev/null:No such file or directory

Discussion:

(too old to reply)

O. Hartmann

2019-06-04 05:32:16 UTC

Hello List,

lately I ran into a serious problem installing packages in a nanoBSD
environment, in which the package repository server is "remotely" on site. The
issue as documented below occurs on both 12-STABLE r348529 and CURRENT r348600
and must have been introduced shortly, since the last known good installation
with the environment of ours was on 21st May 2019.

As far as I know,, the package installation is performed via "chroot'ed"
environment and somehow /dev/null is out of a sudden not accessible anymore
while pkg tries to delegate some output to /dev/null.

What happened here?

Kind regards and thanks in advance,

oh

[...]
All repositories are up to date.
The following 10 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
python3: 3_3 [zeit4]
sudo: 1.8.27_1 [zeit4]
devcpu-data: 1.22 [zeit4]
python36: 3.6.8_2 [zeit4]
readline: 8.0.0 [zeit4]
indexinfo: 0.3.1 [zeit4]
libffi: 3.2.1_3 [zeit4]
gettext-runtime: 0.19.8.1_2 [zeit4]
openldap-sasl-client: 2.4.47 [zeit4]
cyrus-sasl: 2.1.27 [zeit4]

Number of packages to be installed: 10

The process will require 129 MiB more space.
20 MiB to be downloaded.
[1/10] Fetching python3-3_3.txz: . done
[2/10] Fetching sudo-1.8.27_1.txz: .......... done
[3/10] Fetching devcpu-data-1.22.txz: .......... done
[4/10] Fetching python36-3.6.8_2.txz: .......... done
[5/10] Fetching readline-8.0.0.txz: .......... done
[6/10] Fetching indexinfo-0.3.1.txz: . done
[7/10] Fetching libffi-3.2.1_3.txz: ..... done
[8/10] Fetching gettext-runtime-0.19.8.1_2.txz: .......... done
[9/10] Fetching openldap-sasl-client-2.4.47.txz: .......... done
[10/10] Fetching cyrus-sasl-2.1.27.txz: .......... done
Checking integrity... done (0 conflicting)
[1/10] Installing indexinfo-0.3.1...
[1/10] Extracting indexinfo-0.3.1: .... done
[2/10] Installing readline-8.0.0...
[2/10] Extracting readline-8.0.0: .......... done
pkg: Cannot open /dev/null:No such file or directory
[3/10] Installing libffi-3.2.1_3...
[3/10] Extracting libffi-3.2.1_3: .......... done
pkg: Cannot open /dev/null:No such file or directory
[4/10] Installing gettext-runtime-0.19.8.1_2...
[4/10] Extracting gettext-runtime-0.19.8.1_2: .......... done
pkg: Cannot open /dev/null:No such file or directory
[5/10] Installing cyrus-sasl-2.1.27...
pkg: Cannot open /dev/null:No such file or directory
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Baptiste Daroussin

2019-06-04 05:44:09 UTC

Permalink

Post by O. Hartmann
Hello List,
lately I ran into a serious problem installing packages in a nanoBSD
environment, in which the package repository server is "remotely" on site. The
issue as documented below occurs on both 12-STABLE r348529 and CURRENT r348600
and must have been introduced shortly, since the last known good installation
with the environment of ours was on 21st May 2019.
As far as I know,, the package installation is performed via "chroot'ed"
environment and somehow /dev/null is out of a sudden not accessible anymore
while pkg tries to delegate some output to /dev/null.
What happened here?
Kind regards and thanks in advance,
oh
[...]
All repositories are up to date.
python3: 3_3 [zeit4]
sudo: 1.8.27_1 [zeit4]
devcpu-data: 1.22 [zeit4]
python36: 3.6.8_2 [zeit4]
readline: 8.0.0 [zeit4]
indexinfo: 0.3.1 [zeit4]
libffi: 3.2.1_3 [zeit4]
gettext-runtime: 0.19.8.1_2 [zeit4]
openldap-sasl-client: 2.4.47 [zeit4]
cyrus-sasl: 2.1.27 [zeit4]
Number of packages to be installed: 10

What is new is that pkg is using /dev/null as input when running script? this is
new since pkg 1.11 . Somehow this does not seems to be avaalaible in your
environement.

Best regards,
Bapt

O. Hartmann

2019-06-04 08:23:27 UTC

Permalink

On Tue, 4 Jun 2019 07:44:09 +0200

Post by Baptiste Daroussin

Post by O. Hartmann
Hello List,
lately I ran into a serious problem installing packages in a nanoBSD
environment, in which the package repository server is "remotely" on site.
The issue as documented below occurs on both 12-STABLE r348529 and CURRENT
r348600 and must have been introduced shortly, since the last known good
installation with the environment of ours was on 21st May 2019.
As far as I know,, the package installation is performed via "chroot'ed"
environment and somehow /dev/null is out of a sudden not accessible anymore
while pkg tries to delegate some output to /dev/null.
What happened here?
Kind regards and thanks in advance,
oh
[...]
All repositories are up to date.
python3: 3_3 [zeit4]
sudo: 1.8.27_1 [zeit4]
devcpu-data: 1.22 [zeit4]
python36: 3.6.8_2 [zeit4]
readline: 8.0.0 [zeit4]
indexinfo: 0.3.1 [zeit4]
libffi: 3.2.1_3 [zeit4]
gettext-runtime: 0.19.8.1_2 [zeit4]
openldap-sasl-client: 2.4.47 [zeit4]
cyrus-sasl: 2.1.27 [zeit4]
Number of packages to be installed: 10

What is new is that pkg is using /dev/null as input when running script? this
is new since pkg 1.11 . Somehow this does not seems to be avaalaible in your
environement.
Best regards,
Bapt

Hello,

thanks for the hint!

Packages are installed via the pkg -c ${WORLD_ROOT_DIR} option, chroot'ed, as
far as I can see and therefore, there is no /dev/null device.

Mathew's hint solved the problem.

Greetings,

oh
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Johannes Lundberg

2019-06-04 17:02:36 UTC

Permalink

Post by Baptiste Daroussin

What is new is that pkg is using /dev/null as input when running script? this is
new since pkg 1.11 . Somehow this does not seems to be avaalaible in your
environement.

Hi

Same things applies to poudriere-image. I had to add a mount devfs
command to the image.sh script.

Post by Baptiste Daroussin
Best regards,
Bapt

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

j***@hilltopgroup.com

2019-06-11 15:52:43 UTC

Permalink

I'm having the same issue with poudriere image; could you please let me
know what you did to fix it? I'm assuming the image.sh you're referring
to is /usr/local/share/poudriere/image.sh, but I'm not sure where the
change would need to be made.

Thanks in advance,
Joseph

Post by Johannes Lundberg

Post by Baptiste Daroussin

Post by O. Hartmann
Hello List,
lately I ran into a serious problem installing packages in a nanoBSD
environment, in which the package repository server is "remotely" on site. The
issue as documented below occurs on both 12-STABLE r348529 and CURRENT r348600
and must have been introduced shortly, since the last known good installation
with the environment of ours was on 21st May 2019.
As far as I know,, the package installation is performed via
"chroot'ed"
environment and somehow /dev/null is out of a sudden not accessible anymore
while pkg tries to delegate some output to /dev/null.
What happened here?
Kind regards and thanks in advance,
oh
[...]
All repositories are up to date.
python3: 3_3 [zeit4]
sudo: 1.8.27_1 [zeit4]
devcpu-data: 1.22 [zeit4]
python36: 3.6.8_2 [zeit4]
readline: 8.0.0 [zeit4]
indexinfo: 0.3.1 [zeit4]
libffi: 3.2.1_3 [zeit4]
gettext-runtime: 0.19.8.1_2 [zeit4]
openldap-sasl-client: 2.4.47 [zeit4]
cyrus-sasl: 2.1.27 [zeit4]
Number of packages to be installed: 10

What is new is that pkg is using /dev/null as input when running script? this is
new since pkg 1.11 . Somehow this does not seems to be avaalaible in your
environement.

Hi
Same things applies to poudriere-image. I had to add a mount devfs
command to the image.sh script.

Post by Baptiste Daroussin
Best regards,
Bapt

_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to

Johannes Lundberg

2019-06-11 18:52:31 UTC

Permalink

This post might be inappropriate. Click to display it.

Joseph Ward

2019-06-12 00:22:40 UTC

Permalink

Thank you! I only added the mount line, but it seemed to work.

Post by Johannes Lundberg
Hi
This is probably overkill but I've attached a diff that show my patches
to image.sh. It's just a hack so far to make it do what I want and not
meant as general purpose. Use the changes you need for your application.
Changes (only meant to work for building usb images on amd64 and i386)
- mount devfs so pkg will work properly
- add "install packages from official repo" option so you won't have to
build your own packages for each jail
- downloaded packages from official repo is cached locally to avoid
excessive downloads
- hack for i386 so packages are installed properly
- increase swap space to allow for kernel core dumps (for usb image)
- execute post-install script "overlay.sh" in the jail if provided in
the overlay folder
Bapt: Maybe you'll find some of these changes useful? :)
/Johannes

Post by j***@hilltopgroup.com
I'm having the same issue with poudriere image; could you please let
me know what you did to fix it? I'm assuming the image.sh you're
referring to is /usr/local/share/poudriere/image.sh, but I'm not sure
where the change would need to be made.
Thanks in advance,
Joseph

Post by Johannes Lundberg

Post by Baptiste Daroussin

Post by O. Hartmann
Hello List,
lately I ran into a serious problem installing packages in a nanoBSD
environment, in which the package repository server is "remotely" on site. The
issue as documented below occurs on both 12-STABLE r348529 and CURRENT r348600
and must have been introduced shortly, since the last known good installation
with the environment of ours was on 21st May 2019.
As far as I know,, the package installation is performed via "chroot'ed"
environment and somehow /dev/null is out of a sudden not accessible anymore
while pkg tries to delegate some output to /dev/null.
What happened here?
Kind regards and thanks in advance,
oh
[...]
All repositories are up to date.
        python3: 3_3 [zeit4]
        sudo: 1.8.27_1 [zeit4]
        devcpu-data: 1.22 [zeit4]
        python36: 3.6.8_2 [zeit4]
        readline: 8.0.0 [zeit4]
        indexinfo: 0.3.1 [zeit4]
        libffi: 3.2.1_3 [zeit4]
        gettext-runtime: 0.19.8.1_2 [zeit4]
        openldap-sasl-client: 2.4.47 [zeit4]
        cyrus-sasl: 2.1.27 [zeit4]
Number of packages to be installed: 10

What is new is that pkg is using /dev/null as input when running script? this is
new since pkg 1.11 . Somehow this does not seems to be avaalaible in your
environement.

Hi
Same things applies to poudriere-image. I had to add a mount devfs
command to the image.sh script.

Post by Baptiste Daroussin
Best regards,
Bapt

_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to

Baptiste Daroussin

2019-06-12 06:21:45 UTC

Permalink

The first I already committed days ago in poudriere, just I should have added it
as a patch to the poudriere version in ports, I will do it asap.

As for other improvements, sure they sounds like useful, would be happy to
review them if you make pull requests out of them!

Thanks a lot,
Bapt

Matthew Seaman

2019-06-04 05:59:19 UTC

Permalink

Post by O. Hartmann
As far as I know,, the package installation is performed via "chroot'ed"
environment and somehow /dev/null is out of a sudden not accessible anymore
while pkg tries to delegate some output to /dev/null.

Assuming you're chroot'd to /chroot, then:

mount -t devfs devfs /chroot/dev

should allow pkg(8) to work as usual.

Cheers,

Matthew

Rodney W. Grimes

2019-06-04 15:54:03 UTC

Permalink

Post by Matthew Seaman

mount -t devfs devfs /chroot/dev

Perhaps it is time to update the documentation in chroot(8) to
at least provide a pointer to the fact you now need to do either
the above, or somehow populate a /chroot/dev directory?

Can you even still statically create device nodes and have that
work, or is that now totally imposible with the full conversion
to devfs?

Post by Matthew Seaman
should allow pkg(8) to work as usual.
Cheers,
Matthew

--
Rod Grimes ***@freebsd.org
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de