4

I have Xubuntu 18.04 in a chroot environment. I just dropped it in there from a VM I had of it.

Going into the chroot environment, if I try to run apt update I get this error:

/usr/bin/apt-key: 624: /usr/bin/apt-key: cannot create /dev/null: Permission denied

I have tried most of the solutions here: https://unix.stackexchange.com/questions/146633/bash-dev-null-permission-denied As well as this solution: https://superuser.com/a/814594 Neither worked. Same exact output.

Is there some way I can get this working? Thanks in advance.

6 Answers 6

5

I encountered this issue today.

I could resolve it by binding the host machine's /dev/ to chroot environment's /dev/.

# Run in host machine as root(sudo)
mount --bind /dev /path/to/chroot/environment/dev

Also in my case, I needed to bind 3 more file systems.

# Run in host machine as root(sudo)
mount --bind /dev/pts /path/to/chroot/environment/dev/pts
mount --bind /proc /path/to/chroot/environment/proc
mount --bind /sys /path/to/chroot/environment/sys

And then chroot into the environment:

chroot /path/to/chroot/environment
2
  • Is there a reason you would mount --bind /dev and mount --bind /dev/pts? Seems to me mounting /dev would also mount /dev/pts correct?
    – erwin
    Commented May 24, 2023 at 2:57
  • @erwin I guess not. I don't have a deep knowledge about it, but it happened to not behave in this way. I needed to explicitly mount /dev/pts/ as this directory didn't exist (or it existed but was empty) after mounting only /dev/
    – MaGaroo
    Commented May 25, 2023 at 4:00
4

From man null:

   These devices are typically created by:

          mknod -m 666 /dev/null c 1 3
          mknod -m 666 /dev/zero c 1 5
          chown root:root /dev/null /dev/zero

These commands would have to be executed in the chroot environment.

2
  • 2
    I tried this and It didn't help. Same exact error.
    – Batcastle
    Commented Jan 22, 2019 at 5:05
  • This definitely helps if you're trying to chroot into a disk you've mounted from another system. Ubuntu's default mount options for removable media are definitely unhelpful in this case (though a good idea in other cases).
    – Tom
    Commented Apr 8 at 13:44
4

I know this is old and you already found your answer, but another possibility (which I just faced) is that the drive was mounted with the nodev option, disabling any character devices such as /dev/null, even though they show up with the proper permission. Just issuing a mount -o remount,rw /dev/hdaN /mnt from outside the chroot fixed it.

3

Figured out the issue. It wasn't readable/writable by all users. Changed it so all users could read and write and it worked. Thanks anyways!

0

Instead of adding GPG keys for an apt repository inside a chroot with apt-key, you can also place them directly into the /etc/apt/trusted.gpg.d directory with a file extension of either .asc or .gpg according to this Debian bug I stumbled across.

In my case, I was trying to add an apt repository inside a chroot environment while building a base image for my containers.

For example:

wget -q "SOME_URL_HERE" -O- | run_in_chroot sh -c 'cat >/etc/apt/trusted.gpg.d/mykey.asc';

...where run_in_chroot runs a command inside a chroot:

run_in_chroot() {
    chroot "path/to/directory/to/chroot/into" "$@";
}
0

Basically you need to mount a few things like MaGaroo mentioned but be sure to use the right permissions.

This list came from arch-chroot in arch install scripts but is generally applicable to most Linux distributions.

sudo mount -t proc -o nosuid,noexec,nodev /proc /mnt/chroot/proc
sudo mount -t sysfs -o nosuid,noexec,nodev,ro /sys /mnt/chroot/sys
sudo mount -t efivarfs -o nosuid,noexec,nodev /sys/firmware/efi/efivars /mnt/chroot/sys/firmware/efi/efivars
sudo mount -t devtmpfs -o mode=0755,nosuid /dev /mnt/chroot/dev
sudo mount -t devpts -o mode=0620,gid=5,nosuid,noexec /dev/pts /mnt/chroot/dev/pts
sudo mount -t tmpfs -o mode=1777,nosuid,nodev /dev/shm /mnt/chroot/dev/shm
sudo mount --bind /run /mnt/chroot/run
sudo mount -t tmpfs -o mode=1777,strictatime,nodev,nosuid /tmp /mnt/chroot/tmp

or use an /etc/fstab file. Please note that with the noauto option, they won't get mounted automatically, since mounting some of these early on in the booting process might cause problems.

/proc                      /mnt/chroot/proc                      proc      noauto,nosuid,noexec,nodev                 0  0
/sys                       /mnt/chroot/sys                       sysfs     noauto,nosuid,noexec,nodev,ro              0  0
/sys/fimware/efi/efivarfs  /mnt/chroot/sys/firmware/efi/efivars  efivarfs  noauto,nosuid,noexec,nodev                 0  0
/dev                       /mnt/chroot/dev                       devtmpfs  noauto,mode=0755,nosuid                    0  0
/dev/pts                   /mnt/chroot/dev/pts                   devpts    noauto,mode=0620,gid=5,nosuid,noexec       0  0
/dev/shm                   /mnt/chroot/dev/shm                   tmpfs     noauto,mode=1777,nosuid,nodev              0  0
/run                       /mnt/chroot/run                       none      noauto,bind                                0  0
/tmp                       /mnt/chroot/tmp                       tmpfs     noauto,mode=1777,strictatime,nodev,nosuid  0  0

After adding this fstab, you can just mount them with

sudo mount /mnt/chroot/proc
sudo mount /mnt/chroot/sys
sudo mount /mnt/chroot/sys/firmware/efi/efivars
sudo mount /mnt/chroot/dev
sudo mount /mnt/chroot/dev/pts
sudo mount /mnt/chroot/dev/shm
sudo mount /mnt/chroot/run
sudo mount /mnt/chroot/tmp

Note that efivars might not be there on some older computers so you can remove that if it's not there.

You might also want to mount /etc/resolv.conf for some networking stuff.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .