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