Ubuntu DRAC – Ubuntu 20.04 Server Install Failing from Live CD

If the likelihood that the dependencies for the version of a package that is in the release of Ubuntu (or other Debian derived arrangements) is the same as the deps for the version you are trying to build, you could run apt-get build-dep nginx or aptitude build-dep nginx - this will not install the nginx package but will instead install all those listed as dependencies (and their dependencies, as usual) which includes libssl-dev (the package that you are currently looking for).

In most cases this will allow the build of the other (presumably newer) version to be completed successfully, and it saves you installing each library and its header files one by one yourself. Even if there are new dependencies in the other version you are trying to build, build-dep <package> is a good place to start as it means that you only have to manually install the extra new dependencies.

As an example, the result on one of my servers is:

user@host:~$ sudo aptitude build-dep nginx
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initialising package states... Done
The following NEW packages will be installed:
  autotools-dev cvs{a} debhelper gettext{a} html2text{a} intltool-debian{a}
  libcroco3{a} libmail-sendmail-perl{a} libpcre3-dev libpcrecpp0{a}
  libssl-dev libsys-hostname-long-perl{a} po-debconf{a} zlib1g-dev
0 packages upgraded, 14 newly installed, 0 to remove and 19 not upgraded.
Need to get 7,217kB of archives. After unpacking 22.9MB will be used.
Do you want to continue? [Y/n/?]

It is intending to install some libraries and headers, to enable an nginx build, but not nginx itself.

One thing to note is that if you are compiling your own copy because you want different build options rather than needing a different version for some reason, you may be better of compiling from the repository's source for the package rather than using the upstream sources directly. This SO question is the first useful page that came out of a quick search, though you are likely to find more detailed tutorials easily if you need that.

_{An other small thing to note: the packages installed as a result of apt-get build-dep will be marked as manually installed as if you have done this by hand as you are currently doing. That means you can't remove them all in one go (there is no apt-get unintall-dep or similar) - though that is no different from the situation you'll get from manual library/header installs anyway (I only mention the fact as some people expect there to be a one-step way to undo a build-dep operation, and there is not).}

I have downloaded files much larger than 1 GB (>100 GB even) through ftp, ssh, http and never encountered such a problem in such a consistent manner. But have observed and have been troubleshooting the occasional suspicious tcp-rst packets in other situations. A tcp-rst should not happen in a normal situation, it's almost always an abnormal event that deserves some healthy suspicion.

The fact it's so consistent and the connection is reset as opposed to properly closed is an indication something fishy is going on in my opinion. Firewalls and routers (badly configured ones, or just broken) can be doing that kinda thing. You could run tcpdump whilst such a download is happening and study the output.

My guess is that your ISP may be causing this, unwillingly perhaps due to a broken router or firewall.

At times I have been trying to find out about some mysterious tcp resets myself and used tcpdump for this:

I'd say, around the 980 MB mark, tcpdump everything to a file:

tcpdump -w name.dump -i any -nnvvXSs 65535 tcp port XXX

Then use tcpdump to find the reset packet(s):

tcpdump -nnvvXSs 65535 -r name.dump 'tcp[tcpflags] & tcp-rst != 0 and tcp[tcpflags] & tcp-ack != 0' and tcp port XXX

Then once again use tcpdump and grep to look around the timestamp for anything happening that might give a clue. The -A and -B options will output 200 lines before and after the grepped line.

tcpdump -nnvvXSs 65535 -r name.dump | grep -A 200 -B 200 "timestamp of tcp-rst packet"

Ar the servers where this happens using a different ISP? Or a separate router or firewall? Can you verify this does not happen on other servers that use the same ISP, router and firewall?