Re: What should do in chrooted environment?
> On 24 Apr 2018, at 23:39, Marc Branchaud wrote: > On 2018-04-24 09:24 AM, Glen Barber wrote: >> There are additional nits regarding jail(8) that chroot(8) does not have >> the same limitations. Setting/unsetting the immutable flag on something >> like /sbin/init, for example, comes to mind. > > Try > allow.chflags > in your jail.conf. I assume that this also isn't checked by the build so you end up wasting some time as well (but probably only in installworld) I don't see an argument against doing some quick sanity checks before starting a run (be it buildworld, installworld or whatever). -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: What should do in chrooted environment?
On Tue, Apr 24, 2018 at 10:09:40AM -0400, Marc Branchaud wrote: > On 2018-04-24 09:24 AM, Glen Barber wrote: > > There are additional nits regarding jail(8) that chroot(8) does not have > > the same limitations. Setting/unsetting the immutable flag on something > > like /sbin/init, for example, comes to mind. > > Try > allow.chflags > in your jail.conf. > Sure, this works, but it requires (IMHO) more "intervention" than a simple devfs(5) mount in the target build environment. Glen > M. > > > Glen > > > > On Tue, Apr 24, 2018 at 11:49:46AM +0100, krad wrote: > > > wouldn't it just be easier to do this in a jail, and then all of these > > > little bits would be taken care of? > > > > > > On 24 April 2018 at 01:48, O'Connor, Daniel wrote: > > > > > > > > > > > > > > > > On 24 Apr 2018, at 08:14, Glen Barber wrote: > > > > > I think you might not have the devfs mount in the image. With the > > > > > paths > > > > > provided above, I think this should fix it: > > > > > > > > > > # mount -t devfs devfs /mnt/dev > > > > > > > > I wonder if it's worth doing a basic sanity check that /dev/null and > > > > /dev/zero look like device nodes. > > > > > > > > I've made this mistake too and it produces some very confusing error > > > > messages :( > > > > > > > > -- > > > > Daniel O'Connor > > > > "The nice thing about standards is that there > > > > are so many of them to choose from." > > > > -- Andrew Tanenbaum > > > > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > > > ___ > > > > freebsd-stable@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > > To unsubscribe, send any mail to > > > > "freebsd-stable-unsubscr...@freebsd.org" > > > > > signature.asc Description: PGP signature
Re: What should do in chrooted environment?
On 2018-04-24 09:24 AM, Glen Barber wrote: There are additional nits regarding jail(8) that chroot(8) does not have the same limitations. Setting/unsetting the immutable flag on something like /sbin/init, for example, comes to mind. Try allow.chflags in your jail.conf. M. Glen On Tue, Apr 24, 2018 at 11:49:46AM +0100, krad wrote: wouldn't it just be easier to do this in a jail, and then all of these little bits would be taken care of? On 24 April 2018 at 01:48, O'Connor, Daniel wrote: On 24 Apr 2018, at 08:14, Glen Barber wrote: I think you might not have the devfs mount in the image. With the paths provided above, I think this should fix it: # mount -t devfs devfs /mnt/dev I wonder if it's worth doing a basic sanity check that /dev/null and /dev/zero look like device nodes. I've made this mistake too and it produces some very confusing error messages :( -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: What should do in chrooted environment?
There are additional nits regarding jail(8) that chroot(8) does not have the same limitations. Setting/unsetting the immutable flag on something like /sbin/init, for example, comes to mind. Glen On Tue, Apr 24, 2018 at 11:49:46AM +0100, krad wrote: > wouldn't it just be easier to do this in a jail, and then all of these > little bits would be taken care of? > > On 24 April 2018 at 01:48, O'Connor, Daniel wrote: > > > > > > > > On 24 Apr 2018, at 08:14, Glen Barber wrote: > > > I think you might not have the devfs mount in the image. With the paths > > > provided above, I think this should fix it: > > > > > > # mount -t devfs devfs /mnt/dev > > > > I wonder if it's worth doing a basic sanity check that /dev/null and > > /dev/zero look like device nodes. > > > > I've made this mistake too and it produces some very confusing error > > messages :( > > > > -- > > Daniel O'Connor > > "The nice thing about standards is that there > > are so many of them to choose from." > > -- Andrew Tanenbaum > > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > ___ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > signature.asc Description: PGP signature
Re: What should do in chrooted environment?
wouldn't it just be easier to do this in a jail, and then all of these little bits would be taken care of? On 24 April 2018 at 01:48, O'Connor, Daniel wrote: > > > > On 24 Apr 2018, at 08:14, Glen Barber wrote: > > I think you might not have the devfs mount in the image. With the paths > > provided above, I think this should fix it: > > > > # mount -t devfs devfs /mnt/dev > > I wonder if it's worth doing a basic sanity check that /dev/null and > /dev/zero look like device nodes. > > I've made this mistake too and it produces some very confusing error > messages :( > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: What should do in chrooted environment?
> On 24 Apr 2018, at 08:14, Glen Barber wrote: > I think you might not have the devfs mount in the image. With the paths > provided above, I think this should fix it: > > # mount -t devfs devfs /mnt/dev I wonder if it's worth doing a basic sanity check that /dev/null and /dev/zero look like device nodes. I've made this mistake too and it produces some very confusing error messages :( -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: What should do in chrooted environment?
On Tue, Apr 24, 2018 at 07:28:06AM +0900, KIRIYAMA Kazuhiko wrote: > Hi, all > > I've make buildworld in chrooted environment. But failed at > 'stage 4.2: building libraries' [1]: > > objcopy --only-keep-debug libproc.so.3.full libproc.so.3.debug > objcopy --strip-debug --add-gnu-debuglink=libproc.so.3.debug > libproc.so.3.full libproc.so.3 > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libproc.a > /usr/obj/usr/src/tmp/usr/lib/ > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libproc.so.3 > /usr/obj/usr/src/tmp/usr/lib/ > sh /usr/src/tools/install.sh -o root -g wheel -m 444libproc.so.3.debug > /usr/obj/usr/src/tmp/usr/lib/debug/usr/lib/ > sh /usr/src/tools/install.sh -l rs libproc.so.3 > /usr/obj/usr/src/tmp/usr/lib/libproc.so > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 > /usr/src/lib/libproc/libproc.h /usr/obj/usr/src/tmp/usr/include/ > make[5]: "/dev/null" line 1: Need an operator > make[5]: Fatal errors encountered -- cannot continuemake[4]: > "/usr/src/Makefile.inc1" line 421: warning: "MK_AUTO_OBJ=no MAKEFLAGS= > CPUTYPE=dummy make -f /dev/null -m /usr/src/share/mk -V CPUTYPE" returned > non-zero status > make[4]: "/usr/src/Makefile.inc1" line 423: CPUTYPE global should be set with > ?=. > *** Error code 1 > > Stop. > make[3]: stopped in /usr/src > *** Error code 1 > > Stop. > make[2]: stopped in /usr/src > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > > My chrooted environment is a bhyve vm attach & mounted one > like this(*1): > > root@vms:~ # mdconfig -a -t vnode -f /vm/tbedfs/disk0.img > md0 > root@vms:~ # gpart show md0 > => 40 16777136 md0 GPT (8.0G) > 4024 - free - (12K) > 64 10241 freebsd-boot (512K) > 1088 167760232 freebsd-ufs (8.0G) > 1677711141 - free - (21K) > 16777152233 freebsd-swap (12K) > 16777175 1 - free - (512B) > > root@vms:~ # mount /dev/md0p2 /mnt > > > And src and obj are nullfs mounted to latest src > repository(r332874) and OBJDIR respectively: > > > root@vms:~ # uname -a > FreeBSD vms.pis 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331153: Tue Mar 20 > 10:13:56 JST 2018 > ad...@t.pis:/ds/obj/current/12.0/r331153/ds/src/current/12.0/r331153/amd64.amd64/sys/GENERIC > amd64 > root@vms:~ # > admin@vms:~ % df > Filesystem1K-blocks Used Avail Capacity > Mounted on > /dev/aacd0p4 10143484 4624840 470716850%/ > devfs 11 0 100%/dev > /dev/aacd0p514560423728 79273144 13316316688 1%/ds > /ds/.dake 14560423728 79273144 13316316688 1%/.dake > /ds/vm 14560423728 79273144 13316316688 1%/vm > /dev/md0p2 5061084 3053316 160288466%/mnt > /ds/src/stable/11.1/r332874 14560423728 79273144 13316316688 1% > /mnt/usr/src > /ds/obj/stable/11.1/r332874 14560423728 79273144 13316316688 1% > /mnt/usr/obj > admin@vms:~ % > > > Then chroot to /mnt and make buildworld: > > > root@vms:~ # chroot /mnt "make buildworld" > > > Of course 'make buildworld' in vm was successfully finished [2]: > > > admin@tbedfs:~ % uname -a > FreeBSD tbedfs 11.1-STABLE FreeBSD 11.1-STABLE #0 r332428: Thu Apr 12 > 16:37:51 UTC 2018 > r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > admin@tbedfs:~ % df > Filesystem1K-blocks Used Avail Capacity > Mounted on > /dev/vtbd0p28106116 849980 660764811% > / > devfs 11 0 100% > /dev > vms.pis:/.dake 14560423728 83720204 13311869628 1% > /.dake > vms.pis:/ds/src/stable/11.1/r332874 14560423728 83720204 13311869628 1% > /usr/src > vms.pis:/ds/obj/stable/11.1/r332874 14560423728 83720204 13311869628 1% > /usr/obj > admin@tbedfs:~ % su > Password: > root@tbedfs:/usr/home/admin # cd /usr/src/ > root@tbedfs:/usr/src # make buildworld > > > To make buildworld in chrooted environment, what should I do ? > I think you might not have the devfs mount in the image. With the paths provided above, I think this should fix it: # mount -t devfs devfs /mnt/dev Glen signature.asc Description: PGP signature
