Re: 'make installkernel' succeeding on read-only fs?
On 2011/11/19 at 19:24, Alexander Best arun...@freebsd.org wrote: hi there, just stumbled upon this little detail: 1) have / mounted read-only 2) 'make buildkernel' 3) 'make installkernel echo success' - this will fail 4) 'mount -uw /' 5) 'make installkernel echo success' - this will succeed 6) 'mount -ur /' 7) 'make installkernel echo success' - this will succeed. why? According to mount(8), 'mount -ur /' will fail if / is already mounted read-write with any files currently opened by some processes. I think this might be your case. cheers. alex -- If you've got them by the balls, their hearts and minds will follow. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 'make installkernel' succeeding on read-only fs?
On Sun Nov 20 11, Denise H. G. wrote: On 2011/11/19 at 19:24, Alexander Best arun...@freebsd.org wrote: hi there, just stumbled upon this little detail: 1) have / mounted read-only 2) 'make buildkernel' 3) 'make installkernel echo success' - this will fail 4) 'mount -uw /' 5) 'make installkernel echo success' - this will succeed 6) 'mount -ur /' 7) 'make installkernel echo success' - this will succeed. why? According to mount(8), 'mount -ur /' will fail if / is already mounted read-write with any files currently opened by some processes. I think this might be your case. i'd don't think so: otaku% sudo mount -uw / otaku% echo $? 0 otaku% sudo mount -ur / otaku% echo $? 0 ...also 'mount -p' reports / to be read-only again. ...also during 7), mkdir(1) returns an error that / isn't writable. it's install(1) that claims the kernel was successfully installed into /boot/kernel, although installation of the kernel didn't succeed. i don't think this is an install(1) issue, since in 3), install(1) returns an error. i think in 7), install(1)'s output gets somehow redirected to /dev/null, and its return value isn't being preserved. i'll try to use 'mount -ufr /' in 6) and see, if that has any impact. also after 6) i'll try to run install(1) manually to see, whether it actually reports an error (then the build(7) facility is to blame) or not (in which case there's a problem with install(1) itself). cheers. alex cheers. alex -- If you've got them by the balls, their hearts and minds will follow. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 'make installkernel' succeeding on read-only fs?
On Sun Nov 20 11, Alexander Best wrote:
On Sun Nov 20 11, Denise H. G. wrote:
On 2011/11/19 at 19:24, Alexander Best arun...@freebsd.org wrote:
hi there,
just stumbled upon this little detail:
1) have / mounted read-only
2) 'make buildkernel'
3) 'make installkernel echo success'
- this will fail
4) 'mount -uw /'
5) 'make installkernel echo success'
- this will succeed
6) 'mount -ur /'
7) 'make installkernel echo success'
- this will succeed. why?
According to mount(8), 'mount -ur /' will fail if / is already mounted
read-write with any files currently opened by some processes. I think
this might be your case.
i'd don't think so:
otaku% sudo mount -uw /
otaku% echo $?
0
otaku% sudo mount -ur /
otaku% echo $?
0
...also 'mount -p' reports / to be read-only again.
...also during 7), mkdir(1) returns an error that / isn't writable. it's
install(1) that claims the kernel was successfully installed into
/boot/kernel,
although installation of the kernel didn't succeed.
i don't think this is an install(1) issue, since in 3), install(1) returns an
error. i think in 7), install(1)'s output gets somehow redirected to
/dev/null,
and its return value isn't being preserved.
i'll try to use 'mount -ufr /' in 6) and see, if that has any impact. also
after 6) i'll try to run install(1) manually to see, whether it actually
reports an error (then the build(7) facility is to blame) or not (in which
case
there's a problem with install(1) itself).
MYSTERY SOLVED! ;)
install gets executed with the -p option, which implies the -C option. this
means that install will do a comparison of the installed kernel in /boot/kernel
and the one in /usr/obj, before actually executing. during the first
installkernel invocation, the files differ, so install complains. during the
second invocation the files don't differ. that's why install succeeds, although
/ is mounted read-only. ;)
cheers.
alex
cheers.
alex
cheers.
alex
--
If you've got them by the balls,
their hearts and minds will follow.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: -fstack-protector vs. -fstack-protector-all
On Sat Nov 19 11, Dimitry Andric wrote:
On 2011-11-18 15:37, Alexander Best wrote:
what are the reasons for using -fstack-protector instead of
-fstack-protector-all in sys/conf/kern.mk?
My guess would be one or more of the following:
- The price in performance is too high
- The gain in security is too low
- Some routines in the kernel are run before the whole stack protection
infrastructure is in place, ergo they can't have stack protection
- There might be other problems with -fstack-protector-all,
lib/libc/Makefile says:
# XXX For now, we don't allow libc to be compiled with
# -fstack-protector-all because it breaks rtld. We may want to make a
librtld
# in the future to circumvent this.
SSP_CFLAGS:=
${SSP_CFLAGS:S/^-fstack-protector-all$/-fstack-protector/}
defining -fstack-protector-all in sys/conf/kern.mk will only apply it to the
kernel and its components and not to world, i believe.
i've been running a kernel compiled with -fstack-protector-all and haven't
experienced any issues with it, so far.
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
