While I appreciate the clarification for those who did not understand what pro is or what the messages in apt were originating from, I feel this clarification is only the first step. The next goal should be to remove the advertisement from apt completely. I agree with the commercial Pro subscription service and the effort Canonical is putting into keeping these packages updated on their dime. And I hope it’s a good source of incoming to pay for that service.
But advertising a commercial subscription as part of a critical update tool in maintaining infrastructure is not the right place to do it. Users and admins have an expectation of trust, reliability and output from doing updates. Showing updates to the end user that they can’t install because they are not willing or able to pay for a commercial subscription(regardless of who qualifies for a free subscription) breaks that trust and reliability in the apt update system. I’m sorry, but leaving it up to the user/admin to manually delete the advertisement across 3 or 3000 devices is not an adequate solution. Unfortunately, I do not have a better place to display these advertisements. At the very least, a delineation between pro updates and regular updates would be better than the current state. As an example, phased updates and other updates held back for different reasons are mixed in with the commercial subscription updates with no way to tell the apart and which ones are available to install without the commercial subscription. This would break automation and reporting.
I wasted my entire morning trying to unconfigure the ESM messages that are displayed at each login over and over again.
The messages that I want to stop from appearing are:
Expanded Security Maintenance for Applications is not enabled.
Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
I followed the hints, that I read in
The official documentation led me to:
How are the APT messages generated?
`apt-esm-hook` and `apt-esm-json-hook` in config file: `/etc/apt/apt.conf.d/20apt-esm-hook.conf`
We have two distinct apt hooks that allow us to deliver these messages when you run apt upgrade or apt dist-upgrade. They are:
apt-esm-hook
Responsible for populating templates with accurate package counts (i.e. the package count we see on the Expired contract messages). However, the messaging here is created by two distinct steps:
- Our update_messages timer job creates templates for the APT messages this hook will deliver. We cannot create the full message on the timer job, because we need the accurate package names and count. This information can only be obtained when running the
aptcommand.
Note
These templates will only be produced if certain conditions are met. For example, we only produce “expired contract” templates if the contracts are indeed expired.
- When you run either
apt upgradeorapt dist-upgrade, the hook searches for these templates and if they exist, they are populated with the correctaptcontent and delivered to the user.
apt-esm-json-hook
The JSON hook is responsible for delivering the rest of the message we have presented here. This hook is used to inject the message in the exact place we want, so we need to use a specific apt JSON hook to communicate with it.
Note
Those hooks are only delivered on LTS releases. This is because the hooks will not deliver useful messages on non-LTS due to lack of support for ESM services.
How are APT configured to deliver those messages?
We currently ship the package the 20apt-esm-hook.conf configuration that configures both the basic apt hooks to call our apt-esm-hook binary, and also the json API of apt to call our apt-esm-json-hook binary.
So I did just that, I commented out the two hooks.
Commented out hooks in file: `20apt-esm-hook.conf`
$ cat /etc/apt/apt.conf.d/20apt-esm-hook.conf
APT::Update::Pre-Invoke {
“[ ! -e /run/systemd/system ] || [ $(id -u) -ne 0 ] || systemctl start --no-block apt-news.service esm-cache.service || true”;
};
APT::Update::Post-Invoke-Stats {
# Disable ESM messages
# “[ ! -f /usr/lib/ubuntu-advantage/apt-esm-hook ] || /usr/lib/ubuntu-advantage/apt-esm-hook || true”;
};
binary::apt::AptCli::Hooks::Upgrade {
# Disable ESM messages
# “[ ! -f /usr/lib/ubuntu-advantage/apt-esm-json-hook ] || /usr/lib/ubuntu-advantage/apt-esm-json-hook || true”;
};
I rebooter and low and behold,…
Nothing changed
I’ve tested this on a headless Raspberry Pi running: Ubuntu Server 22.04.2 LTS (GNU/Linux 5.15.0-1026-raspi armv7l)
Some helpful tips for people wanting to try for themselves what I did.
The annoying messages are generated as part of the dynamic motd generation (update-motd package).
This service executes /etc/update-motd.d/90-updates-available.
You can test generation of the MOTD scripts with:
$ sudo run-parts /etc/update-motd.d/
On its turn motd.d shows a cached result.
That result was generated by update-notifier and cached in:
“/var/lib/update-notifier/updates-available”
by python script:
/usr/lib/update-notifier/apt_check.py
One can force the generation of the file by doing:
$ sudo /usr/lib/update-notifier/update-motd-updates-available --force
Verify removal of esm apt config with:
$ apt-config dump|grep esm
How can one elegantly unconfigure the messages from appearing at each login?
Hi @Marty
There are two places where pro related messaging happens:
You found and followed the documentation for apt related messages and then rightfully wondered why it didn’t change anything. Well, as you found by now it most likely did change things, but not in the MOTD at login that you were looking at.
It is worth to note that there has already been an effort to make it possible to - as you call it - “elegantly unconfigure” those.
Following the doc on “disable apt news” would give you a way that is way nicer and easier than modifying config files.
But back to the login messages, as I said (and you found by now) there are those two places.
You have debugged your way to find the same as documented, the motd page also documents that it is generated by apt_check.py of update-notifier.
And you are right - currently it is burdensome to disable those MOTD messages if someone wants to.
We are indeed already intending to make this messaging more easily configurable as well.
But due to being intertwined with update-notifier it is more complex to do that and therefore will take a while.
FYI there is a similar discussion happening in this issue leading to - just like your suggestion - backing our intend to work on this, hopefully allowing to tackle that more sooner than later.
While things were tracked internally already I furthermore filed this issue to ensure when we tackle it we will cover it all at once - thanks for your input @Marty!
While things were tracked internally already I furthermore filed this issue to ensure when we tackle it we will cover it all at once - thanks for your input @Marty!
While I can not yet do it all (like splitting update-notifier from pro/esm takes time) I’ve given it a try to (hopefully) better document how it works and how you would disable the different related messaging selectively. Feel free to have a look and chime in at https://github.com/canonical/ubuntu-pro-client/pull/2534
@ paelzer
Thanks for your reply and thanks for creating an issue report, but I’m missing the /etc/update-motd.d/90-updates-available inserting ESM messages that can’t be configured off.
It’s the repeating nature of the login messages and waste of screen real-estate that they consume, that gets increasingly annoying. After logging in for the 100th time we know already that ESM has not been activated. The messages become more annoying than informative each time they are repeated.
That said, I had another look at all the links and the document you worked on. Thanks for the effort.
Unfortunately your document doesn’t show a way to disable the messages that I described. It merely states:
If you want to disable any message of update-notifier (not just related to Ubuntu Pro and ESM) about potentially available updates remove
/etc/update-motd.d/90-updates-available.
I do want to be notified about updates, but I don’t want the superfluous ESM notices being repeated over and over again. So I can’t remove /etc/update-motd.d/90-updates-available for I will lose available update notifications too.
What boggles my mind is, why doesn’t /usr/lib/update-notifier/apt-check adhere to the apt cofiguration in /etc/apt/apt.conf.d/20apt-esm-hook.conf?
Why does /usr/lib/update-notifier/apt-check keep inserting the ESM messages:
In the end it is apt that generates the information and the apt-esm-hook and apt-esm-json-hook in the apt config file: /etc/apt/apt.conf.d/20apt-esm-hook.conf are commented out. So why is this ignored?
I came to the conclusion that the messages can’t be configured off and will be repeated mandatory. They will only disappear when you give into an ESM / Pro subscription.
[quote=“Marty, post:5, topic:34051”]
… but I’m missing the /etc/update-motd.d/90-updates-available inserting ESM messages that can’t be configured off. [/quote]
As my PR linked from that issue shows, right now, you can only disable all or nothing of the info of 90-updates-available. That will include update info due to packages available in the Ubuntu archive as well as those available through ESM.
To split the remaining message further so that you can disable one, but not the other needs more than just config or documentation. It is a proper feature request that we already filed out of this and other discussions at https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/2015420
This will need development in the pro client as well as update-notifier and won’t complete asap, the work on it will happen, but doesn’t fit in the near term plan yet.
You might want to subscribe there to be notified when it is available?
As it seems the problem won’t be solved in the near term. I’m thinking about pragmatically giving into a free personal Ubuntu pro subscription to make the messages go away, but then I read the following:
As I stated above, I’m running:
So now all of a sudden an important legal issue lurks beneath:
What qualifies as a “non-desktop” use case?
I’m running an old 32 bit headless Raspberry Pi 2 with Ubuntu Server (a minimal installation) for personal use.
Is that a “non-desktop” use case? (Running a full fledged desktop on an RPi 2 is very heavy, it swamps the little computer making it useless.)
How can I find out if my setup is a “non-desktop” use case?
I tried commands: lsb_release -a, uname -a and pro status (see outputs below), but none give me any helpful information about determining if this is a non-desktop use case.
lsb_release -a
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Codename: jammy
uname -a
$ uname -a
Linux bug 5.15.0-1026-raspi #28-Ubuntu SMP PREEMPT Fri Mar 10 14:33:39 UTC 2023 armv7l armv7l armv7l GNU/Linux
pro status
$ pro status
SERVICE AVAILABLE DESCRIPTION
esm-apps yes Expanded Security Maintenance for Applications
esm-infra yes Expanded Security Maintenance for Infrastructure
livepatch yes Canonical Livepatch service
realtime-kernel yes Ubuntu kernel with PREEMPT_RT patches integrated
This machine is not attached to an Ubuntu Pro subscription.
See https://ubuntu.com/pro
What commands do I have to enter in order to find out?
What if I might decide to install a little web server later on, will I suddenly be in breach of contract and liable for whatever?
Will Canonical be surveilling my system remotely?
Why would you care? This is about paid support.
The free subscription can be used on desktops as well as VMs, cloud instances or personal servers likewise as long as it does not exceed 5 installs (or 50 installs if you are an Ubuntu member)…
What qualifies as a “non-desktop” use case?
The exact definition of that is always hard and I’d refer to @Lech to answer that. Maybe we can use some insights of that clarification eventually to also put it into the FAQ?
Will Canonical be surveilling my system remotely?
No, there is no “check exactly what you do” functionality
@ogra Thanks for your reply. I took on the great offer for a free pro subscription for my Raspberry Pi (RPi) running Ubuntu Server 22.04 LTS.
But now that I’ve connected my RPi to Ubuntu Pro, I get the following disappointing notification:
No Ubuntu Pro services are available to this system.
$ pro status
No Ubuntu Pro services are available to this system.
For a list of all Ubuntu Pro services, run 'pro status --all'
Enable services with: pro enable <service>
Account: XXXXXXXXXXXXXXXXX
Subscription: Ubuntu Pro - free personal subscription
Whereas previously before connecting the RPi to pro, the pro advertisements in apt kept nagging me about how I was missing security fixes. Pro status said that support was available for:
What has happened here?
Did Ubuntu drop RPi support in the mean time?
Were the advertisements wrong?
I stumbled upon another victim of the false update messaging over here.
Hi @Marty
Sorry, I’m late to the conversation here, and sorry nobody has noticed this yet, but Pro only supports some architectures, and I don’t think the Raspberry Pi 2’s architecture is on the list. For reference, the supported architectures are listed on this page down under the heading “What’s covered?”
Relevant to this case:
ESM on 22.04: amd64, arm64, s390x, ppc64el, RISC-V
Livepatch on 22.04: amd64, s390x
I think the Raspberry Pi 2’s architecture is “armhf” and you can confirm by running dpkg --print-architecture on your Pi.
That means there must be a bug in the pro tool that shows messages about availability and potential ESM updates. Can you share what version of pro you have by running pro version?
I think I have an old pi with that architecture too, so I’ll also try to recreate this issue myself.
Better news on the topic of MOTD ESM messages. We are working on adding a way to disable the MOTD ESM update messages for informed admins who are willing to edit a conffile. It is still in progress, but you can see some more details at the launchpad bug: Bug #2015420 “motd: can't disable esm-related messages” : Bugs : update-notifier package : Ubuntu
Hi @grant.orndorff,
Thanks for you reply. Nice of you to drop in.
You’re correct, I’m running an RPi 2. The somewhat older models consume less power, which is excellent for an always on home server use-case compared to the newer ones, that also require active cooling. The RPi 2 is the sweet spot for performance vs. power drainage for my use.
BTW the previous incarnation of my home server was a rock solid RPi B+ with Raspbian (Debian 7 Wheezy), which reached a maximum uptime of 2116 days, which is 5,8 years. Without a reboot! Then mains power seems to have been interrupted by the power company. Which seemed a good moment to do a hardware and OS upgrade. 
Here are the answers to your questions:
$ dpkg --print-architecture
armhf
$ arch
armv7l
$ pro version
30~22.04
Here are some specs of my RPi 2, which will remain in production until January 2026 at least.
Raspberry Pi 2 Model B Rev 1.1 (a01041 Sony, UK) hardware specs:
Broadcom. BCM2836 processor
A 900MHz quad-core ARM Cortex-A7 CPU (32 bit)
1GB RAM
OS Release info:
Ubuntu Server (32bit, armhf, raspi): 22.04.2 LTS Jammy Jellyfish (EOL: April 2027)
based on: Debian 12 bookworm (EOL: ~ Aug 2026, LTS: ~ Aug 2028)
Thanks for your heads up on bug #2015420.
Thank you for confirming those details!
I booted up 22.04 on a Raspberry Pi 3B+, which is also armhf, to see if I could recreate the problems.
MOTD did show:
Expanded Security Maintenance for Applications is not enabled.
Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
So that is an issue and I just reported it as a bug in update-notifier here: Bug #2052546 “ESM banner shown on unsupported architectures” : Bugs : update-notifier package : Ubuntu
However when I ran pro status on my RPI before connecting it to Pro, it correctly said:
No Ubuntu Pro services are available to this system.
For a list of all Ubuntu Pro services, run 'pro status --all'
This machine is not attached to an Ubuntu Pro subscription.
See https://ubuntu.com/pro
Supported livepatch kernels are listed here: https://ubuntu.com/security/livepatch/docs/kernels
So I was not able to reproduce the issue of pro saying services were available when they were not. It is possible that this bug affected an earlier version of pro and it has been fixed since you saw it.
Hi @grant.orndorff,
Thanks for getting back.
You tested on an Rpi 3B+. That should have a BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC, which is a 64 bit architecture. That should be “arm64” architecture.
Could you run: “$ dpkg --print-architecture” and “$ arch” for me to check that?
You should be able to get Pro support for 10 years with your RPi 3B+.
Please also check with “$ pro status --all”.
I have a rev 1.1 RPi 2B, which is different from the rev 1.2. The revision v1.2 of the Raspberry Pi 2B replaced the BCM2836-SoC (ARM Cortex-A7; ARMv7) with a BCM2837 (ARM Cortex-A53; ARMv8-A) known from the Pi 3B. So your RPi 3B+ has a 64 bit “arm64” architecture whereas my RPi 2B rev 1.1 has a BCM2836-SoC (ARM Cortex-A7; ARMv7) which is 32 bit “armhf” architecture.
To get back to your question. Yes, It is possible that this bug affected an earlier version of pro. It was the status from my previous post. I will disconnect my RPi 2B rev 1.1 (armhf architecture) from pro and run the test again.
Here are the renewed test results:
$ sudo pro detach
Are you sure? (y/N) y
This machine is now detached.
$ pro status
No Ubuntu Pro services are available to this system.For a list of all Ubuntu Pro services, run ‘pro status --all’
This machine is not attached to an Ubuntu Pro subscription.
See Ubuntu Pro | UbuntuSupported livepatch kernels are listed here: https://ubuntu.com/security/livepatch/docs/kernels
$ pro version
30~22.04
As it seems the bug affected an earlier version of pro and it has been fixed since I saw it.
On another note, is the Freexian Extended Long Term Support team likely to support the armhf architecture? They do support the armhf architecture for Debian 8 Jessie and Debian 9 Stretch for 10 years (the 5 years beyond the LTS period).
Yes, sorry for the confusion. The RPi3B+ has an arm64 CPU, but I installed the 32-bit armhf version of 22.04 to try to replicate your issue. When armhf Ubuntu is installed, dpkg --print-architecture says armhf and arch says armv7l.
I’m glad the issue with pro is no longer affecting you.
I don’t know anything about Freexian, so can’t help there
Well actually I’m sorry to say that I’m back at square one. ESM messages that are displayed at each login over and over again. Like:
Yes, I was able to reproduce that and I’ve reported a bug to the appropriate package: Bug #2052546 “ESM banner shown on unsupported architectures” : Bugs : update-notifier package : Ubuntu