On 2/27/19 4:50 PM, Bruce Dubbs via lfs-dev wrote:
On 2/27/19 3:27 PM, Pierre Labastie via lfs-dev wrote:
On 27/02/2019 18:05, Bruce Dubbs via lfs-dev wrote:
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.*
?? I propose to add this on the page "Preparing virtual kernel
systems", after
mounting $LFS/run as a tmpfs. Then it would be perfectly usable in
chroot.
Yup. You are right.
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.
We do mount a tmpfs as $LFS/run on the page "Preparing virtual kernel
systems." Then anything can be copied to it... It is not really a
"virtual"
filesystem: rather a ramdisk.
True.
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>.
Well, that would make it easier to install jhalfs tools for blfs if
network
could be accessed in chroot: make-ca needs to be run for installing
wget, and
make-ca accesses the network. Make-ca cannot be run on the host. I
agree It
may be the only use case...
So your concern is using chroot after LFS and now building BLFS
packages. My question is whether it would work because we are not
running systemd inside chroot. It works fine in sysV so I'll leave it
up to Doug and DJ if they feel the symlink is needed.
I'll note that if the user unmounts the virtual filesystems and then
remounts them (happens often in my classes), then the copy of
resolv.conf needs to be copied each time.
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.
Sure...
Maybe I could tweak jhalfs so that make-ca is run after booting LFS.
But I
need a way to trigger this run.
But if you do not agree for the addition, let's forget about it...
Doug? DJ?
-- Bruce
Pierre, please proceed. I do think it is necessary and would be helpful.
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
