Interrupting the build later than the load_gadget_yaml step creates broken images
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu Image |
Fix Released
|
High
|
Paul Mars |
Bug Description
When pausing ubuntu-image with the -u option to i.e. inspect the populated workdir and then resuming the image build always results in broken filesystems ...
To reproduce run an image build that stops with the -u option and define a workdir using the -w option like:
`ubuntu-image snap --debug -w workdir -u generate_disk_info ubuntu-
then simply restart the build using the -r option:
`ubuntu-image snap --debug -w workdir -r ubuntu-
results in the following:
```
$ LC_ALL=C sudo partx -av pi.img
partition: none, disk: pi.img, lower: 0, upper: 0
Trying to use '/dev/loop180' for the loop device
/dev/loop180: partition table type 'dos' detected
range recount: max partno=1, lower=0, upper=0
/dev/loop180: partition #1 added
$ LC_ALL=C sudo mount /dev/loop180p1 mnt/
mount: /home/ogra/
$
```
this is 100% reproducible on amd64 pc builds and arm64 pi builds, it seems to make no difference if the model assertion is "signed" or "dangerous"
this is slightly fatal since we have customers that need to inject certificate files for automatically onboarding their enterprise network on first boot (and they can not ship that cert in a snap for obvious reasons), if you want to add this file to the "systems/$DATE" directory, you can not use the "load_gadget_yaml" step to interrupt, but need to at least stop at "populate_
dmesg shows the following (but nothing more):
```
[25292407.714934] loop180: detected capacity change from 0 to 7168000
[25292445.112522] FAT-fs (loop180p1): bogus number of reserved sectors
[25292445.112526] FAT-fs (loop180p1): Can't find a valid FAT filesystem
```
description: | updated |
description: | updated |
Changed in ubuntu-image: | |
status: | New → Confirmed |
importance: | Undecided → High |
assignee: | nobody → Paul Mars (upils) |
tags: | added: foundations-todo |
Changed in ubuntu-image: | |
status: | Confirmed → In Progress |
Changed in ubuntu-image: | |
status: | In Progress → Fix Committed |
Changed in ubuntu-image: | |
status: | Fix Committed → Fix Released |
Hey Oliver,
This may not make sense for your use case, but were you able to reproduce after stopping at a different step than generate_disk_info? We already did some improvements on the resume feature in the past months but we may have missed something.