This looks to be affected by rhbz#1753485.

There's a PR open to fix it: https://github.com/rhinstaller/anaconda/pull/2720

Also, I think we probably need an override here for Fedora IoT, since I don't think that flavor wants to switch to Btrfs just yet.

What is the partitioning scheme supposed to be by default? Ext4 with LVM?

I've submitted a PR to add an override for Fedora IoT: https://github.com/rhinstaller/anaconda/pull/2728

(cc: @chrismurphy, @dcavalca)

We don't want to switch to BTRFS at all, the BTRFS proposal was for desktops.

Hello, we have some problems with the identification of the IoT installations. The .buildstamp file from Fedora-IoT-IoT-ostree-x86_64-33-20200709.0.iso looks like this:

> cat /.buildstamp 
[Main]
Product=Fedora-IoT
Version=33
BugURL=your distribution provided bug reporting tool
IsFinal=True
UUID=202007091711.x86_64
Variant=IoT
[Compose]
Lorax=33.6-1

Does it mean that the official product name is "Fedora-IoT" and the version name is "IoT"? I know about the issue https://pagure.io/fedora-iot/issue/24, but it looks like a process thing. Why it should affect the .buildstamp file?

Not sure, what's the problem we need to fix?

The product is supposed to be Fedora rather than Fedora-IoT. Though now I have more questions, since the product is Fedora-IoT rather than Fedora, this should have never picked up the Btrfs change since I changed the Fedora product and this doesn't match to that.

Though now I have more questions, since the product is Fedora-IoT rather than Fedora, this should have never picked up the Btrfs change since I changed the Fedora product and this doesn't match to that.

The installer loads the configuration for Fedora if it is not able to find anything better for the current product and variant names. It is a hard-coded default (https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/core/configuration/anaconda.py#L221).

Not sure, what's the problem we need to fix?

I think that lorax should run with arguments --product "Fedora" --variant "IoT", so we can identify the IoT installations in the standard way (https://github.com/rhinstaller/anaconda/pull/2728/files).

We are able to support the current product name "Fedora-IoT" for the identification, but it is unusual, so I want to make sure that it is the right name and it is not going to change.

Can we please not make any hasty moves here? This is a complex area and I don't think everyone understands all of it.

There's a whole chain of products and standards and conventions involved here. The "Fedora-IoT" value starts out with these two settings - release_name and release_short - in the Pungi config for the IoT compose. IIRC we have always set those two values to be identical to each other in Fedora composes, but they may be different in RHEL composes (remember Pungi is used for Fedora and RHEL, we cannot only consider Fedora requirements).

Those config settings are used by Pungi for various purposes. To the productmd metadata standard they are the "release name" and "release short name", you can see them propagating into productmd metadata for example here (as the ["release"]["short"] and ["release"]["name"] values). The short name also forms part of the compose ID - Fedora-IoT-33-20200709.0 for that compose - which is made up of the release short name, the release number, the date, an indicator for the type (.n. or .t.) if it is not 'production', and the respin number.

Pungi passes the release name to lorax as the "product", and that's how it winds up in the .buildstamp file - lorax uses the "product" value when writing that file.

So these are fairly important and sensitive values we can't just go changing willy-nilly. I think it would be a very bad idea for us to have two different compose configs (and hence two different compose streams) with the same release name and/or same release short name. That isn't a thing that should happen.

I also don't think we should have this separate Fedora-IoT compose stream for Branched/Rawhide, but just changing that wouldn't mean this whole issue goes away. We have several separate compose streams and have had others in the past and will likely have more in the future, if @mattdm gets his way (e.g. a Fedora-Workstation stream and a Fedora-Server stream and so on). As I said above I don't think it is at all a good idea to give all these compose streams the same release name and/or same release short name, and it's pretty likely some or all of them will produce installer images.

We could I guess look at having pungi not use the release name as the --product value for lorax, that might restrict the scope to something manageable, but it's still not a straightforward idea.

So, bottom line, please look through this whole stack from top to bottom and understand it before proposing we change things :)

@adamwill @pbrobinson My PR to fix this was merged, so it'll make it into the next compose after Anaconda team cuts a release and pushes it to Rawhide.

Thanks @ngompa do we know if they have a schedule for the new build?

Unfortunately we just missed their last one, which was yesterday. I don't know if Anaconda could cut another one today. Ideally, they would, so that this can land ASAP.

@pbrobinson It landed today: https://koji.fedoraproject.org/koji/buildinfo?buildID=1542511

So expect this to be fixed with tonight's compose!

Thanks @ngompa I've tagged this into the IoT override and kicked a compose off to see how it goes

Looks like it went fine.

d'oh, sorry, just saw that's the wrong compose :P

There's still some issue here.

https://koji.fedoraproject.org/koji/taskinfo?taskID=47429850

This doesn't seem related to my change. The kickstart in there is already forcing plain partitions, something else is broken in oz/anaconda. :disappointed:

@chrismurphy filed that in Bugzilla already, and it's now marked as POST:

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