Re: [lfs-dev] Inaccuracy in chroot page
Am Samstag, den 14.03.2020, 18:11 +0100 schrieb Pierre Labastie via lfs-dev: > Le 14/03/2020 à 17:36, Bruce Dubbs via lfs-dev a écrit : > > On 3/14/20 10:55 AM, Pierre Labastie via lfs-dev wrote: > > > Le 14/03/2020 à 16:00, Bruce Dubbs via lfs-dev a écrit : > > > > On 3/14/20 3:41 AM, Pierre Labastie via lfs-dev wrote: > > > > > In "6.4 Entering the Chroot Environment", we have: > > > > > > > > > > From this point on, there is no need to use the LFS variable > > > > > anymore, > > > > > because > > > > > all work will be restricted to the LFS file system. This is because > > > > > the Bash > > > > > shell is told that $LFS is now the root (/) directory. > > > > > > > > > > But it is not true that the bash shell is told anything: the _kernel_ > > > > > is told > > > > > that $LFS is now the root (/) directory for all the processes > > > > > launched by the > > > > > first one (that is, here, "env", which itself launches "bash", which > > > > > will > > > > > launch all the others). I am not sure how to phrase this: something > > > > > like: > > > > > - > > > > > ... system. This is because the kernel is told that $LFS is now the > > > > > root (/) > > > > > directory for all the programs run from the current Bash shell. > > > > > - > > > > > But I'm sure native English writers can find something better (without > > > > > excluding non native of course :) > > > > > > > > I think I disagree with your premise. bash IS told where the root > > > > directory > > > > is, but there is some interaction with the kernel. > > > > > > > > When I enter chroot, env no longer exists. It does an 'exec' and > > > > replaces > > > > itself with bash. I took a look at /proc/ for that instance of > > > > bash and > > > > in that directory is the pseudo file 'mounts'. That tells me: > > > > > > > > /dev/sda6 / ext4 rw,noatime 0 0 > > > > > > > > which is my /mnt/lfs directory on the host. My interpretation is that > > > > this is > > > > a configuration for bash. When doing 'cd /', the kernel looks at this > > > > configuration for the bash instance and uses that to determine what disk > > > > partition (it could be a directory) to use for the head of an absolute > > > > path. > > > > > > > > In my opinion what we have now is correct. > > > > > > > > > > Thinking a little more about this, what I mean is the following: bash is > > > not > > > "told" anything, and does not "know" that "/" is $LFS: bash may ask the > > > kernel > > > to open(2) (or stat(2), or other basic calls) a file by passing the > > > filename > > > to the kernel, say, /a/file/name, and it is the kernel which resolves that > > > filename to $LFS/a/file/name, not bash itself. > > > > I'm OK with: > > > > This is because the Bash shell is set up so that $LFS is now the root (/) > > directory. > > > > That is: sed /told/set up so/ > > > > I just feel like I cannot explain. Bash is _unchanged_: it is the _kernel_, > which is set up so that $LFS is the new root for the process where bash (or > anything fork(2)ed from bash) is running. I agree, i think bash not even know that its running in chroot. > Anyway, nobody has complained for > years, let's not change anything. It does not prevent the build to work. also true > Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Inaccuracy in chroot page
Le 14/03/2020 à 17:36, Bruce Dubbs via lfs-dev a écrit : > On 3/14/20 10:55 AM, Pierre Labastie via lfs-dev wrote: >> Le 14/03/2020 à 16:00, Bruce Dubbs via lfs-dev a écrit : >>> On 3/14/20 3:41 AM, Pierre Labastie via lfs-dev wrote: In "6.4 Entering the Chroot Environment", we have: From this point on, there is no need to use the LFS variable anymore, because all work will be restricted to the LFS file system. This is because the Bash shell is told that $LFS is now the root (/) directory. But it is not true that the bash shell is told anything: the _kernel_ is told that $LFS is now the root (/) directory for all the processes launched by the first one (that is, here, "env", which itself launches "bash", which will launch all the others). I am not sure how to phrase this: something like: - ... system. This is because the kernel is told that $LFS is now the root (/) directory for all the programs run from the current Bash shell. - But I'm sure native English writers can find something better (without excluding non native of course :) >>> >>> I think I disagree with your premise. bash IS told where the root directory >>> is, but there is some interaction with the kernel. >>> >>> When I enter chroot, env no longer exists. It does an 'exec' and replaces >>> itself with bash. I took a look at /proc/ for that instance of bash and >>> in that directory is the pseudo file 'mounts'. That tells me: >>> >>> /dev/sda6 / ext4 rw,noatime 0 0 >>> >>> which is my /mnt/lfs directory on the host. My interpretation is that this >>> is >>> a configuration for bash. When doing 'cd /', the kernel looks at this >>> configuration for the bash instance and uses that to determine what disk >>> partition (it could be a directory) to use for the head of an absolute path. >>> >>> In my opinion what we have now is correct. >>> >> >> >> Thinking a little more about this, what I mean is the following: bash is not >> "told" anything, and does not "know" that "/" is $LFS: bash may ask the >> kernel >> to open(2) (or stat(2), or other basic calls) a file by passing the filename >> to the kernel, say, /a/file/name, and it is the kernel which resolves that >> filename to $LFS/a/file/name, not bash itself. > > I'm OK with: > > This is because the Bash shell is set up so that $LFS is now the root (/) > directory. > > That is: sed /told/set up so/ > I just feel like I cannot explain. Bash is _unchanged_: it is the _kernel_, which is set up so that $LFS is the new root for the process where bash (or anything fork(2)ed from bash) is running. Anyway, nobody has complained for years, let's not change anything. It does not prevent the build to work. Pierre Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Inaccuracy in chroot page
On 3/14/20 10:55 AM, Pierre Labastie via lfs-dev wrote: Le 14/03/2020 à 16:00, Bruce Dubbs via lfs-dev a écrit : On 3/14/20 3:41 AM, Pierre Labastie via lfs-dev wrote: In "6.4 Entering the Chroot Environment", we have: From this point on, there is no need to use the LFS variable anymore, because all work will be restricted to the LFS file system. This is because the Bash shell is told that $LFS is now the root (/) directory. But it is not true that the bash shell is told anything: the _kernel_ is told that $LFS is now the root (/) directory for all the processes launched by the first one (that is, here, "env", which itself launches "bash", which will launch all the others). I am not sure how to phrase this: something like: - ... system. This is because the kernel is told that $LFS is now the root (/) directory for all the programs run from the current Bash shell. - But I'm sure native English writers can find something better (without excluding non native of course :) I think I disagree with your premise. bash IS told where the root directory is, but there is some interaction with the kernel. When I enter chroot, env no longer exists. It does an 'exec' and replaces itself with bash. I took a look at /proc/ for that instance of bash and in that directory is the pseudo file 'mounts'. That tells me: /dev/sda6 / ext4 rw,noatime 0 0 which is my /mnt/lfs directory on the host. My interpretation is that this is a configuration for bash. When doing 'cd /', the kernel looks at this configuration for the bash instance and uses that to determine what disk partition (it could be a directory) to use for the head of an absolute path. In my opinion what we have now is correct. Thinking a little more about this, what I mean is the following: bash is not "told" anything, and does not "know" that "/" is $LFS: bash may ask the kernel to open(2) (or stat(2), or other basic calls) a file by passing the filename to the kernel, say, /a/file/name, and it is the kernel which resolves that filename to $LFS/a/file/name, not bash itself. I'm OK with: This is because the Bash shell is set up so that $LFS is now the root (/) directory. That is: sed /told/set up so/ -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Inaccuracy in chroot page
Le 14/03/2020 à 16:00, Bruce Dubbs via lfs-dev a écrit : > On 3/14/20 3:41 AM, Pierre Labastie via lfs-dev wrote: >> In "6.4 Entering the Chroot Environment", we have: >> >> From this point on, there is no need to use the LFS variable anymore, >> because >> all work will be restricted to the LFS file system. This is because the Bash >> shell is told that $LFS is now the root (/) directory. >> >> But it is not true that the bash shell is told anything: the _kernel_ is told >> that $LFS is now the root (/) directory for all the processes launched by the >> first one (that is, here, "env", which itself launches "bash", which will >> launch all the others). I am not sure how to phrase this: something like: >> - >> ... system. This is because the kernel is told that $LFS is now the root (/) >> directory for all the programs run from the current Bash shell. >> - >> But I'm sure native English writers can find something better (without >> excluding non native of course :) > > I think I disagree with your premise. bash IS told where the root directory > is, but there is some interaction with the kernel. > > When I enter chroot, env no longer exists. It does an 'exec' and replaces > itself with bash. I took a look at /proc/ for that instance of bash and > in that directory is the pseudo file 'mounts'. That tells me: > > /dev/sda6 / ext4 rw,noatime 0 0 > > which is my /mnt/lfs directory on the host. My interpretation is that this is > a configuration for bash. When doing 'cd /', the kernel looks at this > configuration for the bash instance and uses that to determine what disk > partition (it could be a directory) to use for the head of an absolute path. > > In my opinion what we have now is correct. > Thinking a little more about this, what I mean is the following: bash is not "told" anything, and does not "know" that "/" is $LFS: bash may ask the kernel to open(2) (or stat(2), or other basic calls) a file by passing the filename to the kernel, say, /a/file/name, and it is the kernel which resolves that filename to $LFS/a/file/name, not bash itself. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Inaccuracy in chroot page
On 3/14/20 3:41 AM, Pierre Labastie via lfs-dev wrote: In "6.4 Entering the Chroot Environment", we have: From this point on, there is no need to use the LFS variable anymore, because all work will be restricted to the LFS file system. This is because the Bash shell is told that $LFS is now the root (/) directory. But it is not true that the bash shell is told anything: the _kernel_ is told that $LFS is now the root (/) directory for all the processes launched by the first one (that is, here, "env", which itself launches "bash", which will launch all the others). I am not sure how to phrase this: something like: - ... system. This is because the kernel is told that $LFS is now the root (/) directory for all the programs run from the current Bash shell. - But I'm sure native English writers can find something better (without excluding non native of course :) I think I disagree with your premise. bash IS told where the root directory is, but there is some interaction with the kernel. When I enter chroot, env no longer exists. It does an 'exec' and replaces itself with bash. I took a look at /proc/ for that instance of bash and in that directory is the pseudo file 'mounts'. That tells me: /dev/sda6 / ext4 rw,noatime 0 0 which is my /mnt/lfs directory on the host. My interpretation is that this is a configuration for bash. When doing 'cd /', the kernel looks at this configuration for the bash instance and uses that to determine what disk partition (it could be a directory) to use for the head of an absolute path. In my opinion what we have now is correct. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Inaccuracy in chroot page
In "6.4 Entering the Chroot Environment", we have: From this point on, there is no need to use the LFS variable anymore, because all work will be restricted to the LFS file system. This is because the Bash shell is told that $LFS is now the root (/) directory. But it is not true that the bash shell is told anything: the _kernel_ is told that $LFS is now the root (/) directory for all the processes launched by the first one (that is, here, "env", which itself launches "bash", which will launch all the others). I am not sure how to phrase this: something like: - ... system. This is because the kernel is told that $LFS is now the root (/) directory for all the programs run from the current Bash shell. - But I'm sure native English writers can find something better (without excluding non native of course :) Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
