[Bug 2090834] Re: vboxpostinstall.sh returned non-zero exit status 1.

[Olivier Gayot]

** Merge proposal linked:
   https://code.launchpad.net/~ogayot/curtin/+git/curtin/+merge/496404

** Changed in: curtin (Ubuntu Noble)
       Status: New => In Progress

** Changed in: curtin (Ubuntu Noble)
     Assignee: (unassigned) => Olivier Gayot (ogayot)

** Changed in: curtin
     Assignee: (unassigned) => Olivier Gayot (ogayot)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to subiquity in Ubuntu.
https://bugs.launchpad.net/bugs/2090834

Title:
  vboxpostinstall.sh returned non-zero exit status 1.

Status in curtin:
  Fix Committed
Status in ubuntu-desktop-provision:
  Triaged
Status in Virtualbox:
  Unknown
Status in curtin package in Ubuntu:
  Fix Committed
Status in subiquity package in Ubuntu:
  Fix Committed
Status in virtualbox package in Ubuntu:
  New
Status in curtin source package in Noble:
  In Progress
Status in subiquity source package in Noble:
  Triaged
Status in virtualbox source package in Noble:
  New
Status in curtin source package in Resolute:
  Fix Committed
Status in subiquity source package in Resolute:
  Fix Committed
Status in virtualbox source package in Resolute:
  New

Bug description:
  [Description]
  We have multiple private bug reports where people try to install Ubuntu 24.04 using virtualbox (with Guest Additions) but vboxpostinstall.sh fails.

  After investigating, I found out that vboxpostinstall.sh indirectly
  relies on usermod to add the `vboxuser` user to a group (vboxuser is
  the default username for VirtualBox unattended installations but can
  be changed by when creating the VM).

  We know for a fact that Subiquity-based installers do not create users
  until first boot so using usermod in a postinstall scripts doesn't
  work.

  [Plan of actions]
  1. [x] Introduce support in the identity section for creating users before firstboot in devel series (i.e., resolute)
  2. [x] Open a PR in virtualbox to make sure they create the user using the identity section, not cloud-init's user-data.
  3. [ ] Backport the Subiquity changes to ubuntu/noble so that 24.04.4 can be installed unattended (provided a patched version of VirtualBox is used).

  [How to reproduce]
  * Setup an Ubuntu host system running questing (i.e., 25.10) or more recent. On older Ubuntu running VirtualBox < 7.1, unattended install for Ubuntu isn't supported at all.
  * Install the following packages:
     - virtualbox
     - virtualbox-guest-additions-iso
  * Start VirtualBox and create a new VM:
     * Select an Ubuntu ISO, such as ubuntu-24.04.3-live-server-amd64.iso
     * [x] Proceed with Unattended Installation
     * Specify a password (twice)
     * [x] Install Guest Additions
     * The default ISO should automatically be picked up for the guest additions if virtualbox-guest-additions-iso is installed)
     * If installing Ubuntu Desktop, bump the memory (8 GiB recommended)
  * Click on "Finish" to start the installation
  * After some time, it fails.
  * The logs show that vboxpostinstall.sh --direct fails with status 1.
  * In the journal, you should see that something (i.e., usermod) failed with `"vboxuser" user does not exist`

  [Testing for 26.04 guest]
  * Requirements
     - [ ] The host must run a version of VirtualBox that includes https://github.com/VirtualBox/virtualbox/pull/439.
  * Run the steps described in [How to reproduce] but use the resolute live server (or desktop) daily ISO and observe a successful installation.

  [Testing for 24.04 guest]
  * Requirements
     - [ ] Wait until a daily ISO of noble with support for user-creation before first boot is available.
     - [ ] The host must run a version of VirtualBox that includes https://github.com/VirtualBox/virtualbox/pull/439.
  * Run the steps described in [How to reproduce] but use the resolute live server (or desktop) daily ISO and observe a successful installation.

  [Workaround]
  https://bugs.launchpad.net/subiquity/+bug/2090834/comments/7

  [Additional info]
  Bug reports all have:

  * CasperMD5CheckResult: fail

  So they all ended up closed automatically. I created an exception so
  that such reports would not automatically get closed if they also
  have:

  * CasperMD5CheckMismatches: ./boot/grub/grub.cfg

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/2090834/+subscriptions