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