I ran freebsd-update(8) this morning to update my 10.1-RELEASE-p1 machine to 10.1-RELEASE-p2. After a 'fetch', freebsd-update reports that it will remove / (the root directory): # freebsd-update fetch Fetching metadata signature for 10.1-RELEASE from update2.freebsd.org... done. Fetching metadata index... done. Fetching 2 metadata patches.. done. Applying metadata patches... done. Inspecting system... done. Preparing to download files... done. Fetching 8 patches..... done. Applying patches... done. Fetching 313 files... done. The following files will be removed as part of updating to 10.1-RELEASE-p2: / The following files will be added as part of updating to 10.1-RELEASE-p2: ... # When installing the updates, it appears that freebsd-update actually tries to remove / as well: # freebsd-update install Installing updates...rmdir: ///: Is a directory done. #
As pointed out on IRC (#freebsd on freenode), running 'freebsd-update fetch' again reports that it still wants to remove the root directory: # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 10.1-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files will be removed as part of updating to 10.1-RELEASE-p2: / #
Occurs here as well.
Same story here, also from 10.1-RELEASE-p1 amd64 hosts. And if `freebsd-update fetch install` was called, the only way to cancel is to kill() it from another term?
Affects me too
No affecting me FreeBSD naked 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 22:51:51 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 sudo freebsd-update fetch Password: Looking up update.FreeBSD.org mirrors... none found. Fetching metadata signature for 10.1-RELEASE from update.FreeBSD.org... done. Fetching metadata index... done. Fetching 2 metadata patches.. done. Applying metadata patches... done. Inspecting system... done. Preparing to download files... done. Fetching 5 patches... done. Applying patches... done. The following files will be updated as part of updating to 10.1-RELEASE-p2: /bin/freebsd-version /usr/lib/private/libunbound.a /usr/lib/private/libunbound.so.5 /usr/lib/private/libunbound_p.a /usr/sbin/unbound jungle@naked:~ % sudo freebsd-update install Installing updates... done.
I have just tested this in a VirtualBox VM and it looks as if I am affected too: # freebsd-update fetch ... The following files will be updated as part of updating to 10.1-RELEASE-p2: /bin/freebsd-version /usr/lib/private/libunbound.a /usr/lib/private/libunbound.so.5 /usr/lib/private/libunbound_p.a /usr/sbin/unbound /usr/src/contrib/unbound/iterator/iterator.c /usr/src/contrib/unbound/iterator/iterator.h /usr/src/sys/conf/newvers.sh # freebsd-update install Installing updates...rmdir: ///: Is a directory done. However: # freebsd-version 10.1-RELEASE-p2 My conclusion: New files have been at least partly installed.
I try the command (freebsd-update fetch) again and i get this: Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 10.1-RELEASE from update6.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files will be removed as part of updating to 10.1-RELEASE-p2: /
(In reply to pvoigt from comment #6) > I have just tested this in a VirtualBox VM and it looks as if I am affected > too: > Was it amd64 or i386? Maybe you can test the opposite of what you previously tried to see what the results are.
(In reply to sf(jungleboogie) from comment #8) > (In reply to pvoigt from comment #6) > > I have just tested this in a VirtualBox VM and it looks as if I am affected > > too: > > > > Was it amd64 or i386? Maybe you can test the opposite of what you previously > tried to see what the results are. Well, I was on amd64.
I am seeing the same thing on amd64. Proceeding does install the updates (and removing / fails, thankfully) but it is definitely worrisome. Also of note--this update decided to install what looked like all of /lib32 on a host where this directory did not previously exist. In this instance I don't mind (in fact, I've wondered previously if there were a way to install new distribution sets using freebsd-update), but it was a surprise.
Same issue. a) it tries to install /usr/lib32/ which I don't need. b) tries to delete / system is a clean install of 10.1-REL that was updated to -p1 a few days ago. amd64 in this case.
See bug 195302 So my system (i386) is unaffected since I have the /usr/lib32/. Maybe the subject can be amended to clarify the architecture.
Same thing happens on my 10.1-p1, amd64 It proposes to first delete / and then install a bunch of /usr/lib32/. This is from "freebsd-update fetch" - I don't think I'll be running "freebsd-update install" until there is a resolution for this.
Same here while trying to update from 10.1-RELEASE-p1 amd64.
For those users who got /usr/lib32 and did not want it, has it been installed in the past, (say, on FreeBSD 10.0)?
(In reply to Harrison Grundy from comment #15) > For those users who got /usr/lib32 and did not want it, has it been > installed in the past, (say, on FreeBSD 10.0)? No. In the past the folder /usr/lib32 contains: /usr/lib32/dtrace: total 0 /usr/lib32/i18n: total 0 /usr/lib32/private: total 0
(In reply to Harrison Grundy from comment #15) > For those users who got /usr/lib32 and did not want it, has it been > installed in the past, (say, on FreeBSD 10.0)? The FreeBSD install I first experienced this on was installed at FreeBSD 10.1-RELEASE and had never had FreeBSD 10.0 installed. This is on an amd64 install.
Hi, all our x86_64 machines are affected , too. But none of our i386 machines is as far as i know. Is it possible to patch from 10.1-RELEASE to 10.1-RELEASE-p1 ?
It's worth noting that the update does not, in fact, delete /. Since I'm using lib32, I've run it on my machines here without any ill effects.
Passing this along from the mailing lists (Thanks, gavin) olli hauer <ohauer@gmx.de> writes: > Is there an issue with freebsd-update or an special reason the update > wants to install lib32? Yes. The freebsd-update distribution for 10.1 was incorrectly built without lib32; as a result, freebsd-update deletes lib32 when upgrading from older releases (see https://bugs.freebsd.org/195302). The only way to fix that was to reintroduce lib32 in the next patch release. Unfortunately, freebsd-update is not able to tell that a newly created file belongs to a distribution which is not installed or disabled in freebsd-update.conf. We decided that this was the lesser of two evils. I will make an announcement later regarding this and the "rm /" issue. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
I didn't see anything regarding this on this thread, but I wanted to add that the issue is affecting me as well, however, it also seems that after applying these patches, 'shutdown -r' no longer restarts, it will only shutdown.
# freebsd-update fetch Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 10.1-RELEASE from update3.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files will be removed as part of updating to 10.1-RELEASE-p2: / So, it will delete root directory after the reboot? What should I do to prevent it?
/ won't be deleted since it's a directory not a file. It's safe to ignore, just scary sounding.
*** Bug 196147 has been marked as a duplicate of this bug. ***
*** Bug 196091 has been marked as a duplicate of this bug. ***
Fixed by r276086 & FreeBSD-EN-14:13.freebsd-update