Re: Making reqpart in kickstart to do BIOS+UEFI with GPT on x86?

[Martin Kolman]

On Thu, Sep 2, 2021 at 9:20 AM Jiri Konecny  wrote:

> Hi everyone,
>
> Dne 01. 09. 21 v 20:22 Joe Wulf napsal(a):
>
> On Wednesday, September 1, 2021, 01:58:21 PM EDT, Neal Gompa
>   wrote:
>
>
> > On Wed, Sep 1, 2021 at 1:47 PM Brian C. Lane  wrote:
> > >
> > > On Wed, Sep 01, 2021 at 04:08:30PM +0200, Dan Horák wrote:
> > > > my idea would be adding a "--hybrid" option to "reqpart" that would
> > > > create both "BIOS" + "EFI" partitions on x86 systems. For remaining
> > > > systems I believe they use only a single boot partition kind, so
> > > > nothing will change there. This way you could create a "works
> > > > everywhere" image the easiest way.
> > >
> > > I'd like to see adding flags an option of last resort :) If it's
> > > possible for anaconda to figure out what's needed automatically that's
> > > would be best.
> > >
> >
> > How would Anaconda be able to figure it out? The idea is that this
> > works *regardless* of what the host says it does. Unless you're just
> > going to make Anaconda always do hybrid for x86, there's no reasonable
> > way for that to be "auto-detected".
> >
>
> When I kickstart, I check "/sys/firmware" for 'efi' which exists, which I
> later use to influence which command to use to rebuild grub.
> My point is that anaconda should be able to check for /sys/firmware/efi,
> for forcing hybrid usage, or it is only a BIOS host.
>
> Yes, Anaconda could look if we can install also UEFI next to the BIOS but
> the point is
> that most of the users do not want this and we are not able to figure out
> if we
> should install only UEFI or both BIOS boot + UEFI.
>
Yeah, I'm afraid some sort of flag will be needed as we certainly don't
want this to be the default behavior.

The use case we are discussing is about (cloud) image generation, right ?
Eq. you want to generate an image that will boot on both BIO or UEFI
system, with Anaconda. I think that makes perfect sense for (cloud) images,
to make them boot anywhere.

Yet for an installation to physical hardware, I don't think it makes sense
- it's either configured to boot as a BIOS machine or an UEFI machine, so
making the thing both BIOS + UEFI capable IMHO does not make sense. Having
both options in place would just complicate things, consume extra space &
make it more fragile.

Ho do you invoke Anaconda in this case ? With --image or something like
that ? Maybe that could be wired to make the resulting image hybrid, but
not trigger on installations to physical or virtual hardware ?


>
> Jirka
>
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/anaconda-devel-list
>
> ___
> Anaconda-devel-list mailing 
> listAnaconda-devel-list@redhat.comhttps://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
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/anaconda-devel-list

Re: Making reqpart in kickstart to do BIOS+UEFI with GPT on x86?

[Martin Kolman]

On Tue, Aug 31, 2021 at 4:58 AM Neal Gompa  wrote:

> Hey all,
>
> Last week, Dan Horak notified the Cloud WG that we accidentally broke
> ppc64le images[1] with our Hybrid BIOS+UEFI on GPT setup[2] because
> now there's no PReP partition being made for POWER images.
>
> He suggested in the ticket that it might be worth asking if we could
> have the reqpart command extended to do BIOS+UEFI setup when on GPT.
> If not by default, perhaps adding a flag to do it?
>
What's would be the difference from the current behavior ?

The docs[0] say about x86 GPT:

"Automatically create partitions required by your hardware platform. These
include a /boot/efi for x86_64 and Aarch64 systems with UEFI firmware,
biosboot for x86_64 systems with BIOS firmware and GPT, and PRePBoot for
IBM Power Systems."

So it would create biosboot and UEFI partitions at the same time (possibly
after a flag being passed) ? Also, does this also impact autopart - should
it provide similar functionality ?

In any case, as this is a but over my head, I'm adding Vendy a Vojta to
chime in on the storage stuff and Javier to possibly comment on the
bootloader related aspects.

[0] https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#reqpart


>
> This would make it a lot easier for me to get this working across
> architectures with Fedora Cloud and would probably be beneficial for
> RHEL 9+ as well.
>
> What do y'all think?
>
> Thanks in advance and best regards,
> Neal
>
> [1]: https://pagure.io/cloud-sig/issue/346
> [2]:
> https://pagure.io/fedora-kickstarts/blob/ec56783946dcd3c81ab55f33a8df8d30cd38355b/f/fedora-cloud-base.ks#_39-47
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
>
> ___
> 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

[Martin Kolman]

