On Thu, Mar 26, 2020 at 11:40:59AM +0100, Pierre Labastie via
blfs-dev wrote:
> Le 23/03/2020 à 03:49, Bruce Dubbs via blfs-dev a écrit :
> > On 3/22/20 9:25 PM, Xi Ruoyao via blfs-dev wrote:
> >> On 2020-03-23 01:44 +0000, Ken Moffat via blfs-dev wrote:
> >>> On Mon, Mar 23, 2020 at 09:12:18AM +0800, Xi Ruoyao via
> >>> blfs-dev wrote:
> >>>> On 2020-03-22 21:34 +0000, Ken Moffat via blfs-dev wrote:
> >>>>
> >>>>> # mount --bind /run /mnt/lfs/run
> >>>>
> >>>> I think it's dangerous: potentially harmful to the host.
> >>>> Some service running in the LFS chroot may overwrite the
> >>>> runtime directory of the service running on the host.
> >>>
> >>> So, you are saying that packages from mozilla should not now
> >>> be built in chroot ?
> >>
> >> No. I think we need a better way.
> >>
> >>> But, what do you mean by a service running in chroot ? I
> >>> assume we are specifically talking of systemd here ? Do
> >>> services not get started during the boot process ? The
> >>> systemd instance in chroot has never started, so I assume it
> >>> will be ineffective and systemd on the host will only care
> >>> about services described in /etc/systemd ?
> >>
> >> Maybe that's not a issue. But still, /run contains lots of
> >> sockets of running services. That means now we can connect
> >> host services from the chroot environment. Even if it's not
> >> dangerous to host, it's polluting the new LFS system.
> >>
> >> Consider /run/initctl. We don't want something in chroot to
> >> switch the *host* to runlevel 1 :).
> >
> > What about
> >
> > mount -t tmpfs /run
> >
> > from within chroot?
> >
> > -- Bruce
>
> FWIIW, here are my findings: On a debian host, we have:
>
> lrwxrwxrwx 1 root root 8 mars 26 09:48 /run/shm -> /dev/shm
> drwxrwxrwt 2 root root 40 mars 26 11:02 /dev/shm
>
> But when mounting /dev to $LFS with mount --bind, we have
>
> drwxr-xr-x 2 root root 40 mars 26 11:01 /mnt/lfs/dev/shm
>
> that is, the sticky bit and the write perm are lost for an average
> user.
>
> Now trying to build FF in chroot (creating kernel virtual
> filesystems and chrooting with the lfs book instructions): - as
> root: needs to issue "export SHELL", but otherwise succeeds
> without anything else (/run exists as a tmpfs , but /run/shm does
> not exist) - as user: no need to run "export SHELL" (I guess "su -
> <user>" does the export), but the perms to /dev/shm need to be
> changed to rwt
>
> In both cases, the build goes to completion (not tried to install)
> after the indicated changes.
>
> Another check I've done: on a lfs system (9.1-rc1 Sys V) as per
> the book, /dev/shm is drwxrwxrwt, and /run/shm does not exist. But
> everybody knows it is possible to build firefox Actually, if you
> just mount a devtmpfs:
>
> mkdir tempdir-for-trying-something sudo mount -t devtmpfs devtmpfs
> tempdir-for-trying-something ls -ld
> tempdir-for-trying-something/shm
>
> then the shm perms are drwxrwxrwt.
>
> So I'd suggest our instructions be changed to mount a devtmpfs in
> $LFS/dev
>
> But what makes me think I do something different from ĸen is that
> I never see: OSError: [Errno 38] Function not implemented
>
>
> Pierre
>
I'll reply in a while with what I have now tested (after I've
assembled my notes). I've gone with Bruce's suggestion to (only)
mount a tmpfs on /run when building in chroot - I think xry111 has
identified the issue (bind mounts are not recursive).
Meanwhile, if you do not see that OSError when building any of firefox,
mozjs{60,68}, seamonkey, thunderbird *in chroot* then you are doing
something different. This issue was raised in
http://lists.linuxfromscratch.org/pipermail/blfs-support/2020-March/081897.html
I'll document *how* I tested so that people can pick it apart if
they wish :)
ĸen
--
When alle is ſayed and all is done, ye must chooſe your faces wisely,
for soon enouff ye will be playing with fyre."
The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
