Our problem installing an old Ubuntu kernel set of packages

August 7, 2020

On Twitter, I said:

It has been '0' days since I've wound up hating Debian's choice to sign package metadata instead of packages (or perhaps 'in addition to' these days). Why? Because it makes it much more difficult to support 'install a package, satisfying dependencies from this directory of debs'.

Naturally there is a story here.

We have some Linux fileservers running Ubuntu, and we are very controlled about upgrading their kernel versions (partly because of mysterious crashes). We have a new kernel version that's proven on our test fileserver and our most recently build fileserver (which is itself a story), and we're looking at upgrading the other fileservers to that kernel. However, this kernel is not the most recent Ubuntu kernel; it's sufficiently old that it's no longer in the official Ubuntu package repositories.

We have our own local Ubuntu mirror, where we never delete packages, and it has all of the many linux-* packages and meta-packages required. However, we can't just do 'apt-get install linux-generic=...' and get all of those packages. Because these older Linux kernels aren't in the Ubuntu official package repositories, they're not in the official repository index files. Because these index files are signed, our mirror can't just rebuild them to reflect the full set of packages we have available. Although we have these files available on our mirror, we can't use them, at least not easily.

Similarly, I suspect this fundamental assumption of signed index files (or at least the existence of index files) is part of why I don't think any dpkg frontend has an option to just get packages and dependencies from a directory you supply. You can 'dpkg -i *.deb' for everything in a directory, but that requires you to carefully curate the directory to have absolutely everything required, and Ubuntu kernels come in a rather large number of packages.

(If there is a command line frontend that supports this, I would like to know about it. I don't count dropping .debs into /var/cache/apt/archives for apt, although I've read that it actually works.)

You don't really have this problem on RPM based systems like CentOS. Since all RPM packages themselves are signed, signed metadata isn't as important and tools like yum and dnf are generally happy to work with a pool of RPMs in a directory.

(Note that unsigned repository metadata opens you up to some attacks, so you definitely want to sign it if possible. It's also safe to generate your own local unsigned repository metadata, since you generally trust yourself.)

(See also my wish to be able to easily update the packages on an Ubuntu ISO image, which also runs into this issue.)

Comments on this page:

By Arnaud Gomes at 2020-08-07 03:03:16:

Debian itself has kind of solved this issue with the snapshot repos, which basically allow you to install packages from "the official repository as it was at this date". I don't know if Ubuntu has anything similar.

In fact this is so convenient we have begun creating our own snapshots system for the third-party repos we mirror. If you have a local mirror anyway, it's not much harder than making sure you keep a copy of old packages, and much more convenient.

 -- A
By dozzie at 2020-08-07 09:49:42:

Because these index files are signed, our mirror can't just rebuild them to reflect the full set of packages we have available

reprepro re-signs the metadata on mirror update/package pull (with your GPG key, of course). Though it doesn't support multiple versions of the same package in the release+component pair, so there's that.

Then, APT version from Debian 9 (Stretch) (or actually even a little earlier version) finally supports installing DEBs from local files, without making them a repository. It wasn't that widely announced, so I only learned it when Buster was stable for a few months.

By George at 2020-08-10 14:34:50:

You want aptly. You really, really want it. Aplty was designed for this specific task and you can make your own custom repo from other guys upstream.

By James (trs80) at 2020-08-31 13:10:12:

`apt install gdebi-core`

Written on 07 August 2020.
« My views on some conventions for Unix command line options
How we choose our time intervals in our Grafana dashboards »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Aug 7 00:00:03 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.