Date: Wed, 7 Oct 2015 21:39:28 -0400 From: Derek Schrock <dereks@lifeofadishwasher.com> To: freebsd-questions@freebsd.org Subject: Re: freebsd-update keeps wanting to remove .. somthing Message-ID: <20151008013928.GA43149@ircbsd> In-Reply-To: <56143B79.4040006@buildingonline.com> References: <5613C59B.8070604@buildingonline.com> <20151006151058.3b627cd2@gumby.homeunix.com> <56143B79.4040006@buildingonline.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 06, 2015 at 05:22:01PM EDT, Dan Busarow wrote: > > Thanks! > > I'll dig in and see what I can find. > I believe this only appears in FreeBSD 9.3 i386. root@freebsd9-i386:~ # uname -a FreeBSD freebsd9-i386 9.3-RELEASE-p21 FreeBSD 9.3-RELEASE-p21 #0: Tue Jul 28 08:57:41 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 It seems to be a bad line in the expected list of old file that's served by the freebsd-update servers. root@freebsd9-i386:/var/db/freebsd-update # cat tINDEX.present INDEX-NEW|aff841e64d37fc9985ac542c3b2471958b39f6c22ee6d3280ae45ff65bdc6d58 INDEX-OLD|9d024d76b279a1804dafdcf33d2e1a5a8bfde1d98cda812a73d173089d071080 /var/db/freebsd-update/files/9d024d76b279a1804dafdcf33d2e1a5a8bfde1d98cda812a73d173089d071080.gz is the expected old list. root@freebsd9-i386:/var/db/freebsd-update # gunzip -c files/9d024d76b279a1804dafdcf33d2e1a5a8bfde1d98cda812a73d173089d071080.gz | tail -n3 world|games|/usr/games/factor|f|0|0|0555|0|3366b537133c334a4811776996cf264cfe934e4973ff64ceb1ea9fccd8282d5e| world|games|/usr/games/factor|f|0|0|0555|0|76a7765e88250af1ef99a73757c8c286cc8755e2244864b9f6c750eba2355743| world|lib32|/|d|0|0|0755|0|| Seems like 'world|lib32|/|d|0|0|0755|0||' is our bad line. root@freebsd9-i386:/var/db/freebsd-update # ls f465c3739385890c221dff1a05e578c6cae0d0430e46996d319db7439f884336-install/ INDEX-NEW INDEX-OLD root@freebsd9-i386:/var/db/freebsd-update # cat f465c3739385890c221dff1a05e578c6cae0d0430e46996d319db7439f884336-install/* |d|0|0|0755|0|| I don't know what the fixed would be other than getting the file that's served from the freebsd-update servers updated or the underlying machine that builds the metadata files is bad in someway. Unless this is some how tied to the update from a couple months ago where freebsd-update tried and failed to delete /. Should I file a PR for this?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151008013928.GA43149>