building pi image fails after "/proc/ not mounted" error

[Sam Lane]

I am just getting started experimenting with building Pi images to eventually produce a flavor image. I was attempting to build the default desktop raspi image. Possibly I am missing a step.

Tried from both a Pi4B 8Gb and also on a CM4, attempting from both Mantic and Jammy. Error is the same.

Using the following steps provided:
- sudo snap install --classic ubuntu-image
- git clone https://git.launchpad.net/ubuntu-images -b mantic
- sudo apt install livecd-rootfs
- sudo ubuntu-image classic -O output/ ubuntu-images/ubuntu-pi-arm64.yaml

The build failed with the following output:

sam@pi-cm4:~$ sudo ubuntu-image classic -O output/ ubuntu-images/ubuntu-pi-arm64.yaml
[0] parse_image_definition
[1] calculate_states
[2] make_temporary_directories
[3] determine_output_directory
[4] build_gadget_tree
[5] prepare_gadget_tree
[6] load_gadget_yaml
[7] verify_artifact_names
[8] germinate
[9] create_chroot
[10] install_packages
[11] prepare_image
[12] preseed_image
[13] customize_fstab
[14] perform_manual_customization
Error: Error running script "/usr/sbin/chroot /tmp/ubuntu-image-0cd0af45-5a65-4e87-9643-770072c93de5/chroot /usr/sbin/oem-config-prepare". Error is exit status 1. Full output below:
⚠️ /proc/ is not mounted. This is not a supported mode of operation. Please fix
your invocation environment to mount /proc/ and /sys/ properly. Proceeding anyway.
Your mileage may vary.
Created symlink /etc/systemd/system/oem-config.target.wants/oem-config.service → /lib/systemd/system/oem-config.service.
⚠️ /proc/ is not mounted. This is not a supported mode of operation. Please fix
your invocation environment to mount /proc/ and /sys/ properly. Proceeding anyway.
Your mileage may vary.
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled or disabled using systemctl.

Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.
⚠️ /proc/ is not mounted. This is not a supported mode of operation. Please fix
your invocation environment to mount /proc/ and /sys/ properly. Proceeding anyway.
Your mileage may vary.
Created symlink /etc/systemd/system/default.target → /lib/systemd/system/oem-config.target.
sudo: unknown user oem
sudo: error initializing audit plugin sudoers_audit

[Sam Lane (samlane00)]

So on an attempt starting with the server pi image instead of the desktop image, these steps completed without error.
Likewise, dropping to a TTY on the desktop image instead of using Gnome terminal / Tilix also works properly.

So I am assuming there is no issue here, aside from how I have been running it...

[Erich Eickmeyer (eeickmeyer)]

A workaround for this is simply, in the terminal, typing `unset DISPLAY` before execution. This is per comment by Steve in https://bugs.launchpad.net/ubuntu-image/+bug/2045336/comments/3. That said, it's possible that ubuntu-image could unset the variable itself which, theoretically, shouldn't leak to the rest of the environment. If not, then resetting it if it was set to begin with should be relatively trivial.

[Paul Mars (upils)]

As you can see in the image definition the call to oem-config-prepare is made with the "execute" manual customization. Users of ubuntu-image can call whatever they want here, so I think we cannot really know and account for every needs of these arbitrary scripts/binaries.

We could unset this variable in ubuntu-image, but it would be a hardcoded behavior for a specific use case in a script that should soon go away.

However, this is not the first time where being able to set/unset env var during manual customization would be useful. So at some point I would like to implement this to cleanly solve this kind of specific cases.

[Steve Langasek (vorlon)]

In the absence of a feature in ubuntu-image to manipulate the environment, does ubuntu-image support commandline arguments to its manual>execute command?

"/usr/bin/env -u DISPLAY /usr/sbin/oem-config-prepare" is the straightforward generic way to do this without particular ubuntu-image support.

[Steve Langasek (vorlon)]

According to ./internal/imagedefinition/README.rst, only "path" is supported, which is passed to

                executeCmd := execCommand("chroot", targetDir, c.ExecutePath)

execCommand() appears to expect a list of arguments, so passing "/usr/bin/env -u DISPLAY /usr/sbin/oem-config-prepare" as a single argument probably fails.

[Steve Langasek (vorlon)]

As features go, supporting passing args to the command to be manually executed is a lot more generally useful than manipulating the environment of that command.

Also, it looks like currently you can only specify a single command for manual execution, would be useful to be able to specify a list of commands to be run in order...

[Paul Mars (upils)]

I understand that at first the idea behind the "execute" customization was to keep it simple and not too powerful so users would be pushed to use a customization package. I do not know if we still want that but if we wanted this customization to be "feature-complete" I agree that we should:

- enable a list of commands to be executed
- enable command line parameters
- enable defining env vars

[Paul Mars (upils)]

See this PR See https://github.com/canonical/ubuntu-image/pull/188 improving the "execute" customization.