On 2/27/19 10:45 AM, Pierre Labastie via lfs-dev wrote:
On 27/02/2019 04:47, Bruce Dubbs via lfs-dev wrote:
We now have all tickets for 8.4 closed and all packages tagged.
Please review what is in the development books and let us know if there are
any changes that need to be made. Small issues are as important at this stage
as big ones.
Not sure this is the place to discuss this, but since it involves a small
addition, I've thought I could talk about that:
- when building a sysv book, once the network page has been completed, network
is accessible in chroot. Of course, networking program are not easy to use
(bash sockets, perl, and openssl, which all give complicated commands), but it
is usable. For example the make-ca script can fetch certificates from the
mozilla site.
- when building a systemd book, the recommandation on the network page is to
create a symlink from /etc/resolv.conf to /run/systemd/resolve/resolve.conf.
Since /run is empty, the network is unusable (no name resolution). This is
easy to fix by adding:
mkdir -pv $LFS/run/systemd/resolve
cp -v {,$LFS}/run/systemd/resolve/resolv.conf
This would not be valid inside chroot.
to "Preparing virtual kernel filesystems".
Note that this copy is just for the duration of the chroot session, since /run
is a tmpfs...
Thoughts?
On the host, /run is a virtual file system that is not mounted in
chroot. $LFS/run/systemd/resolve is not a virtual file system and would
be covered up at boot when /run is mounted.
I don't understand why we need network access in chroot. The user does
have the option of using network access from the host system outside of
chroot and putting a file into /mnt/lfs/<location>.
When the symlink is created, it is a 'broken' link, but to the best of
my knowledge, the target is created at boot time and results in a valid
symlink.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
