Derek Coleman & Associates Inc logoDerek Coleman & Associates Inc

Home / Support / Jenkins LTS on Ubuntu 24.04 LTS

Jenkins LTS on Ubuntu 24.04 LTS — Support & Quick Start

Jenkins LTS automation server on Ubuntu 24.04 LTS with per-VM initial admin password and setup wizard ready on first boot.

Email support Product page Azure Marketplace listing

Known issue on the current image (as of 2026-10-14)

On the "Jenkins LTS on Ubuntu 24.04 LTS — Gen2" plan only: signing in as admin with /root/.jenkins-initial-password returns HTTP 401, because the Configuration-as-Code admin user was never created and Jenkins waits in its setup wizard. The same image also ships controller keys that are identical on every VM deployed from it (Jenkins was started during the image build), so stored credentials on one such VM can be decrypted by anyone holding another. The "Gen2 (usage-based)" plan publishes a fixed image and is not affected. (image build tested: 2026.05.30 — the only version the "Jenkins LTS on Ubuntu 24.04 LTS — Gen2" plan publishes (live tree, read 2026-10-14); the "Gen2 (usage-based)" plan publishes the fixed 2026.928.1759 (see the fixed note below))

What you will see: http://<VM-IP>:8080/ shows "Unlock Jenkins" (anonymous requests get 403); admin + the documented password → 401; /var/lib/jenkins/secrets/initialAdminPassword exists and /root/.jenkins-initial-password does not prove itself.

Workaround:

  1. Unlock the wizard: `sudo cat /var/lib/jenkins/secrets/initialAdminPassword`, paste it at http://<VM-IP>:8080/, install the suggested plugins and create your first admin user (standard Jenkins first run). The 2026-09-15 sweep proved the wizard is active and the file exists; the unlock itself was not sweep-run.
  2. Then replace the shared controller keys, as the fixed image does at first boot: stop Jenkins, delete /var/lib/jenkins/secrets/master.key, /var/lib/jenkins/secret.key and /var/lib/jenkins/identity.key.enc, start Jenkins, and re-enter every stored credential (they were encrypted with the shared key and will not decrypt). Taken from the image's own usage notes; not sweep-run.
  3. For a new deployment, choose the "Gen2 (usage-based)" plan, whose image 2026.928.1759 has both fixes.
sudo cat /var/lib/jenkins/secrets/initialAdminPassword
# after the wizard:
sudo systemctl stop jenkins
sudo rm -f /var/lib/jenkins/secrets/master.key /var/lib/jenkins/secret.key /var/lib/jenkins/identity.key.enc
sudo systemctl start jenkins

Fix status: Fixed in image-factory PRs #224 (admin account created and proven at first boot, merged 2026-09-16) and #351 (controller keys minted per VM, merged 2026-09-28), shipped together as image 2026.928.1759, which is live on the "Gen2 (usage-based)" plan since 2026-09-28. The "Gen2" plan has not received a fixed version: the image you deploy from it today is still the one described above. Track the fix.

Source: our 2026-10-14 image sweep of the newest published build. This notice is removed when a build that passes the same test is live on the Marketplace.

Fixed on image version 2026.928.1759 (the "Jenkins LTS on Ubuntu 24.04 LTS — Gen2 (usage-based)" plan) (published 2026-09-28)

On the usage-based plan the current image (Jenkins LTS 2.568.3 on OpenJDK 21) completes setup at first boot: it creates `admin` with a password generated on your VM, signs in with it against the running Jenkins before writing /root/.jenkins-initial-password, removes the setup wizard's initialAdminPassword, and generates the controller keys (secret.key, secrets/master.key, identity.key.enc) on your VM instead of shipping them in the image.

If you deployed this VM before 2026-09-28, it came from the older image and is not changed by the new publication — redeploy from the current Marketplace version, or apply the one-time repair below:

  1. VMs deployed from image 2026.916.1357 (live 2026-09-16 to 2026-09-28 on this plan) have the working admin account but the SHARED controller keys: stop Jenkins, delete /var/lib/jenkins/secrets/master.key, /var/lib/jenkins/secret.key and /var/lib/jenkins/identity.key.enc, start Jenkins, and re-enter every stored credential (they were encrypted with the shared key and will not decrypt). Taken from the image's usage notes; not sweep-run.
  2. VMs deployed from image 2026.05.30 — still the only version on the "Gen2" plan — have the setup wizard active AND the shared keys: see the Known issue above.
