On 2020-03-26 16:06 +0100, Pierre Labastie via blfs-dev wrote:
> Le 26/03/2020 à 14:41, Ken Moffat via blfs-dev a écrit :
> > 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
>
> The error reported by the OP ("This platform lacks a functioning sem_open
> implementation...") is the one I see when /dev/shm is not world writable, and
> the build is done as a regular user.
> When building as root, the error is different (something about an unknown
> shell).
>
> Those are the only errors I see. Note that chroot is entered with the
> following commands (Makefile syntax):
> sudo mount -v --bind /dev $(MOUNT_PT)/dev; \
> sudo mount -vt devpts devpts $(MOUNT_PT)/dev/pts -o gid=5,mode=620; \
> sudo mount -vt proc proc $(MOUNT_PT)/proc; \
> sudo mount -vt sysfs sysfs $(MOUNT_PT)/sys; \
> sudo mount -vt tmpfs tmpfs $(MOUNT_PT)/run; \
> if [ -h $(MOUNT_PT)/dev/shm ]; then :; \
> sudo mkdir -pv $(MOUNT_PT)/$$(readlink $(MOUNT_PT)/dev/shm); \
> fi;
>
> #Since on debian, /dev/shm is not a symlink, the last mkdir is not executed.
>
> #Note that a tmpfs is mounted on /run.
>
> # Then
> /usr/sbin/chroot $(MOUNT_PT) \
> /usr/bin/env -i \
> HOME=/root TERM="$$TERM" \
> PS1='(lfs chroot) \u:\w\$$ ' \
> PATH=/bin:/usr/bin:/sbin:/usr/sbin \
> /bin/bash --login
> (again Makefile syntax).
>
> Do I understand correctly that you and xry111 suggest that a tmpfs be mounted
> on /dev/shm? Without any perm change? Let me try...
> Yesss:
> root [ / ]# ls -al /dev/shm
> total 0
> drwxrwxrwt 2 root root 40 Mar 26 15:59 .
> drwxr-xr-x 21 root root 3900 Mar 26 09:48 ..
>
> I just added a line:
> sudo mount -vt tmpfs tmpfs $(MOUNT_PT)/dev/shm; \
>
> while still on host
Now the book is handling the case "/dev/shm is a link to /run/shm" correctly and
explicitly. Unfortunately it seems for the case "/dev/shm is *not* a link to
/run/shm" the book is defective. I'm surprised that it didn't cause any problem
building LFS...
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