On Sat, 2021-02-27 at 11:41 -0800, Michel Alexandre Salim wrote:
> On Fri, 2021-02-19 at 14:02 +0100, Martin Kolman wrote:
> > On Tue, 2021-02-16 at 20:16 -0800, Michel Alexandre Salim wrote:
> > > On Tue, 2021-02-16 at 15:05 +0100, Vendula Poncova wrote:
> > > > On Tue, Feb 16, 2021 at 3:16 AM Michel Alexandre Salim
> > > >  wrote:
> > > > > Hi Jiří, Vendula, all,
> > > > > 
> > > > > On Tue, 2021-02-09 at 12:12 +0100, Vendula Poncova wrote:
> > > > > > On Tue, Feb 9, 2021 at 10:42 AM  wrote:
> > > > > > > Hi everyone,
> > > > > > > 
> > > > > > > I see a few options for this. First is to add this directly
> > > > > > > to
> > > > > > > blivet
> > > > > > > library as you pointed out already. However, I don't think
> > > > > > > blivet
> > > > > > > developers would be happy about that because they are trying
> > > > > > > to
> > > > > > > be as
> > > > > > > much as possible general purpose library and this change is
> > > > > > > really
> > > > > > > just
> > > > > > > about Anaconda.
> > > > > > > 
> > > > > > > Another option seems to be to modify Anaconda code directly.
> > > > > > > Unfortunately, I can't tell from top of my mind how hard that
> > > > > > > would
> > > > > > > be
> > > > > > > but still seems like the easiest solution.
> > > > > > > 
> > > > > > > However, the best approach which I can think of is to add
> > > > > > > something
> > > > > > > like that to our configuration files. Benefit would be that
> > > > > > > another
> > > > > > > modifications like that could be done easily in the future.
> > > > > > > That is
> > > > > > > of
> > > > > > > course for a discussion for the Anaconda team because it
> > > > > > > could
> > > > > > > be
> > > > > > > pretty hard to implemented this in some common form.
> > > > > > > 
> > > > > > > Vendy, Vojta, do you have some better ideas or could you tell
> > > > > > > us
> > > > > > > something more about my ideas above?
> > > > > > > 
> > > > > > > Best Regards,
> > > > > > > Jirka
> > > > > > > 
> > > > > > > On Tue, 2021-02-09 at 01:18 -0500, Neal Gompa wrote:
> > > > > > > > On Tue, Feb 9, 2021 at 1:09 AM Michel Alexandre Salim
> > > > > > > >  wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > On Mon, 2021-02-08 at 21:02 -0700, Chris Murphy wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > This is in regards to this Fedora 34 change:
> > > > > > > > > > https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#Scope
> > > > > > > > > > 
> > > > > > > > > > The gist is to do 'mount -o compress=zstd:1' anytime
> > > > > > > > > > Btrfs is
> > > > > > > > > > used,
> > > > > > > > > > whether Destination Installation>Automatic or Custom or
> > > > > > > > > > Advanced-Custom. Apply it during the installation, and
> > > > > > > > > > add it
> > > > > > > > > > to
> > > > > > > > > > /etc/fstab.
> > > > > > > > > > 
> > > > > > > > > > Somehow I got confused thinking that autopart supports
> > > > > > > > > > --
> > > > > > > > > > fsoptions,
> > > > > > > > > > and that would be the way to do this. But (a) --
> > > > > > > > > > fsoptions
> > > > > > > > > > isn't
> > > > > > > > > > supported with autopart, and (b) it wouldn't be a
> > > &g

Re: btrfs compression by default

[Martin Kolman]

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

Re: Migrating from pytz to dateutil.tz + zoneinfo

[Martin Kolman]

On Thu, 2021-02-11 at 10:14 +0100, Miro Hrončok wrote:
> Hello fellow serpents.
> 
> I'm one of the Python maintainers in Fedora and RHEL.
> 
> I've noticed anaconda-core uses the third party pytz module to work with TZ 
> (timzone) data. Since Python 3.9, there is a zoneinfo module in the Python 
> standard library:
> 
> https://docs.python.org/3/library/zoneinfo.html
> https://www.python.org/dev/peps/pep-0615/
> 
> Hence we would like to:
> 
> - deprecate pytz in Fedora
> - avoid pytz in RHEL 10+
Sounds like a good idea. :)

We did some of these migrations in the past, IIRC for some IP address handling 
code
for example from a third party library to new stdlib module.

> 
> Since anaconda is one of the "important" dependents on pytz from both Fedora 
> and 
> RHEL, I'm reaching out to you in advance. Could you please consider migrating 
> to 
> zoneinfo?
> 
> I have not done any such migrations yes, so I don't have any useful links or 
> pointers. However, if you'd be interested I can try with anaconda myself.
That would be much appreciated!

> 
> Note that I don't know if anaconda code from the default branch at 
> https://github.com/rhinstaller/anaconda needs to support older Pythons or 
> not. 
> If needed, I can try to make the changes more universal.
Older Python support is only needed in the existing RHEL branches for RHEL 7 & 
8.

In the default branch we don't support older (<3.9) Python versions.

> 
> Let me know if you need some more info, a patch, or just time to handle it 
> yourselves.
A patch will be the best - and I'm standing by to provide support in all 
relevant things
Anaconda so just ping me on IRC or send me an email if you have any questions 
about or codebase,
how to test changes to it, etc. :)

> 
> Thanks,
> (Please CC me in replies to the list, I don't receive the usual list traffic.)
Done. :)

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

Re: btrfs compression by default

[Martin Kolman]

On Tue, 2021-02-09 at 09:50 -0700, Chris Murphy wrote:
> On Tue, Feb 9, 2021 at 9:15 AM Michel Alexandre Salim
>  wrote:
> > There's a further complication: Chris just informed me that on BIOS
> > systems, space is more of a constraint so the zstd module is not part
> > of GRUB ... meaning we have to handle these two scenarios:
> 
> It's available, but it's the 2nd largest GRUB module at ~100KiB. And
> on BIOS we're space limit right now to 1 MiB MBR gap or BIOS Boot
> partition.
> 
> GRUB works fine with a zstd compressed /boot/ but obviously there's
> next to no benefit compared to the added complexity since the kernel
> and initramfs are already compressed.
> 
> So if it's not difficult to exclude compression on /boot/ that's
> probably preferred?
Are we talking about custom partitioning layouts ? 

Because I've just booted a current Rawhide installer and it creates /boot on a 
separate standard partition
formatted with EXT4 by default, with / and /home on BTRFS.


> 
> 

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

Re: anaconda build enviroment setup

[Martin Kolman]

On Wed, 2021-01-20 at 11:09 +0800, yangtao wrote:
> Hi Sir,
Hi Tao! :)
> 
> I'm a new comer for anaconda. I want to setup anaconda build environment.
> Is there any doc describing this part? Thanks you very much!
We have a script that will install build dependencies on a typical Fedora 
system:

sudo ./scripts/testing/install_dependencies.sh

then

./autogen.sh && ./configure

followed by

make

Next you can use the updates image mechanism to inject your changes into an 
installation image to try them out:

https://fedoraproject.org/wiki/Anaconda/Updates

Hope it helps. :)


> 
> Best Regards! 
> Tao
> 
> 
>  
> 
> ___
> 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: Anaconda add-on on RHEL 6

[Martin Kolman]

