#695 ostree installer overwrites buildinstall output
Closed: Fixed 6 years ago Opened 6 years ago by lsedlar.

When a variant runs both buildinstall and ostree_installer phase, the outputs from the first lorax run are overwritten by the second one.

  1. lorax creates regular boot.iso
  2. pungi puts all outputs (images/, isolinux/, …) to <variant>/<arch>/os/
  3. boot.iso is hardlinked into <variant>/<arch>/iso/
  4. lorax runs for ostree installer, again creating similar outputs
  5. ostree boot.iso is hardlinked into <variant>/<arch>/iso/ (with a unique name, no problem here)
  6. all the files generated by lorax are copied into <variant>/<arch>/os/

This leads to situation where people looking at os/images/boot.iso might expect netinst image, but actually see the ostree installer.

Related bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1477916


There's actually a much more important consequence of this than boot.iso not being the expected file (that's really not terribly important, since the real network install image is easily available from its normal location): the contents of os/images/ are from the OStree compose, not the network install compose, which is bad for anyone doing a PXE boot install or other direct kernel boot install. See https://bugzilla.redhat.com/show_bug.cgi?id=1477916#c3 .

Proposed workaround in #700: when there already is netinst content, Pungi will no longer copy the ostree installer files there. That however means they will not be shipped (other than the ISO itself).

We need a place where to put it, maybe <variant>/<arch>/ostree/ would work (except that there would only be the boot stuff, not the ostree itself)?

We should either enforce a single buildinstall per variant, causing the Workstation Ostree to become its own variant, or we need to namespace secondary buildinstall runs

Using separate variant seems less disruptive than adding the namespace: the path to the files will change anyway, but the change is smaller. Also it's achievable without any code change: pungi-fedora#347

Pungi should however be changed to not allow the overwriting.

Metadata Update from @lsedlar:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 years ago

Metadata Update from @lsedlar:
- Issue tagged with: 4.1.19

6 years ago

Commit 7c237c2 relates to this ticket

Login to comment on this ticket.

Metadata