Ubuntu
cloud-init package

cloud-init locks out user `ubuntu` after upgrade from 22.04 to 24.04

Bug #2075968 reported by Nick Rosbrook
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init (Ubuntu)
New
High
Unassigned
Noble
New
High
Unassigned
Ubuntu ubuntu-24.04.1
ubuntu-release-upgrader (Ubuntu)
Invalid
High
Nick Rosbrook
Noble
Fix Committed
High
Nick Rosbrook
Ubuntu ubuntu-24.04.1

Bug Description

[Impact]

Since Jammy, desktop metapackages have gained a Recommends: cloud-init, which means that cloud-init will be installed on upgrades to Noble. On the first boot following the upgrade, cloud-init will run because as far as cloud-init can detect, this is the first boot. However, this is wrong, and we do not want cloud-init to run after the upgrade.

One practical impact of this is that by default, cloud-init creates user `ubuntu` with `lock_passwd: true`. If the upgraded machine already has a user `ubuntu`, they will be locked out.

[Test Plan]

The proposed patch is for ubuntu-release-upgrader to disable cloud-init if it is being installed for the first time during the upgrade. This is done by creating /etc/cloud/cloud-init.disabled.

Test #1:

This test must be done on 22.04 desktop where cloud-init is not installed.

1. Confirm that cloud-init is not installed

$ apt policy cloud-init

2. Do an upgrade

$ do-release-upgrade -d

3. After the upgrade, confirm that /etc/cloud/cloud-init.disabled was created by ubuntu-release-upgrader

$ cat /etc/cloud/cloud-init.disabled

4. Reboot, and confirm that cloud-init does not run

$ systemctl status cloud-init.target
$ cat /run/cloud-init/ds-identify.log

Test #2:

This test must be done on 22.04 server where cloud-init is installed. A LXD container works.

1. Confirm that cloud-init is installed:

$ apt policy cloud-init

2. Do an upgrade

$ do-release-upgrade -d

3. After the upgrade, confirm that cloud-init was not disabled by ubuntu-release-upgrader

$ stat /etc/cloud/cloud-init.disabled

[Where problems could occur]

It is important that the correct file is created to correctly disable cloud-init. Regressions would be related to whether or not this file is created in the correct circumstances.

[Original Description]

After performing an upgrade, and then rebooting, I am no longer able to login with my user "ubuntu". I get an authentication failure with both the graphical login screen, and when attempting to login on a non-graphical tty.

Dropping to a rescue shell, I can see this in the logs:

root@xubuntu:~# journalctl -b --grep pam
Aug 02 11:52:45 xubuntu systemd[1]: systemd 255.4-1ubuntu8.2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OP>
Aug 02 11:53:00 xubuntu lightdm[1422]: pam_unix(lightdm-greeter:session): session opened for user lightdm(uid=115) by (uid=0)
Aug 02 11:53:00 xubuntu (systemd)[1472]: pam_unix(systemd-user:session): session opened for user lightdm(uid=115) by lightdm(uid=0)
Aug 02 11:53:00 xubuntu lightdm[1422]: gkr-pam: couldn't unlock the login keyring.
Aug 02 11:53:01 xubuntu lightdm[1584]: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "ubuntu"
Aug 02 11:53:40 xubuntu lightdm[1584]: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=ubuntu
Aug 02 11:53:42 xubuntu lightdm[1604]: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "ubuntu"
Aug 02 11:53:49 xubuntu lightdm[1604]: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=ubuntu
Aug 02 11:53:51 xubuntu lightdm[1605]: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "ubuntu"
Aug 02 11:53:58 xubuntu lightdm[1607]: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "root"
Aug 02 11:53:59 xubuntu lightdm[1607]: gkr-pam: unable to locate daemon control file
Aug 02 11:53:59 xubuntu lightdm[1607]: gkr-pam: stashed password to try later in open session
Aug 02 11:53:59 xubuntu lightdm[1422]: pam_unix(lightdm-greeter:session): session closed for user lightdm
Aug 02 11:53:59 xubuntu lightdm[1607]: pam_unix(lightdm:session): session opened for user root(uid=0) by (uid=0)
Aug 02 11:54:00 xubuntu (systemd)[1614]: pam_unix(systemd-user:session): session opened for user root(uid=0) by root(uid=0)
Aug 02 11:54:00 xubuntu lightdm[1607]: gkr-pam: unlocked login keyring
Aug 02 11:54:10 xubuntu (sd-pam)[1473]: pam_unix(systemd-user:session): session closed for user lightdm
Aug 02 11:55:01 xubuntu CRON[2417]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Aug 02 11:55:01 xubuntu CRON[2417]: pam_unix(cron:session): session closed for user root

