/usr/lib/ubuntu-advantage/esm_cache.py:RuntimeError:/usr/lib/ubuntu-advantage/esm_cache.py@22:main:update_esm_caches:is_current_series_lts:get_platform_info
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-advantage-tools (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned | ||
Kinetic |
Fix Released
|
Undecided
|
Unassigned | ||
Lunar |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Original Description]
The Ubuntu Error Tracker has been receiving reports about a problem regarding ubuntu-
If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://
[Impact]
User will see a degrade state on systemd because the `esm_cache` job will fail, since it cannot properly parse /etc/os-release.
This is probably affecting releases that are ubuntu based, and not Ubuntu itself.
[ Test Case ]
Scenario 1:
1) Launch a LXD container with an affected Ubuntu release
2) Install the Pro client version with the fix
3) Modify /etc/os-release so that we don't have the fields VERSION, VERSION_CODENAME and VERSION_ID
4) Run the esm_cache job and verify that it doesn't break anymore
5) Check /var/log/
Scenario 2:
1) Launch a LXD container with an affected Ubuntu release
2) Install the Pro client version with the fix
3) Modify /etc/os-release so that we don't have the fields VERSION_CODENAME and VERSION_ID and change VERSION to "22.04 LTS (modified to 22.04 LTS)"
4) Run the esm_cache job and verify that it doesn't break anymore
5) Check /var/log/
Scenario 3:
1) Launch a LXD container with an affected Ubuntu release
2) Install the Pro client version with the fix
3) Modify /etc/os-release so that VERSION is set to "22.04 LTS (modified to 22.04 LTS)"
4) Run the esm_cache job and verify that it doesn't break anymore
5) Check /var/log/
To test all of these scenarios, we have used the following script:
-------
#!/bin/bash
set -e
series=$1
scenario=$2
name=$series-dev
function cleanup {
lxc delete $name --force
}
function on_err {
echo -e "Test Failed"
cleanup
exit 1
}
trap on_err ERR
lxc launch ubuntu-
sleep 5
lxc exec $name -- apt-get update > /dev/null
lxc exec $name -- apt-get install ubuntu-
# Show latest version of Pro client
# -------
echo "Show latest version of Pro client"
echo "######
lxc exec $name -- apt-cache policy ubuntu-
echo -e "######
# -------
# Reproduce the error
# -------
if [ $scenario == "1" ]; then
lxc exec $name -- sed -i '/VERSION=.*/d' /etc/os-release
lxc exec $name -- sed -i '/VERSION_ID=.*/d' /etc/os-release
lxc exec $name -- sed -i '/VERSION_
elif [ $scenario == "2" ]; then
lxc exec $name -- sed -i '/VERSION_ID=.*/d' /etc/os-release
lxc exec $name -- sed -i '/VERSION_
lxc exec $name -- sed -i 's/VERSION=
else
lxc exec $name -- sed -i 's/VERSION=
fi
echo "Show content /etc/os-release"
echo "######
lxc exec $name -- cat /etc/os-release
echo -e "######
echo "Show error related to /etc/os-release"
echo "######
lxc exec $name -- sh -c "python3 /usr/lib/
echo -e "######
# -------
# Add proposed
# -------
lxc exec $name -- sh -c "echo \"deb http://
lxc exec $name -- apt-get update > /dev/null
lxc exec $name -- apt-get install ubuntu-
# -------
# Show latest version of Pro client
# -------
echo "Show proposed version of Pro client"
echo "######
lxc exec $name -- apt-cache policy ubuntu-
echo -e "######
# -------
if [ $scenario != "3" ]; then
echo "Check that command doesn't fail, but we output the error message"
else
echo "Error no longer appear"
fi
echo "######
lxc exec $name -- python3 /usr/lib/
echo -e "######
if [ $scenario != "3" ]; then
echo "Check that we have logged the issue"
else
echo "Check that we have not logged the issue"
fi
echo "######
lxc exec $name -- tail /var/log/
echo -e "######
cleanup
-------
[ Regression potential ]
We are modifying how we collect information from /etc/os-release. If we have a mismatch between VERSION_ID and VERSION_CODENAME from VERSION, we might now pass different information to the contract server. However, we
believe this is low risk, as those fields should be consistent among themselves
[ Discussion]
Before running the esm_cache job, we check to see if the machine is an ESM release. To perform that check, we gather information from /etc/os-release. If we cannot find the require information there, we raise an Exception that is not being treated on the esm_cache job. We are now not only handling better how we extract information from /etc/os-release, but also making the esm_cache job more resilient to potential unexpected exceptions
description: | updated |
tags: |
added: verification-done verification-done-xenial removed: verification-needed verification-needed-xenial |
Changed in ubuntu-advantage-tools (Ubuntu Lunar): | |
status: | New → Triaged |
status: | Triaged → Fix Committed |
Can you augment the test with a case where VERSION has "22.04 LTS (modified to 22.04 LTS)" and there is no VERSION_ID nor VERSION_CODENAME, so that the new REGEX_OS_ RELEASE_ VERSION regexp you added to parse that more complicated VERSION string is triggered?
And also the "normal" case reported in the error tracker, where all fields are there and correct, and VERSION has "22.04 LTS (modified to 22.04 LTS)" as it was on that user's machine.