| 1 |
On Sunday, 22 April 2018 09:39:23 BST Peter Humphrey wrote: |
| 2 |
> On Sunday, 22 April 2018 07:20:28 BST Jonathan Callen wrote: |
| 3 |
> > Generally, this would indicate a problem resolving DNS. This is |
| 4 |
> > normally caused by not having a correct /etc/resolv.conf inside the |
| 5 |
> > chroot (it generally will need to be the same as the file outside the |
| 6 |
> > chroot). |
| 7 |
> |
| 8 |
> Yes, I'd already thought of that and found it to be right; it's why I tried |
| 9 |
> www-client/links inside the chroot, which works just fine. |
| 10 |
|
| 11 |
I forgot to add a couple of things: |
| 12 |
|
| 13 |
1. The chroot host (this box) is a multilib system, but the chroot client |
| 14 |
(the celeron box) is no-multilib. Could that make a difference? |
| 15 |
|
| 16 |
2. While the fetching is hung, /bin/ps shows two emerge processes: one with |
| 17 |
status S and the other with D. Am I right in thinking that portage spawns |
| 18 |
another process to do the fetching, and waits for it to finish? I hope it's so |
| 19 |
anyway. |
| 20 |
|
| 21 |
That first thought was prompted by the instruction to "mount -o bind /lib/ |
| 22 |
modules /foo/lib/modules" in this page: |
| 23 |
|
| 24 |
https://wiki.gentoo.org/wiki/Project:X86/Chroot_Guide |
| 25 |
|
| 26 |
-- |
| 27 |
Regards, |
| 28 |
Peter. |
Archives