Bug 1477916 - Workstation boot.iso is 1.8 GB, seems to be ostree iso
Summary: Workstation boot.iso is 1.8 GB, seems to be ostree iso
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Václav Pavlín
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException AcceptedBlocker
Depends On:
Blocks: F27BetaFreezeException F27FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2017-08-03 08:15 UTC by Kamil Páral
Modified: 2017-10-17 20:01 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-17 20:01:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Kamil Páral 2017-08-03 08:15:52 UTC
Description of problem:
Petr Schindler noticed we released F26 with extremely huge Workstation's boot.iso. The problem persists even in Rawhide, so reporting as a bug (blocker?) against F27.

If you look at:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/
there is (at this moment):

[   ] Fedora-Workstation-netinst-x86_64-Rawhide-20170731.n.0.iso  2017-07-31 09:56  552M  
[   ] Fedora-Workstation-ostree-x86_64-Rawhide-20170731.n.0.iso  2017-07-31 16:41  1.8G  

and then if you look at:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/os/images/
there is (at this moment):
[   ] boot.iso  2017-07-31 16:41  1.8G  

It's pretty clear that boot.iso should be around those 500 MBs and not 1.8 GB. Also, the boot.iso seems to be the exactly same file as the ostree iso (same approximate size and timestamp). I haven't verified that (downloaded the images), so just speculating here.

This problem seems to be present just for Workstation.

I'm not sure whether this is a blocker or not (the composes are wrong, but I'm not sure it's covered in our criteria), proposing for discussion.

Comment 1 Kevin Fenzi 2017-08-03 16:43:34 UTC
This might be a pungi bug putting the ostree image in the wrong place. 

Adding lsedlar...

Comment 2 Lubomír Sedlář 2017-08-04 08:42:18 UTC
I did verify the images are identical.

The issue here is that both isos are created by running lorax. First lorax creates the boot.iso that is netinst, and Pungi hardlinks it in the iso/ directory with a pretty name.

Then the ostree one is created. It's actually put into a different location (under work/), but at the end the files are copied to the os/ directory and that overwrites what we had previously from creating the netinst.

This only happens in Workstation because that is the only variant that has both netinst and ostree installer isos.

I filed an upstream issue for this: https://pagure.io/pungi/issue/695

Comment 3 DO NOT USE account not monitored (old adamwill) 2017-08-08 22:27:24 UTC
I actually noticed this a couple of weeks ago and tried to poke people on #fedora-releng about it, but no-one followed up.

It is not just boot.iso that's affected: it also (and in fact more importantly, since you can always get the actual netinst ISO from the main location for it) affects the os/images/ directory, which similarly seems to come from the OStree compose rather than the network install compose. The install.img from this directory is what gets downloaded and loaded into memory as stage2 when doing a PXE boot install (or other direct kernel boot install). This means anyone doing a PXE install from the Workstation tree at least wastes a bunch of bandwidth downloading an oversized file, and needs more RAM than they should to actually complete an install (as the file is loaded into RAM)...and I think it also means that anyone doing a PXE install from the Workstation tree ends up with an OStree install, which is very likely not what they wanted. (I haven't checked that for absolutely sure, though).

Comment 4 Jan Kurik 2017-08-15 09:35:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 5 Adam Williamson 2017-08-20 16:31:36 UTC
Moving to proposed Beta blocker, as we're not doing an Alpha for F27.

Comment 6 Kamil Páral 2017-08-21 16:52:55 UTC
Discussed during blocker review [1]:

punt (delay decision) - there was a general feeling in favour of this being a blocker, but it does not clearly violate any existing criteria. we're delaying the decision until there are more folks to help come up with a plan, including release engineering

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-08-21/

Comment 7 Kamil Páral 2017-09-04 16:34:33 UTC
Discussed during blocker review [1]:

punt (delay decision) - we did not yet get around to testing this in more detail or drafting a revised criterion, so we will punt (delay) this one again and try to get it done this week

The things we need is:
1) test the pxe case 
2) draft some kind of criterion this might actually break
3) see how releng feels about it and if the fix is short-term viable

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-09-04/

Comment 8 Kamil Páral 2017-09-11 16:36:19 UTC
Discussed during blocker review [1]:

drop nomination - the Workstation ostree installer image has never been built in an F27 compose; until it is, this bug cannot happen to one. So we're dropping the nomination for now, but will immediately re-nominate it if the bug does start affecting F27 composes

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-09-11/

Comment 9 Lubomír Sedlář 2017-09-11 17:09:44 UTC
The compose configuration for Rawhide is updated to put the workstation ostree into a different location. Pungi got patched to not overwrite anything if the configuration wants that. Instead it will print an error message and abort (before actually doing anything). The patch is not yet released though.

Comment 10 Adam Williamson 2017-09-12 22:55:28 UTC
And as of the 20170912.n.0 compose we're getting Workstation ostree installer images again, and the bug is back:

https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20170912.n.0/compose/Workstation/x86_64/os/images/

note the size of boot.iso and install.img. So, I'm re-nominating this. We either need to disable compose of the Workstation ostree installer image till this is fixed, or just fix it ASAP.

Comment 11 Lubomír Sedlář 2017-09-13 05:55:20 UTC
This PR should fix it for F27 (the previous fix was only applied for Rawhide).
https://pagure.io/pungi-fedora/pull-request/354

Comment 12 Dennis Gilmore 2017-09-14 17:16:10 UTC
+1 to blocker

Comment 13 Adam Williamson 2017-09-15 02:02:58 UTC
Discussed at 2017-09-14 Beta Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2017-09-14/f27-beta-go-no-go-meeting.2017-09-14-17.00.html . We were still undecided on whether this violates any criteria, but we're happy to grant it a freeze exception at least. A fix for it is pending and we're expecting the next compose to have it solved, so we'll check in on that and close the bug if so.

Comment 14 Kamil Páral 2017-09-15 12:57:18 UTC
I just installed F26 Workstation from company PXE and got... F26 Workstation ostree system. So, it definitely affects PXE installations.

+1 Final blocker, in case it's not accepted as Beta blocker

Comment 15 Kamil Páral 2017-09-18 16:16:20 UTC
Discussed at blocker review meeting [1]:

RejectedBlocker (Beta) AcceptedFreezeException (Beta) AcceptedBlocker (Final) - People can easily end up installing ostree edition instead of standard edition by accident, which breaks user expectations of how installation works

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-09-18

Comment 16 Adam Williamson 2017-10-17 20:01:45 UTC
This is clearly resolved in current F27 and Rawhide composes by the separation of the OSTree image into its own variant.


Note You need to log in before you can comment on or make changes to this bug.