"freebsd-update fetch" stops at the editor vi

After upgrading 11.2 to 12.0 is problem:
Code:
sudo freebsd-update fetch
Password:
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 12.0-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
...skipping...
~
~
~
~
~
~
~
~
~
~
~
~
~
~
............
etc etc
Until I enter :q
No updates needed to update system to 12.0-RELEASE-p0
 
Last edited by a moderator:
After upgrading 11.2 to 12.0 is problem

Did you do all the necessary commands and in the right order?

See for example https://www.cyberciti.biz/open-source/freebsd-12-released-here-is-how-to-upgrade-freebsd/"> for all consequetive steps -- e.g. freebsd-update install has to be repeated several times.

The vi-like output could be an incidental mix-up with the setting in your shell's rc file, as I noticed sometimes under 11.2. Just check if you properly escaped the builtin vi(1) command line editor # set -o vi
 
Did you do all the necessary commands and in the right order?

See for example https://www.cyberciti.biz/open-source/freebsd-12-released-here-is-how-to-upgrade-freebsd/"> for all consequetive steps -- e.g. freebsd-update install has to be repeated several times.

The vi-like output could be an incidental mix-up with the setting in your shell's rc file, as I noticed sometimes under 11.2. Just check if you properly escaped the builtin vi(1) command line editor # set -o vi
I did everything right. I don’t use vi at all and answered :q all its proposal during upgrading (for example change file mailer.conf)
 
I get the same error running # freebsd-update fetch. It goes through the first step without any problems but when I press the down arrow key to see if anything has been downloaded I get the same thing as OP and had to use :q to get back to the command line. No other key combo worked for me.

This on a fresh build and first time running it.

It's a bug of some sort. When running ports-mgmt/portmaster to install security/wipe and security/rkhunter I had to do the same thing to get back to the command line.
 
I did everything right. I don’t use vi at all and answered :q all its proposal during upgrading (for example change file mailer.conf)

The upgrade forces you to review the file in question -- as far as I can remember, when prompted any keystroke opens vi / vim to review and change the conf file (so you leave the shell, and enter the editor). when in vi / vim, the only way to quit indeed is :q. vi is basic infrastructure to make such changes.

I don't know if the upgrade also forces to make the proposed changes, and refuses to take a 'no' for an answer. Last days was the first time I did such upgrade for the first time...
 
I just had ports-mgmt/portmaster successfully build x11-fm/xfe. At the end of the build I was presented with this screen:

xfe01.png

To get from that screen back to the command line:

xfe02.png

I had to use the :q command. I built x11-wm/fluxbox right before it and things went normally.

It's the same error I got before with wipe and rkhunter, the only difference being with rkhunter the colon symbol was already present. All I had to do was press q to get back to the command line. This behavior with the colon presented itself again at the end of the build for graphics/epdfview:

epdfview01.png
epdfview02.png
epdfview03.png

This is not normal behavior for using portmaster, is not consistent in happening every time and not something I've had to do before FreeBSD 12.
 
I think it's a bug and I have to wait for patches.For 3 years I have been consistently upgrading on the same server from 10.2 to 12.0 and so far there has been no such error in any version
 
I never upgrade. I've always done a new build for every version or version bump and have always used ports.

I successfully got it up and running but will probably wait before doing any others.
 
Today freebsd-update hangs for a long time and then gives the same message. In general, 12.0 at this stage is the worst release since 10.0
 
It seems to me that it is necessary to work on the 11th and wait for the 13th release, the 12th will be unsuccessful as Vista in the windows: from the very beginning, serious failures in freebsd-update and in pkg upgrade
 
I agree. Right now, I am trying to roll back by rebuilding everything from 11.2 sources. I do not trust freebsd-update to make a proper rollback.
 
So to confirm, this is after the upgrade, and the upgrade went smoothly?

Is the required key combination
Code:
:q<ENTER>

Or simply
Code:
:q

The default PAGER for 12.0-RELEASE has been changed from more(1) to less(1) (can't find any documentation other than a reply to this tweet, and I can see that reflected on my own boxes), so I wonder if it's the latter your seeing the colon is a red herring and actually it's just the 'q' quitting out? If that works you could set your PAGER back to more(1) to restore original behavior.

Not saying that you don't have an issue, but I've got two boxes here (one went from 11.2-RELEASE-p6 to 12.0-RELEASE, the other went from 11.2-RELEASE-p5 (think) to 12.0-BETA2, then jumped each -BETA and -RC to 12.0-RELEASE) which don't have these issues. Then again, I've only done fairly standard ZFS installations, binary updates with freebsd-update(8), and all of my packages are stock from the FreeBSD repository.
 
So, to wrap up. I did a fresh install of a FreeBSD 12.0-RELEASE. After completing the installation I run feebsd-update fetch
Code:
root@freebsd12:~ # freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching public key from update4.freebsd.org... done.
Fetching metadata signature for 12.0-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
At this point I was left in a less empty file where I had to type q
Code:
No updates needed to update system to 12.0-RELEASE-p0.

Given the fact that more has been changed by less I believe the behaviour is expected.
 
There is no bug. You're not "stuck" in vi(1). You're at the end of output that's paged through less(1) (less(1) actually understands a number of vi(1) commands, which is why ":q" works).
 
then let's call it a blunder. Does it change anything?Where is the guarantee that these errors at the very beginning do not form something like an avalanche of errors afterwards?I understand that no one is going to correct this error.It reminds me very much CentOS 6.0. Until CentOS 6.2 appeared it was impossible to work
 
then let's call it a blunder. Does it change anything?Where is the guarantee that these errors at the very beginning do not form something like an avalanche of errors afterwards?I understand that no one is going to correct this error.It reminds me very much CentOS 6.0. Until CentOS 6.2 appeared it was impossible to work

What errors are you referring to?
 
Yes. It used to do this before. You would have seen an empty screen with END at the end of it I think and then pressed enter. Nothing has changed in this respect. There is though an argument that if the file that is being paged is empty that it should just continue and not open the pager?
 
Back
Top