On Wed, 2020-11-18 at 16:19 +0800, edsionte wrote:
> HI all，
> I have successfully tested my add-on program on CentOS 7.4.
> I found that add-on is not supported on centos 6.x. So, is there any way to 
> add a new page on centos 6.x？
IIRC the Anaconda addon support addin in RHEL 7 was created as a response to 
user/customer request to provide an APIfor
extending in Anaconda, as there was nothing like that in RHEL <=6. 
So I'm afraid this is not possible to extend the installer in RHEL 6, short of 
directly changing the code of the
installer itself to display the options you need.
There might be a possibility if you wanted to show the screen on the first boot 
of the system - in RHEL 6 there is
the Firstboot tool, that is run on first boot of the installed system (provided 
it's package is installed) and that can
hostarbitrary plugins addin new screens (IIRC on RHEL6 it has the RHSM and 
KDUMP screens, provided by Firstboot
plugins).
More about Firstboot & Firstboot plugins here: 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.3_technical_notes/firstboothttps://fedoraproject.org/wiki/FirstBoothttps://fedoraproject.org/wiki/FirstBoot/Modules
Firstboot is technically also available in RHEL/CentOS 7, but marked as 
deprecated. Firstboot is not longer availablein
RHEL 8, being replaced by Initial Setup in the first-boot configuration role. 
Initial Setup was introduced in
RHEL/CentOS 7.
> 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: F33: preview swap-on-ZRAM using zram-generator feature change

[Martin Kolman]

- Original Message -
> From: "Chris Murphy" 
> To: "Discussion of Development and Customization of the Red Hat Linux 
> Installer" 
> Sent: Sunday, May 31, 2020 2:45:37 AM
> Subject: F33: preview swap-on-ZRAM using zram-generator feature change
> 
> Hi,
> 
> I'm following-up now that there's a preview of the change proposal ready:
> https://fedoraproject.org/wiki/Changes/SwapOnZRAM
> 
> Highlights:
> 
> - This is a system-wide change, for all editions and spins. And if
> Anaconda folks are still agreeable, it would be included on all
> install media where Anaconda is found: DVD/Live/netinstall.
> 
> - Fedora Workstation edition will no longer create swap-on-disk by
> default. Instead swap-on-zram will be used. I expect to get buy-in
> from other editions/spins to do the same. This applies only to the
> default/automatic partitioning path, as previously discussed.
> 
> - Tentative (proposed) defaults similar to what's used by IoT: ZRAM
> device is 50% RAM, with a 4GiB cap.
> 
> The max size, which is configurable, is to help scale ZRAM device size
> for more uses cases and hopefully settle on a single default Fedora
> wide. This is a bit different than Anaconda's implementation, which
> doesn't activate above 2GiB, and uses a 1:1 ZRAM to RAM ratio. Based
> on my testing, even VM's with 3GiB RAM still prefer to use quite a
> decent amount of swap ~200MiB. If it's available. I think this
> adjustment is neutral to slightly better for Anaconda. And in any case
> the installer and installed environments will have the same
> configuration and implementation as a result of the change.
Back when ZRAM support was introduced in the installation environment the
aim was to enable installations and specially the more memory hungry graphical
installations on devices and VMs with less RAM. For devices with enough RAM
the installation could run just fine & ZRAM would be just extra overhead, so
we decided not to enable it here.

This was quite some time ago (6/7 years ago) and things certainly changed,
making the ZRAM overhead very likely totally negligible on current systems.

So I think dropping the conditions we have at the moment and simply always 
enabling ZRAM
with sensible configuration (like the IoT one mentioned above) should be fine.

> 
> - Disable or somehow deprecate the Anaconda specific implementation,
> to avoid conflict and user confusion among the implementations.
IIRC we discussed using one of the scripts packaged in Fedora 
(I think it was provided by systemd ?), ideally the one used by the other
tools that are part of this system wide change. We just have not did that
just yet.

So I wonder if the image wide defaults change I guess it should be enough
if we coordinate dropping of our zram setup script at the same time the image 
wide change is done ?


> 
> - Test day will be planned
> 
> Critical feedback welcome.
> 
> --
> Chris Murphy
> 
> ___
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
> 

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

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

[Martin Kolman]

- Original Message -
> From: "Neal Gompa" 
> To: "Josh Boyer" 
> Cc: "For testing and quality assurance of Fedora releases" 
> , "kernel"
> , "Discussion of Development and 
> Customization of the Red Hat Linux Installer"
> 
> Sent: Tuesday, August 27, 2019 2:09:41 PM
> Subject: Re: Discussion: what would not blocking on btrfs look like?
> 
> On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer  wrote:
> >
> > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa  wrote:
> > >
> > > On Tue, Aug 27, 2019 at 5:55 AM  wrote:
> > > >
> > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> > > > > On Mon, Aug 26, 2019 at 7:16 AM  wrote:
> > > > > >
> > > > > > 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.
> > > >
> > >
> > > By definition, RHEL *is* the past from a Fedora context. It's forked
> > > from an old version of Fedora that's not supported anymore. It is the
> > > result of decisions that aren't supposed to apply to Fedora. And it is
> > > the result of a different bias that should never apply to Fedora if
> > > the RH ecosystem is supposed to be able to evolve.
> >
> > There is always the *next* RHEL.  Or, if you want to remove a product
> > context, the next enterprise operating system derived from Fedora.
> > RHEL/enterprise is both past and future and Fedora focuses on the
> > future.  You cannot dismiss enterprise as a target by waiving it away
> > as "past".
> >
> 
> Until there's a branch in Anaconda's git for the next version of RHEL,
> it doesn't exist yet. I'm sure people are *thinking* about it, but
> it's obviously on the back burner for a little while. I would expect
> to start to see a rhel-9 branch in Anaconda in 1.5 years, but for now
> it doesn't exist.
> 
> > > From the way you describe it, Fedora is just something occasionally
> > > give lip service to while your main focus is RHEL. That's fine, but
> > > that is a problem for the Fedora context.
> >
> > Neal, I don't understand.  The source code to anaconda is available.
> > What is preventing you from taking it and making a micro-fork that
> > does better btrfs enablement, and packaging that in Fedora and using
> > it in a spin?
> >
> 
> I have seriously contemplated it. It isn't the first time I've done a
> fork because I had to[1].
> 
> But the main reason I don't do it is because it will cause more damage
> in the Fedora community by doing so. Two sets of packages for Anaconda
> that all the things that depend on Anaconda could cause a huge level
> of breakage because the two versions must *always* be drop-in
> replacements for each other. If they're not, it makes it impossible to
> leverage the Fedora tooling to do things like making spins and such. I
> don't even *know* what kind of work it would entail if I wanted it to
> be an official spin composed through pungi. I'm pretty sure the releng
> folks would kill me for doing that, as now pungi would have be aware
> and switch anaconda packages for lorax...
> 
> Additionally, it would require a fork of pykickstart so that further
> enhancements to the Btrfs partitioning can be defined. However, *that*
> causes bigger problems because now there's incompatible grammar. Given
> how poorly the 

Re: "enabling zram.service on LiveOS boots"

[Martin Kolman]

On Wed, 2019-06-19 at 13:21 -0600, Chris Murphy wrote:
> On Wed, Jun 19, 2019 at 10:33 AM Brian C. Lane  wrote:
> > On Wed, Jun 19, 2019 at 01:24:27PM +0200, jkone...@redhat.com wrote:
> > > 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...
> > 
> > Correct. The place to enable it would be in the livesys script that the
> > %post section writes. But I'm not sure if that's too late in the boot
> > process for it to be useful. As long as it is just started, not enabled,
> > from the script it should only run when booting the live iso and not the
> > installed system.
> 
> Or can Anaconda just 'systemctl start zram.service' when it's
> launched, whether on Live or netinstall?
> 
> The problems I'm seeing only in low memory situations, doesn't arise
> until Anaconda launches. So it's fine if 'systemctl start
> zram.service' happens late.
That's actually a good point & certainly the easiest thing to do. 

Because if we start zram really early at boot time, before the desktop 
environment starts
and then make sure to disable it on the installed system, I can imagine the 
installed
system failing to boot if it needed zram to even survive the DE launching.

On the other hand if the DE managed to start without zram, it should be able to 
start 
without it even after installation.

> 
> Looks like the change would go in
> https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-base.ks
> 
> It contains this section:
>110# enable swaps unless requested otherwise
>111swaps=\`blkid -t TYPE=swap -o device\`
>112if ! strstr "\`cat /proc/cmdline\`" noswap && [ -n "\$swaps" ] ; 
> then
>113  for s in \$swaps ; do
>114action "Enabling swap partition \$s" swapon \$s
>115  done
>116fi
>117if ! strstr "\`cat /proc/cmdline\`" noswap && [ -f
> /run/initramfs/live/\${livedir}/swap.img ] ; then
>118  action "Enabling swap file" swapon
> /run/initramfs/live/\${livedir}/swap.img
>119fi
> 
> Umm, anyone got any opinions on removing that whole thing?
> 
> a) I don't really see the point of using some legacy swap partition
> that the installer has some chance of needing to turn off in order to
> modify partitioning or what have you?
> 
> b) Silently activating a persistent swap is a security leak for LiveOS
> users, unless testing for encryption or setting up /dev/urandom key
> based encryption for it.
Sounds like sound arguments to me & details can be worked out once a PR is 
opened
for fedora-kickstarts.

> 
> Also, there is a package, zram-0.3-1.fc30.noarch, which is more
> recently developed and intended to be generic use. Any chance of
> deprecating the anaconda zram stuff and depending on this zram package
> instead?
> https://src.fedoraproject.org/rpms/zram/tree/master
I recommend opening a RFE bug in bugzilla so we can track this. When we added 
zram support
to Anaconda, non of this extra tooling existed yet and it could well be that 
what we are using
has a modern well maintained generic alternative.

> 
> Last, it looks like the systemd folks want to turn all of this into
> native systemd units, and get rid of the livesys script entirely.
> 
Anything that reduces the insanity of the live image creation kickstarts is a 
good thing. :)

___
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

[Martin Kolman]

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.
Looks like it comes from the fedora-repos package:
$ rpm -qf /etc/yum.repos.d/fedora-cisco-openh264.repo fedora-repos-30-1.noarch
I think that's the repo file for the Open H264 change:
https://fedoraproject.org/wiki/OpenH264 id="-x-evo-selection-start-marker">
> 
> 
> 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: Find out aim of your Anaconda changes

[Martin Kolman]

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.
In cases like this nothing beats meeting face to face - sounds good! :)

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

Re: Customizing Anaconda

[Martin Kolman]

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.
Do you mean setting the gecos field for the user ?[0]
Currently this is not supported in the graphicala and text user interface, but 
can be donevia kickstart (which is
basically a config file that can be used to configure an installation)[1].A 
kickstart file can be loaded either from
network or from local media during the installation.
If what you need is really setting the gecos field manually in the user 
interface during the installation,it looks like
we could add it to the "Advanced" dialog on the user configuration screen.
> Is there any guide or examples on such additional changes for anaconda?
> 
> 
> Regards,
> -- 
> Danishka Navin
Best WishesMartin Kolman
[0] https://en.wikipedia.org/wiki/Gecos_field[1] 
https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#user

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

[Martin Kolman]

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?
This should be already possible if you use the network installation image,
you can tell Anaconda to use the updates repo and it will install newest 
versions
of all the packages during installation.

On the Live image this is not really doable/easy as we are basically just 
copying a
pre-made OS image to the target system with rsync. To update it it would be 
necessary
to basically chroot to the target system and run a system update (as you would 
generally do
yourself after the installation).

This has the downside that we would also have to make sure network connectivity 
is available
(which is not required for plain Live installation) and it would actually not 
save any time
(it would still be live install + system update) other than running the update 
automatically
by Anaconda instead of by the user after installation.

I'm thinking something like a service that would start on first boot and ask 
the user if
a system update should be done would be a better fit.



> many thanks for reading! :)
> Majid Hussain

Best Wishes
Martin Kolman

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

Re: Anaconda and hiding the grub-menu be default on Workstation installs

[Martin Kolman]

On Fri, 2018-06-01 at 11:05 +0200, Hans de Goede wrote:


> My next question is if anaconda knows about products
> (e.g. Fedora Workstation vs Fedora server), I believe
> it does, right ?

Yep & we use install class mechanism[0] to handle the variant specific 
differences,
such as Server using XFS by default vs Workstation using EXT4.

So this feature could be added as a new install class property,
which is only enabled for the Workstation install class.

[0] 
https://github.com/rhinstaller/anaconda/tree/master/pyanaconda/installclasses

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

Re: Adopting CoreOS Ignition into Fedora+derivatives ecosystem

[Martin Kolman]

On Tue, 2018-04-17 at 09:38 -0400, Colin Walters wrote:
> We're working on merging some of the CoreOS  
> technologies with
> the Fedora/Atomic technologies.  One thing that came up is they have
> a new take on system bootstrap called Ignition:
> https://github.com/coreos/ignition
> 
> We're investigating making this work in Fedora as well:
> https://pagure.io/atomic-wg/issue/450
> 
> There's a fair amount of overlap with the role of Anaconda in
> terms of system provisioning.  Some of this is actually similar
> to the overlap between kickstart + cloud-init I posted previously:
> 
> https://www.redhat.com/archives/anaconda-devel-list/2014-December/msg8.html
> 
> We're currently thinking Ignition should take over from cloud-init (though 
> the details
> there are still TBD).  Its ability to do partitioning makes it a lot
> closer to kickstart[1].
Yeah, Ignittion also seems to me like more like an enhanced Cloudinit with some
installer bits bolted on & it indeed seems like it could work like a good 
cloudinit replacement.

> 
> One thing I'd floated in some of our discussions was that conceptually
> one could write a kickstart-to-ignition transpiler just like the
> "clc-to-ignition" transpiler:
> https://coreos.com/os/docs/latest/overview-of-ct.html
> I'm not sure if this would be valuable versus writing ct since most
> people are going to be starting "fresh" I suspect, but the fact
> that we could helps understand the concepts here I think.
> 
> Probably where the biggest overlap is around baremetal provisioning;
> CoreOS supports a "PXE-to-Live" model for servers:
> https://coreos.com/os/docs/latest/booting-with-ipxe.html
> as well as a script to install to disk persistently:
> https://coreos.com/os/docs/latest/installing-to-disk.html
> 
> The latter path is like the existing Anaconda+kickstart
> path; so where things intersect most strongly here is what we do
> with those two paths.  I'd suggest that for PXE-to-Live which we
> don't currently productize that we focus on Ignition.

Yeah, PXE-to-Live is pretty different to how Anaconda does,
we generally differentiate the installation environment and
the target system quite clearly and in this case they are basically
combined together. So if Ignition can do it it makes sense to
me to continu using it for this usecase, at least for the time being.

>   
> 
> For persistent installations - I think we'd clearly need to support
> kickstarts, but it's probably useful to look at a path where
> Anaconda includes support for Ignition; perhaps it something like
> a %ignition config stanza in kickstart?
I think that would work - would Anaconda be expected to parse the content
of the section or would just writing the content to a file on the target system
where Ignition will pick it up be enough ?
We could also make sure the ignition package is installed on the target system
when when the %ignition section shows up in kickstart (we already do that for 
various
kickstart commands such as realm, firewall, etc.).

Also alternatively if you wanted some more advanced configuration done during 
the
installation or wanted to provide a configuration GUI/TUI, Anaconda can be 
extended via
addons: 
https://rhinstaller.github.io/anaconda-addon-development-guide/

Addons can have their own kickstart section and can (but don't have to) provide
TUI & GUI screens.

> 
> [1] They even support partitioning the root filesystem
> but I think that only works for the existing CoreOS with the dual-partition
> /usr A/B approach; what I call "classic" Fedora with yum as well as
> the existing Atomic with rpm-ostree both have the operating system
> content in /, not in separate partitions.
This might be a bit unrelated to current topic, but what are the plans with 
supporting the CoreOS A/B approach ?

The git-like aproach rpm-ostree provides seems to me as a much more advanced & 
flexible than just using the
relatively primitive and not very flexibile "you have two and exactly two 
copies of everything" approach.

It seems to me that compared to A/B ostree makes it possibly to have an 
arbitrary number of system states
available and should also be more space efficient (unless CoreOS deduplicates 
the A/B copies somehow).

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

[Martin Kolman]

- Original Message -
> From: jkone...@redhat.com
> To: "Discussion of Development and Customization of the Red Hat Linux 
> Installer" 
> Sent: Tuesday, April 3, 2018 12:52:09 PM
> Subject: Re: Overriding Addons in Anaconda
> 
> 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.
Exactly - we want addons to be self contained and not do depend and interfere 
with each other.

Actually disabling specific addon seems seem to be in the scope of image 
generation/customization,
can't you simple exclude the kdump addon package when you generate your image ?
(eq. if you can add an custom addon you are likely generating your own image 
and can thus exclude existing addons as well)

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

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

Re: Fedora change: reduce initial setup redundancy

[Martin Kolman]

- Original Message -
> From: mcatanz...@gnome.org
> To: anaconda-devel-list@redhat.com
> Cc: sticks...@gmail.com
> Sent: Tuesday, July 4, 2017 4:58:52 AM
> Subject: Fedora change: reduce initial setup redundancy
> 
> Hi Anaconda devs,
> 
> Tomorrow is the system-wide change proposal deadline for F27. I've
> prepared a draft change page for reducing initial setup redundancy in
> Fedora Workstation. We discussed this a few years ago, and you all
> implemented your side of the story already (the user interaction config
> file), but us Workstation folks dropped the ball and left it unused.
> Anyway, the proposal:
> 
> https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
> 
> Ideally I would have prepared this earlier and run it by you *before*
> submitting it... so sorry for the very short notice and for delaying
> way too long. 
Well, it certainly good to see things finally moving also outside of the 
Anaconda proper. :)

>The Workstation WG has approved the general idea of
> reducing redundancy between gnome-initial-setup and Anaconda, but has
> not reviewed this proposal yet either, because I just typed it up an
> hour ago, so at this point it's just me brainstorming. Everything is
> subject to change and approval and your feedback and nothing is set in
> stone.
> 
> We are (OK, I am) basically planning to hide a bunch of Anaconda spokes
> (timezone?, networking, user account creation, root password) using the
> user interaction config file. And then hide some gnome-initial-setup
> panels (language, keyboard layout, timezone?) using a new g-i-s
> configuration file.
Can you clarify this point ? Wouldn't it just be enough for g-i-s to parse the 
user interaction config files and hide it's own corresponding screens 
accordingly ?
I can see the screen mapping might not be 100% the same as in Anaconda/Initial 
Setup,
but I'm not sure yet another configuration file is the answer.
Or am I just missuderstanding things ? :)

> Of course, only when running in Workstation: this
> would not affect other Fedora products that don't have
> gnome-initial-setup. (And the networking panel would be needed for
> netinstall anyway. This proposal is mainly focused on live installs.)
> 
> Technically, we *could* do this without any further changes in
> Anaconda, but it turns out that the installation progress screen looks
> pretty odd with both the account creation and root password spokes
> removed. So some design changes for this page when no spokes are
> present would certainly be desirable.
Yeah - that sounds doable. IIRC there have even been some inquiries from the 
fedora design team
if the banner could be made bigger (as even with the two spokes there is quite 
some unused space)
so I guess this could be done in the same scope.

> 
> So we'd appreciate your feedback on this proposal. Sorry again for the
> late notice. We can edit or delay it at any time, of course.
And sorry for the late answer - I was away for 3 weeks and only got back this 
week. :)
> 
> Thanks,
> 
> Michael
Best Wishes

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

Kickstart documentation has been moved

[Martin Kolman]

Hi,
the upstream kickstart documentation has been moved to Read the Docs:

http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html

The documentation is now automatically generated from the pykickstart source 
code,
includes additional information such as when the given command or option was 
introduced,
should cover more commands and also contains a separate listing of commands for 
Fedora and RHEL.

Thanks a lot Aleksandar Todorov, Chris Lumens and others who made this possible!

Best Wishes
Martin Kolman

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

User config specification implemented

[Martin Kolman]

Hi,
the user config specification has been implemented by Anaconda and is
ready to use by pre & post installation setup tools!
Both current Rawhide and Fedora 25 Anacondas have this functionality
and it is enabled.

I would also like to note that at the moment only the spoke visit
tracking is implemented by Anaconda, not yet the optional option-
changed tracking. 

This is partially deliberate as there is a substantial amount of
options on the screens of the Anaconda GUI, and we would like to first
start tracking the options post installation setup tools are actually
going to use. 

So if you your post installation setup tool needs better granularity
than just the Anaconda screen visit tracking then let us know what
options would you like us to start tracking in the interaction config
files for changes made by the user.

The screen hiding mechanism has also been implemented, so Anaconda will
not show screens that have been marked as visited in an existing user
interaction config file. This can be used by pre-installation setup
tools, like for example a hypothetical language selection widget, which
could use this mechanism to notify Anaconda to skip it's own language
selection screen. Another use case is to hide screens not considered
necessary for a given distro variant.

Best Wishes
Martin Kolman


[0] https://github.com/rhinstaller/anaconda/blob/master/docs/user-inter
action-config-file-spec.rst

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

Re: Anaconda snapshot KS command

[Martin Kolman]

On Thu, 2016-06-23 at 08:56 -0700, Brian C. Lane wrote:
> On Thu, Jun 23, 2016 at 05:36:38PM +0200, Jiří Konečný wrote:
> > 
> > Hello guys,
> > 
> > I'm doing this bug https://bugzilla.redhat.com/show_bug.cgi?id=1113
> > 207 
> > and because of it I need to create new KS command for snapshot
> > creation. Because kickstart is something with really stable API, I
> > want
> > to ask everyone before I'll implement something badly.
> > 
> > Possible solutions:
> > 
> > 
> > Adding --snapshot parameter to existing KS command
> > --
> >  * It should be easier to implement.
> >  * Could be easier to find in documentation.
> >  * It's logically part of that storage type.
> >  * logvol command have big number of parameters now.
> > 
> > Adding standalone snapshot command
> > --
> >  * Harder to implement but it's more general.
> >  * Easier to extend.
> >  * Easier to just add support for btrfs with additional required
> > parameters and anything else in future and syntax will not change
> > so
> > much.
> > 
> > Personally I see the snapshot command as better choice but want to
> > hear
> > your idea.
> I like the standalone snapshot command. The user doesn't need to know
> what's underneath it and could possibly do:
> 
> autopart --type=thinp
> snapshot --name=initial_install
Yeah - and also by having a separate command, we also get a namespace
"for free", unlike if the snapshot functionality was piggybacking on an
existing command, where all commands would need to be accordingly
prefixed (--snapshot-foo, --snapshot--bar, etc.).

> 
> And then switching to btrfs would be as simple as using a different
> autopart type.
> 
> If used with non-autopart it will also need to sanity check their
> storage setup to make sure they are using something that supports
> snapshots.
> 
> I also agree with your comment in the bug, minimize changes to
> Anaconda
> and keep using /.
> 

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

Re: anaconda-patches mailing list

[Martin Kolman]

On Tue, 2016-05-24 at 13:57 -0500, Jason L Tibbitts III wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > "BW" == Bruno Wolff  writes:
> BW> I didn't expect anaconda to benefit that much from github's
> network
> BW> effects. But given that it is, that would make Pagure hard to
> BW> consider soon. The hosting service (as opposed to code) requires
> FAS
> BW> accounts which would be a barrier to entry for the many people
> that
> BW> have github accounts but not FAS accounts.
> 
> There has been talk of changing this.  I know it was being worked on
> (by
> puiterwijk) but I don't know the status.  Allowing multiple auth
> providers brings up a few issues (you have to namespace users) but I
> think there was a plan for dealing with that.
> 
> Anyway, if there's something that you need and pagure doesn't offer,
> I
> would suggest you make the pagure developers aware of that.
While this is a bit off-topic, but still related to Pagure:

I've heard there have been plans to use Pagure to host the Fedora dist
git repos, with the aim of enabling pull requests for packages.

IIRC the idea was to make packaging improvements and fixes easier.
You would not need to pester individual maintainers via email/IRC
anymore - just fire away a pull requests like with normal pull-request
workflow.
It could also possibly help ameliorate the "someone-touched-my-package" 
friction that sometimes shows up when proven packages modify other
peoples packages.

As I find this to be a very interesting idea I just wanted to ask how
this is coming along when there are Pagure People in the thread. :)
> 
> BW> (And I wouldn't expect Github to ever help out by becoming an
> BW> identity provider that Pagure could rely on in addition to FAS.)
> 
> Github supports oauth2; that should be enough, I think.
> 
>  - J<
> 
> ___
> 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: anaconda-patches mailing list

[Martin Kolman]

- Original Message -
> From: "Samantha N. Bueno" 
> To: anaconda-devel-list@redhat.com
> Sent: Monday, May 23, 2016 4:08:50 PM
> Subject: anaconda-patches mailing list
> 
> I'd like to see what are everyone's thoughts on decommissioning
> anaconda-patches list. Now that we've moved to GitHub, it's pretty much
> obsolete, and I think decommissioning it could be beneficial:
> 
> (a) (Way) less email overall.
> 
> (b) The GitHub email script that we have was originally created with the
> intent of preserving the posted patches + discussions forever in
> history, but the patches are not actually included in any emails.
That's weird - I can see the patch content of pull requests & it seems to also 
be in the archive.
for example:
https://lists.fedorahosted.org/archives/list/anaconda-patc...@lists.fedorahosted.org/thread/OTN2IRPIVTTGF24G7WCSWC7O2WP3L2V7/
 
> Additionally, unless someone makes an in-line comment in the patch,
> there usually is no context provided in responses. So, the emails don't
> contain a lot of value.
Yeah, it really is kinda on-directional anyway due to the need to reply on 
GitHub.
> 
> (c) It's a good way to force all the stragglers (e.g. myself) to migrate
> their workflow to GitHub and have everyone working the same way.
> 
> (d) As a benefit of (c), less confusion for new contributors, concerning
> how to post a patch, etc.
Certainly! Only possible issue from the community/contributor perspective could 
be
that there are some people who don't use or don't want to use GitHub, for 
various reasons.
On the other hand I don't think we really got any such contributions recently &
we could use the devel list for that if needed.

> 
> I know we can disassociate the webhook email forwarder from GitHub
> pretty easily. Concerning the list itself though, if there's a way to
> effectively "close it for business" but leave its contents forever
> available for perusal, I think that might be ideal.
It is running on the Fedora infrastructure, so I guess the contacting the
Infra people might be a way to go:
https://fedoraproject.org/wiki/Infrastructure

> 
> Anyway, thoughts?
Yeah, why not. :) Just some remarks above.
> 
> Samantha
> 
> ___
> 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: Potential deprecation in RHEL 7.3 ADDON API

[Martin Kolman]

- Original Message -
> From: "Chris Lumens" 
> To: anaconda-devel-list@redhat.com
> Sent: Wednesday, March 30, 2016 2:36:12 PM
> Subject: Re: Potential deprecation in RHEL 7.3 ADDON API
> 
> > This PR will cause that all existing addons to get deprecation warning
> > message. This includes our OSCAP and KDUMP addons.
> > 
> > The change is really small. You only need to change two lines of code.
> > I'm going to create PR for our addons when this PR receive ACK.
> > 
> > This change happens on master and it will be also in RHEL 7.3 .
> > I want to give you notification about this change before it happens by
> > this mail. If I missed something or you don't want this change please
> > write comments to PR or reply to this mail.
> 
> You can avoid having to deal with deprecation warnings and all that if
> you instead define execute to also take *args and **kwargs, and then
> pass payload to it as a kwarg everywhere.  Addons that don't do that
> just won't have access to the payload, but that's their problem.
I think that the problem is that they might have overridden the method in their 
addon,
so that when we call it with an unknown kwarg they will get an exception.

They might have something like this in their addon code:

def execute(self, storage, ksdata, instclass, users):

Even if we change the parent class method signature to:

def execute(*args, **kwargs):

The overridden method will still be called when we call execute with 
payload=
and they will get:

TypeError: execute() got an unexpected keyword argument 'payload'


I can see two more or less hacky ways of working around this without breaking 
backward compatibility for
addons (which I assume should be maintained on RHEL, mainly due to custom 
addons customers might have):

1) Catch the type error and retry without the payload kwarg:

try:
ad.execute(foo, bar, baz, payload="ABC")
except TypeError:
ad.execute(foo, bar, baz)

2) Use the inspect module to check if the method expects the payload kwarg (or 
**kwargs)
and only call it with it if it does. Note that this is ultra-bleh-hacky and 
probably
also pretty un-Pythonic.

> 
> - Chris
> 
> ___
> 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: anaconda design mockups

[Martin Kolman]

On Thu, 2016-02-25 at 12:22 -0500, David Lehman wrote:
> On Thu, 2016-02-25 at 18:14 +0100, Garrett LeSage wrote:
> > 
> > On 25/02/16 16:06, David Lehman wrote:
> > > 
> > > Right. Just about any time you make an assumption to
> > > significantly
> > > simplify storage you're going to be wrong. Sad but true.
> > Yeah, it's not possible to cover every case all the time and do so
> > in
> > an 
> > easily understandable manner for most things... but especially
> > something 
> > as complicated as storage.
> > 
> > 
> > With regard to Workstation partitioning, however, I'm confident
> > that
> > we 
> > can make life nicer for at least 80% - 90% of the people using
> > Anaconda. 
> > That's one of the goals of this effort, at least.
> I can appreciate that, provided it retains some basic flexibility.
> 
> > 
> > 
> > For the other 10 - 20% of people installing Workstation who really
> > do 
> > want to specify everything, they will still have a
> > similar/familiar 
> > advanced interface to do so. The difference is that we won't drive 
> > everyone into the advanced partitioner (and force them to even 
> > understand partitioning or complicate storage things they *could* 
> > possibly do).
> People seem to resist this, but it would be really great IMO if we
> could stop calling it "partitioning" and start calling it "storage
> configuration" since partitioning is only a fraction of what goes on.
> 
> > 
> > 
> > 
> > There are three main cases for Workstation installs:
> > 1. Empty disk(s). It's obvious what to do here... Have a
> > predefined 
> > recommended partition layout and use that. Advanced partitioning
> > spoke 
> > can, of course, still be selected from the Hub screen for fine-
> > tuning 
> > or 
> > completely different layouts.
> > 2. Disk(s) with data, with more than enough room for Fedora. Same
> > as
> > #1, 
> > except existing data will not be wiped out.
> We did that in F18 or F19 and several users (including me) didn't
> like
> that you don't even have the option of making more space in this
> case.
Also I wonder how frequent this case would actually be - how would you
actually get a disk that is partially used, but has significant
unallocated space ?

Completely empty disk I can imagine (fresh from the factory) as well as
completely allocated one (pre-installed Windows, some Linux distro
install, etc.) but how would a normal user get a disk that is not
either empty or fully allocated to something ?

I can only think of people creating such a layout themselves to use/try
multiple Linux distros or other operating systems. I'm not sure if
there would be very many of those & if they would need a simplified
partitioning screen given their apparent ability to create custom
storage layouts.

> 
> Also, thanks for working on this.
> 
> David
> 
> 
> > 
> > 3. Disk(s) with data, but not enough room. This is where the
> > simple 
> > partitioning screen shows up. There's a path through the advanced 
> > paritioning tool as an action on this screen (and you can also get
> > back 
> > from the Hub screen).
> > 
> > So: 1 & 2 (enough space due to empty disk or pre-partitioned disk)
> > will 
> > be pre-configured by default. 3 will show the resize screen (which
> > has 
> > options to go to the advanced installer or erase and use the
> > entire 
> > disk, in addition to resizing).
> > 
> > It does get a little more complicated when there are multiple (non-
> > USB / 
> > non-SDcard) storage devices on the system; I have some ideas and
> > will 
> > work on mockups to handle that soon.
> > 
> > 
> > Partitioning on a Server install is a different beast, of course.
> > We're 
> > not there yet; the first step is mainly simplifying Workstation.
> > I'm
> > not 
> > sure how much simplification (if any) can happen on a Server
> > install.
> > 
> > 
> > Cheers,
> > Garrett
> > 
> > ___
> > 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

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

Re: anaconda design mockups

[Martin Kolman]

On Fri, 2016-02-26 at 11:26 -0500, Matthew Miller wrote:
> On Fri, Feb 26, 2016 at 01:56:59PM +0100, Martin Kolman wrote:
> > 
> > So do we really need to think about about redesigning the server
> > GUI ?
> > We could just use what we have on Server and only do a
> > simplified/streamlined GUI variant for the Workstation.
> There is some interest in hubs supporting Role configuration, I
> believe. But that doesn't require a redesign.
> 
> > 
> > From feedback I've seen, the big concern is storage configuration.
> > A
> lot of Server users are interested, for better or worse, in the
> old-school approach of building up storage to a final configuration
> from bottom-up building blocks, rather than the end-goal-work-back UI
> Anaconda provides.
> 
> I'm sympathetic to the argument that it's pretty crazy to have
> parallel
> GUIs for both of these approaches. And beyond that, making a GUI for
> the build-up approach where all possibilities actually _work_ is a
> combinatorial nightmare. 
Well, Vojta is doing just that and it seems to be working fine:
https://fedoramagazine.org/manage-your-partitions-like-in-anaconda-with
-blivet-gui/
http://blog.vojtechtrefny.cz/blivet-gui
http://blog.vojtechtrefny.cz/new-blivet-gui-fedora-22

I't (of course) Blivet based & written in Python and could quite easily
be run a an Anaconda spoke - we already did some preliminary
experiments with this.

So maybe Blivet-GUI-spoke could be the perfect default partitioning UI
for the Fedora Server variant ? :)


> But, I wonder if we could make the possibility
> of pre-configuring storage a) more discoverable and b) easier in any
> way?
> 
> See
> http://unix.stackexchange.com/questions/263721/manual-setup-install-m
> ethod-for-fedora
> for just one example.
> 

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

Re: anaconda design mockups

[Martin Kolman]

On Thu, 2016-02-25 at 13:57 -0500, David Cantrell wrote:
> On Thu, Feb 25, 2016 at 01:28:42PM -0500, Matthew Miller wrote:
> > 
> > On Thu, Feb 25, 2016 at 01:13:40PM -0500, David Shea wrote:
> > > 
> > > On 02/25/2016 11:46 AM, Garrett LeSage wrote:
> > > > 
> > > > Is this a *real* requirement in 2016?
> > > Yes. ppc64le uses a VNC interface with a 800x600 display. Even
> > That might go towards different default for Server and Workstation,
> > though, right? Or are people running PPC-LE as desktops?
> There's no ppc64le desktop userbase that I know of, but the concern
> is worth
> discussion.  We're talking about customizing the UX of each variant
> of
> Fedora, but how far do we take that?
Did we get any feedback from the Server working group about the need to
customize/change the current GUI ? As far as I can tell they seem to be
OK with the current design - of course they might not be using it that
much, possibly preferring kickstart installs/TUI. But even in that case
no new server custom GUI is needed.

So do we really need to think about about redesigning the server GUI ?
We could just use what we have on Server and only do a
simplified/streamlined GUI variant for the Workstation.

That should be overal easier.


>   If we make them diverge too far, we
> can't necessarily reuse the interface components in different ways
> among the
> variants.  Not saying that's the case here, just a generalization
> about why
> it is useful to keep the other use cases in mind.
> 
> > 
> > > 
> > > ignoring that case, the X1 carbon has 2560x1440 pixel screen
> > > which,
> > > when scaled to adjust for the high dpi, has an effective
> > > resolution
> > > of 1280x720. This caused trouble on screens that expected 768
> > > vertical pixels.
> > :( That's probably a common enough case for other laptops, too.
> Likely.  And I've been wondering if ARM laptops will take off anymore
> than
> they already are.  If so, that could likely mean smaller
> everything...including screens.
> 

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