freebsd-update says "No such file or directory" for every file

P

phantomflash

Have 9.3-RELEASE-p20 and wanting to update to latest 9.3. (Saving version 10.x for somewhat later -- trying to keep it "simple and quick" for now.) First I run this:

Code: 
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 9.3-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/etc/ntp.conf

The following files will be added as part of updating to 9.3-RELEASE-p39:
/usr/src/contrib/ntp/html/drivers/driver40-ja.html
/usr/src/contrib/ntp/html/drivers/driver45.html
/usr/src/contrib/ntp/html/drivers/driver46.html
/usr/src/contrib/ntp/html/drivers/mx4200data.html
/usr/src/contrib/ntp/html/scripts/accopt.txt

         ...  (171 files in total)

Then I run this and get these errors:
Code: 
# freebsd-update install
Installing updates...install: ///usr/src/contrib/ntp/html/drivers/driver40-ja.html: No such file or directory
install: ///usr/src/contrib/ntp/html/drivers/driver45.html: No such file or directory
install: ///usr/src/contrib/ntp/html/drivers/driver46.html: No such file or directory
install: ///usr/src/contrib/ntp/html/drivers/mx4200data.html: No such file or directory
install: ///usr/src/contrib/ntp/html/scripts/accopt.txt: No such file or directory

  ...  (171 files in total)

I only use bsd to update this system a small number of times a year, and almost every time something goes wrong, but I've made a bunch of notes and found a sequence of commands that seems to work -- and this is a new one on me. Why am I getting all these "No such file or directory" errors, and how to fix? I've done some searching but found nothing that appears relevant. I've already updated the ports using portsnap and portupgrade, which I've learned it seems to help to do first.
 
SirDice said:
By default freebsd-update(8) also updates the sources in /usr/src/. Which you don't have. Hence the errors. You can either populate /usr/src/ or disable updating of the source in freebsd-update.conf(5).
Click to expand...
OK, well, I guess the choice would basically depend on which one would cause fewer problems going forward, in future updates. I don't remember anything like this problem when I updated from 8.4 to 9.3 last year, nor before that in a minor update within the 8.4 version, so it appears perhaps that either the default changed in 9.3, or something strange happened in that process to get rid of sources. (Most, anyway - there are a couple of subdirectories there.)

So which choice would be less likely to cause problems in the future? I don't like diverging from defaults (without a good reason), but I also don't like things going wrong.

And, if it's better to populate those sources, how would that be done?
 
phantomflash said:
So which choice would be less likely to cause problems in the future? I don't like diverging from defaults (without a good reason), but I also don't like things going wrong.
Click to expand...
If you don't build the base system yourself, it's unlikely you will need /usr/src. The only case I can think of right now is building a port that builds a kernel module. Maybe some ports need the sources for other reasons. But if you ever happen to need them, you can always get them using subversion. So I wouldn't worry about that now and just go without, you'll notice when you happen to need them.
 
Zirias said:
If you don't build the base system yourself, it's unlikely you will need /usr/src. The only case I can think of right now is building a port that builds a kernel module. Maybe some ports need the sources for other reasons. But if you ever happen to need them, you can always get them using subversion. So I wouldn't worry about that now and just go without, you'll notice when you happen to need them.
Click to expand...
OK, I decided to try omitting sources. I commented out src from the Components line of /etc/freebsd-update.conf, and re-ran the procedures. I got this:

Code: 
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 9.3-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/etc/ntp.conf

No updates needed to update system to 9.3-RELEASE-p39.



# freebsd-update install
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.


#uname -a
FreeBSD secure.stenocall.com 9.3-RELEASE-p20 FreeBSD 9.3-RELEASE-p20 #0: Tue Jul 21 19:54:53 UTC 2015  root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64


(... then, after reboot ...)


# uname -a
FreeBSD secure.stenocall.com 9.3-RELEASE-p39 FreeBSD 9.3-RELEASE-p39 #0: Wed Mar 16 16:29:56 UTC 2016  root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

But it ran quickly and didn't appear to do anything. And more to the point, apache hasn't been updated, which is the main reason for doing this. The "standalone" copy of openssl, the one in the ports, was updated when I did all the ports, but apache, since it's not in the ports but in the base system, is still unchanged and using the older copy of openssl built into it.

So I'm not sure if I made the wrong change in freebsd-update.conf, or if something else is wrong.

I just don't understand why the process went smoothly the last two times I did it, updating apache without significant hassles, but not this time. Of course the last two updates were run starting in 8.4, and maybe now something is changed in 9.3, but if it is I haven't read any documentation to that effect.
 
phantomflash said:
But it ran quickly and didn't appear to do anything. And more to the point, apache hasn't been updated, which is the main reason for doing this. The "standalone" copy of openssl, the one in the ports, was updated when I did all the ports, but apache, since it's not in the ports but in the base system, is still unchanged and using the older copy of openssl built into it.
Click to expand...
Zirias said:
Huh? apache is not part of base. Was it in earlier releases?
Click to expand...
No, Apache never was part of the base and never will be.
 
Now, wait. A year or two ago, I did read in some documentation somewhere on the Web that it was formerly in the ports, but now was in the base system. Before that, I had tried various things to get it up to update, with only spotty success. But when I read about the difference between ports and base, and that Apache was in the base, I started including base system updates in my procedures to update Apache. Since then I haven't had trouble updating it. Until now that is.

As I mentioned earlier, I already updated all the ports. It was a long procedure, even including some dialogs. But Apache was not updated (even though the standalone openssl, as opposed to the one built into Apache, was).

(In fact I ran portsnap once and portupgrade twice, before doing the base system update. The 2nd run of portupgrade is the one that ran really long. I've developed this procedure over the years because earlier, simpler versions didn't give good results.)

But that was a sort of side comment. Getting back to the original questions of my last post, I was concerned that (1) the base update ran so quickly without seeming to do anything, and that (2) despite everything I've done, Apache is still not updated.
 
After more research, and several interruptions, I'm back to this project. First of all, I can't find where it was, that told me Apache had been moved from the ports to the base system, even though it's in my notes written sometime between 1 and 2 years ago. Now, I have found other sources that say it is in the ports. I don't know who or what told me it wasn't, but somebody or something did, at one time.

So I've come full circle, from first trying ports, then trying the base system, and now back to ports. Still unexplained is why I had so much trouble updating Apache when I only ran the port-updating functions, and why the process only got reliable when I started updating the base system.

Since my last post I re-ran portsnap and portupgrade (telling it to update all ports), and Apache still wasn't updated. Examining the logs more closely, there was a message about Apache being skipped because the system was running the wrong version of Perl. Still unexplained is why the "update all ports" process didn't update Perl! There didn't seem to be any messages I could see that spoke to this.

But instead of pursuing that trail, about that time I stumbled onto some documentation about updating binaries (packages) instead of sources (ports). This sounded more convenient, not to mention I was pretty sure that a binary update of Apache wouldn't care a whit about Perl. Sure enough, I tried it and without much ado, Apache was updated.

So that solves the original task. But I still have the outstanding questions about the base system update, which I asked twice already in this thread, and then I happened to mention Apache and ports, which took the replies in another direction. I'm happy that led to a good place, but it did leave the other question hanging. So to get back to it:

When the base system update was repeatedly saying "No such file or directory" (related to sources), I was advised to "disable updating of the source in freebsd-update.conf". I interpreted that as completely commenting out src from the Components line of that file. When I re-ran the base update, this led to the messages listed in my earlier post, including "No updates needed to update system to 9.3-RELEASE-p39" and "No updates are available to install."

So the question is, did I eliminate too much? Did I misinterpret the answer? If so, what should I have done instead? Or if not, why did it say "No updates?" Does it, perchance, mean that it already, in the first run, did all the base system updates except for those source files?
 
phantomflash said:
After more research, and several interruptions, I'm back to this project. First of all, I can't find where it was, that told me Apache had been moved from the ports to the base system, even though it's in my notes written sometime between 1 and 2 years ago. Now, I have found other sources that say it is in the ports. I don't know who or what told me it wasn't, but somebody or something did, at one time.
Click to expand...
You may be confused with OpenBSD. I do believe, at some point, it had Apache in it's base OS.

Does it, perchance, mean that it already, in the first run, did all the base system updates except for those source files?
Click to expand...
Yep, indeed it did. The update doesn't fail if the files in /usr/src/ aren't there. It just produces a lot of noise. But the update will have been applied nonetheless.
 
OK, thanks -- I really appreciate the information.

Now, there is another question that's been nagging at my mind the last couple of days. Recall that the original messages said

Code: 
The following files will be added as part of updating to 9.3-RELEASE-p39:
/usr/src/contrib/ntp/html/drivers/driver40-ja.html
/usr/src/contrib/ntp/html/drivers/driver45.html
   ... etc.
And then the errors said

Code: 
install: ///usr/src/contrib/ntp/html/drivers/driver40-ja.html: No such file or directory
install: ///usr/src/contrib/ntp/html/drivers/driver45.html: No such file or directory
install: ///usr/src/contrib/ntp/html/drivers/driver46.html: No such file or directory
  ... etc.
So question (1) is: since it said those files "will be added," then why should it care if they weren't there? Why didn't it just add them, as it said it was going to?

The message does say "file or directory," so I looked at the directories. There are only two in /usr/src/contrib, and one of them is ntp/. (I believe I recall installing it at some time in the past.) So for ntp at least it would seem there should be no errors. But in fact the first several errors in the list reference the ntp/ directory tree.

Looking further down, /usr/src/contrib/ntp/html/ does exist, but /usr/src/contrib/ntp/html/drivers/ does not. But there are many other files and directories in that tree, and almost all of them have dates of April 25 of this year, which is when I started doing these updates -- so it appears the procedure created all of them at that time. So we have these additional questions:

(2) Is it really that picky, that it needs that last drivers/ directory to already be there?
(3) Why didn't it just create it, as it appears to have done with all the other subdirectories in the ntp/ tree?
 
