Ubuntu (do-release-upgrade) to 22.04, w/ existing and latest R4.3 deployments

apt info r-base

Package: r-base
Version: 4.3.0-1.2004.0
Priority: optional
Section: gnu-r
Maintainer: Dirk Eddelbuettel edd@debian.org
Installed-Size: 64.5 kB
Depends: r-base-core (>= 4.3.0-1.2004.0), r-recommended (= 4.3.0-1.2004.0)
Recommends: r-base-html, r-doc-html


lsb_release -a

Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal

Hi there,

I need a little help.
It's time for an OS upgrade of one of our Ubuntu Focal (LTS) server, for a year has been running successfully a R installation here, which we installed according to the official instructions.

With a lot of packages installed and needed, fine tuning, different databases connected (at least 20 of them). So my question, because I've read a lot of descriptions about this and they are not clear,
how to do this OS upgrade without the most pain, do I really have to reinstall the whole R?

Like this: sudo apt-get purge r-base r-recommended r-cran-, sudo apt autoremove

Do I have to do all the settings again and reinstall the packages?
Or is it sufficient to update the repos to "Jammy"?

Thank you for any possible guidance on this topic


Hi, @technocrat, you seem to be one of the most active members on this forum...
Can you give me some guidance on my question above?

Or perhaps another starting point or documentation (?) , THX :slight_smile:

Sorry I overlooked this.

If you are doing an in place rollover to jammy, there should be no effect on your existing R setup, including all the user-installed packages. That's how it works on my desktop and I can't think of a reason why it should work any differently on a server.

When nuking, however, there's the added complication of having to replicate the existing setup. A quick and dirty way is to do an inventory of installed packages, save as a vector use that

to_restore <- c("Hmisc", "ggplot2")

The problem is that for packages requiring compilation, it's interactive by default, so would have to be scripted.

As alternative is Dirk's {r2u} package which allows package management through apt to install binaries pre-compiled for Ubuntu so the entire process is only I/O bound. It's somewhat PITA-able to set up without paying close attention to fine details but it sure is fast and something that can be cron'd for update.packages(). I would definitely test drive it on a desktop or VM first, though, to make sure it's running for you ok.

Hope that helps.



1 Like

Hi Richard,

This is definitely orders of magnitude more information than I found online.
Thanks for the guidance :+1:.
What I first understood from your description is that, it's not a two-minute thing to update OS under a running R installation.

Before every major change I take a snapshot and if there's a problem I revert to the original image, and I do this at night so as not to disturb users.
(So don't look for me on Saturday night, because I went to work, :upside_down_face:)

Thanks and I'll get back to you if I have any questions.

@technocrat "Sorry I overlooked this."
no, nothing bad happened, ..... may be because first the Akismet has banned the post for a while, and then later became visible again


1 Like

Good luck. Cmon back if you get stuck.

Thanks again, with minor - major pain, but I got over this OS upgrade relatively easily.
"Jammy" is already roaring in the background :wink:

This topic was automatically closed 42 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.