Skip to main content
edited body
Source Link

I hit the same issue as you. It seems a fairly rare use case, as this is pretty much the only result that comes up for it on Google.

I did eventually find the issue though, and it is to do with mounting /proc into the chroot (from within the Docker container)

In your example, prior to entering/using the rootfs you should mount Docker's /proc into the chroot:

mount -t proc /proc <armbian-rootfs-dir>/proc 

You will then get native speeds for cryptography within your chroot

Edit: This appears to have worked fine on an old Ubuntu 16.04 image chroot, but fails to fix the issue when using debootstrap.

Looking at the contents of the chroot created by debootstrap, the proc folder appears to be a symlink to /proc. My understanding is this should not work, and indeed, running ls /proc from within the chroot results in cannot access 'proc': Too many levels of symbolic links

To get around this (and I'm sure someone will tell me why this is a bad idea), from outside the chroot run:

rm <armbian-rootfs-dir>/proc mkdir -p <armbian-rootfs-dir>/proc mount -t proc /proc <armbian-rootfs-dir>/proc 

This removes the symlink and bind mounts the chroot's /proc to Docker's /proc

It is also worth noting that debootstrap --second-stage appears to unmount \proc/proc again, so you will need to remount it (from outside the chroot) when that phase has completed (ref: Accessing /proc from foreign chroot)

Note: Don't forget to umount <armbian-rootfs-dir>/proc when you have finished with the chroot and wish to image the folder.

I hit the same issue as you. It seems a fairly rare use case, as this is pretty much the only result that comes up for it on Google.

I did eventually find the issue though, and it is to do with mounting /proc into the chroot (from within the Docker container)

In your example, prior to entering/using the rootfs you should mount Docker's /proc into the chroot:

mount -t proc /proc <armbian-rootfs-dir>/proc 

You will then get native speeds for cryptography within your chroot

Edit: This appears to have worked fine on an old Ubuntu 16.04 image chroot, but fails to fix the issue when using debootstrap.

Looking at the contents of the chroot created by debootstrap, the proc folder appears to be a symlink to /proc. My understanding is this should not work, and indeed, running ls /proc from within the chroot results in cannot access 'proc': Too many levels of symbolic links

To get around this (and I'm sure someone will tell me why this is a bad idea), from outside the chroot run:

rm <armbian-rootfs-dir>/proc mkdir -p <armbian-rootfs-dir>/proc mount -t proc /proc <armbian-rootfs-dir>/proc 

This removes the symlink and bind mounts the chroot's /proc to Docker's /proc

It is also worth noting that debootstrap --second-stage appears to unmount \proc again, so you will need to remount it (from outside the chroot) when that phase has completed (ref: Accessing /proc from foreign chroot)

Note: Don't forget to umount <armbian-rootfs-dir>/proc when you have finished with the chroot and wish to image the folder.

I hit the same issue as you. It seems a fairly rare use case, as this is pretty much the only result that comes up for it on Google.

I did eventually find the issue though, and it is to do with mounting /proc into the chroot (from within the Docker container)

In your example, prior to entering/using the rootfs you should mount Docker's /proc into the chroot:

mount -t proc /proc <armbian-rootfs-dir>/proc 

You will then get native speeds for cryptography within your chroot

Edit: This appears to have worked fine on an old Ubuntu 16.04 image chroot, but fails to fix the issue when using debootstrap.

Looking at the contents of the chroot created by debootstrap, the proc folder appears to be a symlink to /proc. My understanding is this should not work, and indeed, running ls /proc from within the chroot results in cannot access 'proc': Too many levels of symbolic links

To get around this (and I'm sure someone will tell me why this is a bad idea), from outside the chroot run:

rm <armbian-rootfs-dir>/proc mkdir -p <armbian-rootfs-dir>/proc mount -t proc /proc <armbian-rootfs-dir>/proc 

This removes the symlink and bind mounts the chroot's /proc to Docker's /proc

It is also worth noting that debootstrap --second-stage appears to unmount /proc again, so you will need to remount it (from outside the chroot) when that phase has completed (ref: Accessing /proc from foreign chroot)

Note: Don't forget to umount <armbian-rootfs-dir>/proc when you have finished with the chroot and wish to image the folder.

added 272 characters in body
Source Link

I hit the same issue as you. It seems a fairly rare use case, as this is pretty much the only result that comes up for it on Google.

I did eventually find the issue though, and it is to do with mounting /proc into the chroot (from within the Docker container)

In your example, prior to entering/using the rootfs you should mount Docker's /proc into the chroot:

mount -t proc /proc <armbian-rootfs-dir>/proc 

You will then get native speeds for cryptography within your chroot

Edit: This appears to have worked fine on an old Ubuntu 16.04 image chroot, but fails to fix the issue when using debootstrap.

Looking at the contents of the chroot created by debootstrap, the proc folder appears to be a symlink to /proc. My understanding is this should not work, and indeed, running ls /proc from within the chroot results in cannot access 'proc': Too many levels of symbolic links

To get around this (and I'm sure someone will tell me why this is a bad idea), from outside the chroot run:

rm <armbian-rootfs-dir>/proc mkdir -p <armbian-rootfs-dir>/proc mount -t proc /proc <armbian-rootfs-dir>/proc 

This removes the symlink and bind mounts the chroot's /proc to Docker's /proc

It is also worth noting that debootstrap --second-stage appears to unmount \proc again, so you will need to remount it (from outside the chroot) when that phase has completed (ref: Accessing /proc from foreign chroot)

Note: Don't forget to umount <armbian-rootfs-dir>/proc when you have finished with the chroot and wish to image the folder.

I hit the same issue as you. It seems a fairly rare use case, as this is pretty much the only result that comes up for it on Google.

I did eventually find the issue though, and it is to do with mounting /proc into the chroot (from within the Docker container)

In your example, prior to entering/using the rootfs you should mount Docker's /proc into the chroot:

mount -t proc /proc <armbian-rootfs-dir>/proc 

You will then get native speeds for cryptography within your chroot

Edit: This appears to have worked fine on an old Ubuntu 16.04 image chroot, but fails to fix the issue when using debootstrap.

Looking at the contents of the chroot created by debootstrap, the proc folder appears to be a symlink to /proc. My understanding is this should not work, and indeed, running ls /proc from within the chroot results in cannot access 'proc': Too many levels of symbolic links

To get around this (and I'm sure someone will tell me why this is a bad idea), from outside the chroot run:

rm <armbian-rootfs-dir>/proc mkdir -p <armbian-rootfs-dir>/proc mount -t proc /proc <armbian-rootfs-dir>/proc 

This removes the symlink and bind mounts the chroot's /proc to Docker's /proc

Note: Don't forget to umount <armbian-rootfs-dir>/proc when you have finished with the chroot and wish to image the folder.

I hit the same issue as you. It seems a fairly rare use case, as this is pretty much the only result that comes up for it on Google.

I did eventually find the issue though, and it is to do with mounting /proc into the chroot (from within the Docker container)

In your example, prior to entering/using the rootfs you should mount Docker's /proc into the chroot:

mount -t proc /proc <armbian-rootfs-dir>/proc 

You will then get native speeds for cryptography within your chroot

Edit: This appears to have worked fine on an old Ubuntu 16.04 image chroot, but fails to fix the issue when using debootstrap.

Looking at the contents of the chroot created by debootstrap, the proc folder appears to be a symlink to /proc. My understanding is this should not work, and indeed, running ls /proc from within the chroot results in cannot access 'proc': Too many levels of symbolic links

To get around this (and I'm sure someone will tell me why this is a bad idea), from outside the chroot run:

rm <armbian-rootfs-dir>/proc mkdir -p <armbian-rootfs-dir>/proc mount -t proc /proc <armbian-rootfs-dir>/proc 

This removes the symlink and bind mounts the chroot's /proc to Docker's /proc

It is also worth noting that debootstrap --second-stage appears to unmount \proc again, so you will need to remount it (from outside the chroot) when that phase has completed (ref: Accessing /proc from foreign chroot)

Note: Don't forget to umount <armbian-rootfs-dir>/proc when you have finished with the chroot and wish to image the folder.

edited body
Source Link

I hit the same issue as you. It seems a fairly rare use case, as this is pretty much the only result that comes up for it on Google.

I did eventually find the issue though, and it is to do with mounting /proc into the chroot (from within the Docker container)

In your example, prior to entering/using the rootfs you should mount Docker's /proc into the chroot:

mount -t proc /proc <armbian-rootfs-dir>/proc 

You will then get native speeds for cryptography within your chroot

Edit: This appears to have worked fine on an old Ubuntu 16.04 image chroot, but fails to fix the issue when using debootstrap.

Looking at the contents of the chroot created by debootstrap, the proc folder appears to be a symlink to /proc. My understanding is this should not work, and indeed, running ls /proc from within the chroot results in cannot access 'proc': Too many levels of symbolic links

To get around this (and I'm sure someone will tell me why this is a bad idea), from outside the chroot run:

rm <armbian-rootfs-dir>/proc mkdir -p <armbian-rootfs-dir>/proc mount -t proc /proc <armbian-rootfs-dir>/proc 

This removes the symlink and bind mounts the chroot's /proc to Docker's /proc

Note: Don't forget to umount umount <armbian-rootfs-dir>/proc when you have finished with the chroot and wish to image the folder.

I hit the same issue as you. It seems a fairly rare use case, as this is pretty much the only result that comes up for it on Google.

I did eventually find the issue though, and it is to do with mounting /proc into the chroot (from within the Docker container)

In your example, prior to entering/using the rootfs you should mount Docker's /proc into the chroot:

mount -t proc /proc <armbian-rootfs-dir>/proc 

You will then get native speeds for cryptography within your chroot

Edit: This appears to have worked fine on an old Ubuntu 16.04 image chroot, but fails to fix the issue when using debootstrap.

Looking at the contents of the chroot created by debootstrap, the proc folder appears to be a symlink to /proc. My understanding is this should not work, and indeed, running ls /proc from within the chroot results in cannot access 'proc': Too many levels of symbolic links

To get around this (and I'm sure someone will tell me why this is a bad idea), from outside the chroot run:

rm <armbian-rootfs-dir>/proc mkdir -p <armbian-rootfs-dir>/proc mount -t proc /proc <armbian-rootfs-dir>/proc 

This removes the symlink and bind mounts the chroot's /proc to Docker's /proc

Note: Don't forget to umount <armbian-rootfs-dir>/proc when you have finished with the chroot and wish to image the folder.

I hit the same issue as you. It seems a fairly rare use case, as this is pretty much the only result that comes up for it on Google.

I did eventually find the issue though, and it is to do with mounting /proc into the chroot (from within the Docker container)

In your example, prior to entering/using the rootfs you should mount Docker's /proc into the chroot:

mount -t proc /proc <armbian-rootfs-dir>/proc 

You will then get native speeds for cryptography within your chroot

Edit: This appears to have worked fine on an old Ubuntu 16.04 image chroot, but fails to fix the issue when using debootstrap.

Looking at the contents of the chroot created by debootstrap, the proc folder appears to be a symlink to /proc. My understanding is this should not work, and indeed, running ls /proc from within the chroot results in cannot access 'proc': Too many levels of symbolic links

To get around this (and I'm sure someone will tell me why this is a bad idea), from outside the chroot run:

rm <armbian-rootfs-dir>/proc mkdir -p <armbian-rootfs-dir>/proc mount -t proc /proc <armbian-rootfs-dir>/proc 

This removes the symlink and bind mounts the chroot's /proc to Docker's /proc

Note: Don't forget to umount <armbian-rootfs-dir>/proc when you have finished with the chroot and wish to image the folder.

added 133 characters in body
Source Link
Loading
added 36 characters in body
Source Link
Loading
added 1 character in body
Source Link
Loading
Post Undeleted by Torz77
added 582 characters in body
Source Link
Loading
added 124 characters in body
Source Link
Loading
Post Deleted by Torz77
Source Link
Loading