Ralf S. Engelschall
2009-Jun-29 09:09 UTC
FreeBSD 7-STABLE and chflags on ZFS now(?) failing
One of my FreeBSD boxes is a 7-STABLE/amd64 one on ZFS, now in
production for over a 1.5 years now and which receives regular upgrades.
The last installation of FreeBSD 7-STABLE was just about 2 weeks ago.
Today the upgrade failed the first time:
----------------------------------------------------------------------------
cd /usr/src; /usr/bin/make -f Makefile.inc1 install
===> share/info (install)
===> lib (install)
===> lib/csu/amd64 (install)
install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /usr/lib
===> lib/libc (install)
install -C -o root -g wheel -m 444 libc.a /usr/lib
install -C -o root -g wheel -m 444 libc_p.a /usr/lib
install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib
install: /lib/libc.so.7: chflags: Invalid argument
*** Error code 71
Stop in /usr/src/lib/libc.
*** Error code 1
Stop in /usr/src/lib.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
3.30s real 0.35s user 0.75s sys
/libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by
"sh"
*** Error code 1
Stop in /usr/adm.
*** Error code 1 (ignored)
/libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by
"sh"
*** Error code 1 (ignored)
/libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by
"sh"
*** Error code 1 (ignored)
/libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by
"sh"
*** Error code 1 (ignored)
/libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by
"sh"
*** Error code 1
Stop in /usr/adm.
*** Error code 1 (ignored)
# sh
/libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by
"sh"
#
----------------------------------------------------------------------------
Fortunately, I was able to quickly recover via "/rescue/cp" by copying
a libc.so.7 from a Jail to the host system (where the upgrade was
performed). But why has this problem occurred now.
Well, /lib is on ZFS and I can remember from the past that ZFS did not
honor chflags. But remains two questions:
1. I thought chflags support for ZFS was added already in the past.
Can it be that just a _few_ chflags flags are supported? It looks
like uchg works while the above schg fails.
2. Assuming that schg was never supported on ZFS by us, why did the
upgrades in the past on this FreeBSD 7-STABLE box never failed until
now? Why now the first time? I would have expected that it already
failed from day zero with the above error.
As workaround I've now put a NO_SCHG=yes into /etc/make.conf and
performed the upgrade from scratch. Now it succeeded, of course. But I
still do not know the answer to the above two questions and this makes
me still feel a little bit unsure about the whole situation...
PS: At a mergemaster run I now got a problems which looks related:
mv: /var/db/mergemaster.mtree: set flags (was: 00000000): Invalid argument
Yes, /var is also on ZFS here. Same problem as it looks. But I'm
sure also this error did not occur in the past...
--
rse@FreeBSD.org Ralf S. Engelschall
FreeBSD.org/~rse rse@engelschall.com
FreeBSD committer www.engelschall.com
Ralf S. Engelschall wrote:> One of my FreeBSD boxes is a 7-STABLE/amd64 one on ZFS, now in > production for over a 1.5 years now and which receives regular upgrades. > The last installation of FreeBSD 7-STABLE was just about 2 weeks ago. > Today the upgrade failed the first time: > > ---------------------------------------------------------------------------- > cd /usr/src; /usr/bin/make -f Makefile.inc1 install > ===> share/info (install) > ===> lib (install) > ===> lib/csu/amd64 (install) > install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /usr/lib > ===> lib/libc (install) > install -C -o root -g wheel -m 444 libc.a /usr/lib > install -C -o root -g wheel -m 444 libc_p.a /usr/lib > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > install: /lib/libc.so.7: chflags: Invalid argument > *** Error code 71 > > Stop in /usr/src/lib/libc. > *** Error code 1 > > Stop in /usr/src/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > 3.30s real 0.35s user 0.75s sys > /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" > *** Error code 1 > > Stop in /usr/adm. > *** Error code 1 (ignored) > /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" > *** Error code 1 (ignored) > /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" > *** Error code 1 (ignored) > /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" > *** Error code 1 (ignored) > /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" > *** Error code 1 > > Stop in /usr/adm. > *** Error code 1 (ignored) > # sh > /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" > # > ---------------------------------------------------------------------------- > > Fortunately, I was able to quickly recover via "/rescue/cp" by copying > a libc.so.7 from a Jail to the host system (where the upgrade was > performed). But why has this problem occurred now. > > Well, /lib is on ZFS and I can remember from the past that ZFS did not > honor chflags. But remains two questions: > > 1. I thought chflags support for ZFS was added already in the past. > Can it be that just a _few_ chflags flags are supported? It looks > like uchg works while the above schg fails.I believe that for schg `zfs get version <file_system_with /lib>` must be 3. To upgrade this: `zfs upgrade <file_system_with /lib>`> > 2. Assuming that schg was never supported on ZFS by us, why did the > upgrades in the past on this FreeBSD 7-STABLE box never failed until > now? Why now the first time? I would have expected that it already > failed from day zero with the above error.Just a try to this strange problem: `man install` say: By default, install preserves all file flags, with the exception of the ``nodump'' flag. With the previous version of zfs there was no flags and so no try to play with flags during update. Henri> > As workaround I've now put a NO_SCHG=yes into /etc/make.conf and > performed the upgrade from scratch. Now it succeeded, of course. But I > still do not know the answer to the above two questions and this makes > me still feel a little bit unsure about the whole situation... > > > PS: At a mergemaster run I now got a problems which looks related: > mv: /var/db/mergemaster.mtree: set flags (was: 00000000): Invalid argument > Yes, /var is also on ZFS here. Same problem as it looks. But I'm > sure also this error did not occur in the past... > > -- > rse@FreeBSD.org Ralf S. Engelschall > FreeBSD.org/~rse rse@engelschall.com > FreeBSD committer www.engelschall.com > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"