On February 27, 2019 3:27:02 PM CST, Pierre Labastie via lfs-dev <[email protected]> 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. > >> >>> 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
make-ca can be run with the -c switch. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
