curtin-dev team mailing list archive

[Michael Hudson-Doyle <mwhudsonlp@xxxxxxxxxxx>]

** Changed in: subiquity
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of curtin
developers, which is subscribed to curtin.
https://bugs.launchpad.net/bugs/1865027

Title:
  focal-arm64 install fails. No space left on device on /target

Status in curtin:
  Invalid
Status in subiquity:
  Fix Released
Status in probert package in Ubuntu:
  Invalid

Bug description:
  When installing Focal on arm64, once the actual installation stage is
  reached, subiquity fails with this terminal output:

  https://paste.ubuntu.com/p/6DWcxNdzPF/

  The curtin and subiquity-debug logs for the very same installation are
  attached. The error seems to be an ENOSPC in /target while curtin is
  running:

  Running command ['sh', '-c', 'mkdir -p "$2" && cd "$2" && rsync -aXHAS
  --one-file-system "$1/" .', '--', '/media/filesystem', '/target']

  but I think this is bogus, as /target is an 8GB partition which should
  be more than enough, and according to the curtin log the partition is
  correctly mounted:

  {
   "vdb2": {
    "ALIGNMENT": "0",
    "DISC-ALN": "0",
    "DISC-GRAN": "512",
    "DISC-MAX": "2147483136",
    "DISC-ZERO": "0",
    "FSTYPE": "",
    "GROUP": "disk",
    "KNAME": "vdb2",
    "LABEL": "",
    "LOG-SEC": "512",
    "MAJ:MIN": "252:18",
    "MIN-IO": "512",
    "MODE": "brw-rw----",
    "MODEL": "",
    "MOUNTPOINT": "",
    "NAME": "vdb2",
    "OPT-IO": "0",
    "OWNER": "root",
    "PHY-SEC": "512",
    "RM": "0",
    "RO": "0",
    "ROTA": "1",
    "RQ-SIZE": "256",
    "SIZE": "8050966528",
    "STATE": "",
    "TYPE": "part",
    "UUID": "",
    "device_path": "/dev/vdb2"
   }
  }

  Running command ['mount', '-t', 'ext4', '-o', 'defaults', '/dev/vdb2',
  '/target/'] with allowed return codes [0] (capture=True)

  Unfortunately it is not easy to monitor what's going on by asking
  subiquity to give us a shell, as when a shell is running *this problem
  doesn't happen*! At least this is what I observe systematically, and
  took me a while to figure out. If I drop to a shell then the
  installation still fails, but this time as described here:

  https://bugs.launchpad.net/curtin/+bug/1864992

  Likely a different issue.

  Given that when the problem happens it is not possible to regain
  control of subiquity and get a shell, and that monitoring the
  installation from a shell is not possible, in order to get the log
  files I had to setup two netcats in background before starting the
  installation and piped the logs out of the system.

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