Been using vi since the late 1980s, so let's assume I'm extremely familiar with it...

Whenever I try to paste now (yes, in insert mode) it first overwrites lines, then pastes part of the selection and sometimes it drops into spell check.

Nothing changed beyond unattended-upgrades doing it's thing.

Removed vi, vim, tried the gtk version, blank ~/.vimrc, no ~/.vimrc, same with all combinations of /etc/vim/vimrc

Removed bashrc, sourced /etc/profile, same...

Same in gnome-terminal and terminator...

Not sure what went wrong, anyone else having similar issues?

vim.gtk3 --version VIM - Vi IMproved 8.1 (2018 May 18, compiled Apr 15 2020 06:40:31) Included patches: 1-2269

Since it does this with blank vimrc files, when recreating it/installing different vims, I've left them blank.

Every other program -- even shell-based editors like pico -- are working.

SSH'ing in from other machines where vim works has the same error.

Update: this is the only 20.04 desktop I have. Bunches of 18.04 laptops/desktops/servers, no issues on them but ssh'ing in from any and the error recurs. Ssh'ing out... let's see... from 20.04 desktop -> ubuntu 18.04 server and 18.04 laptop, same error. So per the comments below, seems something in the gnome or x-windows system. I'm thinking an update overwriting a config file went bad? Not sure which configs in ~/.config/ I should look at? Any hints would be GREATLY appreciated!

  • 1
    The last change that occurred with vim in focal was dated Wed, 15 Apr 2020 16:40:31 +1000 so it's not a vim issue I bet (changelogs.ubuntu.com/changelogs/pool/main/v/vim/…). Currently is just guess work given no-changes to vim implies it's related to something else on your system we know nothing about; if this were on a bug report I'd look at what other packages are on your system but we've been provided none here knowing little about your system
    – guiverc
    Sep 20, 2021 at 0:33
  • 1
    There have been lots of package upgrades in September 2021. Review /var/log/apt/history.log to see what upgrades have reached your system this month. Due to Phased Upgrades, your upgrades may be different from mine (so your title is not particularly helpful).
    – user535733
    Sep 20, 2021 at 1:20
  • I agree with both and was scanning for gnome updates, but I'm not familiar with what would handle -- more correctly interfere with vim only -- clipboard pasting? Thank you both for answering so quickly, I really appreciate it! As it stands I'm pasting to the filesystem with the old << EOF >> and :r importing, super frustrating!
    – AJH
    Sep 20, 2021 at 1:49
  • @guiverc I believe that Linux changed the ioctl() C command due to security concerns. See the link in my answer below. I just ran into it today.
    – Nate T
    Sep 20, 2021 at 3:50
  • @NateT ; using a focal man page would have been better; ie. manpages.ubuntu.com/manpages/focal/man8/gpm.8.html
    – guiverc
    Sep 20, 2021 at 4:02

2 Answers 2


The issue:

Does this answer your question?
...3rd paragraph

It seems that Linux changed the permission level required to access the ioctl() function programmatically, because of "security issues related to copying entire pages.."? As i understand it,pretty much any app that used copy / paste used it via this function, so they all either stopped supporting copy /paste or else found a different implementation.

A workaround Ive been using for vim:

I pay attention to the amount of lines I need to paste. WHen I have my cursor on the line where the paste needs to start (in Normal Mode), I press [N]o where [N] is the number of lines I need cleared. At first, it only clears a single line and puts buffer into Insert Mode, but as soon as escape is pressed, the rest are cleared, and you land back into normal. All is as it was before the command, except for the [N]-line gap below the cursor.


Hitting 9o Esc will create a 9 space gap below the cursor that you can paste into.

It may seem a bit awkward for a day or two, but for me, once I got the hang of it, it felt as if it had always been this way..

  • gpm -- wow, there's a blast from the past! In my case, no, this didn't work... ...it still partially pastes and partially overwrites.
    – AJH
    Sep 20, 2021 at 13:56
  • How? I was suggesting to create a multiple blank lines where the pasted text would go before you paste. There shouldn't be anything to overwrite. Also what do you mean by "partially pastes." ? Mine just overwrites.
    – Nate T
    Sep 20, 2021 at 14:07
  • Let's say I copy your text above and paste it while in insert mode, it's randomly placing the insert not at the insert line -- somewhere below -- and it'd start with "o create a multiple..." and carry on to the end. So something is wrong with what's getting pasted out of the buffer and it's 1) Issuing commands to vim 2) starting the insert at a random spot (that's not after the first "i" character). It's super infuriating, but I solved it, well sort of went nuclear and it fixed itself, see below. Thank you though for the time!
    – AJH
    Sep 21, 2021 at 23:47
  • Glad it was resolved. Btw, have you seen the vim & vi SE yet? If not, check it out. You will enjoy it. Ill delete this once you've seen it.
    – Nate T
    Sep 22, 2021 at 1:28

Nothing was working.

So looking at the install history.log listed above and that vim hasn't changed for a while, I saw that gir1.2-clutter-1.0 was among the updates. I never looked at what the girl* programs do but apt-cache lists it as owning gsettings, so I figured something must've gone wrong after I updated to an NVME from a spinny HDD four months or so ago. Not in the update as things were fine for a while...

I have that old magnetic drive with a copy of ~ from before this happened, I just did the nuclear option of rm -rf ~/.config/ and sync'd the .config back from the hard drive and presto! No more problems, didn't even restart GDM3.

In hindsight I should've tar'd the faulty ~./config and made some config file diffs to find the actual problem, especially since you'all have been so helpful. So shame on me there, but it was super frustrating and I'm both behind on work and spent too much time messing with it.

Off-topic, but I've noticed "reboot" logs as an unsafe shutdown on the nvme, only halt, power off/on doesn't, so it may be I've used the nvme too hard or improperly, and something caused an improper write:

(root): df -h | grep nvme
/dev/nvme0n1p1          1.9T  406G  1.5T  22% /home/

(root): nvme smart-log /dev/nvme0n1p1
Smart Log for NVME device:nvme0n1p1 namespace-id:ffffffff
critical_warning                    : 0
temperature                         : 39 C
available_spare                     : 100%
available_spare_threshold           : 5%
percentage_used                     : 91%
power_cycles                        : 45
power_on_hours                      : 2,806
unsafe_shutdowns                    : 32
media_errors                        : 0
num_err_log_entries                 : 128

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.