focal-arm64 install fails. No space left on device on /target
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
curtin |
Invalid
|
Undecided
|
Unassigned | ||
subiquity |
Fix Released
|
Critical
|
Unassigned | ||
probert (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
When installing Focal on arm64, once the actual installation stage is reached, subiquity fails with this terminal output:
https:/
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/
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:/
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.
Changed in curtin: | |
status: | New → Fix Committed |
Changed in curtin: | |
status: | Fix Committed → New |
Changed in subiquity: | |
status: | Confirmed → Fix Committed |
Changed in curtin: | |
status: | New → Incomplete |
Changed in probert (Ubuntu): | |
status: | New → Incomplete |
Changed in subiquity: | |
status: | Fix Committed → Fix Released |
This seems to be happening again :/ Logs attached. In curtin's install.log I see the following:
dpkg: error processing archive /tmp/apt- dpkg-install- 643qVf/ 19-linux- headers- 5.4.0-18_ 5.4.0-18. 22_all. deb (--unpack): src/linux- headers- 5.4.0-18/ tools/testing/ selftests/ sparc64/ drivers/ drivers_ test.sh' to '/usr/src/ linux-headers- 5.4.0-18/ tools/testing/ selftests/ sparc64/ drivers/ drivers_ test.sh. dpkg-new' : failed to write (No space left on device)
cannot copy extracted data for './usr/
but if I mount /dev/vda2 it's an almost empty filesystem:
Filesystem Size Used Avail Use% Mounted on
/dev/vda2 7.4G 34M 6.9G 1% /target
According to the kernel log the mount did happen at install time:
Mar 31 14:42:48 ubuntu-server kernel: [ 295.394200] EXT4-fs (vda2): mounted filesystem with ordered data mode. Opts: (null)
Subiquity's snapcraft.yaml currently points to one of the latest curtin commits, and the following commits do not seem related to the failure, at least at first glance. However I'm not sure on the exact version of curtin being used on the arm64 subiquity snap (LP: 865075).