Other notes:

(1) During the upgrade, the screen saver was disabled. I know this has been a bug in the past, but I do not believe it is the cause here.
(2) A work around for this is to drop into a rescue shell, and from root, run e.g. `passwd ubuntu` to reset the user's password.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: libpam-modules 1.5.3-5ubuntu5.1
ProcVersionSignature: Ubuntu 6.8.0-39.39-generic 6.8.8
Uname: Linux 6.8.0-39-generic x86_64
ApportVersion: 2.28.1-0ubuntu3
Architecture: amd64
CasperMD5CheckResult: pass
CloudArchitecture: x86_64
CloudID: none
CloudName: none
CloudPlatform: none
CloudSubPlatform: config
CurrentDesktop: XFCE
Date: Fri Aug 2 11:55:51 2024
InstallationDate: Installed on 2024-07-30 (3 days ago)
InstallationMedia: Xubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 (20240216.1)
ProcEnviron:
 LANG=en_US.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
SourcePackage: pam
UpgradeStatus: Upgraded to noble on 2024-08-02 (0 days ago)
mtime.conffile..etc.init.d.apport: 2024-04-23T07:30:10

See original description
Revision history for this message
Nick Rosbrook (enr0n) wrote :
Changed in pam (Ubuntu Noble):
importance: Undecided → Critical
Changed in pam (Ubuntu):
importance: Undecided → Critical
Changed in pam (Ubuntu Noble):
milestone: none → ubuntu-24.04.1
tags: added: rls-nn-incoming
Revision history for this message
Steve Langasek (vorlon) wrote :

Prior to upgrade, was this system configured for passwordless login?

Revision history for this message
Nick Rosbrook (enr0n) wrote :

No it was not.

Revision history for this message
Tim Andersson (andersson123) wrote :

I tried to reproduce this twice, but couldn't. I did a fresh xubuntu 22.04 install, and then upgraded the machine. I didn't experience this bug, but I did get the following crash (attached)

Julian Andres Klode (juliank)
tags: added: foundations-todo
removed: rls-nn-incoming
Revision history for this message
Nick Rosbrook (enr0n) wrote :
Download full text (3.7 KiB)

I dug into this a bit more, and it seems this issue occurs specifically for the user `ubuntu`. Before the upgrade, I copied the contents of /etc/shadow, and compared them to /etc/shadow after the first reboot after the upgrade.

$ diff -u <(/etc/shadow) /home/ubuntu/before/shadow
--- /dev/fd/63 2024-08-08 14:57:08.366981261 -0400
+++ /home/ubuntu/before/shadow 2024-08-08 14:20:17.158139781 -0400
@@ -1,4 +1,4 @@
-root:$y$j9T$NXJHsSu.l5iqspt5f8zzu/$CaDVSozRbChrGCSerFmv3Ck8lxPAQlj9D7MdG4Wrbm6:19943:0:99999:7:::
+root:!:19934:0:99999:7:::
 daemon:*:19769:0:99999:7:::
 bin:*:19769:0:99999:7:::
 sys:*:19769:0:99999:7:::
@@ -25,6 +25,7 @@
 tss:*:19769:0:99999:7:::
 uuidd:*:19769:0:99999:7:::
 tcpdump:*:19769:0:99999:7:::
+avahi-autoipd:*:19769:0:99999:7:::
 usbmux:*:19769:0:99999:7:::
 dnsmasq:*:19769:0:99999:7:::
 kernoops:*:19769:0:99999:7:::
@@ -39,10 +40,5 @@
 colord:*:19769:0:99999:7:::
 pulse:*:19769:0:99999:7:::
 hplip:*:19769:0:99999:7:::
-ubuntu:!$y$j9T$LreISCn8cWENVi4Mw1/cv.$Kkn9WO6CGCd/QUW8CUJoCHRZE8./VZmCfqDixXr8TU6:19934:0:99999:7:::
+ubuntu:$y$j9T$LreISCn8cWENVi4Mw1/cv.$Kkn9WO6CGCd/QUW8CUJoCHRZE8./VZmCfqDixXr8TU6:19934:0:99999:7:::
 sshd:*:19943:0:99999:7:::