phantomflash said:
(2) Is it really that picky, that it needs that last drivers/ directory to already be there?
Click to expand...
Yes, the whole directory structure needs to exist. It's really that picky about it.

(3) Why didn't it just create it, as it appears to have done with all the other subdirectories in the ntp/ tree?
Click to expand...
Those subdirectories have likely been created by hand. Probably because of similar errors while updating in the past.
 
SirDice said:
Yes, the whole directory structure needs to exist. It's really that picky about it.
Click to expand...
Well, I've updated the base system at least twice before, and never recall this problem. So it seems all those directories must have been there at one time. How would they have gotten deleted? Does, for instance, updating across a major version number, like jumping from 8.4 to 9.3, get rid of them?
Those subdirectories have likely been created by hand. Probably because of similar errors while updating in the past.
Click to expand...
If I were only that fast ... :) No, I didn't create 1,014 directories and files, by hand, within one minute (12:31 PM on April 25). That had to've been done by the update procedure. Or more precisely, the directory tree was originally created on or before the day I installed ntp, which according to an older file I found, seems to have been March 15, 2015. Then the April 25, 2016 date of all these files and directories must have been set when I started running updates (the same one that gave me all the errors of files and/or directories "not found").

I mean, how in the world can this scenario fail? I install a program, it installs and runs correctly for over a year, and then the standard means of updating the same program can't finish properly? That doesn't make any sense. What if the new version has new files and/or directories not appearing in the older version? They have to be created by the update process. Who else is going to create them?

In fact, while checking those dates, I noticed that the currently running ntpd is the same date - so it has been updated - it's now version 4.2.8p6.

And now, after thinking about this a little more, it occurs to me - I thought ntp was a port? Sure enough, I have now looked it up and the latest version is 4.2.8p7 (it was updated on April 27, just 2 days after my file dates). So April 25 must have been when I updated my ports, not when I was updating the base system, which occurred later.

So the base system update isn't related to ntp anyway, because it's a port. Then why is the base system update worrying about it? Why's it trying to update its files, and complaining about ostensibly missing things?
 
FreeBSD has an NTP implementation in the base and you can install a different one from ports. They're both named the same but are in fact different.
 
Hmm, well, that may be, but it doesn't really answer any of the questions. Here are the ntp's I have:
Code: 
# whereis ntp
ntp: /usr/src/usr.sbin/ntp

# whereis ntpd
ntpd: /usr/sbin/ntpd /usr/share/man/man8/ntpd.8.gz /usr/src/contrib/ntp/scripts/rc/ntpd


# dir -d usr.sbin/ntp
drwxr-xr-x  4 root  wheel  512 Apr 25 13:31 usr.sbin/ntp

# dir /usr/sbin/ntpd
-r-xr-xr-x  1 root  wheel  746528 Apr 25 13:31 /usr/sbin/ntpd

# dir /usr/share/man/man8/ntpd.8.gz
-r--r--r--  1 root  wheel  10438 Apr 25 13:31 /usr/share/man/man8/ntpd.8.gz

# dir /usr/src/contrib/ntp/scripts/rc/ntpd
-rw-r--r--  1 root  wheel  1819 Apr 25 13:31 /usr/src/contrib/ntp/scripts/rc/ntpd
As you can see they all have the same timestamp.

I am fairly well convinced this is the port, because (1) I think I remember it wasn't on the system last year, and I had to install it; and (2) the ntp version on my system is identical to the version of the port that existed on April 25. (Presumably whatever non-port ntp there may be, since you said it was different, has a different version number.)

But the point is, either this is a port, in which case, why is the base system update trying to mess with it? Or it's not a port, in which case, why can't the base system update (whose job it is to update it), update it?

And of course the other questions from my last post are also still outstanding.
 
No no and no, that's not the port. Its source is at /usr/src/*[/FILE] and it's installed in the base system at /usr/sbin. Ports (the "recipes" to build them) are located at /usr/ports and they are with very few exceptions (I think very close to zero by now) installed under ${LOCALBASE} that defaults to /usr/local.

If it is not updated by freebsd-update(8) when it should be there's something wrong with your system.
 
(Finally getting rid of interruptions and having time to get back to this ...)

SirDice said:
FreeBSD has an NTP implementation in the base and you can install a different one from ports. They're both named the same but are in fact different.
Click to expand...
Well, if this one is not the port, then the base system flavor and the port flavor can't be very different, considering they have the identical version number.

kpa said:
If it is not updated by freebsd-update(8) when it should be there's something wrong with your system.
Click to expand...
Well, I was hoping for a something a little more specific than "there's something wrong with your system." Everything was fine in 8.4. All I did was update it to 9.3. So what might have changed?

SirDice said:
Yes, the whole directory structure needs to exist. It's really that picky about it.
Click to expand...
Now think about what you've said. You're saying if version N of any subsystem has even just one more directory than version N-1, then the update won't work? That doesn't make sense at all. Of course updates are going to be adding files, and/or directories, from time to time.

And remember my other point: Since it said those files "will be added," then it shouldn't care at all if they weren't there. It should just ... you know ... add them, like it said it would.
 
You must log in or register to reply here.
Back
Top