Anaconda modularization, install classes and addons

[Vendula Poncova]

Hello,

We would like to announce that we are moving forward with modularizing
Anaconda, which is a separate effort from the overall Fedora
modularization work. We have been talking about it for the last year,
the general concept was introduced at [1] and now it is time to start
with the implementation.


What is Anaconda modularization?

Anaconda will be split into several modules that will communicate over
DBus. The goal is to introduce a stable way to interact with Anaconda
to support its customization, extensibility and testability. It will
be easier to monitor the installation, maintain an install class or an
addon, drop some modules or provide your own UI.


Will it affect your work? Let us know!

If you maintain an Anaconda extension (install class, addon), please
let us know. This is especially important if you depend on the latest
Anaconda (rawhide, master branch). First, we would like to know how
you use Anaconda in your extension. Second, we can help you keep your
extension functional over the following months. Third, we can help you
with the transition to the new Anaconda once it is stable and ready.


Want to know more?

You can follow our work on modularization on our blog [2] and GitHub
[3]. We also have a mailing list [4] and the IRC channel #anaconda on
freenode. Your feedback is always welcomed!


Have a nice day,
Vendy


[1] https://rhinstaller.wordpress.com/2017/10/09/anaconda-modularisation/
[2] https://rhinstaller.wordpress.com/
[3] https://github.com/rhinstaller/anaconda
[4] https://www.redhat.com/mailman/listinfo/anaconda-devel-list

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Changing Anaconda Installation Source Spoke GUI

[Vendula Poncova]

Hi,

thanks for interesting ideas! I like the suggested UI changes for P1
and P2. I think it makes sense to separate additional repositories
from the installation source. However, I am not so sure about the
solution for P3. Shouldn't the install class enable the repositories?

We plan to move the logic for the installation source on DBus soon.
All big changes should be probably done after that.

Vendy

