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"