-snapd-range-524288-root:!:19943::::::
-snap_daemon:!:19943::::::
-dhcpcd:!:19943::::::
-cups-browsed:!:19943::::::
-polkitd:!*:19943::::::

We can see that the entry for `ubuntu` changed. Looking at the journal, from that boot, it seems that cloud-init changed the passwd:

$ journalctl -b -1 --grep ubuntu
Aug 08 14:50:33 xubuntu kernel: Linux version 6.8.0-40-generic (buildd@lcy02-amd64-075) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #40-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 5 10:34:03 UTC 2024 (Ubuntu 6.8.0-40.40-generic 6.8.12)
Aug 08 14:50:33 xubuntu kernel: Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (Ubuntu Core 2019): c1d57b8f6b743f23ee41f4f7ee292f06eecadfb9'
Aug 08 14:50:33 xubuntu systemd[1]: systemd 255.4-1ubuntu8.2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
Aug 08 14:50:33 xubuntu systemd[1]: Hostname set to <xubuntu>.
Aug 08 14:50:34 xubuntu cloud-init[564]: Cloud-init v. 24.1.3-0ubuntu3.3 running 'init-local' at Thu, 08 Aug 2024 18:50:34 +0000. Up 4.19 seconds.
Aug 08 14:50:34 xubuntu systemd-resolved[632]: Using system hostname 'xubuntu'.
Aug 08 14:50:35 xubuntu cloud-init[760]: Cloud-init v. 24.1.3-0ubuntu3.3 running 'init' at Thu, 08 Aug 2024 18:50:35 +0000. Up 5.51 seconds.
Aug 08 14:50:36 xubuntu passwd[869]: password for 'ubuntu' changed by 'root'
Aug 08 14:50:37 xubuntu cloud-init[760]: SHA256:GGMsp52cN8EAJYlqOdJArAxzOEhwfitNlPBgGQCVOTE root@xubuntu
Aug 08 14:50:37 xubuntu cloud-init[760]: SHA256:TcJuGTUBYjDMo+GVodNfGgE5P5FeszDy/8QddKQanJE root@xubuntu
Aug 08 14:50:37 xubuntu cloud-init[760]: SHA256:hjnsPHfUrAQbIkiRETrAszNsqZppRrI3dhTU4BGKy5s root@xubuntu

Looking at /etc/cloud/cloud.cfg, I see the lock_passwd[1] option set f...

Read more...

affects: pam (Ubuntu) → cloud-init (Ubuntu)
summary: - cannot login after upgrade from xubuntu 22.04 to 24.04
+ cloud-init locks out user `ubuntu` after upgrade from 22.04 to 24.04
Changed in cloud-init (Ubuntu):
importance: Critical → High
Changed in cloud-init (Ubuntu Noble):
importance: Critical → High
Revision history for this message
Chad Smith (chad.smith) wrote :

Can we upload cloud-init collect-logs to this bug to see cloud-init's behavior across this reboot? If cloud-init thinks it didn't run for some reason across upgrade then it may re-run thinking it is a fresh install. Having visiblity to the full /var/log/cloud-init.log would be helpful here.

Revision history for this message
Nick Rosbrook (enr0n) wrote :

Attached.

Revision history for this message
James Falcon (falcojr) wrote (last edit ):

Edit: my diagnosis here is incorrect. Cloud-init will clear some persistent state on python version change, but not clear the entire instance cache.

Original message:
I see `"lock_passwd": true` (a cloud-init default) in the instance-data-sensitive.json file. Was the account manually unlocked at some point?

If so, when doing a release upgrade, cloud-init will see a new python version, clear it's cache, then run as if it was first boot again.

Revision history for this message
Chad Smith (chad.smith) wrote :
Download full text (4.7 KiB)

In the logs there we can see that cloud-init across reboot added a WARNING because it was unable to redetect the LXD datasource in noble:

2024-08-08 18:55:53,280 - cc_final_message.py[WARNING]: Used fallback datasource

This discovery of a new datasource triggers cloud-init to re-run on a system for all modules including:

- setting the default user up (and setting it's password)
- creating new SSH host keys
- re-applying any user-data found

Also what's strange in the attached /var/log/cloud-init.log is that something disrupted cloud-init before it completed all boot stages on the initial run. I see only two of 4 boot stages run before possibly a reboot:

2024-08-08 18:50:34,099 - util.py[DEBUG]: Cloud-init v. 24.1.3-0ubuntu3.3 running 'init-local' at Thu, 08 Aug 2024 18:50:34 +0000. Up 4.19 seconds.
...
2024-08-08 18:50:35,421 - util.py[DEBUG]: Cloud-init v. 24.1.3-0ubuntu3.3 running 'init' at Thu, 08 Aug 2024 18:50:35 +0000. Up 5.51 seconds.
2024-08-08 18:50:37,131 - handlers.py[DEBUG]: finish: init-network: SUCCESS: searching for network datasources
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@...

Read more...

Revision history for this message
Nick Rosbrook (enr0n) wrote :

The installation was done with user `ubuntu`. It was never "manually unlocked", because this is the user I created when I installed Ubuntu on the VM.

Revision history for this message
Nick Rosbrook (enr0n) wrote :

I attached the full journal from the boot immediately after the upgrade.

Revision history for this message
Nick Rosbrook (enr0n) wrote :

> ... because it was unable to redetect the LXD datasource ...

You say "re-detect." AFAIK, this is the *first* time cloud-init is running ever on the host, because cloud-init was *installed* during the upgrade from Jammy to Noble.

Revision history for this message
Chad Smith (chad.smith) wrote :

> If so, when doing a release upgrade, cloud-init will see a new python version, clear it's cache, then run as if it was first boot again.

Ahh the cleared cache is what triggers cloud-init to re-run thereby reapplying any user-data it detects on that subsequent boot. Since default system configuration in this image /etc/cloud/cloud.cfg is to lock_passwd cloud-init happily locks down that passwd access with that leading ! in /etc/shadow

Revision history for this message
James Falcon (falcojr) wrote :

Eh sorry, I think I misspoke. On a new python version we clear the object pickle, not the entire instance cache. Ignore my previous comment.

Revision history for this message
Chad Smith (chad.smith) wrote :

I can confirm in Ubuntu cloudimages on LXD that do-release-upgrade across Jammy -> Noble succeeds having run cloud-init on first image launch in Jammy, removing the cache due to python3 version upgrade, and redetecting LXD datasource config on reboot into Noble with proper instance-id detection.

In this scenario where cloud-init was run before upgrade, /var/lib/cloud/data/previous-iid cache recorded LXD platform's instance-id on first boot, and across upgrade cloud-init determines that instance-id had no delta and doesn't need to run again.

Nick mentioned in comment #13 that cloud-init is being installed across the upgrade path to noble in Xubuntu due to "Recommends: cloud-init".

In the Xubuntu 22.04 -> 24.04 scenario, across reboot into 24.04, there is no cached /var/lib/cloud/data/previous-iid because cloud-init has never run in this image, so the boot of 24.04 triggers cloud-init to attempt to detect datasources, finds potential LXD datasource, so it tries to run as a 'new instance first boot' which applies cloud-init defaults from /etc/cloud/cloud.cfg which states "lock_passwd: true" for the ubuntu user.

So, if cloud-init is being pulled in during do-release-upgrade where it wasn't previously installed, I think we may need to think of a path/hook in do-release-upgrade that can leave cloud-init in a disabled state in that image (because it wasn't originally run in the original image) as it will by default be enabled on next boot and perform default setup and config which will lock down certain users and passwords, create new SSH host keys etc.

One way to disable cloud-init easily is creating an /etc/cloud/cloud-init.disabled file on the system which will keep cloud-init inert intentionally (which is generally a good idea for desktop images to avoid exposure to rogue USB sticks which contain cloud-init user-data being plugged into a laptop and forcing reconfiguration of a laptop)

By providing a quirk if cloud-init gets included in an image that doesn't already contain cloud-init, we can prevent this pitfall by adding something like the following across upgrade.

cat > /etc/cloud/cloud-init.disabled <<EOF
Disabled by do-release-upgrade because cloud-init was pulled in as a `Recommends:` dependency during upgrade and should not be enabled by default
EOF


Revision history for this message
Brett Holman (holmanb) wrote :

> By providing a quirk if cloud-init gets included in an image that doesn't already contain cloud-init, we can prevent this pitfall by adding something like the following across upgrade.
>
> cat > /etc/cloud/cloud-init.disabled <<EOF
> Disabled by do-release-upgrade because cloud-init was pulled in as a `Recommends:` dependency during upgrade and should not be enabled by default
> EOF

Agreed, it seems like this is something that should be fixed external to cloud-init. Part of cloud-init's job is identifying if an instance is fresh (i.e. hasn't ran before on this instance), so it seems to be doing what it is supposed to do. It's just running in an environment where cloud-init wasn't supposed to do that.