On Tue, Apr 24, 2018 at 9:12 PM, Pat Riehecky  wrote:
> Hello Anaconda folks,
>
> I'd like to get a conversation going about the Installation Source Spoke
> GUI.
>
> If this looks viable, I can do a lot of the non-i18n of the work. But
> I'd like to test out the thoughts before diving into the code.
>
> My biggest need is to show users there are other repos they could
> activate.
> This conversation is really about the UI workflow (inspired by PR#1323).
>
> I've got an addon that does a fair job of showing these to users, but
> I'd rather get some of my behavior upstream instead of continuing to
> port the SL anaconda addon.
>
> == Background ==
> The Spoke GUI is trying to do two actions:
>  1. Locate the install tree
>  2. Configure additional repositories
>
> The TUI Spoke is only trying to do (1.) Locate the install tree.
>
> I like the GUI layout of - 1. Locate the install tree.
> All of that looks great and works for me and my user base
> and is consistent between TUI and GUI.
>
> It is the second one - 2. Configure additional repositories - that I'd
> like to reimagine.  It is only available within the GUI.
>
> Configure additional repositories is itself divided into two behaviors:
>  A. Enable/Disable updates.repo
>  B. Create other repos for use
>
> Behavior A. "Enable/Disable updates.repo" has an obvious use case.
>
> Behavior A. is visible to:
>  - Fedora
>  - Scientific Linux
>
> Behavior A. repo can be enabled/disabled via the InstallClass.
>
> Behavior B. "Create other repos for use" is used to add additional repos
> such as ELRepo or EPEL (under EL builds) or Addons such as HA.
>
> Behavior B. is visible to:
>  - Fedora
>  - RHEL
>  - CentOS
>  - Scientific Linux
>  - Springdale Linux
>  - Etc
>
> Behavior B. is populated with entries from .treeinfo under:
>  - RHEL ISO 7 (High Availability, Resilient Storage)
>  - Scientific Linux 7 (Bugfixs, Extras, Repos)
>  - Springdale Linux 7 (Computational, Updates, Addons)
>
> The Behavior B. repos are disabled by default.  Additional repos
> can be seeded by the InstallClass now too.
>
> == Problem ==
>
> P1. If you don't have an install tree specified, when you click
> on "Installation Media", there are no extra repos listed.
> This means the workflow for enabling the Behavior B. repos for
> a netinstall with no set install tree is as follows:
>  Step 1. Click on "Installation Media" and set the install tree
>  Step 2. Click done to validate the install tree
>  Step 3. Click on "Installation Media" again to review additional repos
> The User Experience for Step 3 here is unexpected.
>
> P2. Folks who are looking for the Additional repos don't click on
> "Installation Media" to look for them. If install media is found and
> working, my users don't expect to find them under a "Media" item.
> With nothing broken and nothing requiring interaction, they just don't click
> it.
>  . The RHEL7 addons are on the media, but users are unaware
>  . With the liner install from "old anaconda" users saw these repos
>  . Fedora could possibly put the Cisco H264 and modularity repo here
>  . As an SL maintainer I'd like users to see the repose we've added
>  . I assume the Springdale folks would also like the higher visibility
>  . The CentOS SIGs could be listed here where folks could see them
>
> P3. Repos imported from .treeinfo/InstallClass have no clear way to be
> automatically activated by the InstallClass.
> . SL updates are in 'security' and 'fastbugs' repos, not just 'updates'
> . CERN folks expect some packages to be loaded from a specific repo
>
> == Existing Solutions ==
>
> anaconda-addon-org_scientificlinux_contexts (Solves P2 and P3)
>  The lack of clicks on "Installation Media" was a major driver for
>  creating the Scientific Linux Context Anaconda plugin.
>  I am the primary maintainer of this addon.
>
> updates.img (Solves P3)
>  The CERN folks have an updates.img that forces the CERN repo into the
>  installroot, activates it, and adds a hook in firstboot (locmap) to
>  tweak settings.
>
> == Proposal ==
>
> === UI Workflow (Solve P1 and P2) ===
> Move Action 2. "Configure additional repositories" into a separate Spoke.
>
> Basically this is just chopping sourceWindow in half and moving the behavior
> to another (non-mandatory) Spoke.
> (from pyanaconda/ui/gui/spokes/installation_source.glade)
>
> I propose the name "Additional Software".
>
> I'd like to talk about moving "Install Updates" over here as in this
> workflow "Updates" becomes yet another repo.  Having it activated by
> default for Fedora and SL feels like a 

Re: Question on Anaconda rpmostree payload

[Vendula Poncova]

Hi Colin,

On Thu, May 30, 2019 at 2:47 PM Colin Walters  wrote:

> > > On Tue, May 28, 2019 at 1:04 PM  wrote:
> >
> > >>  We are doing bigger rewrite of the Anaconda and we have a problem
> with
> > >>  the moving sysroot of rpmostree payload.
>
> Is there any more background on this?  Is there an outstanding pull
> request?
>
>
the problem is that we need to somehow inform our DBus modules about the
current path to the system root and that we will have to somehow monitor
whether a DBus module doesn't want to change this path. We could write a
DBus support for that, but we don't think that it is a good idea, because
we don't want to advertise this option.

>
> >  As you know the payload more
> > >>  then we and most of all you know rpmostree I wanted to ask you about
> > >>  the solution.
> > >>
> > >>  Right now the sysroot of the rpmostree is changing during the
> > >>  installation. The code for the sysroot handling changed and we would
> > >>  like to simplify the logic, by having the sysroot on static place all
> > >>  the time.
> > >>
> > >>  >From the commit message I know there is a deployment and physical
> root.
> > >>  The problem is however that you have to change to the other during
> the
> > >>  installation. We would like to avoid this.
>
> This is a complex topic.  I am not sure we can entirely avoid the code
> having
> to support both.
>
> Ultimately, the libostree code is designed to support being invoked from
> *outside* the system (as anaconda does), as well as *inside* the system
> (like `rpm-ostree upgrade` does in a booted system).  This is all of course
> quite symmetrical with yum's --installroot model, except ostree needs to
> handle more things (e.g. the bootloader config is owned by it).
>
> These original commits are relevant:
>
> https://github.com/storaged-project/blivet/commit/5b39c90ae582a8fb008c3633954a33b58394802c
>
> https://github.com/rhinstaller/anaconda/commit/0bbc9adf41b33062bbbfe478b3373a3404de21aa
>
> > >>  If we can avoid changing the sysroot that would be best but in other
> > >>  case I came with an idea of a bind mount. So when the mount is not in
> > >>  the "correct" place we can bind mount the other folder there.
> > >>  However, that could complicate other things.
>
> I want to say that in the past we did a bind mount and switched to
> moving...I had thought the change was in lorax but I can't find it now.
> (...a few more minutes pass with some invocations of `git log
> --grep=ostree` and `git log --grep=mount`...).
>
> Ah ok, see:
>
> https://github.com/rhinstaller/anaconda/commit/664ef7b43f9102aa9332d0db5b7d13f8ece436f0
>
> Are you thinking we basically invert things and basically do mount --rbind
> /mnt/sysroot/...deploy/$checksum ?
> The main issue with that is that the bootloader writing happens *after*
> kickstart processing and the bootloader code in rpmostreepayload assumes
> that it's looking at the physical root right now, but that may not be hard
> to change.
>
>
Thanks for the info and the links. It was very helpful.

I think that we have found a solution that might work. Basically, there
will be two mount points: /mnt/sysimage for the physical root and
/mnt/sysroot for the system root. Then it is simple to remount /mnt/sysroot
withount changing /mnt/sysimage.

This idea is already implemented at:
https://github.com/rhinstaller/anaconda/pull/1996

I have tested several use cases and it seems to work fine so far.

What do you think about it?

Vendy


> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: adding PowerNV as a new PPC machine type in the installer (rhbz#1303219)

[Vendula Poncova]

On Mon, Jun 10, 2019 at 1:56 PM Dan Horák  wrote:

> Hi,
>
> there is a request for not installing the PReP partition on PPC system
> that don't really require it in bug 1303219 [1]. I've spend some time
> working on it and I think I have the solution, see [2] for details.
> Because the testing requires a bare-metal Power machine I'm now thinking
> how to allow testing it with the community in the least intrusive way.
> Right now my plan is to have the anaconda PR merged and use an
> updates.img for the corresponding blivet change. This way anaconda
> itself should work as before and only when used with the updates.img it
> should change the behaviour. What do you think?
>
>
Hello Dan,
the changes for anaconda seem to be safe and reasonable, so I think we
could merge them if you want to.

As Jirka suggested, it is also possible to create one updates image with
anaconda and blivet changes. I can help you with that.

Vendy


>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1303219
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1303219#c5
>
>
> With regards,
>
> Dan
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: "PRE-RELEASE/TESTING"

[Vendula Poncova]

On Mon, Sep 2, 2019 at 9:56 AM Danishka Navin  wrote:

> Hi Jirka,
>
> I used the following command but did't use --product and --version at all.
> Btw, does livecd-creator read from /etc/os-release when we ignore both
> --product and --version?
>
> livecd-creator --verbose --config=hanthana-live-workstation.ks
> --fslabel=h30 --cache=cache --tmpdir=tmp
>
> Then I copied fresh kisktars shipped by fedora and rerun with my custom
> configs.
> I could not reproduce the issue.
>
> I wonder if the issue caused by following entries in the /etc/os-release
> file.
>
> REDHAT_BUGZILLA_PRODUCT="Fedora"
> REDHAT_SUPPORT_PRODUCT="Fedora"
>
>
> Btw, there is a new issue occurred.
> As in this image, Anaconda keeps duplicating the values of redhat-release
> file.
> I am not sure if its a bug or I mage a mistake.
>
> https://pasteboard.co/IvvT4nf.png
>
> Added Hanthana Workstation (Vishwa)' in to the redhat-release file.
> https://pasteboard.co/IvvSiU5.png
>
> If you have digital at the end, it only repeats the digit.
> When using "Hanthana 30"
> https://pasteboard.co/IvvTyBT.png
>
>
> On Mon, Sep 2, 2019 at 1:06 PM  wrote:
>
>> Hello,
>>
>> You have probably used bad parameters when you were invoking lorax. You
>> have to use correct --product and --version parameters otherwise we will be
>> handling your ISO as Rawhide.
>>
>> Could you please tell us what command did you used to create your ISO?
>>
>> Regards,
>> Jirka
>>
>> On Sat, 2019-08-31 at 18:12 +0530, Danishka Navin wrote:
>>
>> Hi there,
>>
>> When I was trying to install f30 based remixed ISO,
>> "PRE-RELEASE/TESTING" text appearing in top-right hand side of anaconda GUI.
>> May I know what could cause this?
>>
>>
Hello,

for Live ISO, there is a little crazy logic that sets up the flag for a
final release:
https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93

Basically, it is determined by a version of a package that provides
system-release, so I would check that.

What is the output of these commands, when you run them on your ISO?
rpm -q  --whatprovides system-release
rpm -q --qf '%{Release}' --whatprovides system-release

Vendy


> both os-release and redhat-release updated and I can see given values.
>> both fedora and fedora-update repos used during the ISO build along with
>> few 3rd party repos.
>>
>> Regards,
>> --
>> Danishka Navin
>>
>>
>>
>>
>>
>> ___
>>
>> Anaconda-devel-list mailing list
>>
>> Anaconda-devel-list@redhat.com
>>
>>
>> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>>
>> ___
>> Anaconda-devel-list mailing list
>> Anaconda-devel-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
>
>
> --
> Danishka Navin
>
>
>
>
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: "PRE-RELEASE/TESTING"

[Vendula Poncova]

On Tue, Sep 3, 2019 at 7:29 PM Danishka Navin  wrote:

>
>
> On Tue, Sep 3, 2019 at 6:16 PM Vendula Poncova 
> wrote:
>
>>
>> On Mon, Sep 2, 2019 at 9:56 AM Danishka Navin  wrote:
>>
>>> Hi Jirka,
>>>
>>> I used the following command but did't use --product and --version at
>>> all.
>>> Btw, does livecd-creator read from /etc/os-release when we ignore both
>>> --product and --version?
>>>
>>> livecd-creator --verbose --config=hanthana-live-workstation.ks
>>> --fslabel=h30 --cache=cache --tmpdir=tmp
>>>
>>> Then I copied fresh kisktars shipped by fedora and rerun with my custom
>>> configs.
>>> I could not reproduce the issue.
>>>
>>> I wonder if the issue caused by following entries in the /etc/os-release
>>> file.
>>>
>>> REDHAT_BUGZILLA_PRODUCT="Fedora"
>>> REDHAT_SUPPORT_PRODUCT="Fedora"
>>>
>>>
>>> Btw, there is a new issue occurred.
>>> As in this image, Anaconda keeps duplicating the values of
>>> redhat-release file.
>>> I am not sure if its a bug or I mage a mistake.
>>>
>>> https://pasteboard.co/IvvT4nf.png
>>>
>>> Added Hanthana Workstation (Vishwa)' in to the redhat-release file.
>>> https://pasteboard.co/IvvSiU5.png
>>>
>>> If you have digital at the end, it only repeats the digit.
>>> When using "Hanthana 30"
>>> https://pasteboard.co/IvvTyBT.png
>>>
>>>
>>>
Anaconda reads the product name and the product version from
/etc/system-release on Live ISO or from the .buildstamp file in network
installations. See my comment about the .buildstamp file below. I think
that all these problems are related.


> On Mon, Sep 2, 2019 at 1:06 PM  wrote:
>>>
>>>> Hello,
>>>>
>>>> You have probably used bad parameters when you were invoking lorax. You
>>>> have to use correct --product and --version parameters otherwise we will be
>>>> handling your ISO as Rawhide.
>>>>
>>>> Could you please tell us what command did you used to create your ISO?
>>>>
>>>> Regards,
>>>> Jirka
>>>>
>>>> On Sat, 2019-08-31 at 18:12 +0530, Danishka Navin wrote:
>>>>
>>>> Hi there,
>>>>
>>>> When I was trying to install f30 based remixed ISO,
>>>> "PRE-RELEASE/TESTING" text appearing in top-right hand side of anaconda 
>>>> GUI.
>>>> May I know what could cause this?
>>>>
>>>>
>> Hello,
>>
>> for Live ISO, there is a little crazy logic that sets up the flag for a
>> final release:
>>
>> https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93
>>
>> Basically, it is determined by a version of a package that provides
>> system-release, so I would check that.
>>
>> What is the output of these commands, when you run them on your ISO?
>> rpm -q  --whatprovides system-release
>> rpm -q --qf '%{Release}' --whatprovides system-release
>>
>
>
> $ rpm -q  --whatprovides system-release
> fedora-release-workstation-30-900.noarch
> $ rpm -q --qf '%{Release}' --whatprovides system-release
> 900[
>
>
It seems to be correct. The liveinst script should set the environment
variable ANACONDA_ISFINAL to True before Anaconda is started.

Network installations use the IsFinal attribute of the .buildstamp file to
determine the value of the flag, but Live ISO shouldn't have this file and
should use ANACONDA_ISFINAL instead. The path to the .buildstamp file can
be /.buildstamp, /tmp/product/.buildstamp or set by the environment
variable PRODBUILDPATH. Could you check that these files do not exist on
your ISO?

Otherwise, I would recommend to report a bug at https://bugzilla.redhat.com/
and attach the Anaconda logs from the installation.


>
>
>> Vendy
>>
>>
>>> both os-release and redhat-release updated and I can see given values.
>>>> both fedora and fedora-update repos used during the ISO build along
>>>> with few 3rd party repos.
>>>>
>>>> Regards,
>>>> --
>>>> Danishka Navin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>>
>>>> Anaconda-devel-list mailing list
>>>>
>>>> Anaconda-devel-list@redhat.com
>>>>
>>>>
>>>> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>>>>
>>>> ___
>>>> Anaconda-devel-list mailing list
>>>> Anaconda-devel-list@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>>>
>>>
>>>
>>> --
>>> Danishka Navin
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Anaconda-devel-list mailing list
>>> Anaconda-devel-list@redhat.com
>>> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>>
>> ___
>> Anaconda-devel-list mailing list
>> Anaconda-devel-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
>
>
> --
> Danishka Navin
>
>
>
>
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Discussion: what would not blocking on btrfs look like?

[Vendula Poncova]

On Fri, Sep 6, 2019 at 3:02 AM Adam Williamson 
wrote:

> On Tue, 2019-09-03 at 13:38 -0400, David Lehman wrote:
> > On Fri, 2019-08-23 at 12:16 -0700, Adam Williamson wrote:
> > > Hey folks!
> >
> > Hi Adam! Thanks for bringing this up again.
> >
> > > So...what should we do? Here are the options as I see 'em:
> > >
> > > 1. Keep supporting btrfs
> > > 2. Just modify the criterion with a btrfs exception, even if it's
> > > weird
> > > 3. Rewrite the criterion entirely
> > > 4. Keep btrfs support in the installer (and blivet-gui) but hide it
> > > as
> > > we used to - require a special boot argument for it to be visible
> > > 5. Drop btrfs support from the installer
> >
> > I like option 3 most. The current criteria have always seemed, to me,
> > too vague. I'd be happy to help hash out the details if/when it
> > happens.
>
> Thanks for the offer.
>
> So aside from the 'fun' of drafting very specific rules, my concern
> with #3 is we would then potentially be shipping an installer that
> presents things as roughly equal choices which are not in fact equally
> supported. You can pick 'btrfs' or 'ext4' from the dropdown...but one
> of those we commit to making sure is working, one of them we don't.
>
> That to me is concerning; in this scenario I'd prefer we indicate
> somehow, somewhere, that all the choices are not equally guaranteed to
> be reliable. WDYT?
>

Hi Adam,

I think that the best option is to add a new storage validation check that
will report a warning if a user wants to use a file system that is not
recommended by the installed product. The list of recommended file systems
would be provided by the Anaconda configuration files, so products and
variants could override it.

We already show warnings with recommendations, for example for too small
root partition or missing swap. The storage validation checks are run for
every type of partitioning, results are logged and warnings have to be
waved by the user in the interactive mode.

Vendy


> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: CoreOS vs Anaconda toolchain

[Vendula Poncova]

On Mon, Sep 9, 2019 at 4:53 PM Pat Riehecky  wrote:

> This does indeed sound interesting.
>
> Anaconda is one of the more complex bits of software I've worked with.
> It does a lot various things with a fair bit of flexibility.
>
> My thoughts after 20 seconds of reflection (aka, not thought through at
> all):
>
> I wonder if it might make sense to converge on something driven by a
> more modern workflow and tooling?  From one perspective
> Anaconda/Ignition are system setup tools.  Might it make sense to begin
> leveraging some of the automation tools to do some of this setup?  Or to
> put another way: Could anaconda/ignition begin to transition into a well
> defined Ansible workflow where the UI sets parameters?  For as much as I
> love kickstart, a YAML formatted document might lend itself to templates
> and easier transition to/from cloud providers
>
>
Hi Pat,

Lars was looking into that for the osbuild. The problem is that Ansible
doesn't have support for systems that are kind of dead (no running services
etc.). However, I think that it would be a great way of sharing code with
other system setup and system building tools.

Vendy


> Pat
>
>
>
>
> On 9/6/19 3:46 PM, Colin Walters wrote:
> > Hi, I wanted to link this here:
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_coreos_coreos-2Dassembler_issues_91=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=7G9J0U8mTAU7eDMuir3ky8hsJEHjBhllLrpArag0ztw=
> > Most importantly starting from
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_coreos_coreos-2Dassembler_issues_91-23issuecomment-2D422830233=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=ZmL0ktGZ4gBP1Cgpmz9QL3MbvKhOQLxZFTNj8ligiEQ=
> > and the most recent ones.
> >
> > Would love to do some brainstorming about how we can share more
> code/ideas in general; I had some specific comments towards the end.
> >
> > One thing not explicitly noted there is how key Ignition is to FCOS (and
> derivatives like RHCOS) - having a common language that works in both bare
> metal as well as e.g. AWS and Azure is a big deal - and today the OpenShift
> 4 installer and the [machine-config-operator](
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openshift_machine-2Dconfig-2Doperator_=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=k-SXz0DOZeNsrdkDpZyg244dxo6akCX9r_RzkPHRIqY=
> ) are built heavily upon it.
> >
> > ___
> > Anaconda-devel-list mailing list
> > Anaconda-devel-list@redhat.com
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_anaconda-2Ddevel-2Dlist=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=hsNc4HvS01zWyo0UIHCxG87CGdpaMvaAlve6TA8iFeY=
>
> --
> Pat Riehecky
>
> Fermi National Accelerator Laboratory
> www.fnal.gov
> www.scientificlinux.org
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Discussion: what would not blocking on btrfs look like?

[Vendula Poncova]

On Mon, Sep 9, 2019 at 5:10 PM Adam Williamson 
wrote:

> On Mon, 2019-09-09 at 15:19 +0200, Vendula Poncova wrote:
> > On Fri, Sep 6, 2019 at 3:02 AM Adam Williamson <
> adamw...@fedoraproject.org>
> > wrote:
> >
> > > On Tue, 2019-09-03 at 13:38 -0400, David Lehman wrote:
> > > > On Fri, 2019-08-23 at 12:16 -0700, Adam Williamson wrote:
> > > > > Hey folks!
> > > >
> > > > Hi Adam! Thanks for bringing this up again.
> > > >
> > > > > So...what should we do? Here are the options as I see 'em:
> > > > >
> > > > > 1. Keep supporting btrfs
> > > > > 2. Just modify the criterion with a btrfs exception, even if it's
> > > > > weird
> > > > > 3. Rewrite the criterion entirely
> > > > > 4. Keep btrfs support in the installer (and blivet-gui) but hide it
> > > > > as
> > > > > we used to - require a special boot argument for it to be visible
> > > > > 5. Drop btrfs support from the installer
> > > >
> > > > I like option 3 most. The current criteria have always seemed, to me,
> > > > too vague. I'd be happy to help hash out the details if/when it
> > > > happens.
> > >
> > > Thanks for the offer.
> > >
> > > So aside from the 'fun' of drafting very specific rules, my concern
> > > with #3 is we would then potentially be shipping an installer that
> > > presents things as roughly equal choices which are not in fact equally
> > > supported. You can pick 'btrfs' or 'ext4' from the dropdown...but one
> > > of those we commit to making sure is working, one of them we don't.
> > >
> > > That to me is concerning; in this scenario I'd prefer we indicate
> > > somehow, somewhere, that all the choices are not equally guaranteed to
> > > be reliable. WDYT?
> > >
> >
> > Hi Adam,
> >
> > I think that the best option is to add a new storage validation check
> that
> > will report a warning if a user wants to use a file system that is not
> > recommended by the installed product. The list of recommended file
> systems
> > would be provided by the Anaconda configuration files, so products and
> > variants could override it.
> >
> > We already show warnings with recommendations, for example for too small
> > root partition or missing swap. The storage validation checks are run for
> > every type of partitioning, results are logged and warnings have to be
> > waved by the user in the interactive mode.
>
> This could work, however it's what I'd call "backwards UI" (I'm sure
> there's a real term for it, but I'm not an expert so I don't know what
> it is) - it's a pattern I find annoying because it makes you make
> choices *before you know what the constraints are*, then tells you you
> broke the mystery rules you didn't know about. ;) It's like password
> systems that just say 'enter a password', then you enter one, and
> *then* it says 'oh BTW it's meant to have more than 8 characters', so
> you enter one with more than 8 characters and it says 'oh yeah and one
> of them has to be upper case', so you upper case one, then it says 'oh
> yeah and one has to be a special character', then you shoot the PC and
> go herd yaks...:P
>

Warnings inform you about potential risks of your choices, but you are
allowed to ignore them unlike the error messages you are talking about. It
is like, when you enter a password with non-ASCII characters, the password
system can say 'be careful, you might not be able to switch a keyboard
layout when typing it', but you can still go ahead and use your password
anyway.

I would expect that users in general know what they are doing (I thought
that is the premise of the Custom Partitioning Spoke), so I understand the
warning about unsupported file systems as a disclaimer.

-- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: sd-boot for UEFI installs

[Vendula Poncova]

On Tue, Jun 30, 2020 at 6:24 PM Jóhann B. Guðmundsson 
wrote:

> Hi
>
> I'm looking into the scope of replacing grub2 with sd-boot for UEFI
> installs in Fedora and I'm wondering how such a change would affect
> Anaconda and if Anaconda is capable of detecting if legacy bios settings
> is in use and if so install and setup grub2 and if not install and setup
> sd-boot.
>
>
Could someone from the bootloader team look into this, please?

Vendy


> Thanks
>
>   JBG
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: F33: preview swap-on-ZRAM using zram-generator feature change

[Vendula Poncova]

On Sun, Jun 28, 2020 at 10:10 PM Chris Murphy 
wrote:

> Hi,
>
> This change has been approved. There are still some details to work
> out. What do Anaconda folks think for the custom partitioning use case
> where the use manually creates disk-based swap? Should and could the
> installer then also do:
>
> 'touch /etc/systemd/zram-generator.conf'
>
> post install? The effect is to disable the zram-generator and there'd
> be only disk-based swap. The alternative outcome without this is
> they'll have both swap-on-zram with a higher priority than the
> swap-on-disk they created.
>
> I'm open to suggestions. I think it's mainly a question about what you
> think the user expects in this situation. That's hard to answer
> because the user expects disk based swap as a long standing
> convention. And there is no convention for either swap-on-zram yet, or
> two swap devices, even though the kernel has supported up to 32 swap
> devices since forever.
>
> The best experience performance wise would be to have the two swaps.
> They gain from swap-on-zram at first, and perhaps mostly. Followed by
> the secondary use of disk based swap. But I'm not opposed to disabling
> zram-generator in this case. It is a more conservative option and
> might better square with expectations.
>
>
Hi Chris,

we have discussed it and we don't really have a strong preference. Enabling
both seems like a slightly better choice, because the installed systems
won't be so different. As far as I know, the hibernation will still work
and, as you said, the performance should be better. The generator can be
always disabled in a %post script of a kickstart file or after booting into
the installed system.

Vendy


>
> Thanks,
>
> Chris Murphy
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Making anaconda disable some storage-related systemd services in post-install config part of livecd install?

[Vendula Poncova]

On Tue, Jun 30, 2020 at 7:01 PM Brian C. Lane  wrote:

> On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote:
> > So 2 questions:
> >
> > 1. What do you think of my proposal to disable these
> > services (when not needed) in the livecd post-install
> > config phase? Would you be willing to accept a
> > merge-req for this?
>

Hi Hans,

I prefer the original plan proposed in the Fedora changes. Let the dmraid
service to disable itself on the first run and remove the
device-mapper-multipath package from Live CD.

The idea of handling this in Anaconda is definitely interesting. As Vojta
suggested, it would make more sense to remove unneeded packages at the end
of the installation. We already track a request to remove the anaconda
packages, so it is a use case that we plan to support in the future. It
wouldn't require the mapping of storage packages to service names, which I
find very fragile. However, it won't be trivial to implement such support
in a robust and meaningful way and we are not really there yet. We are in a
process of modularizing the Anaconda code and there are some missing pieces
that we need to move with this further.

> 2. Its been a long time since I last touched the
> > anaconda code, my python is quite rusty and my
> > plate is way too full, so I was wondering if one
> > of you could implement this if we chose to go this
> > route?
>
> I think implementing this may be even easier. Anaconda runs post-script
> snippets from /usr/share/anaconda/post-scripts/*ks at the end of every
> install. The livecd could drop in a script to handle disabling these, I
> think.
>
>
I agree with Brian. If you want to go this way, then the best option is a
post script. I guess that the script would be generated by the file
https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-base.ks that
belongs to the component spin-kickstarts. It means that no change is needed
in Anaconda.

You should probably talk to someone from Fedora Silverblue in this case,
because they are trying to be as close to Fedora Workstation as possible.

Vendy

Current scripts are here:
>
> https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts
>
> Brian
>
> --
> Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: F33: preview swap-on-ZRAM using zram-generator feature change

[Vendula Poncova]

On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy  wrote:

> Hi,
>
> I am confused. For default partitioning, the idea is to no longr
> create a swap partition, instead there will be both zram-generator and
> zram-generator-defaults packages, which will cause a swap on
> /dev/zram0 to be created during early boot.
>
> When I look in https://pagure.io/fedora-kickstarts all of the ks files
> that contain 'autopart' also contain '--noswap'. Yet Workstation
> edition and others, do have a swap partition created. Suggestions?
>
>
Hi,

the kickstart files from fedora-kickstarts
 are used for Fedora release images.
They don't define the default partitioning of new installations. Is there a
problem with the partitioning on these images?

Default partitioning of new installations is defined in Anaconda:
https://github.com/rhinstaller/anaconda/blob/master/data/anaconda.conf#L16

The change seems to be approved. Can I open a pull request for the changes
in the Anaconda configuration files?

Vendy


>
> Thanks,
>
> Chris Murphy
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Making anaconda disable some storage-related systemd services in post-install config part of livecd install?

[Vendula Poncova]

On Thu, Jul 9, 2020 at 2:03 PM Hans de Goede  wrote:

> Hi,
>
> On 7/9/20 1:06 PM, Neal Gompa wrote:
> > On Thu, Jul 9, 2020 at 7:02 AM Hans de Goede 
> wrote:
> >>
> >> Hi,
> >>
> >> On 7/8/20 12:01 PM, Vendula Poncova wrote:
> >>> On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede  <mailto:hdego...@redhat.com>> wrote:
> >>>
> >>>  Hi,
> >>>
> >>>  On 6/30/20 6:59 PM, Brian C. Lane wrote:
> >>>   > On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote:
> >>>   >> So 2 questions:
> >>>   >>
> >>>   >> 1. What do you think of my proposal to disable these
> >>>   >> services (when not needed) in the livecd post-install
> >>>   >> config phase? Would you be willing to accept a
> >>>   >> merge-req for this?
> >>>   >>
> >>>   >> 2. Its been a long time since I last touched the
> >>>   >> anaconda code, my python is quite rusty and my
> >>>   >> plate is way too full, so I was wondering if one
> >>>   >> of you could implement this if we chose to go this
> >>>   >> route?
> >>>   >
> >>>   > I think implementing this may be even easier. Anaconda runs
> post-script
> >>>   > snippets from /usr/share/anaconda/post-scripts/*ks at the end
> of every
> >>>   > install. The livecd could drop in a script to handle disabling
> these, I
> >>>   > think.
> >>>   >
> >>>   > Current scripts are here:
> >>>   >
> >>>   >
> https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts
> >>>
> >>>  Yes that would be an option, although getting the list of pkgs
> >>>  which are deemed as being necessary for the configured storage
> >>>  (and thus should not have their services disabled) might be
> >>>  tricky to do from such a post-install script ?
> >>>
> >>>  Anyways, going by Vojtěch's reply, there are no objections to
> >>>  removing device-mapper-multipath from the livecd. And it will be
> >>>  quite easy to make the dmraid-activation service disable itself
> >>>  if no dmraid sets are found (it already is a shell script).
> >>>
> >>>  So I believe it would be best to move forward with this as
> >>>  I original proposed in the 2 change pages:
> >>>
> >>>  https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun
> >>>
> https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD
> >>>
> >>>  This requires almost no anaconda changes as mentioned in another
> >>>  part of the thread, the hard-dep on device-mapper-multipath needs
> >>>  to be dropped. But with some luck that is all that is required
> >>>  on the anaconda side.
> >>>
> >>>
> >>> The anaconda's dependency on device-mapper-multipath is caused by
> fcoe-utils:
> >>>
> >>> anaconda -> anaconda-install-env-deps -> fcoe-utils ->
> device-mapper-multipath
> >>>
> >>> Is it expected that the support for FCoE devices will be dropped from
> Live OS?
> >>
> >> That was not part of the Change proposal, but having FCoE support in the
> >> Workstation LiveCD makes about as much sense as having multipath
> support, so
> >> I believe that dropping it is fine. I can amend the Change proposal to
> mention
> >> this.
> >>
> >>> If yes, it shouldn't be a problem to change the dependency on
> fcoe-utils to weak.
> >>
> >> If you can do that, then that would be great. But I believe that dnf
> includes
> >> weak deps by default. I must admit that it is a long time since I've
> done
> >> anything wrt livecd composes. Is there a way to explicitly exclude some
> weak
> >> deps when doing composes, or are they excluded by default now a days?
> >>
> >> I guess I should just re-learn how to do composes and do a compose to
> make
> >> sure things turn out as we want. Is there a short primer on how to do a
> livecd
> >> compose these days somewhere?
> >>
> >
> > If you set them as excluded in the live media kickstart files, they'll
> > be properly excluded. I fixed this some time ago so that even weak
> > installs would not take effect in this scenario.
> >
> > So you'd probably want to add a "-fcoe-utils" line to %packages in
> > fedora-live-base.ks:
> > https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-base.ks
>
> Ok, this sounds good. Anaconda-team, can one of you turn the fcoe-utils
> dep into a weak-dep then and let me know when a build with that change
> has been done.
>
>
https://github.com/rhinstaller/anaconda/pull/2722


> Once that is in place I will make and test the necessary change to the
> fedora-live-base.ks file.
>
> Regards,
>
> Hans
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: F33: preview swap-on-ZRAM using zram-generator feature change

[Vendula Poncova]

On Thu, Jul 9, 2020 at 1:36 PM Neal Gompa  wrote:

> On Thu, Jul 9, 2020 at 7:33 AM Vendula Poncova 
> wrote:
> >
> > On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy 
> wrote:
> >>
> >> Hi,
> >>
> >> I am confused. For default partitioning, the idea is to no longr
> >> create a swap partition, instead there will be both zram-generator and
> >> zram-generator-defaults packages, which will cause a swap on
> >> /dev/zram0 to be created during early boot.
> >>
> >> When I look in https://pagure.io/fedora-kickstarts all of the ks files
> >> that contain 'autopart' also contain '--noswap'. Yet Workstation
> >> edition and others, do have a swap partition created. Suggestions?
> >>
> >
> > Hi,
> >
> > the kickstart files from fedora-kickstarts are used for Fedora release
> images. They don't define the default partitioning of new installations. Is
> there a problem with the partitioning on these images?
> >
> > Default partitioning of new installations is defined in Anaconda:
> >
> https://github.com/rhinstaller/anaconda/blob/master/data/anaconda.conf#L16
> >
> > The change seems to be approved. Can I open a pull request for the
> changes in the Anaconda configuration files?
> >
>
> That would be very helpful, thanks!
>
>
https://github.com/rhinstaller/anaconda/pull/2723


>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Making anaconda disable some storage-related systemd services in post-install config part of livecd install?

[Vendula Poncova]

On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede  wrote:

> Hi,
>
> On 6/30/20 6:59 PM, Brian C. Lane wrote:
> > On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote:
> >> So 2 questions:
> >>
> >> 1. What do you think of my proposal to disable these
> >> services (when not needed) in the livecd post-install
> >> config phase? Would you be willing to accept a
> >> merge-req for this?
> >>
> >> 2. Its been a long time since I last touched the
> >> anaconda code, my python is quite rusty and my
> >> plate is way too full, so I was wondering if one
> >> of you could implement this if we chose to go this
> >> route?
> >
> > I think implementing this may be even easier. Anaconda runs post-script
> > snippets from /usr/share/anaconda/post-scripts/*ks at the end of every
> > install. The livecd could drop in a script to handle disabling these, I
> > think.
> >
> > Current scripts are here:
> >
> > https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts
>
> Yes that would be an option, although getting the list of pkgs
> which are deemed as being necessary for the configured storage
> (and thus should not have their services disabled) might be
> tricky to do from such a post-install script ?
>
> Anyways, going by Vojtěch's reply, there are no objections to
> removing device-mapper-multipath from the livecd. And it will be
> quite easy to make the dmraid-activation service disable itself
> if no dmraid sets are found (it already is a shell script).
>
> So I believe it would be best to move forward with this as
> I original proposed in the 2 change pages:
>
> https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun
>
> https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD
>
> This requires almost no anaconda changes as mentioned in another
> part of the thread, the hard-dep on device-mapper-multipath needs
> to be dropped. But with some luck that is all that is required
> on the anaconda side.
>
>
The anaconda's dependency on device-mapper-multipath is caused by
fcoe-utils:

anaconda -> anaconda-install-env-deps -> fcoe-utils ->
device-mapper-multipath

Is it expected that the support for FCoE devices will be dropped from Live
OS?
If yes, it shouldn't be a problem to change the dependency on fcoe-utils to
weak.

Vendy

Regards,
>
> Hans
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: F33: preview swap-on-ZRAM using zram-generator feature change

[Vendula Poncova]

On Thu, Jul 9, 2020 at 5:22 PM Chris Murphy  wrote:

> On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy 
> wrote:
> >
> > One item I haven't worked through yet is how 'inst.zram' should
> > inhibit the zram-generator. The generator runs during early boot.
> >
> > My current thinking is 'inst.zram' can just 'systemctl stop
> > swap-create@zram0.service' since it will exist already. In that case
> > it could optionally be renamed to 'inst.nozram'. What do you think?
> >
> > I think the timing of the changes isn't very critical. If the release
> > images have zram-generator first, it will run sooner and the Anaconda
> > implementation will fail (error messages in logs, but otherwise
> > non-fatal). Whereas if the Anaconda implementations go away first, the
> > lack of swap on zram in low memory situations might cause problems.
>
>
I have opened a draft for the Anaconda zram service. It will be marked as
blocked until it is safe to merge it:
https://github.com/rhinstaller/anaconda/pull/2727



> I've opened an issue with upstream zram-generator folks. Igor suggests
> they could parse for 'inst.zram' or 'inst.nozram' and inhibit the
> creation of swap-on-zram.
>
> https://github.com/systemd/zram-generator/issues/42
>
>
> --
> Chris Murphy
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: F33: preview swap-on-ZRAM using zram-generator feature change

[Vendula Poncova]

On Fri, Jul 10, 2020 at 6:14 PM Chris Murphy 
wrote:

>
>
> On Thu, Jul 9, 2020, 12:58 PM Chris Murphy 
> wrote:
>
>> Use zram-generator instead of zram
>> https://pagure.io/fedora-comps/pull-request/513
>>
>> Replace 'zram' with 'zram-generator', and exclude Cloud edition
>> https://pagure.io/fedora-kickstarts/pull-request/658
>
>
>
>
> Those have been accepted. Anaconda PR #2723 and #2727 can happen anytime.
>
>
Ok.


> About inst.zram
> https://github.com/systemd/zram-generator/issues/42
>
> Another possibility is to just deprecate it. If swap is really not needed,
> zram device won't be used. There's no RAM preallocated for the zram device.
> If it is needed, it gets used on demand, and prevents reclaim. Pretty much
> win win.
>
>
>
I have talked about it with the team and we prefer the deprecation of the
inst.zram option. The zram-generator can always introduce its own option if
there is a demand for it.

Vendy

---
> Chris Murphy
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Query about rhinstaller/anaconda#2651

[Vendula Poncova]

Hi,

David is right, the logic is the same as before. The possible fixes of the
name and the description are discussed at
https://github.com/rhinstaller/anaconda/pull/2691.

Vendy

On Fri, Jun 26, 2020 at 4:26 AM David Lehman  wrote:

> On Thu, 2020-06-25 at 21:29 -0400, Neal Gompa wrote:
> > Hey all,
> >
> > So I was looking at the Anaconda commits today, and I saw this
> > change[1] land, which changes how default partitioning is set up. The
> > change is somewhat confusing to me, because it _seems_ like it makes
> > it so that we suddenly are encrypting swap and other volumes by
> > default in Fedora, and I don't recall anyone asking for that to
> > happen.
> >
> > Admittedly, this change is a bit ambiguous when compared to what the
> > code looked like before, but the comment that says "the mount point
> > will be encrypted" makes me think that setting "(encrypted)" will
> > actually encrypt by default.
> >
> > Can someone please help me understand what's going on here?
>
> Assuming it works like the old code did, "will be encrypted" actually
> means "will be encrypted if the user specifies _encrypted_ automatic
> partitioning".
>
> People of the snake, please correct me if I'm wrong.
>
> HTH
>
> >
> > Thanks in advance!
> >
> > [1]:
> >
> https://github.com/rhinstaller/anaconda/commit/d6df9b3c597b14a8e12fafaacc2765d24c6bdce2
> >
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: F33: preview swap-on-ZRAM using zram-generator feature change

[Vendula Poncova]

On Thu, Jul 16, 2020 at 7:13 AM Chris Murphy 
wrote:

> I've tested some images and this is going OK for the Live ISOs, but
> the boot.iso based images like netinstallers and dvds (silverblue,
> Server DVD) for some reason do not have zram-generator-defaults on
> them. Therefore those installation environments don't have a
> swap-on-zram setup.
>
> I see the 'Recommends: zram-generator-defaults'
>
> https://src.fedoraproject.org/rpms/anaconda/blob/master/f/anaconda.spec#_187
>
> Yet that's somehow not enough? Nor is it enough that
> zram-generator-defaults is in @standard, to get it onto all the
> install media?
>
>
It looks like lorax doesn't install weak dependencies. I have opened a new
pull request to fix the boot.iso:
https://github.com/weldr/lorax/pull/1048


> Related PRs
> https://pagure.io/fedora-comps/pull-request/513
> https://pagure.io/fedora-kickstarts/pull-request/658
>
> So far the installed OS's from these do have zram-generator-defaults
> installed, and the swap-on-zram device is up and running OK. The one
> installation that doesn't have it is the 'Custom Fedora' (I think this
> is also known as minimal package set) installation I used when doing
> an Everything netinstall installation.
>
>
> ---
> Chris Murphy
>
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Scoping out the change needed for Anaconda to support resizing Btrfs filesystems

[Vendula Poncova]

On Fri, Nov 13, 2020 at 2:22 PM  wrote:
>
> Hello Michel,
>
> It's great to see community help for the BTRFS features! We will try to
> help you to get the work done as smooth as possible.
>
> First advice. If you need help with debbuging or questions about code
> just come to our #anaconda on freenode IRC and you should be able to
> get answers soon (GMT +1, Czech Republic timezone).
>
> For the rest see my replies below.
>
>
> On Thu, 2020-11-12 at 17:11 -0800, Michel Alexandre Salim wrote:
> > Dear Anaconda developers,
> >
> > There's this 7 year old bug about Anaconda not being able to resize
> > Btrfs filesystems, despite Btrfs itself supporting resizing.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=962143
> >
> > Now that Fedora defaults to Btrfs on desktop variants, since Facebook
> > uses Fedora as its preferred desktop Linux distribution we might be
> > able to dedicate some manpower to working on this, but need help to
> > scope out this work.
> >
> > Would any change needed be limited to python-blivet, or would other
> > components need to be touched?
>
> I didn't looked on the code but I expect that you have to take care of
> both blivet and Anaconda to fix the RFC.
>

Hello,

this change should affect only the "Reclaim Disk Space" dialog. Is it
correct? In that case, its scope depends on the Blivet's
implementation. If the btrfs partition can be resizable the same way
as any other resizable partition, no changes should be needed in
Anaconda. Otherwise, it might be necessary to modify our
implementation, extend the DBus API or change the user interface.

I'm adding Vojta Trefny to CC.

Vendy

> >
> > Also, what's the best way to test this, build Anaconda from the
> > master
> > branch and use it for our installation?
>
> Building is too unpleasant experience for testing. Ideally you should
> be using updates image feature[1]. Updates image is just an image (or
> tar) which is upacked and files in it will replace files in the
> installation environment. Until you need to touch Dracut code (not
> expected here) you should be fine to generate updates image, upload to
> a HTTP server and boot with inst.updates. You can also replace blivet
> by this. See my blog post about Anaconda debugging for more details[2].
> My recommended way is to use the make-updates wrapper[3] mentioned as
> the last part in blog post. Also for any other questions please feel
> free to ask :).
>
>
> Aside of this. This is a great candidate for Pure Community Feature[4].
> If possible, could you or someone else please maintain this feature in
> Anaconda so there will be contact on someone who can fix the feature if
> it breaks?
>
> [1]:
> https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-updates
> [2]:
> https://rhinstaller.wordpress.com/2019/10/11/anaconda-debugging-and-testing-part-1/
> [3]:
> https://github.com/rhinstaller/devel-tools/tree/master/anaconda_updates
> [4]:
> https://anaconda-installer.readthedocs.io/en/latest/contributing.html#pure-community-features
>
> Best Regards,
> Jirka
>
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: netinstall image finds network, but seems unable to connect in F34 and F35

[Vendula Poncova]

On Thu, Jun 24, 2021 at 9:46 PM stan  wrote:

> I wanted to install F35 from the nightly netinstall image.  But, when I
> tried to install, it hung with both the F34 official, and F35 20210622
> iso image.  I was using optical media.
>
> If I started with the network up, it would hang forever at the language
> selection page.  If I then closed the network, it would proceed to the
> hub page.  If I then restarted the network, the software selection
> items would cycle forever.  In both cases, the message on tty4 was
> something like
> DEBUG NetworkManager ... ndisc [ethernet device] solicit next scheduled
> solicitation is in xxx seconds
> The solicitation time would double for every iteration.  It seems like
> it is looking in the wrong place.  I could ping the DNS servers from
> tty2, and the network spoke said the network was up.
>
> I thought that I could do a minimal install from the network install
> media if there was no network connection.  So, I selected that option
> in the software selection screen.  When I verified it, it said the
> media was valid to install from.  But that was not the case.  This also
> cycled forever.  In asking about this on the test list, I was informed
> that the install.img on the netinstall media is only for running, and
> not installing.  I *was* able to successfully install using the server
> everything ISO as the install repository.
>
> Chris Murphy suggested that I mention both of these issues here.
>
>
Hi, could you please report a bug on bugzilla and attach there all files
with installation logs (especially the file named syslog)? You can find
them during the installation in /tmp or on the installed system in
/var/log/anaconda/. It would help us to figure out the problem.

Vendy

___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/anaconda-devel-list
>
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/anaconda-devel-list

Re: btrfs compression by default

[Vendula Poncova]

On Tue, Feb 9, 2021 at 10:42 AM  wrote:
>
> Hi everyone,
>
> I see a few options for this. First is to add this directly to blivet
> library as you pointed out already. However, I don't think blivet
> developers would be happy about that because they are trying to be as
> much as possible general purpose library and this change is really just
> about Anaconda.
>
> Another option seems to be to modify Anaconda code directly.
> Unfortunately, I can't tell from top of my mind how hard that would be
> but still seems like the easiest solution.
>
> However, the best approach which I can think of is to add something
> like that to our configuration files. Benefit would be that another
> modifications like that could be done easily in the future. That is of
> course for a discussion for the Anaconda team because it could be
> pretty hard to implemented this in some common form.
>
> Vendy, Vojta, do you have some better ideas or could you tell us
> something more about my ideas above?
>
> Best Regards,
> Jirka
>
> On Tue, 2021-02-09 at 01:18 -0500, Neal Gompa wrote:
> > On Tue, Feb 9, 2021 at 1:09 AM Michel Alexandre Salim
> >  wrote:
> > >
> > > Hi,
> > >
> > > On Mon, 2021-02-08 at 21:02 -0700, Chris Murphy wrote:
> > > > Hi,
> > > >
> > > > This is in regards to this Fedora 34 change:
> > > > https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#Scope
> > > >
> > > > The gist is to do 'mount -o compress=zstd:1' anytime Btrfs is
> > > > used,
> > > > whether Destination Installation>Automatic or Custom or
> > > > Advanced-Custom. Apply it during the installation, and add it to
> > > > /etc/fstab.
> > > >
> > > > Somehow I got confused thinking that autopart supports --
> > > > fsoptions,
> > > > and that would be the way to do this. But (a) --fsoptions isn't
> > > > supported with autopart, and (b) it wouldn't be a universal
> > > > approach
> > > > anyway. And we want this to be consistent. Now I'm thinking it
> > > > needs
> > > > to go somewhere in:
> > > >
> > > > https://github.com/storaged-project/blivet/blob/3.4-devel/blivet/devices/btrfs.py
> > > >
> > > > Am I on the right track, or does it need to go somewhere else, or
> > > > in
> > > > addition to that?
> > > >
> > > (I'm one of the change owners, and trying to figure this out with
> > > Chris).
> > >
> > > Ideally we have a solution that is configurable - i.e. this is
> > > exposed
> > > via a kickstart command (and probably entailing changes in Anaconda
> > > and
> > > pykickstart), but if that is not possible, or require a lot of
> > > rework
> > > (which we can try to work on), if we are willing to carry a patch
> > > for
> > > blivet or some other component to override the behavior just for
> > > Fedora
> > > 34, what's the best way of achieving that?
> > >
> > > Btrfs is probably the only filesystem with built-in compression
> > > that we
> > > potentially care about, so designing an interface to expose this
> > > functionality might be an overkill -- but we're not sure.
> > >
> >
> > Eventually, VDO might get integrated into the mainline tree, so
> > having
> > the interface which could be used for LVM compression through VDO
> > wouldn't be too bad.
> >
> >
> >
>
>

Hello!

The change says: "On variants using btrfs as the default filesystem,
enable transparent compression using zstd." It means that the
compression has to be configurable per product, so we need to add a
new configuration option to the Anaconda configuration files
(something like btrfs_compression_enabled = True). I guess you planned
to use interactive-defaults.ks, but we are going to replace this file
with the configuration files anyway.

I have checked the Blivet's code and we might be able to redefine the
_mount_class attribute of the BTRFS class. The mount class defines
default mount options. That should be enough to fix all partitioning
methods. What do you think, Vojta?

Vendy

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: [RESCUE] Take long time to pass the disks scanning and checks

[Vendula Poncova]

Hi,

you can use the ignoredisk kickstart command to skip scans and checks of
disks that won't be used during the installation:
https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#ignoredisk

Alternatively, you can clear your disks in the %pre section of the
kickstart file.

Vendy

On Mon, Apr 19, 2021 at 1:40 PM Giuseppe Della Bianca 
wrote:

> Hi.
>
> It would be useful during rescue or installation to be able to decide on
> which
> disk or partition anaconda will perform the scans and checks.
>
> For example in my system there are several additional disks with many
> btrfs
> subvolumes, and anaconda takes a very long time to pass the disk scanning
> and
> checks phase.
>
> gdb
>
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/anaconda-devel-list
>
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/anaconda-devel-list

Re: btrfs compression by default

[Vendula Poncova]

On Tue, Feb 16, 2021 at 3:16 AM Michel Alexandre Salim
 wrote:
>
> Hi Jiří, Vendula, all,
>
> On Tue, 2021-02-09 at 12:12 +0100, Vendula Poncova wrote:
> > On Tue, Feb 9, 2021 at 10:42 AM  wrote:
> > >
> > > Hi everyone,
> > >
> > > I see a few options for this. First is to add this directly to blivet
> > > library as you pointed out already. However, I don't think blivet
> > > developers would be happy about that because they are trying to be as
> > > much as possible general purpose library and this change is really
> > > just
> > > about Anaconda.
> > >
> > > Another option seems to be to modify Anaconda code directly.
> > > Unfortunately, I can't tell from top of my mind how hard that would
> > > be
> > > but still seems like the easiest solution.
> > >
> > > However, the best approach which I can think of is to add something
> > > like that to our configuration files. Benefit would be that another
> > > modifications like that could be done easily in the future. That is
> > > of
> > > course for a discussion for the Anaconda team because it could be
> > > pretty hard to implemented this in some common form.
> > >
> > > Vendy, Vojta, do you have some better ideas or could you tell us
> > > something more about my ideas above?
> > >
> > > Best Regards,
> > > Jirka
> > >
> > > On Tue, 2021-02-09 at 01:18 -0500, Neal Gompa wrote:
> > > > On Tue, Feb 9, 2021 at 1:09 AM Michel Alexandre Salim
> > > >  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Mon, 2021-02-08 at 21:02 -0700, Chris Murphy wrote:
> > > > > > Hi,
> > > > > >
> > > > > > This is in regards to this Fedora 34 change:
> > > > > > https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#Scope
> > > > > >
> > > > > > The gist is to do 'mount -o compress=zstd:1' anytime Btrfs is
> > > > > > used,
> > > > > > whether Destination Installation>Automatic or Custom or
> > > > > > Advanced-Custom. Apply it during the installation, and add it
> > > > > > to
> > > > > > /etc/fstab.
> > > > > >
> > > > > > Somehow I got confused thinking that autopart supports --
> > > > > > fsoptions,
> > > > > > and that would be the way to do this. But (a) --fsoptions isn't
> > > > > > supported with autopart, and (b) it wouldn't be a universal
> > > > > > approach
> > > > > > anyway. And we want this to be consistent. Now I'm thinking it
> > > > > > needs
> > > > > > to go somewhere in:
> > > > > >
> > > > > > https://github.com/storaged-project/blivet/blob/3.4-devel/blivet/devices/btrfs.py
> > > > > >
> > > > > > Am I on the right track, or does it need to go somewhere else,
> > > > > > or
> > > > > > in
> > > > > > addition to that?
> > > > > >
> > > > > (I'm one of the change owners, and trying to figure this out with
> > > > > Chris).
> > > > >
> > > > > Ideally we have a solution that is configurable - i.e. this is
> > > > > exposed
> > > > > via a kickstart command (and probably entailing changes in
> > > > > Anaconda
> > > > > and
> > > > > pykickstart), but if that is not possible, or require a lot of
> > > > > rework
> > > > > (which we can try to work on), if we are willing to carry a patch
> > > > > for
> > > > > blivet or some other component to override the behavior just for
> > > > > Fedora
> > > > > 34, what's the best way of achieving that?
> > > > >
> > > > > Btrfs is probably the only filesystem with built-in compression
> > > > > that we
> > > > > potentially care about, so designing an interface to expose this
> > > > > functionality might be an overkill -- but we're not sure.
> > > > >
> > > >
> > > > Eventually, VDO might get integrated into the mainline tree, so
> > > > having
> > > > the interface which could be used for LVM compression through VDO
> > > > wouldn't be too bad.
> > > >
> >