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.
>
>> 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.
> 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...
>
> 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...
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
