user133831's questions

I am installing Ubuntu 20.04 server via UEFI HTTP booting, subiquity and a NoCloud data source. The actual install works and I get the base OS running.

I also need to configure some things after installation is complete, or on first boot after the installer has rebooted however.

I have tried various things in user-data:

  write_files:
    - path: /target/etc/example.conf
      permissions: 644
      content: |
        example content
    - path: /target/var/lib/cloud/scripts/per-once/test.sh
      permissions: 755
      content: |
        #!/bin/sh
        date > /tmp/i_ran
        date
        echo test1
  runcmd:
    - echo test2 > /tmp/test2
    - cloud-init-per once testing echo test3
    - [ cloud-init-per, once, testing2, touch, /tmp/test4 ]
    - [ curtin, in-target, --target=/target, --, cloud-init-per, once, testing3, touch, /tmp/testing5 ]
  late-commands:
    - echo test5 > /target/etc/test5.conf
    - curtin in-target --target=/target -- cloud-init-per once testing9 touch /tmp/testing9

The commands run (as seen in the subiquity debug log) but nothing seems to leave a mark on the installed system. e.g. no files in /tmp or /etc and no messages in the post reboot logs that I have found. I have tried write_files with, and without /target before it.

What is the intended method to write arbitrary files on the target or run arbitrary commands after install?

I am trying to get an upstart job to start after both 2 other jobs have completed. As an example, I have debug.conf that looks like:

start on stopped networking and stopped screen-cleanup
task
script
    date
end script

I have added a date call at the end of screen-cleanup.conf's script, and at the beginning of networking's post-stopped script as well. The time stamps should allow me to see roughly what order things were run in.

I have rebooted several times now and the behaviour seems to be variable. Initially I found that the above "debug" job would run after "networking" but before "screen-cleanup" had finished (based on the date outputs). Since then I have tried various tests and found that similar conditions, but dependent on signals I was sending via initctl emit (to save me from having to reboot) rather than "stopped", work as expected.

To explore the behaviour at boot more I have created and removed various test jobs and now I find that the "debug" job does not run at all. I copied the conf file to another name and changed the "and" to an "or" and verified that that job does fire twice on boot.

I have looked at the cookbook but I can't see what I'm doing wrong. screen-cleanup is a task as well, if that makes a difference (its the file that came with the screen package apart from my additional call to date).

I'm running 13.10 though I'm hoping for something that works back to 12.04 LTS at worst.

EDIT: and after more reboots I'm back to the job triggering on the first thing to stop (networking), rather than the last (screen-cleanup). I can only assume there is an extra factor I'm not noticing.