Nick Rosbrook (enr0n)
Changed in ubuntu-release-upgrader (Ubuntu Noble):
importance: Undecided → High
Changed in ubuntu-release-upgrader (Ubuntu):
importance: Undecided → Medium
importance: Medium → High
Changed in ubuntu-release-upgrader (Ubuntu Noble):
assignee: nobody → Nick Rosbrook (enr0n)
status: New → Triaged
Changed in ubuntu-release-upgrader (Ubuntu):
status: New → Triaged
assignee: nobody → Nick Rosbrook (enr0n)
Changed in ubuntu-release-upgrader (Ubuntu Noble):
milestone: none → ubuntu-24.04.1
Nick Rosbrook (enr0n)
description: updated
Nick Rosbrook (enr0n)
description: updated
Revision history for this message
Nick Rosbrook (enr0n) wrote :

I don't think this is necessary to include in oracular.

Changed in ubuntu-release-upgrader (Ubuntu Noble):
status: Triaged → In Progress
Changed in ubuntu-release-upgrader (Ubuntu):
status: Triaged → Invalid
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello Nick, or anyone else affected,

Accepted ubuntu-release-upgrader into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:24.04.21 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in ubuntu-release-upgrader (Ubuntu Noble):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-noble
Revision history for this message
Nick Rosbrook (enr0n) wrote :

Test #1:

ubuntu@xubuntu:~$ apt policy cloud-init
cloud-init:
  Installed: (none)
  Candidate: 24.1.3-0ubuntu1~22.04.5
  Version table:
     24.1.3-0ubuntu1~22.04.5 500
        500 http://us.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://us.archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
     23.1.2-0ubuntu0~22.04.1 500
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu jammy-security/main i386 Packages
     22.1-14-g2e17a0d6-0ubuntu1~22.04.5 500
        500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        500 http://us.archive.ubuntu.com/ubuntu jammy/main i386 Packages
ubuntu@xubuntu:~$ sudo sed -i 's/Prompt=lts/Prompt=normal/g' /etc/update-manager/release-upgrades
[sudo] password for ubuntu:
ubuntu@xubuntu:~$ do-release-upgrade --proposed
Checking for a new Ubuntu release

= Welcome to Ubuntu 24.04 LTS 'Noble Numbat' =

The Ubuntu team is proud to announce Ubuntu 24.04 LTS 'Noble Numbat'.

To see what's new in this release, visit:
  https://wiki.ubuntu.com/NobleNumbat/ReleaseNotes

[ ...SNIP... ]

ubuntu@xubuntu:~$ cat /etc/cloud/cloud-init.disabled
Disabled by ubuntu-release-upgrader. LP: #2075968.
ubuntu@xubuntu:~$ sudo reboot

...

ubuntu@xubuntu:~$ systemctl status cloud-init.target
○ cloud-init.target - Cloud-init target
     Loaded: loaded (/usr/lib/systemd/system/cloud-init.target; static)
     Active: inactive (dead)
ubuntu@xubuntu:~$ cat /run/cloud-init/ds-identify.log
[up 2.96s] ds-identify
disabled by marker file /etc/cloud-init.disabled
[up 2.97s] returning 2
[up 15.08s] ds-identify
disabled by marker file /etc/cloud-init.disabled
[up 15.09s] returning 2

Test #2:

nr@six:~$ lxc launch ubuntu:jammy j
nr@six:~$ lxc exec j bash
root@j:~# apt policy cloud-init
cloud-init:
  Installed: 24.1.3-0ubuntu1~22.04.5
  Candidate: 24.1.3-0ubuntu1~22.04.5
  Version table:
 *** 24.1.3-0ubuntu1~22.04.5 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     23.1.2-0ubuntu0~22.04.1 500
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
     22.1-14-g2e17a0d6-0ubuntu1~22.04.5 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
root@j:~# sed -i 's/Prompt=lts/Prompt=normal/g' /etc/update-manager/release-upgrades
root@j:~# do-release-upgrade --proposed -f DistUpgradeViewNonInteractive
[ ...SNIP... ]
root@j:~# stat /etc/cloud/cloud-init.disabled
stat: cannot statx '/etc/cloud/cloud-init.disabled': No such file or directory

tags: added: verification-done verification-done-noble
removed: verification-needed verification-needed-noble
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.