sudo systemctl stop jenkins
sudo rm -f /var/lib/jenkins/secrets/master.key /var/lib/jenkins/secret.key /var/lib/jenkins/identity.key.enc
sudo systemctl start jenkins

Image change: see the pull request.

Source: the Marketplace live version set for this offer, read from Partner Center on 2026-09-28. New deployments take the newest version by default.

At a glance

Application ports8080 (Jenkins web UI)
Open in browserhttp://<VM-IP>:8080/
Admin credential filesudo cat /root/.jenkins-initial-password # image 2026.928.1759; on image 2026.05.30: sudo cat /var/lib/jenkins/secrets/initialAdminPassword
Sign in asadmin (image 2026.928.1759, usage-based plan). On image 2026.05.30 (the Gen2 plan) no account exists until you create one through the setup wizard — see Known issue
Service(s)jenkins
Configuration/var/lib/jenkins/ (JENKINS_HOME; Jenkins' own secrets in /var/lib/jenkins/secrets/)
Logsjournalctl -u jenkins -f
VersionJenkins LTS 2.568.3 on OpenJDK 21 (image 2026.928.1759 — the "Gen2 (usage-based)" plan); the "Gen2" plan still publishes image 2026.05.30 with the Jenkins LTS release current at that build
PlatformUbuntu 24.04 LTS

Quick start

  1. Deploy from the Azure Marketplace (Get It Now → Create), choosing your SSH key at the Administration step.
  2. Allow inbound SSH (22) for yourself plus the application port(s): 8080 (Jenkins web UI) — restrict to your own IP where possible. The in-image firewall already allows them; only the Network Security Group (NSG) keeps them closed.
  3. Open http://<VM-IP>:8080/ and sign in as admin with the password in /root/.jenkins-initial-password (usage-based plan; see First login for the Gen2 plan's wizard).
  4. Create your first pipeline (New Item → Pipeline) or connect agents; put Jenkins behind HTTPS before exposing it beyond your network.

First login / credentials

This image generates its admin credential on the VM at first boot — nothing is pre-set. SSH into the VM with the username + key you chose at deploy, then print the generated credential:

ssh <your-username>@<VM-IP>
sudo cat /root/.jenkins-initial-password   # image 2026.928.1759; on image 2026.05.30: sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Sign in as admin (image 2026.928.1759, usage-based plan). On image 2026.05.30 (the Gen2 plan) no account exists until you create one through the setup wizard — see Known issue.

  1. Check which image your VM runs: `sudo test -f /root/.jenkins-initial-password && echo fixed-image`. If the file exists (image 2026.928.1759, deployed from the usage-based plan), setup is already complete: there is no Unlock Jenkins screen, first boot created `admin` with a password generated on your VM and signed in with it before recording the file.
  2. Open http://<VM-IP>:8080/ and sign in as admin with `sudo cat /root/.jenkins-initial-password`; change the password (admin → Configure) and delete the file once stored securely. Add plugins from Manage Jenkins → Plugins.
  3. If instead /var/lib/jenkins/secrets/initialAdminPassword exists, your VM came from image 2026.05.30 (the Gen2 plan): unlock the setup wizard with `sudo cat /var/lib/jenkins/secrets/initialAdminPassword`, create your first admin user, and treat the VM as exposed — its unlock secret and controller keys are the same on every VM from that image (Known issue below).

Image 2026.928.1759 (usage-based plan): sign in as admin with /root/.jenkins-initial-password — the password was proven against the running Jenkins at first boot, and the controller keys were generated on your VM. Image 2026.05.30 (Gen2 plan): the setup wizard is active and the keys are shared — see Known issue.

Still stuck?

Email support@dcassociatesgroup.com (response within 1 business day) or send a message via the contact form. Include the offer name, VM size, region, and any log output — sudo journalctl -u <service> -n 100 usually tells the story.