Re: Spin maintainers attention required! Anaconda keyboard layout switching needs to change

[jkonecny]

Adding anaconda-devel list too.

On Thu, 2021-04-29 at 12:26 +0200, jkone...@redhat.com wrote:
> Hi everyone,
> 
> I've just filed a bug with all the details about the topic so we can
> start discussion there:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1955025
> 
> 
> I gave a short summary here.
> 
> The libxklavier library will be deprecated from a future Fedora (it
> doesn't mean Fedora 35!). Anaconda and InitialSetup are using this
> library to be able to read and switch keyboard layouts. We need to
> find
> a proper replacement and for that I need to get ideas from Fedora
> Spin
> maintainers. I don't know your environment good enough to decide what
> would be best for your spin.
> 
> Please if you have an idea how to approach this issue. Tell us
> ideally
> in the bug. Thanks for everyone for your input!
> 
> 
> Best Regards,
> Jirka from Anaconda team
> 


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

Re: livemedia-creator lorax customizing question

[jkonecny]

Hi Niene,

As far as I know there is no easy way how to move files between mock
environment and live DVD. Reason for that is it's kind a installation
in chroot or VM.

However, this is a question on Brian C. Lane who is the maintainer of
LMC on Anaconda question. Adding him here explicitly if he is able to
tell you more.

Best Regards,
Jirka

On Sun, 2021-04-04 at 11:21 +0200, Niene Rink wrote:
> Hello,
> since yesterday i am a step further.
> 
> from a post which is closed:
> 
> https://github.com/weldr/lorax/issues/197
> 
> a guy describes exact my problem. Brian answers and closed this
> threat
> with the info to use --add-arch-template.
> 
> I recognize, that lmc has not the parameter, so how to use his
> parameter with lmc?
> 
> So i look into the default arch templates, i found a
> section, but this section is not in the template which
> livemediacreator
> uses (under /live/x86...).
> 
> so i add this section in the 
> usr/share/lorax/templates.d/99-generic/live/x86.tmpl
> 
> template. Cause i am not familar with the mako language, after trial
> and error a lot, i set the workdir, which is not set in the live
> tmpl,
> to "." in the live/x68.tmpl.
> 
> i create an iso-graft in my mock chroot root-dir and move a testfile
> inside.
> 
> build the live iso and, voila, its there, but not where i am expect
> it.
> As i remember correctly, it was in the /run/ tree, not in the
> root
> filesystem.
> 
> 
> I still try to search a method to put files into the live os tree.
> 
> i am able to create a directory there (with  the post section of the
> flatten ks file) but i am not able to move a file from mock-chroot
> inside that directory.
> 
> So, is there an easy way to move files to a liveos with lmc from a
> mock environment?
> 
> Greetings from germany and keep healthy,
> Jörn Rink
> 
> ___
> 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: anaconda source install and configure

[jkonecny]

Hello Fred,

Solving dependencies for Anaconda is quite unfriendly and because of
that we have a universal solution on master now. I would recommend you
to use our container which has all the dependencies already to build
rpm files.

If you want to use the container for the build follow these steps:

cd anaconda
make -f Makefile.am container-shell   # This will download our
container from our repository and run shell in it

./autogen.sh && ./configure
make rpms                                       # Shortcut in our
Makefile to build rpm files

`CTRL+d` to exit the container

Your rpm files are placed in ./result/build/01-rpm-build/



However, if you don't want to use our container I would suggest you to
use `dnf builddep ./anaconda.spec` to install all the dependencies.
Unfortunately, you have to run `./autogen.sh && ./configure`` first.

Hope the above will help you. In case you have more questions ideally
stop by at #anaconda on freenode IRC.

Best Regards,
Jirka 
 

On Tue, 2021-03-30 at 15:41 +1100, Fred 1 wrote:
> oh duh, because i was just extracting the source tars and using them,
> totally ignored the .spec file,
> so dependencies listed in there
> but I still have a problem
> 
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating doc/Makefile
> config.status: creating glade/Makefile
> config.status: creating src/Makefile
> config.status: creating python/Makefile
> config.status: creating config.h
> config.status: config.h is unchanged
> config.status: executing depfiles commands
> config.status: executing libtool commands
> 
> *** Anaconda encountered the following issues during configuration:
> Unable to use python library
> 
> *** Anaconda will not successfully build without these missing
> dependencies
> so now the missing dependencies fixed but, the error is now weird ?
> what missing dependencies now?
> cause nothing is listed
> 
> 
> 
> 
> 
> ___
> 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: Anaconda startup blocked

[jkonecny]

Hello,

To be able to help you, we need more information. In general in CentOS
Stream there shouldn't be any InstallClasses but from what you wrote
here I'm not sure if you are using CentOS Stream or different CentOS
variant.

Ideally please file a bug in https://bugzilla.redhat.com/ and send
reply here with the link to the bug.

Best Regards,
Jirka

On Tue, 2021-03-30 at 18:22 +0800, yangtao wrote:
> Hi Sir,
> 
> While I installing CentOS, X server start up failed, and falling back
> to text mode.
> Unfortunately, the anaconda is blocked, and the last message is about
> installclass.
> Is there possible anaconda blocked on installclass?
> 
> 
> Best Regards!
> Tao
> 
> 
>  
> ___
> 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

[jkonecny]

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.
> 
> 
> 


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

Fwd: Re: Fedora 34 Change: Ignore Anaconda kernel boot parameters without 'inst.' prefix (System-Wide change)

[jkonecny]

Hi everyone,

Forwarding this message from the fedora-devel list also to our anaconda
devel list to spread the message a bit more.

Best Regards,
Jirka

 Forwarded Message 
From: jkone...@redhat.com
To: Development discussions related to Fedora
, devel-annou...@lists.fedoraproject.org
Subject: Re: Fedora 34 Change: Ignore Anaconda kernel boot parameters
without 'inst.' prefix (System-Wide change)
Date: Tue, 02 Feb 2021 17:47:16 +0100

Hello everyone,

We've created patch to require 'inst.' prefix for all Anaconda kernel
boot arguments. To make transition smoother  warnings will stay there.
That means that you will get warning but the argument will be ignored
and not processed by Anaconda.

Pull request for the change:
https://github.com/rhinstaller/anaconda/pull/3136

We want to give everyone a bit more time, so we are planning to merge
this in two days. If you have any objections please feel free to write
those to the pull request.

Best Regards,
Jirka Konecny

On Mon, 2020-12-07 at 10:45 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Ignore_Anaconda_kernel_boot_parameters_without_inst_prefix
> 
> == Summary ==
> Right now Anaconda allows usage of boot options both with the 'inst'
> prefix (inst.stage2=) and without (stage2=). We would like to ignore
> the use of Anaconda kernel boot parameters which do not contain the
> 'inst.' prefix.
> 
> == Owner ==
> * Name: [[User:jkonecny| Jiří Konečný]]
> * Email: 
> 
> 
> == Detailed Description ==
> Anaconda allows you to use kernel boot parameters with and without
> the 'inst.' prefix right now (e.g. inst.repo= / repo=). However,
> specifying boot parameters without the 'inst' prefix has not been
> recommended for years and has been deprecated since Fedora 33. We
> (Anaconda team) would like to make it an official requirement now
> that users must specify the 'inst.' prefix all the time.
> 
> The reason for this is frequent parameter conflicts with other
> projects. We already had a few issues with conflicts in the past,
> such as if the user ran an installation with `debug`. In that case
> the installation boot would enable debug mode for the kernel and also
> for Anaconda which is probably not what the user intended.
> Another reason is to make it readable at first glance what belongs to
> Dracut (rd.), kernel (no prefix) or Anaconda (inst.). 
> 
> == Feedback ==
> We have sent mail about doing the deprecation on Fedora 33. The only
> issue there was why the prefix is 'inst.' and not 'anaconda.'.
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/43LKTJOUO5TB7LGFWPRNXOYLEQF3KLGG/#ENTHA45Y6VO45FAD4ULPSHCTOXPML3PA
> 
> == Benefit to Fedora ==
> This change should make crystal clear what kernel boot parameters are
> processed by the Anaconda installer.
> It will also avoid conflicts with other kernel boot parameters.
> 
> == Scope ==
> * Proposal owners: Remove support to process arguments without the
> 'inst.' prefix and require the 'inst.' prefix for kernel boot
> parameters consumed by Anaconda.
> 
> * Other developers:
> All configurations using the not-recommended solution without prefix
> will have to change the invocation of the kernel boot options
> consumed by Anaconda. These users are already warned since Fedora 33
> after boot.
> This should not be a problem for ISOs we ship because they already
> use the recommended 'inst.' prefix everywhere. However, it will
> probably touch some custom PXE configurations and other custom ISO
> configurations which are prone to this, because users often want to
> save typing and not explicitly write the 'inst.' prefix. Fortunately,
> most of these configuration changes shouldn't be that hard to change.
> 
> * Release engineering: [https://pagure.io/releng/issue/9889 #9889] 
> * Policies and guidelines: This should not be required. All the
> documentation should use the recommended 'inst.' prefix already.
> * Trademark approval: No (not needed for this Change)
> * Alignment with Objectives: No
> 
> 
> == Upgrade/compatibility impact ==
> If your custom infra configuration is not updated then new Fedora
> installations could not install correctly. Most probably the ISO will
> not boot (use of 'stage2=') or your repositories won't be used (use
> of 'repo=').
> 
> 
> == How To Test ==
> # You need a Virtual Machine and ISO for testing.
> # Boot the installation using the ISO and try Anaconda specific
> kernel boot parameters. See here to find out the list
> https://anaconda-installer.readthedocs.io/en/latest/boot-options.html
> .
> # Parameters without the prefix should be ignored and with the prefix
> should be used.
> 
> 
> == User Experience ==
> Users of Fedora official ISOs should not be impacted because all the
> Fedora official ISOs should already use the recommended prefix.
> 
> == Dependencies ==
> Don't know about any packages impacted by this change.
> 
> 
> == Contingency Plan ==
> * Contingency mechanism: The Anaconda team will revert 

Re: Anaconda running on ubuntu

[jkonecny]

Hello,

Unfortunately, I can't help you much here. It's not tested or used on
Ubuntu as I'm aware of. And because I don't think there is DNF packaged
then I guess you need to do some changes to Anaconda to support this.

The best shot would be to use VM with CentOS and run Anaconda there. In
general it's not much recommended to use Anaconda on your production
machine. We are doing plenty of destructive operations and bugs in
conditions could happen ...

If you are really interested in running Anaconda under Ubuntu feel free
to test that and report your result. I would be pretty interested how
it worked.

Best Regards,
Jirka 

On Mon, 2020-11-09 at 13:16 +, Schreiber, Vincent wrote:
> Hello Red Hat Installer Engineering Team,
> I have very simple question: is it simply possible to use anaconda on
> ubuntu?
> 
> I want to rebuild a docker image of centos 7 using their method,
> which requires amongst other things the anaconda-tui package. Before
> I clone the git-code you provided underrhinstaller / anaconda on
> github,  I'd rather ask you if that would crash my system or simply
> doesn't work. Perhaps there is readme or documentation I didn't found
> yet.
> 
> Anyways, thanks for your time and I would be very happy if you give
> me a response.
> 
> Best regards,
> 
> Vincent Schreiber
> 
> 
> ___
> 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: Scoping out the change needed for Anaconda to support resizing Btrfs filesystems

[jkonecny]

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.

> 
> 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

Deprecation of Anaconda boot parameters without inst. prefix

[jkonecny]

Hello everyone,

Anaconda team has decided to deprecate use of Anaconda kernel boot
parameters without 'inst.' prefix. As you may already know you can
specify Anaconda kernel boot parameters both with and without 'inst.'
prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means that when
you use Anaconda option without the 'inst.' prefix you will now get a
warning. We are *not* disabling parameters without a prefix yet.

The reason for this is keep running into parameter conflicts with other
projects. As an example there is 'debug' parameter for both kernel and
us, so when you want to enable kernel debugging in installation
environment you will also enable Anaconda debug mode.

Because of this I have created the following pull request for Anaconda:

https://github.com/rhinstaller/anaconda/pull/2786


In case you have any objections please start discussion either on the
pull request or here.


Best regards,
Jirka



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

Re: Helloworld Anaconda add-on

[jkonecny]

On Wed, 2019-11-06 at 10:24 +0100, jkone...@redhat.com wrote:
> On Wed, 2019-11-06 at 17:08 +0800, edsionte wrote:
> > yes! It works right now.  :)Thanks.
> 
> Great! :).
> 
> > And what's the difference between these two branch? 
> 
> We are making bigger changes in Fedora Rawhide to switch Anaconda to
> a modular Anaconda. Read here for more info:
> 
> https://rhinstaller.wordpress.com/2017/10/09/anaconda-modularisation/

Another source of information could be presentation:
https://beta.lbry.tv/@ITConferences:5/DevConf-JiriKonecny--Anaconda_is_still_Evolving:9
or in YT if you don't like LBRY:
https://youtu.be/00W8SsRrU8g?t=458 id="-x-evo-selection-start-marker">
Jirka

> The differences are mostly thanks to that.
> 
> Jirka
> >  于2019年11月6日周三 下午4:36写道：
> > > Ohh, I've missed that you are trying to create the addon on
> > > CentOS-7.
> > > Right now, you are using master branch which is for Fedora
> > > Rawhide. For CentOS-7 you have to use rhel7-branch
> > > https://github.com/rhinstaller/hello-world-anaconda-addon/tree/rhel7-branch
> > > Try to use this and see if it will help you.
> > > On Wed, 2019-11-06 at 16:20 +0800, edsionte wrote:
> > > > Thanks your reply,
> > > > “inst.updates=hd:/sdb4:/images/updates.img ”  was my writing
> > > > error，sorry for that.
> > > > Actually, I used "inst.updates=hd:sdb4:/images/updates.img" as
> > > > you said above, and the menu hasn't new category.I  have read :
> > > > pyanaconda/ui/categories/__init__.pypyanaconda/ui/categories/sy
> > > > stem.py  
> > > > 
> > > > After comparing with these files, I found that “hello-world-
> > > > anaconda-
> > > > addon/org_fedora_hello_world/categories/hello_world.py” are
> > > > missing the following  lines：
> > > > displayOnHubGUI="SummaryHub"displayOnHubTUI="SummaryHub"sortOrd
> > > > er = 100
> > > > displayOnHubGUI  default value is none. The comment in the code
> > > > says that if this value is none, then this category will not be
> > > > displayed.
> > > > 
> > > > SO I add these lines in 
> > > > 
> > > > “hello-world-anaconda-
> > > > addon/org_fedora_hello_world/categories/hello_world.py”.
> > > > but, when the installer runs, click Continue button in Welcome
> > > > page(chosse language), there is a error message page, and the
> > > > More Info is shown：
> > > > /usr/lib64/python2.7/sit-
> > > > packages/pyanaconda/ui/gui/hubs/__init__.py, line 132, in
> > > > _createBox()  spoke=spokeClass(self.data, self.storage,
> > > > self.payload, self.instclass)
> > > > TypeError: __init__() takes exactly 4 arguments (5
> > > > given)
> > > > 
> > > > Now, what should I do next ？ :(
> > > >  于2019年11月6日周三 下午3:48写道：
> > > > > Hello,
> > > > > You should use:
> > > > > inst.updates=hd:/dev/sdb4:/images/updates.img
> > > > > or 
> > > > > inst.updates=hd:sdb4:/images/updates.img
> > > > > 
> > > > > For more info please see:
> > > > > https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-repo
> > > > > It's using the same syntax as inst.updates.
> > > > > Best Regards,Jirka
> > > > > On Wed, 2019-11-06 at 13:25 +0800, edsionte wrote:
> > > > > > Hi all,
> > > > > > I want to test my first “hello word” Anaconda addon
> > > > > > program.
> > > > > > 
> > > > > > Firstly, I use this source code ( 
> > > > > > https://github.com/rhinstaller/hello-world-anaconda-addon/)
> > > > > > ， and make a outfile updates.img. 
> > > > > > Then, I made a USB boot disk （CentOS 7.4）, and placed
> > > > > > updates.img into the directory “images/”  of boot disk.
> > > > > > 
> > > > > > Then I used inst.updates=hd:/sdb4:/images/updates.img boot
> > > > > > option, There isn't a new helloworld Category on the
> > > > > > installation menu.
> > > > > > 
> > > > > > Is there anything wrong with steps above？  
> > > > > > 
> > > > > > Thanks.
> > > > > > edison
> > > > > > 
> > > > > > ___Anaconda-
> > > > > > devel-list mailing listanaconda-devel-l...@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: Helloworld Anaconda add-on

[jkonecny]

On Wed, 2019-11-06 at 17:08 +0800, edsionte wrote:
> yes! It works right now.  :)Thanks.

Great! :).
> And what's the difference between these two branch? 

We are making bigger changes in Fedora Rawhide to switch Anaconda to a
modular Anaconda. Read here for more info:

https://rhinstaller.wordpress.com/2017/10/09/anaconda-modularisation/

The differences are mostly thanks to that.
Jirka
>  于2019年11月6日周三 下午4:36写道：
> > Ohh, I've missed that you are trying to create the addon on CentOS-
> > 7.
> > Right now, you are using master branch which is for Fedora Rawhide.
> > For CentOS-7 you have to use rhel7-branch
> > https://github.com/rhinstaller/hello-world-anaconda-addon/tree/rhel7-branch
> > Try to use this and see if it will help you.
> > On Wed, 2019-11-06 at 16:20 +0800, edsionte wrote:
> > > Thanks your reply,
> > > “inst.updates=hd:/sdb4:/images/updates.img ”  was my writing
> > > error，sorry for that.
> > > Actually, I used "inst.updates=hd:sdb4:/images/updates.img" as
> > > you said above, and the menu hasn't new category.I  have read :
> > > pyanaconda/ui/categories/__init__.pypyanaconda/ui/categories/syst
> > > em.py  
> > > 
> > > After comparing with these files, I found that “hello-world-
> > > anaconda-addon/org_fedora_hello_world/categories/hello_world.py”
> > > are missing the following  lines：
> > > displayOnHubGUI="SummaryHub"displayOnHubTUI="SummaryHub"sortOrder
> > > = 100
> > > displayOnHubGUI  default value is none. The comment in the code
> > > says that if this value is none, then this category will not be
> > > displayed.
> > > 
> > > SO I add these lines in 
> > > 
> > > “hello-world-anaconda-
> > > addon/org_fedora_hello_world/categories/hello_world.py”.
> > > but, when the installer runs, click Continue button in Welcome
> > > page(chosse language), there is a error message page, and the
> > > More Info is shown：
> > > /usr/lib64/python2.7/sit-
> > > packages/pyanaconda/ui/gui/hubs/__init__.py, line 132, in
> > > _createBox()  spoke=spokeClass(self.data, self.storage,
> > > self.payload, self.instclass)
> > > TypeError: __init__() takes exactly 4 arguments (5 given)
> > > 
> > > Now, what should I do next ？ :(
> > >  于2019年11月6日周三 下午3:48写道：
> > > > Hello,
> > > > You should use:
> > > > inst.updates=hd:/dev/sdb4:/images/updates.img
> > > > or 
> > > > inst.updates=hd:sdb4:/images/updates.img
> > > > 
> > > > For more info please see:
> > > > https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-repo
> > > > It's using the same syntax as inst.updates.
> > > > Best Regards,Jirka
> > > > On Wed, 2019-11-06 at 13:25 +0800, edsionte wrote:
> > > > > Hi all,
> > > > > I want to test my first “hello word” Anaconda addon program.
> > > > > 
> > > > > Firstly, I use this source code ( 
> > > > > https://github.com/rhinstaller/hello-world-anaconda-addon/) ，
> > > > > and make a outfile updates.img. 
> > > > > Then, I made a USB boot disk （CentOS 7.4）, and placed
> > > > > updates.img into the directory “images/”  of boot disk.
> > > > > 
> > > > > Then I used inst.updates=hd:/sdb4:/images/updates.img boot
> > > > > option, There isn't a new helloworld Category on the
> > > > > installation menu.
> > > > > 
> > > > > Is there anything wrong with steps above？  
> > > > > 
> > > > > Thanks.
> > > > > edison
> > > > > 
> > > > > ___Anaconda-
> > > > > devel-list mailing listanaconda-devel-l...@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: Helloworld Anaconda add-on

[jkonecny]

Hello,
You should use:
inst.updates=hd:/dev/sdb4:/images/updates.img
or 
inst.updates=hd:sdb4:/images/updates.img

For more info please see:
https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-repo
It's using the same syntax as inst.updates.
Best Regards,Jirka
On Wed, 2019-11-06 at 13:25 +0800, edsionte wrote:
> Hi all,
> I want to test my first “hello word” Anaconda addon program.
> 
> Firstly, I use this source code ( 
> https://github.com/rhinstaller/hello-world-anaconda-addon/) ， and
> make a outfile updates.img. 
> Then, I made a USB boot disk （CentOS 7.4）, and placed updates.img
> into the directory “images/”  of boot disk.
> 
> Then I used inst.updates=hd:/sdb4:/images/updates.img boot option,
> There isn't a new helloworld Category on the installation menu.
> 
> Is there anything wrong with steps above？  
> 
> Thanks.
> edison
> 
> ___Anaconda-devel-list
> mailing listanaconda-devel-l...@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

Anaconda development blog post is published!

[jkonecny]

Hello everyone,

I'm giving you a heads-up that we have published a new blog post
related to Anaconda OS Installer. This is the first from a series of
posts about Anaconda development and debugging.

https://rhinstaller.wordpress.com/2019/10/11/anaconda-debugging-and-testing-part-1/


Enjoy reading,
Jirka


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

Re: Proposal to use repo files in Anaconda environment

[jkonecny]

On Thu, 2019-09-26 at 08:26 -0700, Brian C. Lane wrote:
> On Thu, Sep 26, 2019 at 02:25:49PM +0200, jkone...@redhat.com wrote:
> > On Fri, 2019-09-20 at 10:21 -0700, Brian C. Lane wrote:
> > > On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkone...@redhat.com
> > > wrote:
> 
> [snip]
> 
> > > With an updates.img solution like you are describing here is
> > > there
> > > anything
> > > to be done? Can't it already drop new repos into
> > > /etc/yum.repos.d/ or
> > > /etc/anaconda.repos.d/ ?
> > 
> > In general no, it should work without changes. That is a great
> > benefit
> > of this solution. The only thing is if we want to create a tool for
> > the
> > updates image creation.
> > 
> > I was also thinking about a behavior nuances. Like, if we want to
> > change default behavior of how Anaconda works with these
> > repositories
> > than it may be interesting to have a separate folder to found out
> > these
> > repositories.
> > 
> > > With my lmc patch for certs I am doing something like this, but
> > > only
> > > with the cert files, not the repo files. updates.img
> > > 
> > > https://github.com/weldr/lorax/pull/839
> > 
> > Our idea is to have everything as part of the updates image, repo
> > files
> > and certificates.
> > 
> > > From the perspective of lmc no-virt mode and lorax-composer
> > > (which
> > > use anaconda directly) it would be most useful to add a --repo
> > > and/or
> > > --repodir cmdline option to anaconda that adds the repos to the
> > > dnf
> > > base
> > > object, similar to the way that lorax does things:
> > > 
> > > https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114
> > > 
> > > updates.img doesn't help with these use cases.
> > 
> > Seems interesting. I'm just thinking if we don't want to rather use
> > configuration files for Anaconda. Not sure, it would require a
> > change
> > in the Anaconda but shouldn't be that hard.
> > 
> > FYI: Configuration files were added to Anaconda recently to be able
> > override behavior and it is the replacement for install classes.
> > For
> > you it would mean that you will create the configuration file (ini
> > format) in the specified directory to tell us where to look for the
> > repo files.
> > 
> > There is also a question, is there a use for the --repodir which
> > can't
> > be solved by changing configuration files of Anaconda or otherwise
> > what
> > is the preferred way here?
> 
> Oh, interesting! I wasn't aware of that, I'll take a look at it and
> see
> if I can make it work w/o any other changes.

Yes, I think it will be interesting for your. However, we have to first
implement the drop dir solution to avoid changing system anaconda
configuration. It's on our TODO list and if you have any use for that
now, we can make it higher priority.

> 
> 
> > > I totally agree with the goals here, the repo command in
> > > kickstart is
> > > getting too long, but we need a way to handle special cases where
> > > people
> > > need access to more of the dnf options.
> > > 
> > > At the same time I'm worried about the loss of information that
> > > this
> > > can
> > > cause. Although I don't want to just dump dnf repo files into
> > > kickstart
> > > -- that defeats the purpose of making it (somewhat) disconnected
> > > from
> > > the
> > > specific backends like yum vs dnf.
> > 
> > I think you have the same even now. The default settings for Fedora
> > depends on what variant are you using. Based on the environment you
> > are
> > using for the installation you will get the result.
> 
> With kickstart you don't use the host environment's repos, unless you
> specifically reference them (at least that's how it used to work).
> eg.
> you can enable the updates repo shipped on the boot.iso with 'repo
> --name=updates' but if you don't do that the only repos used are the
> ones in the kickstart.

Yes that is true and it is still supported. Also you can set closest
mirror without kickstart which will use pre-installed fedora repo files
. That is basically the same as repo --name solution but from GUI. The
point is that this feature depends on a stage2 environment and that is
exactly what I meant.

Thanks to this you are able to create KS file which don't have all the
information. I'm not convinced that adding repo files more support from
Anaconda will make this situation any worse. 

> 
> > > Another option may be to use %pre to write out the repo files
> > > (I'm
> > > not
> > > sure if anaconda will currently pick those up, but it should be
> > > possible
> > > to fix if it doesn't).
> > 
> > We are thinking about tweaking existing sections to be able to just
> > dump a general file somewhere (could be a script which will be run
> > in
> > the other section or repo file). That would be better solution for
> > the
> > %pre sections repo dumping. It would look like:
> > 
> > %pre --dump-file=/anaconda.repos.d/my.repo
> > 
> > %end
> > 
> > However, this will not solve GPG key files or certificates so we
> > are
> > more thinking 

Re: Proposal to use repo files in Anaconda environment

[jkonecny]

On Fri, 2019-09-20 at 10:21 -0700, Brian C. Lane wrote:
> On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkone...@redhat.com wrote:
> > Hello everyone,
> > 
> > We (the Anaconda installer team) want to solve multiple problems by
> > one
> > solution and we want 
> > 
> > *YOUR FEEDBACK!*
> > 
> > 
> > In short we are proposing to use custom repo files when configuring
> > Anaconda for image creation instead of adding even more complexity
> > to
> > the kickstart repo command. For more details see the link below.
> > 
> > Purpose of this mail is to give everyone interested in the topic a
> > place to discuss our proposal to find out if we didn't miss
> > something
> > or better case, if you agree with it :). It could be that this is
> > not
> > applicable for Lorax / Pungi / live-cd tool in that case please
> > write a
> > response to the document.
> > 
> > You can read details here:
> > 
> > https://hackmd.io/@prJIqOTeSxC-W0RNGKIGbQ/ByzIz3kIH/edit
> > 
> > Please, all the relevant comments should stay in the document if
> > possible. If that solution won't work because of higher traffic
> > then we
> > will find a better solution but the point is to have everything on
> > one
> > place.
> 
> Sorry, I really don't like the hackmd.io thing, we regularly use
> email
> for discussions like this and should continue the discussion on the
> feoora-devel list.

That's fine. I wanted to create a living document to have everything on
one place but it looks that email is preferred. I don't mind moving the
conversation here.

> 
> With an updates.img solution like you are describing here is there
> anything
> to be done? Can't it already drop new repos into /etc/yum.repos.d/ or
> /etc/anaconda.repos.d/ ?

In general no, it should work without changes. That is a great benefit
of this solution. The only thing is if we want to create a tool for the
updates image creation.

I was also thinking about a behavior nuances. Like, if we want to
change default behavior of how Anaconda works with these repositories
than it may be interesting to have a separate folder to found out these
repositories.

> 
> With my lmc patch for certs I am doing something like this, but only
> with the cert files, not the repo files. updates.img
> 
> https://github.com/weldr/lorax/pull/839

Our idea is to have everything as part of the updates image, repo files
and certificates.

> 
> From the perspective of lmc no-virt mode and lorax-composer (which
> use anaconda directly) it would be most useful to add a --repo and/or
> --repodir cmdline option to anaconda that adds the repos to the dnf
> base
> object, similar to the way that lorax does things:
> 
> https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114
> 
> updates.img doesn't help with these use cases.

Seems interesting. I'm just thinking if we don't want to rather use
configuration files for Anaconda. Not sure, it would require a change
in the Anaconda but shouldn't be that hard.

FYI: Configuration files were added to Anaconda recently to be able
override behavior and it is the replacement for install classes. For
you it would mean that you will create the configuration file (ini
format) in the specified directory to tell us where to look for the
repo files.

There is also a question, is there a use for the --repodir which can't
be solved by changing configuration files of Anaconda or otherwise what
is the preferred way here?

> 
> I totally agree with the goals here, the repo command in kickstart is
> getting too long, but we need a way to handle special cases where
> people
> need access to more of the dnf options.
> 
> At the same time I'm worried about the loss of information that this
> can
> cause. Although I don't want to just dump dnf repo files into
> kickstart
> -- that defeats the purpose of making it (somewhat) disconnected from
> the
> specific backends like yum vs dnf.

I think you have the same even now. The default settings for Fedora
depends on what variant are you using. Based on the environment you are
using for the installation you will get the result.

> 
> Another option may be to use %pre to write out the repo files (I'm
> not
> sure if anaconda will currently pick those up, but it should be
> possible
> to fix if it doesn't).

We are thinking about tweaking existing sections to be able to just
dump a general file somewhere (could be a script which will be run in
the other section or repo file). That would be better solution for the
%pre sections repo dumping. It would look like:

%pre --dump-file=/anaconda.repos.d/my.repo

%end

However, this will not solve GPG key files or certificates so we are
more thinking about this for an image creation which in general can
generate the repo files in a drop dir and used that directory.

Best Regards,
Jirka

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

Proposal to use repo files in Anaconda environment

[jkonecny]

Hello everyone,

We (the Anaconda installer team) want to solve multiple problems by one
solution and we want 

*YOUR FEEDBACK!*


In short we are proposing to use custom repo files when configuring
Anaconda for image creation instead of adding even more complexity to
the kickstart repo command. For more details see the link below.

Purpose of this mail is to give everyone interested in the topic a
place to discuss our proposal to find out if we didn't miss something
or better case, if you agree with it :). It could be that this is not
applicable for Lorax / Pungi / live-cd tool in that case please write a
response to the document.

You can read details here:

https://hackmd.io/@prJIqOTeSxC-W0RNGKIGbQ/ByzIz3kIH/edit

Please, all the relevant comments should stay in the document if
possible. If that solution won't work because of higher traffic then we
will find a better solution but the point is to have everything on one
place.

Have a great day everyone,
Jirka

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

Re: CoreOS vs Anaconda toolchain

[jkonecny]

On Mon, 2019-09-09 at 17:35 -0400, Matthew Miller wrote:
> On Fri, Sep 06, 2019 at 04:46:59PM -0400, Colin Walters wrote:
> > Would love to do some brainstorming about how we can share more
> > code/ideas in general; I had some specific comments towards the
> > end.  
> 
> Thanks for bringing this up, Colin. I appreciate the work-together
> effort in
> particular. In the github issue you note:
> 
>   And now here's the thing - all of the current image-building
>   tools in the Fedora ecosystem (ImageFactory, virt-install,
>   and lorax-composer/LMC) end up being wrappers around running
>   Anaconda in a VM.
> 
> ... and I want to comment a bit on how we got there. Specifically, we
> previously had, like, half-a-dozen different ways to create an OS
> image,
> ranging from shells scripts wrapping yum to more complicated
> packages. We
> were using one of these to create the cloud image, and it starting
> having
> all sorts of complicated and weird bugs, and really had no maintainer
> (just
> accumulated hacks from rel-eng). 
> 
> So, we decided to standardize on _one code path_, and _the thing
> which has a
> dedicated team behind it_.
> 
> Now, I appreciate that there is a team behind Ignition too, so things
> are
> different in some respects, but I think the basic part remains: let's
> make
> sure we have long term maintenance in mind whatever decisions are
> made. And
> let's please not have too many different ways of doing the same
> thing.
> 

+1 for that. Your saying exactly what I'm thinking off.

I know that Ignition have a different UX than Anaconda so it have also
a different user base and knowledge requirements. What I think can
improve is better cooperation and code/libraries sharing. 

For example libblockdev[0] is a great candidate, it's used by Anaconda
and it should be used by Ignition from my PoV.

Another great candidate would be to create a library to solve
bootloader setup and installation. We talked to bootloader developers
about this already and they are willing to maintain such a library. I
think that would be really valuable for us the same way as for
Ignition.

Also if there are storage related requirements Ignition want to
implement we could be able to help them. It should be possible to make
our storage module a standalone module which can be then used by them
so we can share the storage code between projects.

It would be great to meet and discuss these ideas. Are the developers
of the Ignition planning to go to DevConf.cz? It would be great to meet
there. What do you think?

[0]: https://github.com/storaged-project/libblockdev

Best Regards,
Jirka

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

Re: "Modifying /etc/os-release for re-branding?"

[jkonecny]

On Wed, 2019-09-11 at 09:54 +0530, Danishka Navin wrote:
> Is it ok to modify /etc/os-release for re-branding purpose? 

Hi Danishka Navin,
Good question on a bad place. Adding Fedora devel list here, there
could be someone who is able to answer you this question.
Jirka
> On Wed, Sep 4, 2019 at 6:11 PM Vendula Poncova 
> wrote:
> > On Tue, Sep 3, 2019 at 7:29 PM Danishka Navin 
> > wrote:
> > > On Tue, Sep 3, 2019 at 6:16 PM Vendula Poncova <
> > > vponc...@redhat.com> wrote:
> > > > On Mon, Sep 2, 2019 at 9:56 AM Danishka Navin <
> > > > danis...@gmail.com> 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 

Re: I'm the new maintainer of pykickstart

[jkonecny]

Hi Brian,

Thanks for all your work and special thanks for making a stable place
for the pykickstart again.

Congratulations for getting this project under your umbrella. We will
try to help you with PR reviews and other project related stuff ;).
I'm looking forward for our cooperation!

Best Regards,
Jirka

On Thu, 2019-09-05 at 16:28 -0700, Brian C. Lane wrote:
> Today we created a new, permanent, location for pykickstart:
> 
> https://github.com/pykickstart/pykickstart/
> 
> And I've agreed to be the new maintainer. I've been involved with
> Anaconda and pykickstart since I joined Red Hat in 2010 so this isn't
> a
> new experience for me :)
> 
> My general philosophy for this is going to be "don't break it". I
> consider pykickstart to be one of the best examples of how to write a
> python library, especially one that has to support so many different
> features and versions so I have no plans to make fundamental changes.
> I
> consider it primarily to be in maintenance mode, driven by bugfixing
> and
> requests from Anaconda.
> 
> Recently there have been some requests to add features to pyks for
> the
> livecd-creator project that don't have (and never will) support in
> Anaconda. I've been trying to come up with a way to make everyone
> happy
> -- and haven't.
> 
> At the moment I think the best way to proceed is to require that new
> features need to have patches, and be accepted by, Anaconda. Anything
> else is just going to lead to a fractured user experience, confusing
> documentation, difficult to debug problems, etc. Since Anaconda is
> the
> primary user for pyks it makes practical sense to have the installer
> team's input on new features.
> 
> I also will *not* be re-reviewing any old closed requests. If the
> previous maintainers declined to add something I am not going to re-
> open
> it.
> 

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

Re: "PRE-RELEASE/TESTING"

[jkonecny]

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?
> 
> 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 listanaconda-devel-l...@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?

[jkonecny]

On Tue, 2019-08-27 at 14:59 -0700, Adam Williamson wrote:
> On Tue, 2019-08-27 at 13:25 -0400, David Cantrell wrote:
> > > Josh, to be fair, I can see Neal's point here. In a way you seem
> > > to be
> > > kinda sending him in circles here: "anaconda team doesn't have
> > > the
> > > time/resources to invest in btrfs development, but you can help
> > > by
> > > sending them pull requests. Oh, you sent them a pull request and
> > > they
> > > rejected it? Well, it's because they don't have time/resources
> > > for
> > > btrfs development..." You're right that one rejected PR doesn't
> > > necessarily indicate a contribution model problem, but putting
> > > the
> > > wider issue aside, a very simple one-liner with a major impact on
> > > btrfs
> > > functionality being rejected *does* seem to say a lot about the
> > > prospects of any btrfs-related work being accepted.
> > > 
> > > Putting myself in Neal's shoes, given my experience with that PR
> > > and
> > > other attempts to help out with btrfs in anaconda, why would I
> > > invest
> > > my time and effort to write another one when it seems extremely
> > > likely
> > > it would be rejected?
> > 
> > There's an assumption here that when someone is asked to send a PR,
> > it
> > will always be accepted.
> 
> No, that's not what I'm assuming, but if we (Red Hat) tell people
> that
> it would be a good idea to send PRs, we should at least be
> *potentially* willing to accept them. We should not be saying 'send
> PRs' if there is no chance of them being accepted. And it would be
> nicest if we gave people a roadmap: here are the specific things you
> can do that would be acceptable to us as a way to continue including
> btrfs handling in the installer.

Sorry but I have to react on this. It's killing me how many of you
people here are telling Anaconda does not accept patches. That is
really not true. We have smaller amount of contributions from community
that is partially our fault because of a lack of documentation but
mainly it's really hard to develop & test Anaconda and most users see
it just once in a few years so it's not bothering them so much. I guess
most of the installers are in the same situation.

Please before any of you will tell again that Anaconda team is not
accepting patches, please look on the last few years history. How many
patches were "rejected" and how many were accepted. There are just a
few patches which weren't accepted and basically only a few PR (I would
even say the only one) for BTRFS. That is unfortunate but it's not all
our contributions.

Please stop saying all the time that Anaconda is not accepting
contributions or that users doesn't have a chance to get the
contributions in.


> 
> Just as a for instance - if the anaconda team would find it
> acceptable
> to maintain btrfs installer support if some person or some group came
> up with a way to modularize filesystem support in the installer such
> that that person or group could maintain it and the existing anaconda
> devs would not have to worry about it (and perhaps even such that
> images could easily be built with or without support for specific
> filesystems), then we should tell people that that is the kind of
> work
> we're looking for and would accept if it was done.
> 
> I know the folks on both sides here and I understand both their
> frustrations: the anaconda team is trying to maintain a very large
> project with very limited resources and very specific demands from
> the
> people who write their paychecks, which is absolutely a difficult
> position to be in. But also, the community folks here are trying
> their
> best to contribute - not just to demand that the RH folks do stuff
> for
> them, but actually to contribute - but feel like they are being given
> no guidance at all as to what kind of contribution would actually be
> welcomed or acceptable, they feel like the message is "just keep
> coming
> up with stuff and we'll keep rejecting it until we see something we
> like". I know it's a tough position for both sides, but I really hope
> we can get somewhere more positive than here with it.
> 
> >   Enabling and/or fixing btrfs functionality in
> > anaconda is not a zero cost.  There's also the issue that anaconda
> > has
> > always aimed to not break systems.  Does the project have the
> > resources
> > to guarantee that and fix problems that show up?  What might appear
> > at
> > first as a "one line patch" comes with a lot of other assumptions
> > and
> > expectations from users.
> > 
> > > I think we at least owe it to people to be clear about whether
> > > there is
> > > any point in them investing time and effort *trying* to
> > > contribute to
> > > btrfs support in anaconda, and if the answer is currently "no",
> > > whether
> > > there would realistically be any prospect of there being any way
> > > to
> > > change this.
> > > 
> > > I also think there are other perspectives that might at least
> > > potentially be useful here. Right now we've 

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

[jkonecny]

On Tue, 2019-08-27 at 16:54 -0600, Chris Murphy wrote:
> On Tue, Aug 27, 2019 at 1:02 PM David Cantrell 
> wrote:
> > On 8/27/19 2:00 PM, Chris Murphy wrote:
> > > The Fedora working group's technical specification states Btrfs
> > > is to
> > > be the default. Yet the working group has said it's uncomfortable
> > > taking action on this decision expressly because the Federal
> > > kernel
> > > team's official recommendation is to not recommend Btrfs. And I
> > > agree.
> > > I trust the Fedora kernel team as they've clearly stated limited
> > > resources and interest in Btrfs, the expectations and parameters
> > > for
> > > properly supporting Btrfs either as bug blocker worthy, and as a
> > > default file system from a user advocacy point of view.
> > 
> > OK, so 8 years has gone by and the landscape around btrfs looks
> > different in Fedora.  Given the kernel team's position, is it worth
> > still having the FESCo decision and kernel team's recommendation at
> > odds?
> 
> They aren't at odds.
> 
> 8 years ago FESCo decision on Btrfs
> 5 years ago Workstation working group decision on Btrfs (their
> requirements and specs docs were signed off by FESCo)
> 3 years ago kernel team said while they don't recommend it, they
> acknowledged it was ultimately up to the working group to decide, and
> noted they were sick of having this conversation every release
> 
> The Workstation working group has, correctly in my view, put their
> own
> decision in abeyance, as a result of the kernel team's official
> recommendation. How does the Btrfs landscape in Fedora look different
> to you in three years?
> 
> The way the landscape looks different to me:
> 
> One, the possibility of getting a kernel engineer who works on Btrfs
> to join the Fedora kernel team, so that the team has the capacity to
> support and recommend (at least as a team, not that any individual
> needs to give up one tiny bit of their Btrfs scepticism) is an
> important development.
> 
> Two, that in the interim, Red Hat is where the landscape has really
> changed has occurred with respect to Btrfs, and I see indications of
> this bias being injected back into Fedora: suggesting that a Red Hat
> shift away from Btrfs somehow is actually a Fedora shift away from
> Btrfs, suggesting a do over vote in the Workstation working group, or
> even an undo vote by FESCo to set aside the Workstation working group
> vote.
> 
> And to what end? All that's needed is for the Anaconda team to
> provided the same courtesy of clear expectations and parameters, as
> the kernel team has done.
> 
> > > > If it's a best effort thing, then that makes it easier for
> > > > projects and contributors.  Going back to Adam's original list,
> > > > I would
> > > > suggest a FESCo decision like this should require explicit opt-
> > > > in by the
> > > > user to enable btrfs functionality in the application in
> > > > question.  For
> > > > example, in the installer that could be enabled via a boot
> > > > parameter (we
> > > > did this initially when btrfs functionality was first enabled
> > > > in anaconda).
> > > 
> > > That can only be considered to be a remarkable regression, not
> > > just in
> > > the context of Fedora, but in the context of the top 10 linux
> > > distributions all of which have visible Btrfs support in their
> > > GUI
> > > installers. Fedora's installer being the first to make Btrfs
> > > invisible
> > > by default would be a remarkable first indeed.
> > 
> > I'm merely offering an example scenario.
> > 
> > This does illustrate a problem with expectations among users.  It's
> > visible now, but not a priority, which leads to frustration.
> 
> Just like today's kernel team, Anaconda today are not obligated to
> make it a priority. But qualifying what "not a priority" actually
> means is necessary. The question is what are the preconditions for
> others who will make it a priority? And whether Anaconda is going to
> slow walk every PR that tries to improve Btrfs support? What about
> simplifying the Btrfs support in Anaconda to make it easier to
> maintain with priority parity with other file systems? Gut all the
> multiple device stuff, perhaps? Btrfs can easily do quite a lot of
> adjustments post-install, it's one of it's most central features. Few
> options are mkfs only.

Removing something from Anaconda to replace it by BTRFS functionality
doesn't really help. It would even make our lives harder. The point is
that the same code has to be there because of the RHEL so it would only
diverge our effort that everything have to be done twice.

> 
> 
> > > > I'm not advocating one way or another for btrfs.  But it seems
> > > > we as a
> > > > project need a larger decision and policy around btrfs in
> > > > general so we
> > > > can set expectations for users and developers.
> > > 
> > > That decision and policy has already been made. Do you want it
> > > reverted?
> > 
> > I guess I meant to say "FESCo needs to revisit this decision for a
> > potential 

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

[jkonecny]

On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> On Mon, Aug 26, 2019 at 7:16 AM  wrote:
> > On Sat, 2019-08-24 at 07:31 -0700, Adam Williamson wrote:
> > > On Fri, 2019-08-23 at 19:00 -0600, Chris Murphy wrote:
> > > > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson
> > > >  wrote:
> > > > 
> > > > > So, there was recently a Thing where btrfs installs were
> > > > > broken,
> > > > > and
> > > > > this got accepted as a release blocker:
> > > > > 
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388
> > > > 
> > > > Summary: This bug was introduced and discovered in linux-next,
> > > > it
> > > > started to affect Fedora 5.3.0-rc0 kernels in openqa tests,
> > > > patch
> > > > appeared during rc1, and the patch was merged into 5.3.0-rc2.
> > > > The
> > > > bug
> > > > resulted in a somewhat transient deadlock which caused installs
> > > > to
> > > > hang, but no corruption. The fix, 2 files changed, 12
> > > > insertions, 8
> > > > deletions (1/2 the insertions are comments).
> > > > 
> > > > How remarkable or interesting is this bug? And in particular,
> > > > exactly
> > > > how much faster should it have been fixed in order to avoid
> > > > worrying
> > > > about it being a blocker bug?
> > > > 
> > > > 7/25 14:27 utc bug patch was submitted to linux-btrfs@
> > > > 7/25 22:33 utc bug was first reported in Fedora bugzilla
> > > > 7/26 19:20 utc I confirmed upstream's patch related to this bug
> > > > with
> > > > upstream and updated the Fedora bug
> > > > 7/26 22:50 utc I confirmed it was merged into rc2, and updated
> > > > the
> > > > Fedora bug
> > > > 
> > > > So in the context of status quo, where Btrfs is presented as an
> > > > option
> > > > in the installer and if there are bugs they Beta blocking, how
> > > > could
> > > > or should this have been fixed sooner? What about the handling
> > > > should
> > > > have been different?
> > > 
> > > Nothing. The kernel team's concern is not related to this bug or
> > > the
> > > handling of this bug in any way. The only relevance of the bug is
> > > that
> > > it alerted the kernel team to the fact that we currently block on
> > > btrfs, which they think we should not.
> > 
> > I understand them. The point is, for them and even us (the
> > installer)
> > is work on BTRFS not a priority. It's something we can't benefit on
> > RHEL and it could be almost completely replaced by LVM + xfs
> > solution.
> > However, it still giving us bugs and making our test surface
> > bigger.
> > 
> > > From the Anaconda team PoV it would make our lives easier to not
> > support BTRFS at all. I'm not saying that we should drop BTRFS in
> > Fedora, only that it would be easier for Anaconda team to be
> > without
> > that on Fedora.
> 
> This is flat-out a trap. This is what makes Anaconda such a failure
> as
> a community project. Why does the past (RHEL) affect the present and
> future (Fedora)? There's basically no way whatsoever to make anything
> better with this logic. The Anaconda releases that any improvements
> would be going into aren't even landing into the RHEL 8 branch that
> governs the latest iteration of Fedora's past. From any reasonable
> person's perspective, this answer makes no sense unless you're using
> RHEL as an excuse to not support Fedora.
> 

RHEL is not the past. Everything we do we have to think that it will go
to RHEL and if it is Fedora specific we have to create a way to disable
the functionality for another RHEL branching. And yes, we have a few
things (not only a BTRFS) specific to Fedora the same way as a few
things specific to RHEL which are disabled on Fedora.

And as I wrote before, I'm not saying that we will remove the BTRFS
support from Fedora. The point is that making the list specific to
releases smaller will make our live easier.

___
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?

[jkonecny]

On Sat, 2019-08-24 at 07:31 -0700, Adam Williamson wrote:
> On Fri, 2019-08-23 at 19:00 -0600, Chris Murphy wrote:
> > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson
> >  wrote:
> > 
> > > So, there was recently a Thing where btrfs installs were broken,
> > > and
> > > this got accepted as a release blocker:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388
> > 
> > Summary: This bug was introduced and discovered in linux-next, it
> > started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch
> > appeared during rc1, and the patch was merged into 5.3.0-rc2. The
> > bug
> > resulted in a somewhat transient deadlock which caused installs to
> > hang, but no corruption. The fix, 2 files changed, 12 insertions, 8
> > deletions (1/2 the insertions are comments).
> > 
> > How remarkable or interesting is this bug? And in particular,
> > exactly
> > how much faster should it have been fixed in order to avoid
> > worrying
> > about it being a blocker bug?
> > 
> > 7/25 14:27 utc bug patch was submitted to linux-btrfs@
> > 7/25 22:33 utc bug was first reported in Fedora bugzilla
> > 7/26 19:20 utc I confirmed upstream's patch related to this bug
> > with
> > upstream and updated the Fedora bug
> > 7/26 22:50 utc I confirmed it was merged into rc2, and updated the
> > Fedora bug
> > 
> > So in the context of status quo, where Btrfs is presented as an
> > option
> > in the installer and if there are bugs they Beta blocking, how
> > could
> > or should this have been fixed sooner? What about the handling
> > should
> > have been different?
> 
> Nothing. The kernel team's concern is not related to this bug or the
> handling of this bug in any way. The only relevance of the bug is
> that
> it alerted the kernel team to the fact that we currently block on
> btrfs, which they think we should not.

I understand them. The point is, for them and even us (the installer)
is work on BTRFS not a priority. It's something we can't benefit on
RHEL and it could be almost completely replaced by LVM + xfs solution.
However, it still giving us bugs and making our test surface bigger.

>From the Anaconda team PoV it would make our lives easier to not
support BTRFS at all. I'm not saying that we should drop BTRFS in
Fedora, only that it would be easier for Anaconda team to be without
that on Fedora.

> 
> > I note here that ext2 and ext3 are offered as file systems in
> > Custom/Advanced partitioning and in this sense have parity with
> > Btrfs.
> > If this same bug occurred in ext2 or ext3 would or should that
> > cause
> > discussion to drop them from the installer,
> 
> You're misunderstanding here. It's not the fact that a bug showed up
> which caused the concern.

___
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?

[jkonecny]

On Fri, 2019-08-23 at 16:10 -0400, Neal Gompa wrote:
> On Fri, Aug 23, 2019 at 3:48 PM Justin Forbes 
> wrote:
> > On Fri, Aug 23, 2019 at 2:17 PM Adam Williamson
> >  wrote:
> > > Hey folks!
> > > 
> > > So, there was recently a Thing where btrfs installs were broken,
> > > and
> > > this got accepted as a release blocker:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388
> > > 
> > > The bug was fixed, so that's fine, but along the way, Laura said
> > > this:
> > > 
> > > "I'm strongly against anything with btrfs being a blocker. If
> > > that's in
> > > the criteria I think we should see about removing btrfs simply
> > > because
> > > we don't have the resources to actually deal with btrfs besides
> > > reporting bugs upstream."
> > > 
> > > and Justin followed up with:
> > > 
> > > "Agreed, btrfs has been a gamble pretty much always. See previous
> > > discussion around proposals to make btrfs default. Ext4 and xfs
> > > should
> > > be the only release blocking."
> > > 
> > > So, that's the whole kernel team 'strongly against' blocking on
> > > btrfs.
> > > Which means we should talk about not doing that any more!
> > > 
> > > This is a bit complicated, though, because of how the Final
> > > criteria
> > > are phrased. Basic does not include btrfs at all, and Beta
> > > includes a
> > > laundry list we can just remove btrfs from:
> > > 
> > > "When using both the installer-native and the blivet-gui-based
> > > custom
> > > partitioning flow, the installer must be able to:
> > > 
> > > * Correctly interpret, and modify as described below, any disk
> > > with a
> > > valid ms-dos or gpt disk label and partition table containing
> > > ext4
> > > partitions, LVM and/or btrfs volumes, and/or software RAID arrays
> > > at
> > > RAID levels 0, 1 and 5 containing ext4 partitions
> > > * Create mount points backed by ext4 partitions, LVM volumes or
> > > btrfs
> > > volumes, or software RAID arrays at RAID levels 0, 1 and 5
> > > containing
> > > ext4 partitions
> > > ..."
> > > 
> > > so those two are easy. However, the Final criterion is not
> > > laundry
> > > list-style. The relevant Final criterion is this:
> > > 
> > > "The installer must be able to create and install to any workable
> > > partition layout using any file system and/or container format
> > > combination offered in a default installer configuration."
> > > 
> > > with a somewhat apologetic explanatory footnote:
> > > 
> > > "Wait, what?
> > > Yeah, we know. This is a huge catch-all criterion and it's
> > > subject to a
> > > lot of on-the-fly interpretation. Broadly what it's 'meant to
> > > mean' is
> > > that you should be able to do anything sane that the Installation
> > > Destination spoke attempts to let you do, without the installer
> > > exploding or failing. We are trying to write more specific
> > > criteria
> > > covering this area, but it's not easy. Patches welcome, as the
> > > kids
> > > say..."
> > > 
> > > so as the footnote says, the rule is basically "if the installer
> > > lets
> > > you do it, it ought to work". It seems a bit awkward to craft an
> > > exception for btrfs from that. I mean, technically it's easy:
> > > 
> > > "The installer must be able to create and install to any workable
> > > partition layout using any file system and/or container format
> > > combination offered in a default installer configuration, except
> > > btrfs."
> > > 
> > > but that's odd. Why is btrfs, alone, an exception? It kinda goes
> > > against the fundamental idea of the criterion: that we stand
> > > behind
> > > everything the UI offers.
> > 
> > All of this, the criteria, and the UI support for btrfs are from
> > the
> > many years old proposal to make btrfs the default filesystem.  In
> > the
> > beginning, it was not ready, but did show promise. This proposal
> > came
> > up for several releases in a row, and at the end of it, even the
> > upstream developers recommended against it.  At this point, it is
> > safe
> > to say that btrfs will not be the default.  Since that time, things
> > have not gotten better.   Yes, there is active btrfs development
> > upstream.  It is fairly narrowly focused, and not something we can
> > rely upon for a supported default among the Fedora use cases.
> 
> Getting btrfs in Fedora to be in a state where it *could* be the
> default is something I am working towards. However, it is *very* hard
> when people keep shutting down discussions that I try to have about
> enablement related to it. The situation with btrfs today is many
> orders of magnitude better than before, and yet I've mostly been
> improving Btrfs support in Fedora in tiny ways because the bigger
> things to do (improving kickstart, Anaconda, etc.) are impossible due
> to how difficult it is to contribute to those projects.

Sorry about this. One of the major reasons why contribution to Anaconda
is hard is because of the insane amount of possibilities which can go
wrong with the simple patch and the really hard 

Re: Fedora LiveOS, journal missing ~25s of early boot

[jkonecny]

Hello Chris,

Thanks a lot for your investigation, work to make this fixed and giving
us a heads-up. If I see it correctly it is now built in the Rawhide so
we don't have to intervene at this point.

If there anything else we can help you with. Feel free to ask.

Best Regards,
Jirka

On Tue, 2019-07-30 at 10:10 -0600, Chris Murphy wrote:
> Hi,
> 
> Summary: On Fedora LiveOS, e.g.
> Fedora-Workstation-Live-x86_64-Rawhide-20190728.n.1.iso, the journal
> is missing the first 20-30s of all boot/startup related messages. The
> reason is a bit complicated, systemd-journald appears to have a bug
> wanting keep_free space too high, and Fedora's lives have had
> shrinking free space consistently over time as the "payload" gets
> bigger. The result is now systemd-journald almost immediately vacuums
> the first journal file, deleting it, causing the loss of early boot
> and startup messages.
> 
> Why I think Anaconda team might care: LiveOS is inherently a
> non-deterministic environment for the installer, and losing a bunch
> of
> early boot and startup messages like all the liveos assembly, the
> overlay (whether dm or overlayfs based in the future), networking,
> udev and other non-kernel device discovery, and dracut debug messages
> - don't exist in the journal and quite a lot of such messages for
> whatever reason do not forward to console or kmsg when using
> systemd.journald.forward_to_X parameters. Therefore if the journal is
> deleted, the messages are flat out gone and any troubleshooting and
> introspection is really difficult.
> 
> I proposed this as a blocker bug.
> https://bugzilla.redhat.com/show_bug.cgi?id=1715699
> 
> It's been rejected twice, mainly because the Fedora Basic Release
> Criterion for system logging applies to the post-installed system. It
> doesn't apply to any of the installer images. So there is a proposal
> over on test@ list to change the location of this requirement so that
> it applies to installer images. And I figured installer devs might
> have an opinion if this is blocker worthy.
> 
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/message/QAV3I2W6337ZW7CSYJYAU2SY3GL4KI6F/
> 
> https://fedoraproject.org/wiki/Basic_Release_Criteria#System_logging
> 
> 
> 

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

Anaconda modularization and your addon

[jkonecny]

Good day Thomas,

I'm working on Anaconda (Fedora/RHEL/CentOS installer) and we have
recently seen your presentation about addon on Anaconda you are using
for the CERN purposes[0]. That's great to hear you are using and
extending our project. Hope you like how Anaconda progress.
   
I want to ask you about current status of this addon. If you are using
it or testing it on Fedora or if you are planning to adapt it on RHEL-
8? The reason is that we are doing a bigger improvement of how Anaconda
is working on the backend side and it will probably touch your addon.
We want to provide you a stable API which you and even us will use. You
can look on my presentation [1] and our blog [2] unfortunately
it's little bit outdated but the main idea stays the same. You can also
look on the recent upstream changes, all the work we are doing is more
or less used on Fedora even now.

I writing you mainly because we want to avoid breaking of your addon.
In case you will have problems with the addon thanks to the transition
to a new solution please feel free to contact us on

mailing list:
anaconda-devel-list@redhat.com

or IRC:
freenode #anaconda

[0]:
https://www.youtube.com/watch?v=Fbml_WGMnoQ=youtu.be=PLuRtbOXpVDjDh4NucvtwGLYZUJe6efi3x=510

[1]: https://www.youtube.com/watch?v=00W8SsRrU8g=1s

[2]:
https://rhinstaller.wordpress.com/2017/10/09/anaconda-modularisation/
https://rhinstaller.wordpress.com/2017/11/23/anaconda-modularization-install-classes-and-addons/
   
Best regards,
Jirka

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

Re: On disk repos, anaconda, and Installation Source

[jkonecny]

Hello,
So about the code and treeinfo. This repository is not loaded because
it is disabled on the netboot image and the code is iterating only
between enabled repositories, which is the correct behavior I would
say.
Yes the comment is wrong, originally it was above the
``self.set_updates_enabled(self._updates_enabled)`` line and the
meaning was that all the repos there will be enabled (under some
conditions) and user can adjust this by the checkbox in UI. The are of
course the conditions so it's not always so or so. That comment should
definitely change or the whole code should be rewritten to be more
readable.
You can read the conditions if you follow the `enabled` variable in
this method. In short these local repositories will be enabled if there
is no installation method set and it is not automatic installation --
(in other words "Closest mirror" installation). 
And no, this repositories shouldn't be loaded into the addon list right
now. We can think about that in the further changes but now it is just
implementation detail of the Closest mirror installation type.
Cheers,Jirka

On Fri, 2019-06-14 at 13:58 -0500, Pat Riehecky wrote:
> I noticed an unexpected behavior in Fedora 30.
> 
> 
> 
> The net install disk for Workstation ships with the
> 'fedora-cisco-openh264' repo on the media.  However, the repo is
> not
> listed under the 'Installation Source' spoke.
> 
> 
> 
> Should this repo be loaded into the addons list?
> 
> 
> 
> I suppose this is a bit of confusion based on this comment [1],
> vs
> the actual behavior where only `.treeinfo` repos that are also on
> disk get enabled [2]
> 
> 
> 
> Thoughts?
> 
> 
> 
> Pat
> 
> 
> 
> 
> 
> [1]
> https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/payload/dnfpayload.py#L1144
> 
> 
> 
> [2] self.addons seems to be populated via __init__.py and what it
> finds in `.treeinfo` I think.
> 
> https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/payload/dnfpayload.py#L1235
> 
> 
> 
> -- Pat Riehecky
> Fermi National Accelerator Laboratorywww.fnal.gov
> www.scientificlinux.org
>   
> 
> ___Anaconda-devel-list
> mailing listanaconda-devel-l...@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: "enabling zram.service on LiveOS boots"

[jkonecny]

Hi Chris,

There has to be change in the live media creation. Anaconda don't have
power on what is booted on Live DVD.

I think the Fedora kickstart used to create the DVD Live image is the
change target here. That kickstart should enable the service so it will
be auto-started during the Live DVD boot. However, if we do that then
the service will be also enabled on the installed system which is
probably not what we wanted to do...

Adding Brian to the conversation. Do you have an idea how to enable a
service on the live media but not in the installed system?

Another option is to change the kernel boot parameters to require the
service as you said below, but that also has to change in the kickstart
file.

Jirka

On Mon, 2019-06-17 at 08:40 -0600, Chris Murphy wrote:
> Hi,
> 
> Fedora Workstation WG agreed some time ago to enable zram.service
> when
> booting LiveOS, which is already the behavior for netinstalls.
> https://pagure.io/fedora-workstation/issue/56#comment-546837
> 
> How should this be done?
> 
> On netinstall boot I see zram.service is loaded, active, and executed
> /usr/libexec/anaconda/zramswapon by I think anaconda itself starts
> this service.
> 
> On LiveOS boot I see zram.service is loaded, inactive.
> 
> I thought about changing zram.service to add
> 
> ConditionKernelCommandLine=rd.live.image
> 
> But that'd break the netinstall case.
> 
> It could also be done by making only the LiveOS kernel command line
> include 'systemd.wants=zram.service'
> 
> And still another option is I'm seeing there are two of these, at
> least in Rawhide Lives.
> 
> [root@localhost-live ~]# systemctl list-unit-files | grep zram
> zram-swap.servicedisabled
> zram.service static
> [root@localhost-live ~]#
> 
> zram.service is part of the anaconda package, and zram-swap.service
> is
> part of  zram-0.3-1.fc30.noarch
> 
> It's not yet determined if installed Workstation systems will change
> default behavior to swap on zram, zswap, or something else.
> 
> Thanks,
> 
> 
> 

___
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)

[jkonecny]

Hi Dan,

You don't need to merge anything. All changes can be done by one
updates image. We are creating updates image with new Blivet changes
all the time.

You can do this manually from anaconda source (with your changes) by
calling:

./scripts/makeupdates -t  -k

Then you will see ./updates/ folder in the anaconda git root. You can
copy whole blivet to the path:

./updates/run/install/updates/blivet

That way you can test both Anaconda and Blivet changes together.

Another solution is to use this tool:

https://github.com/rhinstaller/devel-tools/tree/master/anaconda_updates

Anaconda updates should be able to automate some steps but it requires
additional configuration. 

Jirka

On Mon, 2019-06-10 at 13:54 +0200, 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?
> 
> 
> [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: Question on Anaconda rpmostree payload

[jkonecny]

Good point.
Adding Anaconda devel list. The community could be interesting on this.
Jirka
On Tue, 2019-05-28 at 14:29 -0400, Colin Walters wrote:
> Adding Dusty and Jonathan.
> 
> Can we take this thread to anaconda-devel@ ?  No reason not to
> discuss in public AFAICS, and this way conversation is archived for
> historical purposes, etc.
> 
> On Tue, May 28, 2019 at 1:04 PM  wrote:
> > Hello,
> > 
> > 
> > 
> > We are doing bigger rewrite of the Anaconda and we have a problem
> > with
> > 
> > the moving sysroot of rpmostree payload. 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.
> > 
> > 
> > 
> > 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.
> > 
> > 
> > 
> > 
> > 
> > Could you please give a suggestion for this?
> > 
> > 
> > 
> > 
> > 
> > Thanks,
> > 
> > Jirka 
> > 
> > 
> > 
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Find out aim of your Anaconda changes

[jkonecny]

On Mon, 2019-05-13 at 10:29 -0500, Pat Riehecky wrote:
> For folks following along at home,
> 
> Samantha, Lars, and I had a really productive conversation at Summit!
> 
> I think we developed a few ideas from there.
> 
> Those ideas have a bit of work needed to turn them into proposals,
> which 
> will then need some review, which will then need  you get the
> idea.
> 
> Pat

That's great Pat. I didn't talked to Samantha yet but I'm looking
forward to hear about your discussion.

And sorry that I didn't replied to your original mail yet. I was ill
for the last week :(.

Jirka

> 
> On 4/26/19 8:38 AM, Samantha Bueno wrote:
> > Hi Pat,
> > 
> > Just wanted to let you know that I will be at Summit this year. I
> > manage the installer team and can definitely meet up with you.
> > You're
> > right that there won't be a detailed text trail to reference later,
> > but it's always helpful to meet up with users and customers, so I'd
> > be
> > glad to chat. :) You definitely have some interesting ideas, and
> > it's
> > really useful to see the use cases/stories you've provided as well
> > --
> > very well thought-out. This is exactly the kind of thing that helps
> > us
> > with our long-term planning for the project. That said, apologies
> > that
> > we still have not provided a detailed reply to you yet. We're a bit
> > pinched for time lately, but rest assured that it has not fallen
> > off
> > our radar.
> > 
> > Feel free to contact me off-list to exchange contact info.
> > 
> > Thanks,
> > 
> > On Wed, Apr 17, 2019 at 3:58 PM Pat Riehecky 
> > wrote:
> > > Hello,
> > > 
> > > I'll see if I can explain my goals and what I'm hoping to
> > > achieve/make
> > > easy.  I will also be at Summit this year if any folks want to
> > > meet up
> > > for a chat or I might be able to setup a conference call - that
> > > may be
> > > easier.  But that doesn't have the helpful listserv archives...
> > > 
> > > The anaconda addon I'm currently playing with is targeted at
> > > Fedora
> > > (31?) but, if it works out, I'm likely to try and get it into
> > > shape for
> > > any EL8 build.
> > > 
> > > My hope long term is to make use of the DBus API, but I'm still
> > > getting
> > > the hang of that...
> > > 
> > > I'm targeted entirely at the DNF payload for now, but I'm
> > > interested in
> > > the rpm-ostree one as well.  I've just never found the time to
> > > really
> > > explore rpm-ostree in this manner.
> > > 
> > > As for my vision for what I'm aiming to achieve, I'm hopeful to
> > > get
> > > Anaconda able to account for these usage patterns during install:
> > > 
> > > 1) Make it easier for users to install packages from EPEL (such
> > > as the
> > > Cinnamon or KDE desktops) at install time.
> > > 
> > > 2) Allow users to select their desired variant/spin (e.g., Fedora
> > > Scientific, Silverblue, Fedora Astronomy, Fedora Design Suite,
> > > CentOS
> > > oVirt, CentOS HPC etc.) within Anaconda at install time.
> > > 
> > > 3) Make it easier for users to enable some extra repos the
> > > distribution
> > > trusts for general use and have others available but disabled by
> > > default.  Users may or may not want those repos.
> > > 
> > > I tend to get drawn to .treeinfo as a place where the
> > > "installation"
> > > talks about what it knows and who it trusts.
> > > 
> > > To illustrate points 1-3, I have some user stories / generic
> > > ramblings
> > > on behavior I've seen.
> > > 
> > > --
> > > Summation of thoughts on EL side
> > > 
> > > In many ways one of my strong desires on the EL side is being
> > > able to
> > > take ##.0 media point it at a ##.10 install tree and have
> > > anaconda say
> > > "Hey I found these variants and these repos that may or may not
> > > have
> > > existed X years ago, but you can just use them."
> > > 
> > > --
> > > Summation of thoughts on the Fedora side
> > > 
> > > Spins are neat; Labs has cool stuff.  Users may not be aware or
> > > know how
> > > to get what they want.  One boot.iso that does all that and maybe
> > > either
> > > RPM or OS-Tree could help curious folks try various things
> > > without
> > > having to make extra media.
> > > 
> > > ---
> > > Story 1: Desktop Environments
> > > 
> > > This story is about our EL users.
> > > 
> > > A large number of our workstation users have a strong preference
> > > for
> > > Cinnamon Desktop or KDE.  With RHEL7, Cinnamon is packaged up in
> > > EPEL.
> > > With RHEL8, I believe there are folks planning to get Cinnamon
> > > and KDE
> > > into EPEL8.  This is great!
> > > 
> > > However, I'd like to simplify things for folks doing the
> > > installation.
> > > The initial plan was to just add EPEL as a disabled repo and
> > > instruct
> > > users on how to click to enable EPEL.  Then they would see the
> > > Cinnamon
> > > Desktop group in the UI.  These folks are not often interested in
> > > Linux
> > > administration, but require root access for custom kernel driver
> > > development, installation of 

Re: Find out aim of your Anaconda changes

[jkonecny]

Hi Pat,

I must say that you have a big and interesting goals. We need to sit
down and think about that.

I just want to say you that we have holidays in Czech from tomorrow to
Monday so there will be a delay before we find a time to do that.

Have a great weekend and thanks for the reply,
Jirka

On Wed, 2019-04-17 at 14:57 -0500, Pat Riehecky wrote:
> Hello,
> 
> I'll see if I can explain my goals and what I'm hoping to
> achieve/make 
> easy.  I will also be at Summit this year if any folks want to meet
> up 
> for a chat or I might be able to setup a conference call - that may
> be 
> easier.  But that doesn't have the helpful listserv archives...
> 
> The anaconda addon I'm currently playing with is targeted at Fedora 
> (31?) but, if it works out, I'm likely to try and get it into shape
> for 
> any EL8 build.
> 
> My hope long term is to make use of the DBus API, but I'm still
> getting 
> the hang of that...
> 
> I'm targeted entirely at the DNF payload for now, but I'm interested
> in 
> the rpm-ostree one as well.  I've just never found the time to
> really 
> explore rpm-ostree in this manner.
> 
> As for my vision for what I'm aiming to achieve, I'm hopeful to get 
> Anaconda able to account for these usage patterns during install:
> 
> 1) Make it easier for users to install packages from EPEL (such as
> the 
> Cinnamon or KDE desktops) at install time.
> 
> 2) Allow users to select their desired variant/spin (e.g., Fedora 
> Scientific, Silverblue, Fedora Astronomy, Fedora Design Suite,
> CentOS 
> oVirt, CentOS HPC etc.) within Anaconda at install time.
> 
> 3) Make it easier for users to enable some extra repos the
> distribution 
> trusts for general use and have others available but disabled by 
> default.  Users may or may not want those repos.
> 
> I tend to get drawn to .treeinfo as a place where the "installation" 
> talks about what it knows and who it trusts.
> 
> To illustrate points 1-3, I have some user stories / generic
> ramblings 
> on behavior I've seen.
> 
> --
> Summation of thoughts on EL side
> 
> In many ways one of my strong desires on the EL side is being able
> to 
> take ##.0 media point it at a ##.10 install tree and have anaconda
> say 
> "Hey I found these variants and these repos that may or may not have 
> existed X years ago, but you can just use them."
> 
> --
> Summation of thoughts on the Fedora side
> 
> Spins are neat; Labs has cool stuff.  Users may not be aware or know
> how 
> to get what they want.  One boot.iso that does all that and maybe
> either 
> RPM or OS-Tree could help curious folks try various things without 
> having to make extra media.
> 
> ---
> Story 1: Desktop Environments
> 
> This story is about our EL users.
> 
> A large number of our workstation users have a strong preference for 
> Cinnamon Desktop or KDE.  With RHEL7, Cinnamon is packaged up in
> EPEL.  
> With RHEL8, I believe there are folks planning to get Cinnamon and
> KDE 
> into EPEL8.  This is great!
> 
> However, I'd like to simplify things for folks doing the
> installation.  
> The initial plan was to just add EPEL as a disabled repo and
> instruct 
> users on how to click to enable EPEL.  Then they would see the
> Cinnamon 
> Desktop group in the UI.  These folks are not often interested in
> Linux 
> administration, but require root access for custom kernel driver 
> development, installation of unpackaged sources, or building/running 
> containers/VMs.
> 
> The main goal here is to provide a clear non-technical workflow for
> "How 
> do I get Cinnamon Desktop when I install my system?"
> 
> The current SL7 workflow is:
>   open a terminal
>   sudo yum install yum-conf-epel
>   sudo yum install @cinnamon-desktop
>   logout
>   select Cinnamon Session in GDM
>   login
> 
> For CentOS7 the workflow is:
>   open a terminal
>   sudo yum install http://path/to/epel-release
>   sudo yum install @cinnamon-desktop
>   logout
>   select Cinnamon Session in GDM
>   login
> 
> Whereas, If the repo is listed under Software Sources (behavior from
> the 
> reverted bit) the workflow would be:
>Click on Software Sources
>Check the box next to EPEL
>Click on Software Selection (which is automatically marked for
> review 
> when you change Software Sources)
> 
> On my test node, Cinnamon Session was the default if you use the yum 
> group from Anaconda.
> 
> If users are installing off of a DVD (Not Live Image) and not on the 
> network, EPEL will not be available.  So, EPEL shouldn't be enabled
> by 
> default to permit offline installations.  Anaconda is currently
> smart 
> enough that if I add a repo requiring the network but do not have a 
> network connection "all the right stuff" happens.  EPEL is external,
> so 
> disabled generically feels like the right default anyway.
> 
> I like a lot about the reverted workflow.  I think it provides a
> clean 
> user experience.  Getting folks to click on Software Sources is 
> achievable but that is also a workflow I'd like to 

Find out aim of your Anaconda changes

[jkonecny]

Hello Pat,

You started to raise more and more pull requests to our Anaconda code
base. I really like we have that active contributor like you, however,
we have a hard time to see what you want to achieve with these changes.

It is not that trivial to test your changes and also we would like to
help you to create a solution which will be beneficial for all of us.
So before I'll merge your another PR[1], I would like to know more
about your project.

We have a vision of what is your aim for these changes.
At RHEL 7 & RHEL-8 you have an ability to add disabled addon
repositories specific for your distribution, this was removed[2] with a
message that we will provide you another solution how to add this back.
Our changes which will make your changes incompatible are now planned
to RHEL-8.2.
What we are planing to have (and we need to have) is the ability to add
a repository by DBus API and disable this repository by the same API
afterwards. However for that, you have to have an addon. There are also
other options in our aim but we have to know what you are trying to
achieve first. 

Could you please answer the questions below:

1) Are you planning to have an Anaconda addon which will use our DBus
API?

2) Are you planning to branch SC from Fedora or only from RHEL?

3) I know you want to have EPEL repository disabled by default in the
source spoke but how do you want to achieve this state? 

4) Is there something else you want to change from the default Anaconda
behavior?

[1]: https://github.com/rhinstaller/anaconda/pull/1949
[2]: https://github.com/rhinstaller/anaconda/pull/1690

Thanks a lot for your contributions,
Jirka

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

Re: Customizing Anaconda

[jkonecny]

Hi Navin,
It depends how you want to control this user organization/id. 
Do you have an addon which will setup this? Do you want to extend the
existing Anaconda graphical user interface?Do you want to extend the
existing Anaconda text user interface?Or should this be supported by
kickstart installation only?
Could you please answer the questions?Jirka
On Mon, 2019-04-15 at 21:00 +0530, Danishka Navin wrote:
> Hi there,
> 
> I am working on a fedora remix. 
> I need to let user to add organization name/id during the user
> account creation.
> Is there any guide or examples on such additional changes for
> anaconda?
> 
> 
> Regards,
> -- 
> Danishka Navin
> 
> 
> 
> 
> 
> ___Anaconda-devel-list
> mailing listanaconda-devel-l...@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: feature request the ability to install updates from the internet while installing

[jkonecny]

Hello Majid,

You are unable to do that with Live DVD. However, you are able to do
that with netinst ISO:

64bit Workstation:

https://download.fedoraproject.org/pub/fedora/linux/releases/28/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-28-1.1.iso

32bit Workstation:

https://download.fedoraproject.org/pub/fedora-secondary/releases/28/Workstation/i386/iso/Fedora-Workstation-netinst-i386-28-1.1.iso

Hope this helps you,
Jirka K.

On Thu, 2018-07-26 at 13:37 +0100, Majid Hussain wrote:
> hi all,
> I hope you all are having a great day,
> would it be possable to have anaconda install updates while
> installing fedora?
> 
> just a thought I had after reinstalling today, it would save time
> maybe a box that says get updates or something?
> 
> is this feezable?
> many thanks for reading! :)
> Majid Hussain

___
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

[jkonecny]

Hello Pat,


On Tue, 2018-04-24 at 14:12 -0500, 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.

Could you please point us to screenshots of your addon? I think it
would help us to get better overall idea of what are you trying to
achieve here.

> 
> == 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.

This is a UX problem and it would be nice to solve.


> 
> 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

This may be solved by some of the changes we are making right now. See
below.

> 
> == 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 solvable programming problem.

Wouldn't it 

Re: Installer support for flatpak

[jkonecny]

Hello Matthias,
Those steps sound reasonable to me. In addition to that (when those
pointsbelow will work) it could be nice to support flatpak as a
kickstart command. For example to  add remote repositories and it even
could be interesting having flatpak as Anaconda payload so the 
%packages section will support them.
However, everything above is for later better look & feel, for the
first version the %post section is a great idea. It is nice proof of
concept.
I have also a question are you planning to have Atomic Workstation Live
DVD oronly netinst?
I'm looking forward to see Atomic Workstation in action ;),Jirka
On Tue, 2018-04-17 at 11:32 +, Matthias Clasen wrote:
> Hi,
> 
> I would like to discuss flatpak support for anaconda.
> 
> The issue comes up in the context of Atomic Workstation and
> rpm-ostree. Currently, the OS image contains a bunch of
> preinstalled desktop applications (as rpms). It would make a
> lot more sense to move to installing all desktop applications
> as flatpaks, so they are independent from the OS.
> 
> For preinstalled apps, that means anaconda may have to learn
> a bit about flatpak. We are aiming to have flatpaks built in Fedora
> infrastructure well before F29, and that would be the time when
> we can consider preinstalling them.
> 
> When I talked to Colin about this before, he suggested
> a few steps for this:
> 
> 1) Make the flatpak command work in %post
> 2) Add a flatpak repository to the iso
> 
> Is there anything else that is needed ?
> 
> Matthias
> 
> 
> ___
> 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: Overriding Addons in Anaconda

[jkonecny]

Hello Gabe Alford,
Basically you can't do that and I don't think we wanted to allow that.
Addons should be isolated or they should have an API but you shouldn't
be allowed to change them without their notice.
Sorry for the bad news.
Jirka
On Mon, 2018-03-26 at 17:18 -0600, Gabe Alford wrote:
> Hello,
> 
> I was wondering if there is a way to get/modify a list of Addons from
> another Addon in Anaconda, or if there is a way that I can get the
> %addon sections of another Addon?
> 
> Basically, I would like to create an addon that can disable the kdump
> addon or any addon from a provided list.
> 
> 
> 
> 
> ___
> 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: Lorax has changed groups on github: rhinstaller -> weldr

[jkonecny]

Wish you good luck on the other place in GitHub world. :)

We will miss you Lorax.

On Mon, 2018-03-19 at 14:15 -0700, Brian C. Lane wrote:
> I've just completed moving Lorax over to the weldr group on
> github.com
> The new location is:
> 
> https://github.com/weldr/lorax
> (github will forward you to the new location if you visit the
> rhinstaller one)
> 
> All issues and PRs have be preserved in the move.
> 
> You can update git to point to the new location like so:
> 
> git remote set-url origin g...@github.com:weldr/lorax.git
> 
> Docs are now hosted here:
> 
> http://weldr.io/lorax/
> 
> (sadly github doesn't forward the old docs location to the new one)
> 
> If you have any problems, or find something I've forgotten to update
> please let me know.
> 

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

Re: How did redhat build centos7 image.

[jkonecny]

Hi Vit Ry,


Thank you for links. It's nice to have step by step tutorial. I will
save it for later :).

Jirka

On Tue, 2017-12-05 at 02:14 +0300, Vit Ry wrote:
> Hi, Jirka! 
> You can start here for lorax:  https://www.brianlane.com/creating-the
> -anaconda-bootiso-with-lorax.html 
> 
> My quick en-tutor draft can be found here:  https://github.com/Frodox
> /bitthinker.com/blob/master/content/en/develop/how-to-create-custom-
> centos-like-linux-distro-iso.mdmd  , but it is still in progress and
> ru-version in priority (and with more examples). You can write
> me/here if you have any questions in progress.
> 
> Regards,
> Vit Ry.
> 
> 
>   On Mon, 04 Dec 2017 10:52:04 +0300  wrote
>  
>  > Hello,
>  > The Lorax tool is used for creating boot.iso including initrd. The
> same tool is also used for creating Fedora and RHEL.
>  > https://github.com/rhinstaller/lorax
>  > Jirka
>  > On Wed, 2017-11-22 at 11:38 +0800, 徐毅
> wrote:___ 
>  > Anaconda-devel-list mailing list 
>  > Anaconda-devel-list@redhat.com 
>  > https://www.redhat.com/mailman/listinfo/anaconda-devel-listHi,
>  It's very interesting to understand deep in linux step by
> step.   But where still a question confuse me for years.
>  >  How did redhat build centos7 image from zero.
>  >  I found installer program anaconda. And I know how to build
> bootable iso using gemisoimage.  But i donn't know how redhat
> build inital initramfs.
>  >  I didn't found that on git.centos.com  So, please
> help me!
>  > 
>  > 
>  >   thanks very much !!!
> ___Anaconda-devel-list
> mailing listAnaconda-devel-list@redhat.comhttps://www.redhat.com/mail
> man/listinfo/anaconda-devel-list
> 
> 
> ___
> 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: How did redhat build centos7 image.

[jkonecny]

Hello,
The Lorax tool is used for creating boot.iso including initrd. The same
tool is also used for creating Fedora and RHEL.
https://github.com/rhinstaller/lorax
Jirka
On Wed, 2017-11-22 at 11:38 +0800, 徐毅 wrote:
> Hi, It's very interesting to understand deep in linux step by
> step. 
>  
>  But where still a question confuse me for years.
> 
>  How did redhat build centos7 image from zero.
> 
>  I found installer program anaconda. And I know how to build
> bootable iso using gemisoimage.
>  
>  But i donn't know how redhat build inital initramfs.
> 
>  I didn't found that on git.centos.com
>  
>  So, please help me!
> 
> 
> 
>   thanks very much !!!
> 
> ___
> 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: Mandatory user spoke

[jkonecny]

Hello,
You should be able to modify the UserSpoke in a similar way how the
Source spoke is working:
https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/ui/gui/s
pokes/installation_source.py#L576
You need to have mandatory and ready properties implemented.
Also if you want to use this only for Initial Setup you can use
environment flag in a similar way how we are using it in the Network
spoke. This will enable you to run the code only inside of Initial
Setup and not in Anaconda.
https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/ui/gui/s
pokes/network.py#L1530
You just replace the ANACONDA_ENVIRON by this:
https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/constant
s.py#L135 (Firstboot is name of InitialSetup, historically reasons)

You can of course hide this spoke and use your addon spoke by
implementing this property:
https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/ui/gui/s
pokes/custom_storage.py#L211
or by changing configuration file /etc/sysconfig/anaconda, you should
be able to find it in Anaconda documentation.
I hope this will help you.
Jirka

On Wed, 2017-08-30 at 23:18 +0300, Cristian Stan wrote:
> Hello all, 
> 
> I have an issue I could not fix by myself so far:
> 
> We have a custom Fedora build. After the base Anaconda install,
> Initial Setup runs with two spokes, one with a custom add-on, and the
> user creation spoke. 
> Our issues are with the default user creation spoke; we should both
> enable by default the 'Make this user administrator' checkbox and
> make the user creation mandatory, so that the setup may not be exited
> without creating a user. I've even tried disabling altogether the
> user creation spoke to be able to run my own user creation add-on.
> I've had no luck so far.
> 
> 
> What I've tried until now:
> 
> To enable by default 'Make this user administrator' I have:
> 
> * modified the 'c_admin' object in user.glade to enable it by default
> * tested separately the 'c_admin' user.glade object in Glade
> Interface Designer (it works, as expected)
> * tested the 'c_admin' modification on 'c_usepassword' (to isolate
> the issue; the same setting for one object does not work for the
> other)
> 
> To make the original user creation spoke in Initial Setup mandatory I
> have:
> 
> * modified the '_checkUsername' method from user.py, class
> 'UserSpoke' (Anaconda sources)
> 
> All the modifications were performed after Anaconda's first stage and
> before running Initial Setup.
> 
> 
> 
> Do you have any ideas about this and how should I proceed?
> 
> 
> Thank you, your help is greatly appreciated!
> 
> Cristian Stan
> 
> 
> ___
> 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: logging mount assembly and bootloader install, chroot missing?

[jkonecny]

On Sat, 2017-09-09 at 18:36 -0700, Adam Williamson wrote:
> On Tue, 2017-08-08 at 12:22 -0600, Chris Murphy wrote:
> > The program.log shows mount commands for assembly, followed by
> > installation itself copying files to a path prefix /mnt/sysimage,
> > and
> > then bootloader setup. Isn't there a chroot happening before the
> > bootloader setup? It's not in the log so I'm having some difficulty
> > exactly replicating an installation environment while
> > troubleshooting
> > this bug:
> > 
> > So the questions are:
> > Is there a chroot?
> > Is there a way to discover the command being used?
> > And if there is a chroot, is there a way to log this command in the
> > future?
> > 
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1289752
> 
> Use the source, Luke:
> 
> https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/bootlo
> ader.py
> 
> and then search for 'root='. You'll find that most of the bootloader
> installation-related commands run via iutil.execWithRedirect, with
> root
> set to iutil.getSysroot() . Of course, you can look in iutil.py to
> see
> what these do. If you *do* look there, you'll see that indeed the
> relevant functions don't *currently* log the root argument. I think a
> PR to add this wouldn't be unreasonable.

I like this idea so I've created PR for that:
https://github.com/rhinstaller/anaconda/pull/1191

Jirka

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

Re: Automated rescue mode

[jkonecny]

Hello,

First of all, nice solution for your issue and thank you for sharing it
here. IMHO it could be really valuable for others. 

The "Automated rescue" looks to me like an interesting idea. It could
be enhancement of the existing "rescue" kickstart command.
Unfortunately, we are swamped with other work right now but we will
look on that in the future.

Please file an RFE bug to bugzilla and write there how do you think
this feature should work. It will be better for addressing future
questions and implementing the best solution. 

Jirka

On Mon, 2017-07-03 at 09:57 +0300, Artem Bityutskiy wrote:
> Hi,
> 
> I am using the stock Fedora 25 OS installer as a "service OS", just
> because it is convenient and I do not have to build my own. Should
> something bad happen to a host in my automation system, I just boot
> the
> host into the Fedora installer's kernel/initramfs over network and
> have
> a decent rescue environment.
> 
> The Fedora OS installer is based on Anaconda. It can find and mount
> the
> "sysroot" to "/mnt/sysimage", which is also very convenient.
> 
> Now, I wanted my "service OS" to automatically do this - find the
> sysroot and properly mount it without any questions asked. I could
> not
> find the "right" way of doing this, and ended up with a hacky trick.
> 
> I am sharing the trick in case someone else will be googling for it
> in
> the future. And of course I'd appreciate better ideas.
> 
> First of all, boot anaconda into the rescue mode, by adding
> 'inst.rescue' to kernel boot parameters.
> 
> I also have a bunch of 'inst.ks' and 'inst.stage2' and dracut
> networking parameters.
> 
> And yes, I have a very small minimal KS file too, which only
> configures
> repositories and some network-related stuff. Does not do anything
> about
> partitions or packages. 
> 
> Then I put this to my %pre in order to make anaconda proceed with
> mounting the sysroot:
> 
> tmux send-keys -t anaconda -- 1 C-m
> 
> It is hackish, but works. It basically sends key "1" to anaconda, so
> anaconda selects the "Continue" choice, and proceeds with mounting
> sysroot.
> 
> This is not the first time I use anaconda's tmux terminal to achieve
> my
> goals with anaconda. E.g., I use it for capturing anaconda's VGA
> output
> remotely.
> 
> So thanks for using tmux in anaconda - very handy!
> 
> ___
> 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