Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Matthew Miller]

We've got a 300+ message thread in just one week, with 66 different
participants. This handily beats discussions systemd-resolved,
btrfs-by-default, and even switching the default editor to nano.

Clearly there's a lot to talk about here. Would it be useful to have a
high-bandwidth, moderated conversation via video call about the best path
forward?

(Because of the number of likely participants, Jitsi probably won't cut it,
so this would likely be via Bluejeans.)

It'll obviously be difficult to find a time where _everyone_ can
participate, so this wouldn't be a deciding-things meeting, rather a
"talking about possibilities and hopefully coming to more mutual
understanding" meeting. And I would make sure there are good notes.*


(* volunteers who are good at note taking welcome!)

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[David Cantrell]

On Tue, Apr 12, 2022 at 07:20:52PM -0400, Matthew Miller wrote:
>  We've got a 300+ message thread in just one week, with 66
> different
>  participants. This handily beats discussions systemd-resolved,
>  btrfs-by-default, and even switching the default editor to nano.
>  
>  Clearly there's a lot to talk about here. Would it be useful to have a
>  high-bandwidth, moderated conversation via video call about the best path
>  forward?
>  
>  (Because of the number of likely participants, Jitsi probably won't cut it,
>  so this would likely be via Bluejeans.)
>  
>  It'll obviously be difficult to find a time where _everyone_ can
>  participate, so this wouldn't be a deciding-things meeting, rather a
>  "talking about possibilities and hopefully coming to more mutual
>  understanding" meeting. And I would make sure there are good notes.*
>  
>  
>  (* volunteers who are good at note taking welcome!) 
Here are some thread stats I took just now:


Overall statistics
------------------
Total number of messages: 310
Number of messages that is a reply: 306 (98.71%)
Total size: 4191268
Average size: 13520
Total number of writers: 78
Number of people who wrote >1 message: 37 (47.44%)

Top writers
   | # msgs|av size| total|time | e-mail address
---+-------+-------+------+-----+--------------------------------
  1]     40|  14224|568978|13:24| neal gompa <ngompa13(a)gmail.com&gt;
  2]     33|  11715|386622|13:30| devel(a)lists.fedoraproject.org
  3]     31|  13173|408389|13:19| robbie harwood <rharwood(a)redhat.com&gt;
  4]     29|  13091|379662|14:56| chris murphy <lists(a)colorremedies.com&gt;
  5]     15|  21574|323617|14:26| jared dominguez <jaredz(a)redhat.com&gt;
  6]     13|  11834|153851|13:37| dominik 'rathann' mierzejewski
<dominik(a)greysector.net&gt;
  7]     11|  19316|212484|17:23| demi marie obenour <demiobenour(a)gmail.com&gt;
  8]      8|  10816| 86533|12:56| chris adams <linux(a)cmadams.net&gt;
  9]      8|  16190|129527|11:26| "thomas schmitt" <scdbackup(a)gmx.net&gt;
 10]      8|  11985| 95880|07:52| gary buhrmaster <gary.buhrmaster(a)gmail.com&gt;


While the thread is busy, here are the top participants (with #2 excepted).

The core issue still comes down to having resources to continue maintaining
BIOS boot support in Fedora and so far no one has come forward to work on
that.  If a video call can come up with a community plan to do that, I would
say it might be worth it.  Otherwise it may just be a continuing of the thread
as it is now.

Thanks,

-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Red Hat, Inc. | Boston, MA | EST5EDT

[Michael Catanzaro]

On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell 
<dcantrell(a)redhat.com&gt; wrote:
>  The core issue still comes down to having resources to continue 
>  maintaining
>  BIOS boot support in Fedora and so far no one has come forward to 
>  work on
>  that. 
It's not true, although you can be forgiven for missing it in such a 
massive thread. Hans proposed to start a BIOS SIG to handle this. This 
seems like a very credible proposal.

Michael

[David Cantrell]

On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
>  On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
>  <dcantrell(a)redhat.com&gt; wrote:
>  > The core issue still comes down to having resources to continue
>  > maintaining
>  > BIOS boot support in Fedora and so far no one has come forward to work
>  > on
>  > that.
>  
>  It's not true, although you can be forgiven for missing it in such a massive
>  thread. Hans proposed to start a BIOS SIG to handle this. This seems like a
>  very credible proposal. 
Ah, yes.  I do remember the post from Hans, but thought he was more outlining
how a Legacy BIOS SIG could work and what would need to happen rather than
volunteering to set one up and do that.  But I went back and reread that post
and yes, he did volunteer to do just that.

If a video call happens to discuss this feature proposal, ensure Hans can
attend.

Thanks,

-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Red Hat, Inc. | Boston, MA | EST5EDT

[Samuel Sieb]

On 4/13/22 07:54, David Cantrell wrote:
>  The core issue still comes down to having resources to continue
> maintaining
>  BIOS boot support in Fedora and so far no one has come forward to work on
>  that. 
As far as I can tell from the responses in the other thread, there is 
not currently an issue with BIOS support.  This is merely a belief that 
it will become a problem in the future.  Given that supposedly no more 
BIOS-only computers are being made, why are you expecting future 
problems since nothing will change from where it is now?

[David Cantrell]

On Wed, Apr 13, 2022 at 09:34:18AM -0700, Samuel Sieb wrote:
>  On 4/13/22 07:54, David Cantrell wrote:
>  > The core issue still comes down to having resources to continue maintaining
>  > BIOS boot support in Fedora and so far no one has come forward to work on
>  > that.
>  
>  As far as I can tell from the responses in the other thread, there is not
>  currently an issue with BIOS support.  This is merely a belief that it will
>  become a problem in the future.  Given that supposedly no more BIOS-only
>  computers are being made, why are you expecting future problems since
>  nothing will change from where it is now? 
What you are describing is not a zero-maintenance issue.  Even if nothing
changes around BIOS boot support in the software, the entire OS around it
changes which means as a component of the OS, the boot loader needs ongoing
maintenance to ensure it continues to build and work.  For example, consider
new releases of gcc and binutils.

The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in
Fedora.

Thanks,

-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Red Hat, Inc. | Boston, MA | EST5EDT

[Hans de Goede]

Hi,

On 4/13/22 18:07, David Cantrell wrote:
>  On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
> > On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
> > <dcantrell(a)redhat.com&gt; wrote:
> >> The core issue still comes down to having resources to continue
> >> maintaining
> >> BIOS boot support in Fedora and so far no one has come forward to work
> >> on
> >> that.
> >
> > It's not true, although you can be forgiven for missing it in such a massive
> > thread. Hans proposed to start a BIOS SIG to handle this. This seems like a
> > very credible proposal.
>  
>  Ah, yes.  I do remember the post from Hans, but thought he was more outlining
>  how a Legacy BIOS SIG could work and what would need to happen rather than
>  volunteering to set one up and do that.  But I went back and reread that post
>  and yes, he did volunteer to do just that. 
Correct.

>  If a video call happens to discuss this feature proposal, ensure Hans
> can
>  attend. 
FWIW, ATM I think everything which can be said about
this has been said and I'm not sure if having a video
call about this will add anything new.

As for setting up the SIG if necessary, my plan is to
try to keep the SIG lite weight on the process side
and focus on the practical things.

What I envision for the SIG is:

1. I'm not sure if it is possible to setup group ownership
of pkgs in pagure? So to keep things simple the few packages which
are only necessary for BIOS boot can be handed over to me and then
I'll just add other people willing to help out as co-maintainers.

2. Setup a mailinglist for this and have that in bugzilla + PR
Cc for all the relevant packages.

3. Have people from the SIG regularly test Fedora N and
Fedora N + 1 (after branching) on machines which only support
BIOS booting and file bugs (if any) + report the results to
the mailinglist.

4. Have people from the SIG try to regularly do bugzilla
triage of relevant packages.

And I would also like to have a discussion about splitting
the BIOS boot grub bits out into a separate src.rpm
(using the same Source0 as the main grub) so that this can
be build by the SIG without needing help from the bootloader
team (the main grub package can only be built by a few people
because of secureboot signing). The idea is to avoiding
bottlenecking on the bootloader team when some BIOS boot bugs
in grub need to be fixed, quoting from my original email about
this:

"""
I've been thinking about how this could be done for grub; also
because of the issue that the EFI builds of grub need to be
signed with Fedora's secure boot keys, which means only a few
people can do grub2 builds atm.

One option which I think we should consider is sticking with
a single downstream git fork (until we have managed to get
everything we need upstream), so stick with:

https://github.com/rhboot/grub2/

As the Source0 provider for the packages and then next to:

https://src.fedoraproject.org/rpms/grub2

Add a:

https://src.fedoraproject.org/rpms/grub2-bios

And moving the build of all sub-packages which are
only necessary for BIOS support to the second src.rpm.

This way the Legacy BIOS SIG could maintain
the grub2-bios src.rpm (and binary pkgs it builds).
The SIG _must_ then of course still submit pull-reqs to:
https://github.com/rhboot/grub2/ for any changes.

But in case of e.g. a beta blocking BIOS only bug they
could solve that with a patch in the src.rpm and kickof
a build right away without blocking on the bootloader
team and thus without causing a spike in
work-pressure/load for the bootloader team.

And then once the pull-req is merged (possibly
a revised version of it) the next build of
the grub2-bios src.rpm can pull in the new Source0
and drop its local changes (IOW grub2-bios _must_
not become a separate fork).
"""

Regards,

Hans

[David Cantrell]

On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
>  Hi,
>  
>  On 4/13/22 18:07, David Cantrell wrote:
>  > On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
>  >> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
>  >> <dcantrell(a)redhat.com&gt; wrote:
>  >>> The core issue still comes down to having resources to continue
>  >>> maintaining
>  >>> BIOS boot support in Fedora and so far no one has come forward to work
>  >>> on
>  >>> that.
>  >>
>  >> It's not true, although you can be forgiven for missing it in such a
> massive
>  >> thread. Hans proposed to start a BIOS SIG to handle this. This seems like a
>  >> very credible proposal.
>  > 
>  > Ah, yes.  I do remember the post from Hans, but thought he was more outlining
>  > how a Legacy BIOS SIG could work and what would need to happen rather than
>  > volunteering to set one up and do that.  But I went back and reread that post
>  > and yes, he did volunteer to do just that.
>  
>  Correct.
>  
>  > If a video call happens to discuss this feature proposal, ensure Hans can
>  > attend.
>  
>  FWIW, ATM I think everything which can be said about
>  this has been said and I'm not sure if having a video
>  call about this will add anything new. 
Agreed.

>  As for setting up the SIG if necessary, my plan is to
>  try to keep the SIG lite weight on the process side
>  and focus on the practical things.
>  
>  What I envision for the SIG is:
>  
>  1. I'm not sure if it is possible to setup group ownership
>  of pkgs in pagure? So to keep things simple the few packages which
>  are only necessary for BIOS boot can be handed over to me and then
>  I'll just add other people willing to help out as co-maintainers.
>  
>  2. Setup a mailinglist for this and have that in bugzilla + PR
>  Cc for all the relevant packages.
>  
>  3. Have people from the SIG regularly test Fedora N and
>  Fedora N + 1 (after branching) on machines which only support
>  BIOS booting and file bugs (if any) + report the results to
>  the mailinglist.
>  
>  4. Have people from the SIG try to regularly do bugzilla
>  triage of relevant packages.
>  
>  And I would also like to have a discussion about splitting
>  the BIOS boot grub bits out into a separate src.rpm
>  (using the same Source0 as the main grub) so that this can
>  be build by the SIG without needing help from the bootloader
>  team (the main grub package can only be built by a few people
>  because of secureboot signing). The idea is to avoiding
>  bottlenecking on the bootloader team when some BIOS boot bugs
>  in grub need to be fixed, quoting from my original email about
>  this:
>  
>  """
>  I've been thinking about how this could be done for grub; also
>  because of the issue that the EFI builds of grub need to be
>  signed with Fedora's secure boot keys, which means only a few
>  people can do grub2 builds atm.
>  
>  One option which I think we should consider is sticking with
>  a single downstream git fork (until we have managed to get
>  everything we need upstream), so stick with:
>  
>  https://github.com/rhboot/grub2/
>  
>  As the Source0 provider for the packages and then next to:
>  
>  https://src.fedoraproject.org/rpms/grub2
>  
>  Add a:
>  
>  https://src.fedoraproject.org/rpms/grub2-bios
>  
>  And moving the build of all sub-packages which are
>  only necessary for BIOS support to the second src.rpm.
>  
>  This way the Legacy BIOS SIG could maintain
>  the grub2-bios src.rpm (and binary pkgs it builds).
>  The SIG _must_ then of course still submit pull-reqs to:
>  https://github.com/rhboot/grub2/ for any changes.
>  
>  But in case of e.g. a beta blocking BIOS only bug they
>  could solve that with a patch in the src.rpm and kickof
>  a build right away without blocking on the bootloader
>  team and thus without causing a spike in
>  work-pressure/load for the bootloader team.
>  
>  And then once the pull-req is merged (possibly
>  a revised version of it) the next build of
>  the grub2-bios src.rpm can pull in the new Source0
>  and drop its local changes (IOW grub2-bios _must_
>  not become a separate fork).
>  """ 
OK, given this proposal, I'd like the original change proposal amended to
essentially say "transfer legacy BIOS boot support to newly formed Legacy BIOS
SIG" or something like that.  The logistics at that point can be sorted out as
the SIG sees fit.  I'd like to see the original proposal advance forward and
this gives a plan for the legacy BIOS piece.

Can you followup with the proposal owners to make that amendment?

Thanks,

-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Red Hat, Inc. | Boston, MA | EST5EDT

[Kevin Fenzi]

...snip bios sig plan...

Thanks for that Hans! 

If that proves acceptable for change owners here that would perhaps take
care of the short term problem. What about longer term though? Would the
thought be that the BIOS sig would remain around for the forseeable
future maintaining BIOS boot? Or would there be some kind of roadmap to
retirement?

kevin

[Michel Alexandre Salim]

On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
>  Hi,
>  
>  
>  1. I'm not sure if it is possible to setup group ownership
>  of pkgs in pagure? So to keep things simple the few packages which
>  are only necessary for BIOS boot can be handed over to me and then
>  I'll just add other people willing to help out as co-maintainers.
>   
yup, Python, Rust, and Go SIG does this all the time

>  2. Setup a mailinglist for this and have that in bugzilla + PR
>  Cc for all the relevant packages.
>  
The group will get emailed just like a normal maintainer, IIRC. Someone
will need to register that group's email in Bugzilla just like a normal
account

Best,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Matthew Miller]

On Wed, Apr 13, 2022 at 03:27:14PM -0400, David Cantrell wrote:
>  > FWIW, ATM I think everything which can be said about
>  > this has been said and I'm not sure if having a video
>  > call about this will add anything new.
>  Agreed. 
Works for me -- I just wanted to put the option there in case it _would_ be
helpful.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Wed, Apr 13, 2022 at 12:56:11PM -0700, Kevin Fenzi wrote:
>  If that proves acceptable for change owners here that would perhaps
> take
>  care of the short term problem. What about longer term though? Would the
>  thought be that the BIOS sig would remain around for the forseeable
>  future maintaining BIOS boot? Or would there be some kind of roadmap to
>  retirement? 
I think it would make sense for the group to be set up with with some sort
of "retirement becomes the default if the SIG stops being active" policy. I
mean, not as a surprise, but so the situation is clear.

It'd be cool to see if we can make a bios-to-uefi thing like Clover work.
That might be something interesting for the SIG to do. But, I don't think
that's really a small project!



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Kevin Kofler]

Matthew Miller wrote:
>  We've got a 300+ message thread in just one week, with 66
> different
>  participants. This handily beats discussions systemd-resolved,
>  btrfs-by-default, and even switching the default editor to nano.
>  
>  Clearly there's a lot to talk about here. Would it be useful to have a
>  high-bandwidth, moderated conversation via video call about the best path
>  forward? 
No. The consensus in the mailing list is pretty clear, so I do not see why 
we should move the discussion to another medium…

>  (Because of the number of likely participants, Jitsi probably
> won't cut
>  it, so this would likely be via Bluejeans.) 
… and a proprietary one at that!

Unless somebody is not happy with the outcome of the discussion on the 
mailing list (which is that dropping BIOS support at this time is clearly 
not acceptable) and hopes to get another outcome on another medium.

        Kevin Kofler

[Kevin Kofler]

Hans de Goede wrote:
>  As the Source0 provider for the packages and then next to:
>  
>  https://src.fedoraproject.org/rpms/grub2
>  
>  Add a:
>  
>  https://src.fedoraproject.org/rpms/grub2-bios
>  
>  And moving the build of all sub-packages which are
>  only necessary for BIOS support to the second src.rpm.
>  
>  This way the Legacy BIOS SIG could maintain
>  the grub2-bios src.rpm (and binary pkgs it builds). 
Would it not make more sense to rename the locked down grub2 SRPM that will 
become UEFI only to grub2-efi and let grub2 be the BIOS one, to match the 
naming of the binary RPMs (which are already split)?

        Kevin Kofler

[Neal Gompa]

On Wed, Apr 13, 2022 at 8:45 PM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Hans de Goede wrote:
>  > As the Source0 provider for the packages and then next to:
>  >
>  > https://src.fedoraproject.org/rpms/grub2
>  >
>  > Add a:
>  >
>  > https://src.fedoraproject.org/rpms/grub2-bios
>  >
>  > And moving the build of all sub-packages which are
>  > only necessary for BIOS support to the second src.rpm.
>  >
>  > This way the Legacy BIOS SIG could maintain
>  > the grub2-bios src.rpm (and binary pkgs it builds).
>
>  Would it not make more sense to rename the locked down grub2 SRPM that will
>  become UEFI only to grub2-efi and let grub2 be the BIOS one, to match the
>  naming of the binary RPMs (which are already split)?
>  
The binary RPM for grub's BIOS boot code is grub2-pc (and
grub2-pc-modules), not grub2. But "grub2-pc" is not particularly
descriptive as a source package name, so grub2-bios makes sense for
the source package name if we need to split it.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Neal Gompa wrote:
>  The binary RPM for grub's BIOS boot code is grub2-pc (and
>  grub2-pc-modules), not grub2. 
Oh, it used to be just grub2 until F26 (included), I had either forgotten or 
not noticed at all that it had been renamed back in F27 already. (It used to 
be the case for years that grub2 was BIOS GRUB and grub2-efi was UEFI GRUB, 
I still do not see what the point in changing that was.)

        Kevin Kofler

[Gary Buhrmaster]

On Thu, Apr 14, 2022 at 12:38 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Matthew Miller wrote:
>  > We've got a 300+ message thread in just one week, with 66 different
>  > participants. This handily beats discussions systemd-resolved,
>  > btrfs-by-default, and even switching the default editor to nano.
>  >
>  > Clearly there's a lot to talk about here. Would it be useful to have a
>  > high-bandwidth, moderated conversation via video call about the best path
>  > forward?
>
>  No. The consensus in the mailing list is pretty clear, so I do not see why
>  we should move the discussion to another medium…
>
>  > (Because of the number of likely participants, Jitsi probably won't cut
>  > it, so this would likely be via Bluejeans.)
>
>  … and a proprietary one at that!
>
>  Unless somebody is not happy with the outcome of the discussion on the
>  mailing list (which is that dropping BIOS support at this time is clearly
>  not acceptable) and hopes to get another outcome on another medium. 
Actually, I came out of the discussion with an
understand that results in the same (current)
status, but has different implications, which is
that as long as there are a sufficient number of
individuals with competency who are willing
to put their own resources (time/effort) into
legacy BIOS support it will continue.

So I think those of us with BIOS only systems
thank you for your commitment of your time
and effort (and understand when you and
others no longer have those "free" resources
to invest).

So thank you Kevin for committing your time/effort.

F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Thomas Schmitt]

Hi,

Neal Gompa wrote:
>  The binary RPM for grub's BIOS boot code is grub2-pc (and
>  grub2-pc-modules), not grub2. But "grub2-pc" is not particularly
>  descriptive as a source package name, so grub2-bios makes sense for
>  the source package name if we need to split it. 
May i propose "grub2-pc-bios" instead ? Or "grub2-legacy-bios" ?

There is a habit in the web to call EFI "the BIOS of the computer".
Google "EFI BIOS" yields this confusing nomenclature mainly with german
language texts. Like
 
https://www.heise.de/news/Updates-notwendig-Sicherheitsluecken-im-UEFI-BI...
  "Zahlreiche Bugs in UEFI-BIOS-Versionen der Firma Insyde H2O"
  = "Numerous bugs in UEFI-BIOS-versions of the company Insyde H2O"
But some english mix-ups are to see too
  https://superuser.com/questions/1247300/how-to-make-uefi-bios-start-grub-...


Have a nice day :)

Thomas

[Ralf Corsépius]

Am 13.04.22 um 20:05 schrieb David Cantrell:

>  The Legacy BIOS SIG is a good proposal to handle this sort of ongoing
> work in
>  Fedora. 
I do not agree with this statement.  Like previous "Legacy SIGs" this is 
a red herring to obfuscate RHATs lack of disinterest with topics, which 
do not match into their business objectives.

Ralf

[Vitaly Zaitsev]

On 13/04/2022 23:11, Matthew Miller wrote:
>  It'd be cool to see if we can make a bios-to-uefi thing like
> Clover work. 
I don't think it's possible because the MBR -> GPT conversion will 
destroy all partitions on the original drive.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Tomasz Torcz]

On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote:
>  
>  
>  Am 13.04.22 um 20:05 schrieb David Cantrell:
>  
>  > The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in
>  > Fedora.
>  
>  I do not agree with this statement.  Like previous "Legacy SIGs" this is a
>  red herring to obfuscate RHATs lack of disinterest with topics, which do not
>  match into their business objectives. 
  Really? Fedora is mainly a volunteer effort, someone has to do the work.
SIG is a good solution. RedHat is under no obligation to work on
everything.

-- 
Tomasz Torcz               “Never underestimate the bandwidth of a station
tomek(a)pipebreaker.pl        wagon filled with backup tapes.”  — Jim Gray

[Jóhann B. Guðmundsson]

On 14.4.2022 09:17, Tomasz Torcz wrote:
>  On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote:
> >
> > Am 13.04.22 um 20:05 schrieb David Cantrell:
> >
> >> The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in
> >> Fedora.
> > I do not agree with this statement.  Like previous "Legacy SIGs" this is a
> > red herring to obfuscate RHATs lack of disinterest with topics, which do not
> > match into their business objectives.
>     Really? Fedora is mainly a volunteer effort, someone has to do the work.
>  SIG is a good solution. RedHat is under no obligation to work on
>  everything.
>  
Anything that adds to the bureaucracy level of a project or community in 
general is never a good thing since such process gets in the way of the 
people that are actually doing all the work ( more often than not too 
much energy spent on bureaucracy than the actual work itself ).

In this case that SIG would be created for no good reason since the 
outcome is inevitable.

What the project needs to decide upon is...

For how long should fedora support any given hardware ( electric 
components do not last forever ) ?

For example EU has regulation that requires vendors to have spare parts 
available for 7–10 years after date of manufacturing so it makes sense 
for the project to support hw no longer than a decade from the date of 
it's manufacturing. ( which makes the oldest hw being support being 
manufactured in 2012 ) and every process,workflows and decision being 
bound by that.

Is Fedora an distribution that does not revert but always transforms, 
rolls out and moves forward or is it an distribution that is stuck in 
the past ( from a software and hardware point of view )?


JBG

[Gary Buhrmaster]

On Wed, Apr 13, 2022 at 9:12 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:

>  It'd be cool to see if we can make a bios-to-uefi thing like
> Clover work.
>  That might be something interesting for the SIG to do. But, I don't think
>  that's really a small project! 
This is mostly off topic, and while I have not
carefully tracked the project in recent years,
the clover uefi emulator has been said to
work a lot of the time out of the box, but due
to some of the ways that vendors choose to
implement bios features/tables it can require
complex configuration, typically unique for
that particular system (type).  I also seem to
recall there were some utilities to try to
assist figuring out that configuration, but
those were not always for the faint of heart.
The hard part (as is usually the case) was
dealing with those edge cases, even as the
clover project has a lot of documentation
trying to help.

[Kevin Kofler]

Ralf Corsépius wrote:
>  I do not agree with this statement.  Like previous "Legacy
> SIGs" this is
>  a red herring to obfuscate RHATs lack of disinterest with topics, which
>  do not match into their business objectives. 
I am also worried that this is just a delayed retirement, as it was for 32-
bit i686, where the SIG was very quickly declared a failure, without even 
being given time to organize.

Still, it is better than retiring it immediately. But like you, I am worried 
that this is not really a long-term commitment and that people will be 
attempting to kill BIOS support again at even the smallest dent in SIG 
activity.

        Kevin Kofler

[Kevin Kofler]

Jóhann B. Guðmundsson wrote:
>  In this case that SIG would be created for no good reason since the
>  outcome is inevitable. 
I still do not see what is inevitable about the outcome. Keeping legacy, no 
longer changing, interfaces working forever should require next to no 
effort.

>  For how long should fedora support any given hardware ( electric
>  components do not last forever ) ? 
Ideally, as long as there is at least one person still using it. In 
practice, it probably requires more than one person, but the user base for 
legacy BIOS is still large judging from the feedback in the thread.

>  For example EU has regulation that requires vendors to have spare
> parts
>  available for 7–10 years after date of manufacturing so it makes sense
>  for the project to support hw no longer than a decade from the date of
>  it's manufacturing. ( which makes the oldest hw being support being
>  manufactured in 2012 ) and every process,workflows and decision being
>  bound by that. 
Lack of availability of original spare parts does not mean that the hardware 
suddenly magically stops working for everybody.

>  Is Fedora an distribution that does not revert but always
> transforms,
>  rolls out and moves forward or is it an distribution that is stuck in
>  the past ( from a software and hardware point of view )? 
Running on both old and new hardware does not preclude in any way shipping 
the most recent software. This is a false dichotomy.

        Kevin Kofler

[Miro Hrončok]

On 13. 04. 22 22:29, Michel Alexandre Salim wrote:
>  On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
> > Hi,
> >
> >
> > 1. I'm not sure if it is possible to setup group ownership
> > of pkgs in pagure? So to keep things simple the few packages which
> > are only necessary for BIOS boot can be handed over to me and then
> > I'll just add other people willing to help out as co-maintainers.
> >
>  yup, Python, Rust, and Go SIG does this all the time 
No, Python SIG does not. Each package needs a primary maintainer. The SIG 
co-maintains it. There are some exceptions when somebody set Python SIG as the 
primary point of contact, but pagure still tracks the "main admin" user/person 
-- this cannot be a group.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Peter Boy]

>  Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson
> <johannbg(a)gmail.com&gt;:
>  
>  For example EU has regulation that requires vendors to have spare parts available for
> 7–10 years after date of manufacturing so it makes sense for the project to support hw no
> longer than a decade from the date of it's manufacturing. ( which makes the oldest hw
> being support being manufactured in 2012 ) and every process,workflows and decision being
> bound by that.
>  
>  Is Fedora an distribution that does not revert but always transforms, rolls out and moves
> forward or is it an distribution that is stuck in the past ( from a software and hardware
> point of view )? 
Sorry, you simple didn’t get the point. It is not just about hardware. Some Cloud
providers doesn’t support UEFI boot at the moment - so said various voices from Cloud WG.
And some data center insist ob BIOS boot because of whatever, presumably management
infrastructure. So, the hardware does or does not support UEFI, doesn’t matter in these
cases.

And there is obviously some hardware around younger than 10 years that don’t support UEFI,
at least not without problems.

And yes, there is some hardware older than 10 years. Currently Linux is known to support
older hardware. Do we want to ditch that? 

Nevertheless, old or new hardware is not the issue.

The question is: how many users do we want to leave behind? Or: how many users must we
leave behind because we can’t do the job.

[Jóhann B. Guðmundsson]

On 14.4.2022 11:53, Peter Boy wrote:
> > Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson <johannbg(a)gmail.com&gt;:
> >
> > For example EU has regulation that requires vendors to have spare parts available for
> 7–10 years after date of manufacturing so it makes sense for the project to support hw no
> longer than a decade from the date of it's manufacturing. ( which makes the oldest hw
> being support being manufactured in 2012 ) and every process,workflows and decision being
> bound by that.
> >
> > Is Fedora an distribution that does not revert but always transforms, rolls out and
> moves forward or is it an distribution that is stuck in the past ( from a software and
> hardware point of view )?
>  Sorry, you simple didn’t get the point. It is not just about hardware. Some Cloud
> providers doesn’t support UEFI boot at the moment - so said various voices from Cloud WG.
> And some data center insist ob BIOS boot because of whatever, presumably management
> infrastructure. So, the hardware does or does not support UEFI, doesn’t matter in these
> cases. 

So you are saying that 3rd party vendors ( cloud providers ) now dictate 
and decide the direction of the project?


JBG

[JadoNena]

>  The question is: how many users do we want to leave behind? Or: how
> many users must we leave behind because we can’t do the job. 
We are just users.  Our expert development is for other professions than writing drivers
and operating systems.

My company has about 200 Fedora user PCs around the world.
Plus about 20 servers in real hardware and 30-50 in virtual.
More are in RedHat too but I am not talking about those here.

We had decided on the RH+Centos+Fedora Eco system.

All desktops and some laptops (that equals about 170) use NVidia graphics.  In every case
we use the NVidia drivers.  They are built with the DKIM software.  It is not convenient
but it is worth the effort.  We can rely on the NVidia software to work all the time. And
we have access to the CUDA code and so on.

For the servers plus the user PCs about 60% are on BIOS boot not UEFI.  May be half of
those are BIOS only.

My company has a budget.  We do the planning for 2-3 years.
It pays for developers salarys.  And for new hardware.  And for VPS rental costs.  And for
user training.
And for our Enterprise support products and services like RedHat.

Unplanned and unexpected changes cost to my company a very large amount.
We always plan our strategy to control and best minimize that cost.
We must operate successfully for to pay those salarys and to purchase that hardware and
services.

All of this discussion waves a red flag at us.
We think we hear that Fedora has philosophy arguments about opensource and propietary and
BIOS and UEFI.
We read the crazy mathematics about numbers of users based on I don't know what.

But only a few people are talking about the real costs to users.

Okay, the developers here are interested only in what makes the life easier for them.
And want to not have "3rd party vendors now dictate" decisions.
I can understand that theory too.

But for here we deal with the real world where budgets require plans and hardware exists
for years.
With this decision making the red flag means that "today & now" we must
start with planning for alternatives to the RH+Centos+Fedora Eco system.

We did not expect this from the RH+Centos+Fedora Eco system.
That maybe is our mistake?

And that is all just one person at one company's opinion.

Jado

[Jóhann B. Guðmundsson]

On 14.4.2022 11:42, Kevin Kofler via devel wrote:
>  Jóhann B. Guðmundsson wrote:
>
> > For example EU has regulation that requires vendors to have spare parts
> > available for 7–10 years after date of manufacturing so it makes sense
> > for the project to support hw no longer than a decade from the date of
> > it's manufacturing. ( which makes the oldest hw being support being
> > manufactured in 2012 ) and every process,workflows and decision being
> > bound by that.
>  Lack of availability of original spare parts does not mean that the hardware
>  suddenly magically stops working for everybody.
>  
No but it does mean that they cant run indefinitely

And there needs to be a number on this to adjust users expectation and 
10 years is a reasonable number from a business, parts and 
recycle/re-use availability,

What is unreasonable is to be expecting that it's supported indefinitely 
from OS and or HW vendors.

JBG

[Tomasz Torcz]

On Thu, Apr 14, 2022 at 01:42:26PM +0200, Kevin Kofler via devel wrote:
>  Jóhann B. Guðmundsson wrote:
>  > In this case that SIG would be created for no good reason since the
>  > outcome is inevitable.
>  
>  I still do not see what is inevitable about the outcome. Keeping legacy, no 
>  longer changing, interfaces working forever should require next to no 
>  effort. 
  So the SIG would have next to no work to do. Great!
In reality, distribution around BIOS booting change, compilers change,
there is always some effort required even to maintain status quo.

-- 
Tomasz Torcz               “Never underestimate the bandwidth of a station
tomek(a)pipebreaker.pl        wagon filled with backup tapes.”  — Jim Gray

[Peter Boy]

>  Am 14.04.2022 um 14:05 schrieb Jóhann B. Guðmundsson
> <johannbg(a)gmail.com&gt;:
>  
>  On 14.4.2022 11:53, Peter Boy wrote:
> > 
> >> Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson <johannbg(a)gmail.com&gt;:
> >> 
> >> For example EU has regulation that requires vendors to have spare parts available
> for 7–10 years after date of manufacturing so it makes sense for the project to support hw
> no longer than a decade from the date of it's manufacturing. ( which makes the oldest
> hw being support being manufactured in 2012 ) and every process,workflows and decision
> being bound by that.
> >> 
> >> Is Fedora an distribution that does not revert but always transforms, rolls out
> and moves forward or is it an distribution that is stuck in the past ( from a software and
> hardware point of view )?
> > Sorry, you simple didn’t get the point. It is not just about hardware. Some Cloud
> providers doesn’t support UEFI boot at the moment - so said various voices from Cloud WG.
> And some data center insist ob BIOS boot because of whatever, presumably management
> infrastructure. So, the hardware does or does not support UEFI, doesn’t matter in these
> cases.
>  
>  
>  So you are saying that 3rd party vendors ( cloud providers ) now dictate and decide the
> direction of the project?
>   
Nobody dictates anything. The provider has its good reasons, whatever it is. And Fedora
has its own reasons. As I said, it’s just our decision: how many users do we want to leave
behind. Or can we think of a good solution and find the strength to organize it so that we
don't lose any users or as few as possible. It's our problem, not anyone
else's. 

Or: how much do we care about our users? And how connected do we feel to our users?

[Jóhann B. Guðmundsson]

On 14.4.2022 12:18, JadoNena via devel wrote:
>  But for here we deal with the real world where budgets require plans
> and hardware exists for years. 

If you are dealing with the real world with real businesses then you 
should be aware of the fact that businesses are usually on a 3 - 5 year 
hw replacement cycle since it save costs as studies like these have 
found [¹].

After 3 - 5 years those computers are introduced into the re-use/recycle 
ecosystem and re-purposed elsewhere with the hw vendors being forced to 
support that cycle.

With 10 years of hw support in fedora it would fit nicely into that cycle.


That said obviously companies will lose that cost saving if they end up 
having to spend it in a license cost elsewhere, be it Red Hat, Microsoft 
or something else..


JBG


1. 
https://news.microsoft.com/en-nz/2018/10/16/true-cost-of-not-replacing-co...

[Neal Gompa]

On Thu, Apr 14, 2022 at 8:18 AM JadoNena via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  > The question is: how many users do we want to leave behind? Or: how many users must
> we leave behind because we can’t do the job.
>
>  We are just users.  Our expert development is for other professions than writing drivers
> and operating systems.
>
>  My company has about 200 Fedora user PCs around the world.
>  Plus about 20 servers in real hardware and 30-50 in virtual.
>  More are in RedHat too but I am not talking about those here.
>
>  We had decided on the RH+Centos+Fedora Eco system.
>
>  All desktops and some laptops (that equals about 170) use NVidia graphics.  In every case
> we use the NVidia drivers.  They are built with the DKIM software.  It is not convenient
> but it is worth the effort.  We can rely on the NVidia software to work all the time. And
> we have access to the CUDA code and so on.
>
>  For the servers plus the user PCs about 60% are on BIOS boot not UEFI.  May be half of
> those are BIOS only.
>
>  My company has a budget.  We do the planning for 2-3 years.
>  It pays for developers salarys.  And for new hardware.  And for VPS rental costs.  And
> for user training.
>  And for our Enterprise support products and services like RedHat.
>
>  Unplanned and unexpected changes cost to my company a very large amount.
>  We always plan our strategy to control and best minimize that cost.
>  We must operate successfully for to pay those salarys and to purchase that hardware and
> services.
>
>  All of this discussion waves a red flag at us.
>  We think we hear that Fedora has philosophy arguments about opensource and propietary and
> BIOS and UEFI.
>  We read the crazy mathematics about numbers of users based on I don't know what.
>
>  But only a few people are talking about the real costs to users.
>
>  Okay, the developers here are interested only in what makes the life easier for them.
>  And want to not have "3rd party vendors now dictate" decisions.
>  I can understand that theory too.
>
>  But for here we deal with the real world where budgets require plans and hardware exists
> for years.
>  With this decision making the red flag means that "today & now" we must
> start with planning for alternatives to the RH+Centos+Fedora Eco system.
>
>  We did not expect this from the RH+Centos+Fedora Eco system.
>  That maybe is our mistake?
>
>  And that is all just one person at one company's opinion.
>  
First: ***do not panic!***

Second: This is not a foregone conclusion yet. It's merely a
***proposal***, and one that most of the community has reacted
negatively to. It may happen someday, but we *do* care about our
larger ecosystem and user community. Chances are pretty good we'll
have the capability to work with legacy BIOS boot on x86_64 machines
for a few more years.

Third: You pay for enterprise support from Red Hat, Inc. That means
you have the ability to inform Red Hat through your business
relationship of your needs. That subscription you pay for your RHEL
systems allows you a direct relationship and influence over *their*
roadmap. If you tell them that this would be a problem if it made its
way into RHEL, they will account for that in their roadmap planning.
Take advantage of that capability and talk to your account manager
about it. It's their job to listen to your concerns and ensure that is
accounted for. That's the value of the Red Hat Enterprise Linux
subscription you pay for!

As for anyone else looking at this thread with RHEL-tinted lenses as
more activist RHEL customers, please direct your feedback to your
account managers.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[JadoNena]

Hello,

>  On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa
> <ngompa13(a)gmail.com&gt; wrote: 
Thank you very much for your reply.  You are one of those several people that we have been
reading has some good sense for users!

>  First: do not panic! 
Of course panic is a bad idea.
I am just observing this largest ever (?), very loud public thread.
Our response is to start planning.  It it our "anti-panic" approach and we work
to never kick the can too far along.

>  Second: This is not a foregone conclusion yet. It's merely a
Yes that is a possibility too.

But I do not even now see it as a choice to NOT begin to plan and act.
Not with this discussion, even if there are some user-supporting voices.

>  Third: You pay for enterprise support from Red Hat, Inc. That means
>  you have the ability to inform Red Hat through your business
>  relationship of your needs. 
It is good advice.  Of course we are doing that too.
They listen to be sure. The usual action if not the answer is that RedHat is not Fedora.
So use more RedHat.
Of course it is many @redhat voices here, in this Fedora discussion, that look like they
are making these proposals.
It is a circle of logic that we have not so much luck with.
In our experience there is there also a disconnection too often between revenue, customer
requirements, and developers.  That is a different discussion and, today, it does not
really matter what "we" think about it, it is just the way of things.

>  As for anyone else looking at this thread with RHEL-tinted lenses as
>  more activist RHEL customers, please direct your feedback to your
>  account managers. 
We cross fingers that like you advise maybe those voices that pay the bills will have some
effect.

Jado

[Ben Beasley]

For desktop-class hardware, the parts that are most likely to fail 
around the decade mark are storage drives, power supplies, and perhaps 
fans. All of these are fully standardized and in plentiful supply; there 
is no reason that first-party hardware vendor support should be required 
to keep old desktop systems in service.

Dropping support for old hardware in Fedora should always be based on 
the costs and benefits, not on a rigid planned lifecycle.

– Ben

On 4/14/22 08:25, Jóhann B. Guðmundsson wrote:
> On 14.4.2022 11:42, Kevin Kofler via devel wrote:
>> Jóhann B. Guðmundsson wrote:
>>
>>> For example EU has regulation that requires vendors to have spare parts
>>> available for 7–10 years after date of manufacturing so it makes sense
>>> for the project to support hw no longer than a decade from the date of
>>> it's manufacturing. ( which makes the oldest hw being support being
>>> manufactured in 2012 ) and every process,workflows and decision being
>>> bound by that.
>> Lack of availability of original spare parts does not mean that the 
>> hardware
>> suddenly magically stops working for everybody.
>>
> No but it does mean that they cant run indefinitely
>
> And there needs to be a number on this to adjust users expectation and 
> 10 years is a reasonable number from a business, parts and 
> recycle/re-use availability,
>
> What is unreasonable is to be expecting that it's supported 
> indefinitely from OS and or HW vendors.
>
> JBG
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

[Neal Gompa]

On Thu, Apr 14, 2022 at 8:58 AM JadoNena <jadochneinaber(a)protonmail.ch&gt; wrote:
>  Hello,
>
>  > On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>
>  Thank you very much for your reply.  You are one of those several people that we have
> been reading has some good sense for users!
>
>  > First: do not panic!
>
>  Of course panic is a bad idea.
>  I am just observing this largest ever (?), very loud public thread.
>  Our response is to start planning.  It it our "anti-panic" approach and we work
> to never kick the can too far along.
>
>  > Second: This is not a foregone conclusion yet. It's merely a
>
>  Yes that is a possibility too.
>
>  But I do not even now see it as a choice to NOT begin to plan and act.
>  Not with this discussion, even if there are some user-supporting voices.
>
>  > Third: You pay for enterprise support from Red Hat, Inc. That means
>  > you have the ability to inform Red Hat through your business
>  > relationship of your needs.
>
>  It is good advice.  Of course we are doing that too.
>  They listen to be sure. The usual action if not the answer is that RedHat is not Fedora.
> So use more RedHat.
>  Of course it is many @redhat voices here, in this Fedora discussion, that look like they
> are making these proposals.
>  It is a circle of logic that we have not so much luck with.
>  In our experience there is there also a disconnection too often between revenue, customer
> requirements, and developers.  That is a different discussion and, today, it does not
> really matter what "we" think about it, it is just the way of things.
>  
I've heard this before in the past too. Thankfully nowadays, it's much
easier to refute that. While it is true that RHEL is not Fedora and
they can (and sometimes do) make substantially different choices for
RHEL than Fedora did, they largely don't (especially since they've
been burned fairly recently doing that once).

With Fedora ELN providing that RHEL-ish build of Fedora Rawhide
continuously[1], the goal is to be able to take that to build the next
major version of CentOS Stream faster, which directly becomes Red Hat
Enterprise Linux[2].

With this information in hand, it's easy to see that Fedora Changes
are a good proxy for how future RHEL might evolve, and it's worth
giving feedback early about those changes to your Red Hat account
team. I certainly know of others who do that with decent success. :)

[1]: https://docs.fedoraproject.org/en-US/eln/
[2]: https://www.redhat.com/en/resources/centos-stream-datasheet




--
真実はいつも一つ！/ Always, there's only one truth!

[John Reiser]

On 4/14/22 02:01, Vitaly Zaitsev via devel wrote:
>  On 13/04/2022 23:11, Matthew Miller wrote:
> > It'd be cool to see if we can make a bios-to-uefi thing like Clover work.
>  
>  I don't think it's possible because the MBR -> GPT conversion will destroy all
> partitions on the original drive. 
An internet search for "convert MBR to GPT" yields many results,
including some from authoritative sources including Microsoft and Dell.
Some of them even have "without data loss" in the page title.
I myself have done this at least twice in 5 years with no data loss,
using the 'gdisk' utility (man 8 gdisk) in Fedora.
The conversion is particularly easy when the MBR partitions
do not cover the first and last 1MB of the drive,
which has been a prevalent practice for many years.

[Vitaly Zaitsev]

On 14/04/2022 15:31, John Reiser wrote:
>  Some of them even have "without data loss" in the page
> title.  
Without moving data to another physical drive this operation is too 
dangerous.

I tried on my testing VM and lost all data from that VM. Restored snapshot.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Martin Jackson]

In many industrial and retail use cases, 10 years is the low end. 3-5 years is an
accounting timeline (for depreciation) not necessarily the useful life of the asset. If
the asset can be used after it’s done depreciating that is a bonus for the company using
it.

Thanks,

>  On Apr 14, 2022, at 7:24 AM, Jóhann B. Guðmundsson
> <johannbg(a)gmail.com&gt; wrote:
>  
>  On 14.4.2022 11:42, Kevin Kofler via devel wrote:
> > Jóhann B. Guðmundsson wrote:
> > 
> >> For example EU has regulation that requires vendors to have spare parts
> >> available for 7–10 years after date of manufacturing so it makes sense
> >> for the project to support hw no longer than a decade from the date of
> >> it's manufacturing. ( which makes the oldest hw being support being
> >> manufactured in 2012 ) and every process,workflows and decision being
> >> bound by that.
> > Lack of availability of original spare parts does not mean that the hardware
> > suddenly magically stops working for everybody.
> > 
>  No but it does mean that they cant run indefinitely
>  
>  And there needs to be a number on this to adjust users expectation and 10 years is a
> reasonable number from a business, parts and recycle/re-use availability,
>  
>  What is unreasonable is to be expecting that it's supported indefinitely from OS and
> or HW vendors.
>  
>  JBG
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[John Reiser]

On 4/14/22 07:07, Vitaly Zaitsev via devel wrote:
>  On 14/04/2022 15:31, John Reiser wrote:
> > Some of them even have "without data loss" in the page title. 
>  
>  Without moving data to another physical drive this operation is too dangerous.
>  
>  I tried on my testing VM and lost all data from that VM. Restored snapshot. 
Please show what "sudo fdisk $DEVICE_NAME" says for the 'p' (print)
command (then 'q' to quit),
both before and after the attempted conversion.

[Ralf Corsépius]

Am 14.04.22 um 13:39 schrieb Kevin Kofler via devel:
>  Ralf Corsépius wrote:
> > I do not agree with this statement.  Like previous "Legacy SIGs" this is
> > a red herring to obfuscate RHATs lack of disinterest with topics, which
> > do not match into their business objectives.
>  
>  I am also worried that this is just a delayed retirement, as it was for 32-
>  bit i686, where the SIG was very quickly declared a failure, without even
>  being given time to organize. 
IMO, the 32bit "retirement" never was a serious "retirement" nor a 
serious attempt "to pass it to the community", either. Some people will 
find this rude, but I perceived as a long term planned assassination!

Ralf

[Hans de Goede]

Hi David,

On 4/13/22 21:27, David Cantrell wrote:
>  On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 4/13/22 18:07, David Cantrell wrote:
> >> On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
> >>> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
> >>> <dcantrell(a)redhat.com&gt; wrote:
> >>>> The core issue still comes down to having resources to continue
> >>>> maintaining
> >>>> BIOS boot support in Fedora and so far no one has come forward to work
> >>>> on
> >>>> that.
> >>>
> >>> It's not true, although you can be forgiven for missing it in such a
> massive
> >>> thread. Hans proposed to start a BIOS SIG to handle this. This seems like a
> >>> very credible proposal.
> >>
> >> Ah, yes.  I do remember the post from Hans, but thought he was more outlining
> >> how a Legacy BIOS SIG could work and what would need to happen rather than
> >> volunteering to set one up and do that.  But I went back and reread that post
> >> and yes, he did volunteer to do just that.
> >
> > Correct.
> >
> >> If a video call happens to discuss this feature proposal, ensure Hans can
> >> attend.
> >
> > FWIW, ATM I think everything which can be said about
> > this has been said and I'm not sure if having a video
> > call about this will add anything new.
>  
>  Agreed.
>  
> > As for setting up the SIG if necessary, my plan is to
> > try to keep the SIG lite weight on the process side
> > and focus on the practical things.
> >
> > What I envision for the SIG is:
> >
> > 1. I'm not sure if it is possible to setup group ownership
> > of pkgs in pagure? So to keep things simple the few packages which
> > are only necessary for BIOS boot can be handed over to me and then
> > I'll just add other people willing to help out as co-maintainers.
> >
> > 2. Setup a mailinglist for this and have that in bugzilla + PR
> > Cc for all the relevant packages.
> >
> > 3. Have people from the SIG regularly test Fedora N and
> > Fedora N + 1 (after branching) on machines which only support
> > BIOS booting and file bugs (if any) + report the results to
> > the mailinglist.
> >
> > 4. Have people from the SIG try to regularly do bugzilla
> > triage of relevant packages.
> >
> > And I would also like to have a discussion about splitting
> > the BIOS boot grub bits out into a separate src.rpm
> > (using the same Source0 as the main grub) so that this can
> > be build by the SIG without needing help from the bootloader
> > team (the main grub package can only be built by a few people
> > because of secureboot signing). The idea is to avoiding
> > bottlenecking on the bootloader team when some BIOS boot bugs
> > in grub need to be fixed, quoting from my original email about
> > this:
> >
> > """
> > I've been thinking about how this could be done for grub; also
> > because of the issue that the EFI builds of grub need to be
> > signed with Fedora's secure boot keys, which means only a few
> > people can do grub2 builds atm.
> >
> > One option which I think we should consider is sticking with
> > a single downstream git fork (until we have managed to get
> > everything we need upstream), so stick with:
> >
> > https://github.com/rhboot/grub2/
> >
> > As the Source0 provider for the packages and then next to:
> >
> > https://src.fedoraproject.org/rpms/grub2
> >
> > Add a:
> >
> > https://src.fedoraproject.org/rpms/grub2-bios
> >
> > And moving the build of all sub-packages which are
> > only necessary for BIOS support to the second src.rpm.
> >
> > This way the Legacy BIOS SIG could maintain
> > the grub2-bios src.rpm (and binary pkgs it builds).
> > The SIG _must_ then of course still submit pull-reqs to:
> > https://github.com/rhboot/grub2/ for any changes.
> >
> > But in case of e.g. a beta blocking BIOS only bug they
> > could solve that with a patch in the src.rpm and kickof
> > a build right away without blocking on the bootloader
> > team and thus without causing a spike in
> > work-pressure/load for the bootloader team.
> >
> > And then once the pull-req is merged (possibly
> > a revised version of it) the next build of
> > the grub2-bios src.rpm can pull in the new Source0
> > and drop its local changes (IOW grub2-bios _must_
> > not become a separate fork).
> > """
>  
>  OK, given this proposal, I'd like the original change proposal amended to
>  essentially say "transfer legacy BIOS boot support to newly formed Legacy BIOS
>  SIG" or something like that.  The logistics at that point can be sorted out as
>  the SIG sees fit.  I'd like to see the original proposal advance forward and
>  this gives a plan for the legacy BIOS piece. 
TBH I'm not sure if that is the direction in which the proposal owner
(Robbie) wants to go, Robbie ?

>  Can you followup with the proposal owners to make that amendment?
I've send Robbie an offlist email asking him to weigh in here.

Regards,

Hans

[Hans de Goede]

Hi Michel,

On 4/13/22 22:29, Michel Alexandre Salim wrote:
>  On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
> > Hi,
> >
> >
> > 1. I'm not sure if it is possible to setup group ownership
> > of pkgs in pagure? So to keep things simple the few packages which
> > are only necessary for BIOS boot can be handed over to me and then
> > I'll just add other people willing to help out as co-maintainers.
> >
>  yup, Python, Rust, and Go SIG does this all the time
>  
> > 2. Setup a mailinglist for this and have that in bugzilla + PR
> > Cc for all the relevant packages.
> >
>  The group will get emailed just like a normal maintainer, IIRC. Someone
>  will need to register that group's email in Bugzilla just like a normal
>  account 
Interesting, so how does this work. I just realized that to allow
adding a list to the Cc in pagure (src.fedoraproject.org) it probably
needs a FAS account too and then log in with that account and then
hit the "watch" button ?

So does this require creating a "fake" FAS account for the SIG ?

So the steps would be:

1. Request mailinglist
2. Create FAS account using mailinglist address as email 
3. Create bugzilla account using mailinglist address as email

?

All I can find on this is:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_encouraging_comaint...

Which does not describe haivng actual groups at all ?

And I don't see how I can put the mailinglist in the Cc
for bugs + PRs without creating a FAS account for it ?


Regards,

Hans

[Hans de Goede]

Hi,

On 4/13/22 23:11, Matthew Miller wrote:
>  On Wed, Apr 13, 2022 at 12:56:11PM -0700, Kevin Fenzi wrote:
> > If that proves acceptable for change owners here that would perhaps take
> > care of the short term problem. What about longer term though? Would the
> > thought be that the BIOS sig would remain around for the forseeable
> > future maintaining BIOS boot? Or would there be some kind of roadmap to
> > retirement?
>  
>  I think it would make sense for the group to be set up with with some sort
>  of "retirement becomes the default if the SIG stops being active" policy. I
>  mean, not as a surprise, but so the situation is clear. 
That is fair, although I hope that if the SIG runs out of steam for this,
that at least it will still have enough life in it to send out a proper
notice about BIOS boot support is really going away.

Regards,

Hans

[Fabio Valentini]

On Thu, Apr 14, 2022 at 5:09 PM Hans de Goede <hdegoede(a)redhat.com&gt; wrote:
>  Hi Michel,
>
>  On 4/13/22 22:29, Michel Alexandre Salim wrote:
>  > On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
>  >> Hi,
>  >>
>  >>
>  >> 1. I'm not sure if it is possible to setup group ownership
>  >> of pkgs in pagure? So to keep things simple the few packages which
>  >> are only necessary for BIOS boot can be handed over to me and then
>  >> I'll just add other people willing to help out as co-maintainers.
>  >>
>  > yup, Python, Rust, and Go SIG does this all the time
>  >
>  >> 2. Setup a mailinglist for this and have that in bugzilla + PR
>  >> Cc for all the relevant packages.
>  >>
>  > The group will get emailed just like a normal maintainer, IIRC. Someone
>  > will need to register that group's email in Bugzilla just like a normal
>  > account
>
>  Interesting, so how does this work. I just realized that to allow
>  adding a list to the Cc in pagure (src.fedoraproject.org) it probably
>  needs a FAS account too and then log in with that account and then
>  hit the "watch" button ? 
No, that's not how this usually works. The steps would be something like:

1. request a FAS dist-git group (not a fake-group user, but an actual group!)
2. request a mailing list for this group
3. create a bugzilla account, using the email address of the mailing list
4. set the bugzilla account of the FAS group to be the address of the
mailing list

This is what we did for the Rust SIG, and the - now defunct -
Stewardship SIG and Java Maintainers SIG:
https://pagure.io/fedora-infrastructure/issue/7638
https://pagure.io/fedora-infrastructure/issue/8902

Fabio

[Jóhann B. Guðmundsson]

On 14.4.2022 13:09, Ben Beasley wrote:
>  For desktop-class hardware, the parts that are most likely to fail 
>  around the decade mark are storage drives, power supplies, and perhaps 
>  fans. All of these are fully standardized and in plentiful supply; 
>  there is no reason that first-party hardware vendor support should be 
>  required to keep old desktop systems in service. 

We need to actually see some real hard data involving those fail parts 
from the manufactures themselves and or official repair shops since 
there are plethora of "refurbished" hw out there ranging from "cosmetic 
imperfections" to outright "motherboard replacements".  I've experience

and seen plethora of spectacular computer failures as part of my dayjob 
and in my own hw.


>  Dropping support for old hardware in Fedora should always be based on 
>  the costs and benefits, not on a rigid planned lifecycle. 

Well here's the thing this is one of these reoccurring long threaded 
discussion ( which means they are stuck in status quo ) that happen 
every once in a while, back in the day it used to be Alan Cox that was 
advocating for lifetimes support of steam powered devices, today the 
dialog involves deprecating legacy bios.

It should be quite apparent prevent the hw support lifecycle dialog from 
ever occurring again we need a rigid planned supported hw lifecycle.

That can be 10 years project wide or simply something that each WG 
tailors for their own target audience ( shorter, longer that's for them 
to decide since they should be doing all the work involving their 
"products" and their maintenance ) but as I said we need a rigid planned 
supported hw lifecycle, leaving this things are one more time just means 
that we will have this dialog again further down the line.


JBG

[Jóhann B. Guðmundsson]

On 14.4.2022 14:07, Martin Jackson wrote:
>  In many industrial and retail use cases, 10 years is the low end. 3-5
> years is an accounting timeline (for depreciation) not necessarily the useful life of the
> asset. If the asset can be used after it’s done depreciating that is a bonus for the
> company using it. 

HW security is one reason the companies are replacing their hw after 3-5 
years and in those cases the assets being deprecated are removed from 
the premise.


JBG

[Vitaly Zaitsev]

On 14/04/2022 16:21, John Reiser wrote:
>  Please show what "sudo fdisk $DEVICE_NAME" says for the
> 'p' (print) 
>  command (then 'q' to quit),
>  both before and after the attempted conversion. 
I no longer have legacy BIOS configurations. VMs have been reinstalled 
from scratch after trying to convert them.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Peter Boy]

>  Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson
> <johannbg(a)gmail.com&gt;:
>  
>  It should be quite apparent prevent the hw support lifecycle dialog from ever occurring
> again we need a rigid planned supported hw lifecycle.
>   
Again, the legacy BIOS discussion is not about hardware, as implied by the name. It is
software and support and management software infrastructure.

[Ben Beasley]

I’m not talking about refurbished parts or new old stock. I’m talking about the brand-new
SATA HDDs and SSDs, ATX power supplies, case fans, and other components that are
backwards-compatible in systems pushing twenty years old (SATA) or older (PSUs, fans).
Maybe I misunderstand, but your argument seems to be based on the idea that all
replacement parts are custom designs tied to OEM support policies rather than commodities
based on long-lived standards.

It also feels like this is an argument in favor of intentionally forcing people to retire
old hardware “for their own good” because it is too unreliable or hard to fix. That isn’t
a goal of this Change as far as I can tell, and if you are in fact suggesting that removal
of hardware support should be an objective rather than an unfortunate necessity based on
limited resources, I don’t think you’ll find much community support for that position.

On Thu, Apr 14, 2022, at 11:33 AM, Jóhann B. Guðmundsson wrote:
> On 14.4.2022 13:09, Ben Beasley wrote:
>> For desktop-class hardware, the parts that are most likely to fail around the
decade mark are storage drives, power supplies, and perhaps fans. All of these are fully
standardized and in plentiful supply; there is no reason that first-party hardware vendor
support should be required to keep old desktop systems in service. 
>
>
> We need to actually see some real hard data involving those fail parts 
> from the manufactures themselves and or official repair shops since 
> there are plethora of "refurbished" hw out there ranging from
"cosmetic 
> imperfections" to outright "motherboard replacements".  I've
experience 
> and seen plethora of spectacular computer failures as part of my dayjob 
> and in my own hw.
>
>
>
>> 
>> Dropping support for old hardware in Fedora should always be based on the costs
and benefits, not on a rigid planned lifecycle. 
>
>
> Well here's the thing this is one of these reoccurring long threaded 
> discussion ( which means they are stuck in status quo ) that happen 
> every once in a while, back in the day it used to be Alan Cox that was 
> advocating for lifetimes support of steam powered devices, today the 
> dialog involves deprecating legacy bios. 
>
> It should be quite apparent prevent the hw support lifecycle dialog 
> from ever occurring again we need a rigid planned supported hw 
> lifecycle.
>
> That can be 10 years project wide or simply something that each WG 
> tailors for their own target audience ( shorter, longer that's for them 
> to decide since they should be doing all the work involving their 
> "products" and their maintenance ) but as I said we need a rigid 
> planned supported hw lifecycle, leaving this things are one more time 
> just means that we will have this dialog again further down the line.
>
>
>
> JBG
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

[Robbie Harwood]

Hans de Goede <hdegoede(a)redhat.com&gt; writes:

>  On 4/13/22 21:27, David Cantrell wrote:
>
> > OK, given this proposal, I'd like the original change proposal
> > amended to essentially say "transfer legacy BIOS boot support to
> > newly formed Legacy BIOS SIG" or something like that.  The logistics
> > at that point can be sorted out as the SIG sees fit.  I'd like to see
> > the original proposal advance forward and this gives a plan for the
> > legacy BIOS piece.
>
>  TBH I'm not sure if that is the direction in which the proposal owner
>  (Robbie) wants to go, Robbie ? 
More complicated than that.  As alluded to elsewhere in the thread, a
SIG doesn't actually require a change proposal (
https://fedoraproject.org/wiki/Creating_a_Fedora_SIG ) and I'd feel
weird proposing the creation of a SIG that I'm not going to participate
in.  I don't oppose others stepping forward if they wish.

Regarding the change proposal itself, there seems to be consensus that
legacy bios booting will be going away "eventually", even if for my
purposes "eventually" means "we have this mudslinging again in x
releases".  Absent a formal date or even consensus around what
"deprecation" means, I'm not sure what purpose a revised/new proposal
would serve at this juncture.

>  I've send Robbie an offlist email asking him to weigh in here.
My pronouns are they/them.

Be well,
--Robbie

[Martin Jackson]

It happens that way in some places but not everywhere. I believe someone earlier mentioned
how this whole discussion is security theater - some companies know this to be true and
have fiscal policies that reflect that.

I have direct experience working for a large organization where 3-5 years was more a
guideline than a rule. Please be aware of that, is all I am asking here. 7 years is common
and some assets I saw in use for well over 10. Hardware security is a factor but by no
means the overriding one.

Thanks,

>  On Apr 14, 2022, at 10:47 AM, Jóhann B. Guðmundsson
> <johannbg(a)gmail.com&gt; wrote:
>  
>  On 14.4.2022 14:07, Martin Jackson wrote:
> > In many industrial and retail use cases, 10 years is the low end. 3-5 years is an
> accounting timeline (for depreciation) not necessarily the useful life of the asset. If
> the asset can be used after it’s done depreciating that is a bonus for the company using
> it.
>  
>  
>  HW security is one reason the companies are replacing their hw after 3-5 years and in
> those cases the assets being deprecated are removed from the premise.
>  
>  
>  JBG
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Jóhann B. Guðmundsson]

On 14.4.2022 15:53, Peter Boy wrote:
> > Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson <johannbg(a)gmail.com&gt;:
> >
> > It should be quite apparent prevent the hw support lifecycle dialog from ever
> occurring again we need a rigid planned supported hw lifecycle.
> >
>  Again, the legacy BIOS discussion is not about hardware, as implied by the name. It is
> software and support and management software infrastructure. 

Bios is a software that is directly tied to hw lifecycle from vendors so 
it most certainly is (in)directly related to hw support discussion in 
Fedora.

Then there is the fact that clinging to legacy bios is working against 
Fedora's own foundation "First" in which is stated "Fedora always aims

to provide the future, first".


JBG


JBG

[Gary Buhrmaster]

On Thu, Apr 14, 2022 at 2:08 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 14/04/2022 15:31, John Reiser wrote:
>  > Some of them even have "without data loss" in the page title.
>
>  Without moving data to another physical drive this operation is too
>  dangerous.
>
>  I tried on my testing VM and lost all data from that VM. Restored snapshot. 
There are certainly cases where this can happen
given the power of the tools that can be used.

There are also cases where it has been shown
to have worked without issue (if one follows all
the steps).

Having a backup (and testing it) before one
modifies your disk partition is certainly one of
the recommended steps.

Given that one is far more likely to report the
failures than the successes, there is no way to
draw any real conclusion about how many
failures and successes there are, and their
causes, if you are one of those that lost their
system you tend to get a strong opinion.

[Robbie Harwood]

Hans de Goede <hdegoede(a)redhat.com&gt; writes:

>  What I envision for the SIG is:
>
>  1. I'm not sure if it is possible to setup group ownership
>  of pkgs in pagure? So to keep things simple the few packages which
>  are only necessary for BIOS boot can be handed over to me and then
>  I'll just add other people willing to help out as co-maintainers. 
As I've mentioned multiple times elsewhere, this isn't about packages,
and I don't think it's helpful to think in terms of them.

>  And I would also like to have a discussion about splitting
>  the BIOS boot grub bits out into a separate src.rpm
>  (using the same Source0 as the main grub) so that this can
>  be build by the SIG without needing help from the bootloader
>  team (the main grub package can only be built by a few people
>  because of secureboot signing). The idea is to avoiding
>  bottlenecking on the bootloader team when some BIOS boot bugs
>  in grub need to be fixed, quoting from my original email about
>  this: 
Trying to avoid re-hashing our lengthy off-list conversation, here are
some thoughts (mine and other interested parties's):

At minimum, we need a Legacy BIOS SIG to provide:

- a "place" to assign bugs (e.g., email address)
- a means to fix issues

By default, we understand the former to be the SIG's email address, and
the latter to be PRs to dist-git of relevant packages.

The overall goal of the SIG needs to be to reduce load on existing
bootloader contributors.  If it is not doing this, it needs to be
dissolved.

## SIG package maintenance

If the SIG wants to maintain any BIOS-only packages, that's up to them.
Assuming Brian's change to use grub2 instead of syslinux on legacy
install media ( https://github.com/weldr/lorax/pull/1226 ), the only
other packages in question here would be those to support VESA/fbdev:

- xorg-x11-drv-vesa
- xorg-x11-drv-fbdev
- xorg-x11-server-Xorg
- syslinux

## Fedora deliverables

Given there is consensus that legacy BIOS is on its way out, we think
Fedora release criteria in this area should be re-evaluated.  Not only
does support change from "fully supported" to "best effort", but we
should re-evaluate what is/isn't release blocking, and probably clarify
who owns what parts.

## grub2

By default, the Legacy SIG is expected to perform contributions in the
form of triage and PRs.  Normal “upstream first” rules apply here (i.e.,
send it wherever possible, otherwise send to the downstream rhboot
repo).

Current grub2 maintainers consider splitting the package (probably grub2
and grub2-pc, to match current naming, or grub2-legacy or something)
undesirable for a number of reasons.  A nonexhaustive list of what would
need to be satisfactorily resolved before a split could considered:

- There needs to be a primary (and probably secondary) package owner
  from the SIG as a prerequisite for a new bugzilla component.

- Everything in grub2-common, grub2-tools, and grub2-tools-extra is
  available on both UEFI and legacy.  In most cases, the content is in
  fact shared: one file works on both.

- The new grub2-bios is secondary to the main grub2 package, which means
  that the Legacy SIG is responsible for not conflicting with any grub2
  subpackage, and nothing in grub2 can depend on anything in the legacy
  package.

- More generally, problems with the shared core can and will manifest
  primarily on one platform.  Bugzilla ping-pong needs to not be played.

- Feature incompatibilities can and will occur.  (Maybe this is okay, or
  just the Legacy SIG's responsibility to sort out in all cases.)

- Current maintainers do not have much capacity for mentoring, and since
  the point is to be rid of legacy, we can't help much at all with
  bugfixes.

Be well,
--Robbie

[Chris Adams]

Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
>  Given there is consensus that legacy BIOS is on its way out 
I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out, but it
doesn't seem that it is true across the board in VM environments.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Peter Boy]

>  Am 14.04.2022 um 20:20 schrieb Chris Adams
> <linux(a)cmadams.net&gt;:
>  
>  Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
> > Given there is consensus that legacy BIOS is on its way out
>  
>  I don't think this statement is true, unless Fedora doesn't want to be
>  considered for a bunch of popular VM hosts (e.g. Linode and such) that
>  have no stated plans to support UEFI. 
1++


>  Maybe "legacy BIOS on physical hardware" is on its way out,
> but it
>  doesn't seem that it is true across the board in VM environments. 
That’s maybe true for desktops, but in the server world any server needs to be able to do
bios boot, because of the data center requirements.

[Hans de Goede]

Hi Robbie,

On 4/14/22 20:02, Robbie Harwood wrote:
>  Hans de Goede <hdegoede(a)redhat.com&gt; writes:
>  
> > What I envision for the SIG is:
> >
> > 1. I'm not sure if it is possible to setup group ownership
> > of pkgs in pagure? So to keep things simple the few packages which
> > are only necessary for BIOS boot can be handed over to me and then
> > I'll just add other people willing to help out as co-maintainers.
>  
>  As I've mentioned multiple times elsewhere, this isn't about packages,
>  and I don't think it's helpful to think in terms of them.
>  
> > And I would also like to have a discussion about splitting
> > the BIOS boot grub bits out into a separate src.rpm
> > (using the same Source0 as the main grub) so that this can
> > be build by the SIG without needing help from the bootloader
> > team (the main grub package can only be built by a few people
> > because of secureboot signing). The idea is to avoiding
> > bottlenecking on the bootloader team when some BIOS boot bugs
> > in grub need to be fixed, quoting from my original email about
> > this:
>  
>  Trying to avoid re-hashing our lengthy off-list conversation, here are
>  some thoughts (mine and other interested parties's):
>  
>  At minimum, we need a Legacy BIOS SIG to provide:
>  
>  - a "place" to assign bugs (e.g., email address)
>  - a means to fix issues
>  
>  By default, we understand the former to be the SIG's email address, and
>  the latter to be PRs to dist-git of relevant packages.
>  
>  The overall goal of the SIG needs to be to reduce load on existing
>  bootloader contributors. 
Ack I agree that bugzilla triage of BIOS boot bugs +
fixing them once identified needs to be the main focus
of the SIG.

That and regularly testing N + 1 boot media BIOS booting
to catch any regressions early on.

>  If it is not doing this, it needs to be
>  dissolved.
>  
>  ## SIG package maintenance
>  
>  If the SIG wants to maintain any BIOS-only packages, that's up to them.
>  Assuming Brian's change to use grub2 instead of syslinux on legacy
>  install media ( https://github.com/weldr/lorax/pull/1226 ), the only
>  other packages in question here would be those to support VESA/fbdev:
>  
>  - xorg-x11-drv-vesa
>  - xorg-x11-drv-fbdev
>  - xorg-x11-server-Xorg 
I personally do not believe that it will be necessary to keep
maintaining VESA support, I agree that without legacy BIOS
support it definitely is not needed though. I believe that ajax
has submitted a separate change proposal for this, so this is
best discussed there.

>  - syslinux 
As you say it looks like this one may no longer be necessary and
otherwise the SIG can pick it up.

>  ## Fedora deliverables
>  
>  Given there is consensus that legacy BIOS is on its way out, we think
>  Fedora release criteria in this area should be re-evaluated.  Not only
>  does support change from "fully supported" to "best effort", but we
>  should re-evaluate what is/isn't release blocking, and probably clarify
>  who owns what parts. 
Given what the server product folks have indicated that BIOS
boot support is quite important for them I'm not sure if changing the
release criteria is in order. I do agree that any blocker bugs related
to legacy BIOS booting should be assigned to; and taken care of by
the legacy BIOS boot SIG.

>  ## grub2
>  
>  By default, the Legacy SIG is expected to perform contributions in the
>  form of triage and PRs.  Normal “upstream first” rules apply here (i.e.,
>  send it wherever possible, otherwise send to the downstream rhboot
>  repo).
>  
>  Current grub2 maintainers consider splitting the package (probably grub2
>  and grub2-pc, to match current naming, or grub2-legacy or something)
>  undesirable for a number of reasons.  A nonexhaustive list of what would
>  need to be satisfactorily resolved before a split could considered:
>  
>  - There needs to be a primary (and probably secondary) package owner
>    from the SIG as a prerequisite for a new bugzilla component.
>  
>  - Everything in grub2-common, grub2-tools, and grub2-tools-extra is
>    available on both UEFI and legacy.  In most cases, the content is in
>    fact shared: one file works on both.
>  
>  - The new grub2-bios is secondary to the main grub2 package, which means
>    that the Legacy SIG is responsible for not conflicting with any grub2
>    subpackage, and nothing in grub2 can depend on anything in the legacy
>    package.
>  
>  - More generally, problems with the shared core can and will manifest
>    primarily on one platform.  Bugzilla ping-pong needs to not be played.
>  
>  - Feature incompatibilities can and will occur.  (Maybe this is okay, or
>    just the Legacy SIG's responsibility to sort out in all cases.)
>  
>  - Current maintainers do not have much capacity for mentoring, and since
>    the point is to be rid of legacy, we can't help much at all with
>    bugfixes. 
Ok, if you prefer going through PR-s then lets give that a try,
I'm a bit worried that always needing to go through the bootloader team
may get in the way of expedient fixing of BIOS related bugs and that
this may cause extra work for the bootloader team at inconvenient times.

But lets see how this goes, we can always reconsider this later.

Regards,

Hans

[Peter Boy]

That’s a step into the right direction, but needs some corrections:

>  Am 14.04.2022 um 20:02 schrieb Robbie Harwood
> <rharwood(a)redhat.com&gt;:
>  
>  
>  The overall goal of the SIG needs to be to reduce load on existing
>  bootloader contributors.  If it is not doing this, it needs to be
>  dissolved. 
The first overall goal is to maintain bios boot and by doing this to expand the existing
boot loader contributors.
>  
>  ## SIG package maintenance
>  
>  If the SIG wants to maintain any BIOS-only packages, that's up to them.
>  Assuming Brian's change to use grub2 instead of syslinux on legacy
>  install media ( https://github.com/weldr/lorax/pull/1226 ), the only
>  other packages in question here would be those to support VESA/fbdev:
>  
>  - xorg-x11-drv-vesa
>  - xorg-x11-drv-fbdev
>  - xorg-x11-server-Xorg 
Somewhere else I read these are going to vanish because nothing is still using it?

>  - syslinux
>  
>  ## Fedora deliverables
>  
>  Given there is consensus that legacy BIOS is on its way out, we think
>  Fedora release criteria in this area should be re-evaluated.  Not only
>  does support change from "fully supported" to "best effort", but we
>  should re-evaluate what is/isn't release blocking, and probably clarify
>  who owns what parts. 
The goal is not to touch or modify the release criteria and blocking issues


>  
>  ## grub2
>  
>  By default, the Legacy SIG is expected to perform contributions in the
>  form of triage and PRs.  Normal “upstream first” rules apply here (i.e.,
>  send it wherever possible, otherwise send to the downstream rhboot
>  repo).
>  
>  Current grub2 maintainers consider splitting the package (probably grub2
>  and grub2-pc, to match current naming, or grub2-legacy or something)
>  undesirable for a number of reasons.  A nonexhaustive list of what would
>  need to be satisfactorily resolved before a split could considered:
>  
>  - There needs to be a primary (and probably secondary) package owner
>   from the SIG as a prerequisite for a new bugzilla component.
>  
>  - Everything in grub2-common, grub2-tools, and grub2-tools-extra is
>   available on both UEFI and legacy.  In most cases, the content is in
>   fact shared: one file works on both.
>  
>  - The new grub2-bios is secondary to the main grub2 package, which means
>   that the Legacy SIG is responsible for not conflicting with any grub2
>   subpackage, and nothing in grub2 can depend on anything in the legacy
>   package. 
Both groups cooperate in a way that best fits the goal to keep Fedora able to boot from
any of the supported media (for a probably limited time, e.g. 5 years)


>  
>  - More generally, problems with the shared core can and will manifest
>   primarily on one platform.   
The maintainer of that platform lead the problem solving.


>  - Feature incompatibilities can and will occur.  (Maybe this is okay,
> or
>   just the Legacy SIG's responsibility to sort out in all cases.) 
Feature incompatibilities will get resolved by the lead of the  part that is affected most
with support from each other.

It is the common responsibility to resolve issues. Responsibility ping-pong needs to be
avoided. 

>  - Current maintainers do not have much capacity for mentoring, and
> since
>   the point is to be rid of legacy, we can't help much at all with
>   bugfixes. 
In the initial phase, the "Bios-Boot-Maintainers" receive a detailed briefing to
ensure their working preconditions.

[Neal Gompa]

On Thu, Apr 14, 2022 at 2:29 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  > Am 14.04.2022 um 20:20 schrieb Chris Adams <linux(a)cmadams.net&gt;:
>  >
>  > Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
>  >> Given there is consensus that legacy BIOS is on its way out
>  >
>  > I don't think this statement is true, unless Fedora doesn't want to be
>  > considered for a bunch of popular VM hosts (e.g. Linode and such) that
>  > have no stated plans to support UEFI.
>
>  1++
>
>
>  > Maybe "legacy BIOS on physical hardware" is on its way out, but it
>  > doesn't seem that it is true across the board in VM environments.
>
>  That’s maybe true for desktops, but in the server world any server needs to be able to do
> bios boot, because of the data center requirements.
>  
This is not completely true for servers either. Proprietary BMCs like
iDRAC and iLO both have transitioned to UEFI in the past few years. At
least the first one I got my hands on that didn't mark EFI support as
experimental (and worked properly) was in 2016. Supermicro IPMI has
supported UEFI boot on most servers since about 2018, so it's
certainly in place in a number of places. The Redfish standard became
supported in EDK2 in 2019 as well.

Server adoption is definitely *much* slower than desktop adoption
because servers are much more expensive to deal with and replace. Not
to mention, Microsoft just didn't bother making it matter for Windows
Server certification until last year (even though Windows is a small
part of the market relative to Linux).

The tooling is there, it's just going to take the next decade to catch
up to desktops.



--
真実はいつも一つ！/ Always, there's only one truth!

[Justin Forbes]

On Thu, Apr 14, 2022 at 6:39 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Ralf Corsépius wrote:
>  > I do not agree with this statement.  Like previous "Legacy SIGs" this is
>  > a red herring to obfuscate RHATs lack of disinterest with topics, which
>  > do not match into their business objectives.
>
>  I am also worried that this is just a delayed retirement, as it was for 32-
>  bit i686, where the SIG was very quickly declared a failure, without even
>  being given time to organize. 
The i686 SIG was given multiple releases to organize. The original
proposal which triggered the SIG to form was for F27, the proposal to
finally kill it and declare the SIG inactive was F31.  But this is
different from the i686 kernel SIG in some critical ways.  First, the
rate of churn around the boot code is massively smaller than the churn
in kernel code. Second, it seemed that most of the people who showed
interest in the i686 SIG had little to no kernel experience, while
Hans and others interested should be capable of doing the work as long
as they are willing.  And lastly, many of the i686 issues which popped
up were issues which kept the kernel from building, so there was more
urgency around them.  While I don't have plans to participate in the
BIOS boot SIG, I do think it is in capable hands provided the people
who have commented interest in participating continue to do so.

Justin

> Still, it is better than retiring it immediately. But like you, I am worried
> that this is not really a long-term commitment and that people will be
> attempting to kill BIOS support again at even the smallest dent in SIG
> activity.
>
>         Kevin Kofler
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Matthew Miller]

On Thu, Apr 14, 2022 at 12:18:12PM +0000, JadoNena via devel wrote:
>  All of this discussion waves a red flag at us. 
[...]
>  But only a few people are talking about the real costs to users.
Please don't read too much into everything you see in big mailing list
threads like this, especially as you go into the their deep depths. We
absolutely do care about these things!


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Jóhann B. Guðmundsson]

On 14.4.2022 16:38, Ben Beasley wrote:
>  I’m not talking about refurbished parts or new old stock. I’m talking
> about the brand-new SATA HDDs and SSDs, ATX power supplies, case fans, and other
> components that are backwards-compatible in systems pushing twenty years old (SATA) or
> older (PSUs, fans). Maybe I misunderstand, but your argument seems to be based on the idea
> that all replacement parts are custom designs tied to OEM support policies rather than
> commodities based on long-lived standards. 
I'm talking about the entire hw range in the computer, every single 
component which can break not just the nuts and bolts on the computer 
case, or the PSU fans etc. ( It's interesting how you always avoid 
mentioning motherboard/GPU failures etc ).

As much as people may dislike it, the fact is those long lived standards 
have been replaced with a newer standards and not all replacement parts 
are backwards compatible like for example for a video device to work on 
a motherboard with a legacy BIOS, or in CSM mode, it needs a VGA option 
ROM to initialize the card.

Most video cards/IGPs for the last few years have dropped legacy BIOS 
support and only have UEFI ROMs ( which means they wont work on legacy 
bios or in CSM mode ) so we already are in an era when people are buying 
replacement parts which either needs to be old enough or legacy-friendly 
enough to work on that legacy hardware and as much as I dislike it, 
entering an era of vendor locked replacement parts ( Like AMD epyc CPU's 
getting locked to computer vendors. AMD epyc CPU's from Dell HW wont 
work on Lenovo HW and visa versa even if those are the exact same CPU 
models etc. )

Trying to support that legacy scenario where certain hw may or may not 
work is a nightmare for developers, support teams and Fedora since 
Fedora is not a distribution with a long term support, LTS distributions 
are better suited to support legacy hw then Fedora ever will.


JBG

[Jóhann B. Guðmundsson]

On 14.4.2022 18:20, Chris Adams wrote:
>  Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
> > Given there is consensus that legacy BIOS is on its way out
>  I don't think this statement is true, unless Fedora doesn't want to be
>  considered for a bunch of popular VM hosts (e.g. Linode and such) that
>  have no stated plans to support UEFI.
>
>  Maybe "legacy BIOS on physical hardware" is on its way out 

It's not an maybe, it is on it's way out either physically or simply via 
firmware update [1]

"In the bios, upgraded to 810 the option to enable legacy boot is greyed 
out"

So how do people propose the situation to be handled when firmware from 
vendors, disables the legacy boot option via firmware update.

Is Fedora supposed to block/blacklist those firmware updates via some 
plugin in lvfs based on user feedback when their legacy boot mode 
suddenly stops working or is it expected that upstream lvfs team looks 
into this or what?


JBG

1. 
https://forum-en.msi.com/index.php?threads/msi-pro-dp20z-5m-legacy-boot-h...

[Jóhann B. Guðmundsson]

On 14.4.2022 18:29, Peter Boy wrote:
> > Maybe "legacy BIOS on physical hardware" is on its way out, but it
> > doesn't seem that it is true across the board in VM environments.
>  That’s maybe true for desktops, but in the server world any server needs to be able to do
> bios boot, because of the data center requirements.
>  
Interesting I would assume that those data center requirements would 
make it a requirement for example to be using uefi's native http 
protocol to address the shortcomings of traditional (i)pxe, so which 
data center requirement are those and where can I find documentation 
about them?


JBG

[Nikolay Nikolov]

On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:
>  On 14.4.2022 18:20, Chris Adams wrote:
> > Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
> >> Given there is consensus that legacy BIOS is on its way out
> > I don't think this statement is true, unless Fedora doesn't want to be
> > considered for a bunch of popular VM hosts (e.g. Linode and such) that
> > have no stated plans to support UEFI.
> >
> > Maybe "legacy BIOS on physical hardware" is on its way out
>
>
>  It's not an maybe, it is on it's way out either physically or simply 
>  via firmware update [1]
>
>  "In the bios, upgraded to 810 the option to enable legacy boot is 
>  greyed out"
>
>  So how do people propose the situation to be handled when firmware 
>  from vendors, disables the legacy boot option via firmware update.
>
>  Is Fedora supposed to block/blacklist those firmware updates via some 
>  plugin in lvfs based on user feedback when their legacy boot mode 
>  suddenly stops working or is it expected that upstream lvfs team looks 
>  into this or what? 
Fedora doesn't install these updates. Users install these updates, when 
they have a problem, which they need to resolve. Most people never 
update their BIOS [1], because their system is working just fine. Only 
power users do, and they know how to read changelogs and how to backup 
their previous working BIOS. So, no, it's not Fedora's problem if a 
users installs a BIOS update that bricks their system, or renders it 
unbootable (for whatever reasons, doesn't matter whether they're related 
to legacy boot or not). We have no obligation to prevent that. The right 
approach to BIOS update is "don't do it, unless you have to". If it 
ain't broke, don't fix it. I've been burned so many times, due to buggy 
BIOS updates, most of them unrelated to legacy boot. We don't prevent 
BIOS updates that break UEFI or secure boot, or which brick the system, 
so why should we prevent BIOS updates that break legacy boot?

And besides, non-UEFI systems don't normally receive BIOS updates that 
break legacy boot, because legacy boot is the only boot option 
available, so what is your point, exactly?

If you want to deprecate legacy boot on new installs on UEFI-capable 
BIOS-es, that's another story. E.g. if the installer detects that the 
BIOS is modern (e.g. later than 2017-2018) and UEFI capable, but is 
running in legacy boot mode, it could prints a warning and suggest to 
the user to restart and turn off legacy boot from the BIOS setup. The 
installer promises better hardware support, firmware updates and happier 
times to the user if the operating system is installed in UEFI mode. 
Finally user decides whether to do that, or choose to continue on their 
own risk. That is totally reasonable, IMHO. But it is a completely 
different thing than dropping legacy BIOS support completely.


1. It is indeed still universally called BIOS, even though it's UEFI: 
https://www.asrock.com/support/BIOSIG.asp?cat=BIOS10

Best regards,

Nikolay

>
> JBG
>
> 1. 
>
https://forum-en.msi.com/index.php?threads/msi-pro-dp20z-5m-legacy-boot-h...
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

[Jóhann B. Guðmundsson]

On 14.4.2022 22:24, Nikolay Nikolov wrote:
>  On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:
> > On 14.4.2022 18:20, Chris Adams wrote:
> >> Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
> >>> Given there is consensus that legacy BIOS is on its way out
> >> I don't think this statement is true, unless Fedora doesn't want to be
> >> considered for a bunch of popular VM hosts (e.g. Linode and such) that
> >> have no stated plans to support UEFI.
> >>
> >> Maybe "legacy BIOS on physical hardware" is on its way out
> >
> >
> > It's not an maybe, it is on it's way out either physically or simply 
> > via firmware update [1]
> >
> > "In the bios, upgraded to 810 the option to enable legacy boot is 
> > greyed out"
> >
> > So how do people propose the situation to be handled when firmware 
> > from vendors, disables the legacy boot option via firmware update.
> >
> > Is Fedora supposed to block/blacklist those firmware updates via some 
> > plugin in lvfs based on user feedback when their legacy boot mode 
> > suddenly stops working or is it expected that upstream lvfs team 
> > looks into this or what?
>
>  Fedora doesn't install these updates. Users install these updates, 
>  when they have a problem 

In the past they did, today users ( including the novice ones ) update 
it as Gnome notifies them about available update just like they do when 
they receive anyother software update notification.


>  And besides, non-UEFI systems don't normally receive BIOS updates
> that 
>  break legacy boot, because legacy boot is the only boot option 
>  available, so what is your point, exactly? 

Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise 
the option to disable it would not be there ) in which the vendor 
himself seemingly decided to disable the legacy part of the bios via 
firmware update which highlight the fact that we somehow need to deal 
with that situation if we want to continue to support the legacy bios 
option.

How I have no clue, which is why I pointed at an potential lvfs plugin 
or the lvfs team.


JBG

[Nikolay Nikolov]

On 4/15/22 01:53, Jóhann B. Guðmundsson wrote:
>  On 14.4.2022 22:24, Nikolay Nikolov wrote:
> >
> > On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:
> >> On 14.4.2022 18:20, Chris Adams wrote:
> >>> Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
> >>>> Given there is consensus that legacy BIOS is on its way out
> >>> I don't think this statement is true, unless Fedora doesn't want to
> be
> >>> considered for a bunch of popular VM hosts (e.g. Linode and such) that
> >>> have no stated plans to support UEFI.
> >>>
> >>> Maybe "legacy BIOS on physical hardware" is on its way out
> >>
> >>
> >> It's not an maybe, it is on it's way out either physically or simply 
> >> via firmware update [1]
> >>
> >> "In the bios, upgraded to 810 the option to enable legacy boot is 
> >> greyed out"
> >>
> >> So how do people propose the situation to be handled when firmware 
> >> from vendors, disables the legacy boot option via firmware update.
> >>
> >> Is Fedora supposed to block/blacklist those firmware updates via 
> >> some plugin in lvfs based on user feedback when their legacy boot 
> >> mode suddenly stops working or is it expected that upstream lvfs 
> >> team looks into this or what?
> >
> > Fedora doesn't install these updates. Users install these updates, 
> > when they have a problem
>
>
>  In the past they did, today users ( including the novice ones ) update 
>  it as Gnome notifies them about available update just like they do 
>  when they receive anyother software update notification. 
Really? I didn't know that. At least on my computers, Gnome has never 
notified me about a BIOS update from my motherboard vendor. Besides, 
it's proprietary software, so I wouldn't expect Fedora to be offering it 
by default. Doesn't it need adding an extra software repository?

> > And besides, non-UEFI systems don't normally receive BIOS updates 
> > that break legacy boot, because legacy boot is the only boot option 
> > available, so what is your point, exactly?
>
>
>  Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise 
>  the option to disable it would not be there ) in which the vendor 
>  himself seemingly decided to disable the legacy part of the bios via 
>  firmware update which highlight the fact that we somehow need to deal 
>  with that situation if we want to continue to support the legacy bios 
>  option.
>
>  How I have no clue, which is why I pointed at an potential lvfs plugin 
>  or the lvfs team. 
I think we should check the BIOS date in the installer and deprecate (as 
in, print warnings to the user in the installer) legacy boot on newer 
systems (e.g. newer than 2017 or some other cutoff date, when we decide 
that UEFI becomes more stable), an by deprecate, I mean, show warnings 
to the user and suggest that they continue on their own risk. Of course, 
we should also check for virtual machines, like e.g. QEMU/SeaBIOS, that 
are known to be stable in legacy BIOS mode and not show the warning in 
them, even if the BIOS date is new (although SeaBIOS seems to use an old 
date - 06/23/99).

Nikolay
>
> JBG
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

[Kevin Kofler]

Jóhann B. Guðmundsson wrote:
>  Then there is the fact that clinging to legacy bios is working
> against
>  Fedora's own foundation "First" in which is stated "Fedora always
> aims
>  to provide the future, first". 
How is it against "First" to continue providing the future also for hardware 
of the past? "First" means that Fedora *delivers* the latest&greatest, not 
that it *requires* the latest&greatest. Doing the latter actually goes 
against the "Freedom" (where is my Freedom Zero, run the software as I 
wish?), "Features" (desupporting old hardware = removing a feature) and 
"Friends" (people dropping support for my hardware are not my friends!) 
foundations.

As I already pointed out once, continued support for old hardware does *not* 
preclude shipping the latest software first. You keep bringing up this false 
dichotomy. The repetition does not make it any truer.

        Kevin Kofler

[Kevin Kofler]

Jóhann B. Guðmundsson wrote:
>  Trying to support that legacy scenario where certain hw may or may
> not
>  work is a nightmare for developers, support teams and Fedora since
>  Fedora is not a distribution with a long term support, LTS distributions
>  are better suited to support legacy hw then Fedora ever will. 
Nobody is asking Fedora to provide support for fixing old hardware if it 
breaks. All we are asking for is for Fedora to continue running on old 
hardware that is *not* broken.

Some parts are hard to swap, others are easy. My soon 14-year-old notebook 
has a relatively new hard disk (standard SATA laptop/notebook HDD, thinner 
than the original one, but the screws hold it in the correct position, so 
that does not matter and actually improves cooling airflow) and power supply 
adapter (cheap generic universal power supply, one of the offered plugs is 
both physically and electrically compatible with my notebook). The old HDD 
might even have worked longer, I replaced it after the first failed sector, 
with a faster (7200 rpm instead of 5400 rpm) one with twice the capacity 
(512 GB instead of 256 GB, though, if I had waited a bit longer, I could 
have gotten an SSD of the same size instead for that price, but now I do not 
want to replace the storage again in that ancient notebook). The power 
supply adapter was the only thing I *had* to replace, as the old one had 
failed completely.

(And, realistically speaking, the HDD and the power supply are statistically 
among the parts most likely to fail to begin with.)

        Kevin Kofler

[Kevin Kofler]

Jóhann B. Guðmundsson wrote:
>  No but it does mean that they cant run indefinitely 
Only if the spare parts that are not available actually fail (and if you 
cannot find the spare parts through less official channels, such as buying 
another broken computer where the part you need is still working). And, as 
explained elsewhere in this thread, the parts most likely to fail can 
actually be replaced with generic replacements.

Also keep in mind that many Fedora users have one or two computers, not 
hundreds. That makes it much less likely to run into a hardware failure in a 
given time interval, and there is very little incentive to "fix" what is not 
broken.

>  And there needs to be a number on this to adjust users expectation
> and
>  10 years is a reasonable number from a business, parts and
>  recycle/re-use availability, 
10 years is *not* a reasonable number when a notebook still runs great after 
14 years.

>  What is unreasonable is to be expecting that it's supported
> indefinitely
>  from OS and or HW vendors. 
One of the reasons people use GNU/Linux is exactly to escape the hardware 
manufacturers' planned obsolescence treadmill.

        Kevin Kofler

[Jóhann B. Guðmundsson]

On 15.4.2022 00:38, Kevin Kofler via devel wrote:
>  Jóhann B. Guðmundsson wrote:
> > Trying to support that legacy scenario where certain hw may or may not
> > work is a nightmare for developers, support teams and Fedora since
> > Fedora is not a distribution with a long term support, LTS distributions
> > are better suited to support legacy hw then Fedora ever will.
>  Nobody is asking Fedora to provide support for fixing old hardware if it
>  breaks. All we are asking for is for Fedora to continue running on old
>  hardware that is *not* broken. 

Yes I got that it's the hw version of "if it builds let's ship it, even 
if upstream is dead" approach.

The thing is we could elimination so much of technical debt in Fedora if 
we would drop the legacy bios support and could move the distro quite a 
bit forward in coming releases if we did but from the looks of it, it 
seems to have been already decided to "form a sig" and drop this 
proposal so meh Fedora 40 then...


JBG

[Kevin Kofler]

Justin Forbes wrote:
>  The i686 SIG was given multiple releases to organize. The original
>  proposal which triggered the SIG to form was for F27, the proposal to
>  finally kill it and declare the SIG inactive was F31. 
But, the way I remember it, the SIG was declared inactive just because of 
*one* unfixed kernel bug (the primary platforms have hundreds) and perceived 
lack of mailing list activity (IIRC, the complaints were that there were too 
few messages, but that limit is arbitrary, and that the bug was not 
discussed on the mailing list, which is normal because that is what Bugzilla 
is for).

>  But this is different from the i686 kernel SIG in some critical ways.
But is this going to help, if the SIG will be held to unreasonable standards 
just to have an excuse to kill it at the next opportunity?

        Kevin Kofler

[Jóhann B. Guðmundsson]

On 14.4.2022 23:25, Nikolay Nikolov wrote:
>  On 4/15/22 01:53, Jóhann B. Guðmundsson wrote:
> > On 14.4.2022 22:24, Nikolay Nikolov wrote:
> >>
> >> On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:
> >>> On 14.4.2022 18:20, Chris Adams wrote:
> >>>> Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
> >>>>> Given there is consensus that legacy BIOS is on its way out
> >>>> I don't think this statement is true, unless Fedora doesn't want
>
> >>>> to be
> >>>> considered for a bunch of popular VM hosts (e.g. Linode and such) 
> >>>> that
> >>>> have no stated plans to support UEFI.
> >>>>
> >>>> Maybe "legacy BIOS on physical hardware" is on its way out
> >>>
> >>>
> >>> It's not an maybe, it is on it's way out either physically or 
> >>> simply via firmware update [1]
> >>>
> >>> "In the bios, upgraded to 810 the option to enable legacy boot is 
> >>> greyed out"
> >>>
> >>> So how do people propose the situation to be handled when firmware 
> >>> from vendors, disables the legacy boot option via firmware update.
> >>>
> >>> Is Fedora supposed to block/blacklist those firmware updates via 
> >>> some plugin in lvfs based on user feedback when their legacy boot 
> >>> mode suddenly stops working or is it expected that upstream lvfs 
> >>> team looks into this or what?
> >>
> >> Fedora doesn't install these updates. Users install these updates, 
> >> when they have a problem
> >
> >
> > In the past they did, today users ( including the novice ones ) 
> > update it as Gnome notifies them about available update just like 
> > they do when they receive anyother software update notification.
>
>  Really? I didn't know that. At least on my computers, Gnome has never 
>  notified me about a BIOS update from my motherboard vendor. Besides, 
>  it's proprietary software, so I wouldn't expect Fedora to be offering 
>  it by default. Doesn't it need adding an extra software repository? 

It's fwup/lvfs [1] and nope you dont need to jump through any additional 
hoops for that, it just work ( or it does not if the vendor is not part 
of lfvs ).


> >
> >
> >> And besides, non-UEFI systems don't normally receive BIOS updates 
> >> that break legacy boot, because legacy boot is the only boot option 
> >> available, so what is your point, exactly?
> >
> >
> > Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise 
> > the option to disable it would not be there ) in which the vendor 
> > himself seemingly decided to disable the legacy part of the bios via 
> > firmware update which highlight the fact that we somehow need to deal 
> > with that situation if we want to continue to support the legacy bios 
> > option.
> >
> > How I have no clue, which is why I pointed at an potential lvfs 
> > plugin or the lvfs team.
>
>  I think we should check the BIOS date in the installer and deprecate 
>  (as in, print warnings to the user in the installer) legacy boot on 
>  newer systems (e.g. newer than 2017 or some other cutoff date, when we 
>  decide that UEFI becomes more stable), an by deprecate, I mean, show 
>  warnings to the user and suggest that they continue on their own risk. 
>  Of course, we should also check for virtual machines, like e.g. 
>  QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not 
>  show the warning in them, even if the BIOS date is new (although 
>  SeaBIOS seems to use an old date - 06/23/99). 

That's something that needs to be worked out with the Anaconda team but 
I think Javier already provide the best path forward with regards to 
Anaconda when I started the dialog two years ago but for whatever reason 
that's not part of Robbie's proposal.


JBG

1. https://fwupd.org/

[Jóhann B. Guðmundsson]

On 15.4.2022 00:44, Kevin Kofler via devel wrote:
>  One of the reasons people use GNU/Linux is exactly to escape the
> hardware
>  manufacturers' planned obsolescence treadmill. 
True but that does not mean Fedora is the best distro for that + it 
looks like hw vendors are taking lessons from the Apple playbook and 
starting to vendor lock parts for their hw.


JBG

[Samuel Sieb]

On 4/14/22 15:53, Jóhann B. Guðmundsson wrote:
>  On 14.4.2022 22:24, Nikolay Nikolov wrote:
> >
> > On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:
> >> On 14.4.2022 18:20, Chris Adams wrote:
> >>> Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
> >>>> Given there is consensus that legacy BIOS is on its way out
> >>> I don't think this statement is true, unless Fedora doesn't want to
> be
> >>> considered for a bunch of popular VM hosts (e.g. Linode and such) that
> >>> have no stated plans to support UEFI.
> >>>
> >>> Maybe "legacy BIOS on physical hardware" is on its way out
> >>
> >>
> >> It's not an maybe, it is on it's way out either physically or simply 
> >> via firmware update [1]
> >>
> >> "In the bios, upgraded to 810 the option to enable legacy boot is 
> >> greyed out"
> >>
> >> So how do people propose the situation to be handled when firmware 
> >> from vendors, disables the legacy boot option via firmware update.
> >>
> >> Is Fedora supposed to block/blacklist those firmware updates via some 
> >> plugin in lvfs based on user feedback when their legacy boot mode 
> >> suddenly stops working or is it expected that upstream lvfs team 
> >> looks into this or what?
> >
> > Fedora doesn't install these updates. Users install these updates, 
> > when they have a problem
>  
>  
>  In the past they did, today users ( including the novice ones ) update 
>  it as Gnome notifies them about available update just like they do when 
>  they receive anyother software update notification. 
That only applies to a UEFI system, so it doesn't matter if legacy mode 
gets disabled by the update since it's already using UEFI to boot.

[Nikolay Nikolov]

On 4/15/22 04:01, Jóhann B. Guðmundsson wrote:
>  On 14.4.2022 23:25, Nikolay Nikolov wrote:
> >
> > On 4/15/22 01:53, Jóhann B. Guðmundsson wrote:
> >> On 14.4.2022 22:24, Nikolay Nikolov wrote:
> >>>
> >>> On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:
> >>>> On 14.4.2022 18:20, Chris Adams wrote:
> >>>>> Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
> >>>>>> Given there is consensus that legacy BIOS is on its way out
> >>>>> I don't think this statement is true, unless Fedora doesn't
> want 
> >>>>> to be
> >>>>> considered for a bunch of popular VM hosts (e.g. Linode and such) 
> >>>>> that
> >>>>> have no stated plans to support UEFI.
> >>>>>
> >>>>> Maybe "legacy BIOS on physical hardware" is on its way out
> >>>>
> >>>>
> >>>> It's not an maybe, it is on it's way out either physically or 
> >>>> simply via firmware update [1]
> >>>>
> >>>> "In the bios, upgraded to 810 the option to enable legacy boot is 
> >>>> greyed out"
> >>>>
> >>>> So how do people propose the situation to be handled when firmware 
> >>>> from vendors, disables the legacy boot option via firmware update.
> >>>>
> >>>> Is Fedora supposed to block/blacklist those firmware updates via 
> >>>> some plugin in lvfs based on user feedback when their legacy boot 
> >>>> mode suddenly stops working or is it expected that upstream lvfs 
> >>>> team looks into this or what?
> >>>
> >>> Fedora doesn't install these updates. Users install these updates, 
> >>> when they have a problem
> >>
> >>
> >> In the past they did, today users ( including the novice ones ) 
> >> update it as Gnome notifies them about available update just like 
> >> they do when they receive anyother software update notification.
> >
> > Really? I didn't know that. At least on my computers, Gnome has never 
> > notified me about a BIOS update from my motherboard vendor. Besides, 
> > it's proprietary software, so I wouldn't expect Fedora to be offering 
> > it by default. Doesn't it need adding an extra software repository?
>
>
>  It's fwup/lvfs [1] and nope you dont need to jump through any 
>  additional hoops for that, it just work ( or it does not if the vendor 
>  is not part of lfvs ).
>  
Oh, wow! Yeah, my new desktop has an ASRock motherboard and my laptop is 
an HP and, and while both vendors (HP and Asus) participate in lvfs, 
they don't seem to upload a lot of firmware updates (HP has uploaded 34 
firmware files, for comparison Dell has uploaded 2033 firmware files). 
But I'm still surprised that Fedora by default downloads and updates 
proprietary firmware, downloaded from the Internet. Btw, does this work 
in legacy boot mode as well? If I recall correctly, someone in the 2020 
thread mentioned that fwupd requires boot in UEFI mode, but I don't 
remember the exact details.
> >
> >>
> >>
> >>> And besides, non-UEFI systems don't normally receive BIOS updates 
> >>> that break legacy boot, because legacy boot is the only boot option 
> >>> available, so what is your point, exactly?
> >>
> >>
> >> Obviously this was for dual bios mode ( legacy and uefi ) ( 
> >> otherwise the option to disable it would not be there ) in which the 
> >> vendor himself seemingly decided to disable the legacy part of the 
> >> bios via firmware update which highlight the fact that we somehow 
> >> need to deal with that situation if we want to continue to support 
> >> the legacy bios option.
> >>
> >> How I have no clue, which is why I pointed at an potential lvfs 
> >> plugin or the lvfs team.
> >
> > I think we should check the BIOS date in the installer and deprecate 
> > (as in, print warnings to the user in the installer) legacy boot on 
> > newer systems (e.g. newer than 2017 or some other cutoff date, when 
> > we decide that UEFI becomes more stable), an by deprecate, I mean, 
> > show warnings to the user and suggest that they continue on their own 
> > risk. Of course, we should also check for virtual machines, like e.g. 
> > QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not 
> > show the warning in them, even if the BIOS date is new (although 
> > SeaBIOS seems to use an old date - 06/23/99).
>
>
>  That's something that needs to be worked out with the Anaconda team 
>  but I think Javier already provide the best path forward with regards 
>  to Anaconda when I started the dialog two years ago but for whatever 
>  reason that's not part of Robbie's proposal.
>  
What was Javier's proposal?

Best regards,

Nikolay

>  JBG
>
>  1. https://fwupd.org/
>
>
>  _______________________________________________
>  devel mailing list --devel(a)lists.fedoraproject.org
>  To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List
> Archives:https://lists.fedoraproject.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure

[Gary Buhrmaster]

On Thu, Apr 14, 2022 at 11:39 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:

>  I am also worried that this is just a delayed retirement, as it was
> for 32-
>  bit i686, where the SIG was very quickly declared a failure, without even
>  being given time to organize. 
Well, presumably, if you are a member of the SIG(*)
you will get to make sure that that does not happen.

Gary



(*) And if you choose not to be an active contributing
member of the SIG you really don't get to tell others
how to use their time/resources (in other words, I as I
said with many other projects and forums, you get to
actively contribute, or you get the results from those
that do (i.e. your "opinion" is worth about as much
as the electrons it was posted from)).

[Peter Boy]

>  Am 15.04.2022 um 00:24 schrieb Nikolay Nikolov
> <nickysn(a)gmail.com&gt;:
>  
>  If you want to deprecate legacy boot on new installs on UEFI-capable BIOS-es, that's
> another story. E.g. if the installer detects that the BIOS is modern (e.g. later than
> 2017-2018) and UEFI capable, but is running in legacy boot mode, it could prints a warning
> and suggest to the user to restart and turn off legacy boot from the BIOS setup. The
> installer promises better hardware support, firmware updates and happier times to the user
> if the operating system is installed in UEFI mode. Finally user decides whether to do
> that, or choose to continue on their own risk. That is totally reasonable, IMHO. But it is
> a completely different thing than dropping legacy BIOS support completely. 

++1

That’s a really reasonable plan to start „deprecating“ Bios boot.

[Vitaly Zaitsev]

On 15/04/2022 01:25, Nikolay Nikolov wrote:
>  At least on my computers, Gnome has never notified me about a BIOS 
>  update from my motherboard vendor. Besides, it's proprietary software, 
>  so I wouldn't expect Fedora to be offering it by default. Doesn't it 
>  need adding an extra software repository? 
https://fwupd.org/lvfs/devices/

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 15/04/2022 03:51, Nikolay Nikolov wrote:
>  But I'm still surprised that Fedora by default downloads and
> updates 
>  proprietary firmware, downloaded from the Internet. 
1. Fedora itself doesn't download anything. The user must manually allow 
installation of such update.
2. Vulnerable firmware is a bigger problem.
3. LVFS is maintained only by hardware vendors.

>  Btw, does this work in legacy boot mode as well? 
No. UEFI is mandatory in order to use UEFI update capsule.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 15/04/2022 00:53, Jóhann B. Guðmundsson wrote:
>  Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise
>
>  the option to disable it would not be there ) in which the vendor 
>  himself seemingly decided to disable the legacy part of the bios via 
>  firmware update which highlight the fact that we somehow need to deal 
>  with that situation if we want to continue to support the legacy bios 
>  option. 
fwupd operates only in UEFI mode. Problem solved.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Matthew Miller]

On Thu, Apr 14, 2022 at 09:29:27PM +0000, Jóhann B. Guðmundsson wrote:
>  >That’s maybe true for desktops, but in the server world any
> server needs
>  >to be able to do bios boot, because of the data center requirements.
>  >
>  Interesting I would assume that those data center requirements would
>  make it a requirement for example to be using uefi's native http
>  protocol to address the shortcomings of traditional (i)pxe, so which
>  data center requirement are those and where can I find documentation
>  about them? 
I think Peter's referring to "practical requirements" not "compliance
requirements" — the latter probably indeed better with UEFI, secure boot,
and a lot more, but the former in the real world being "yes, we've got way
more legacy hardware, configuration, and policy than ideal, but we also
don't have the staffing or budget to change it all at once". That's unlikely
to be publically documented — but nonetheless is believably true. (And I
think it's probably _particularly_ the case in small-medium environments
which might choose Fedora Server.)

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Björn Persson]

Jóhann B. Guðmundsson wrote:
>  For example EU has regulation that requires vendors to have spare
> parts 
>  available for 7–10 years after date of manufacturing so it makes sense 
>  for the project to support hw no longer than a decade from the date of 
>  it's manufacturing. 
I fail to imagine what use case you might have in mind where that
requirement would interact with Fedora. If such regulation would be
applied to Fedora, the closest equivalent would be that the Fedora
Project would be required to provide bug fixes to old releases for seven
to ten years, so Fedora would essentially have to be RHEL.

If I had the kind of strictly specified system where any broken part
must be replaced with an identical part, then I would definitely not
run the constantly changing Fedora on it. Such a system would rather
run RHEL, or something even more stable than RHEL. It makes no sense to
take special care to keep the hardware unchanging for ten years, even
when repairing it, and then replace the software twice a year with
different user interfaces, changed behavior and a new set of bugs in
every release.

As for the kind of computers that Fedora is suitable for, I'll use them
until they break, whether that happens after five or fifteen years, and
then I'll replace the broken part or the whole computer with modern
hardware that can be expected to last for many more years.

If a broken part is less than three years old, then I have a right to
get it repaired or replaced. Past the three-year limit I won't make any
attempt to buy the exact same model to replace a broken motherboard
(where the bios is stored). I'll take the opportunity to upgrade to the
latest stuff when I need to buy a new motherboard anyway, so it will
remain useful for as long as possible. That doesn't change at any seven-
or ten-year limit. I seriously doubt I could find a seven-year-old
motherboard on the market anyway. Used perhaps, but not from the vendor.

If a computer doesn't break, I may eventually have to replace it when
the processor can no longer keep up with the software's demands, but
that takes much longer than ten years nowadays.

Björn Persson

[Björn Persson]

Jóhann B. Guðmundsson wrote:
>  "In the bios, upgraded to 810 the option to enable legacy boot
> is greyed 
>  out"
>  
>  So how do people propose the situation to be handled when firmware from 
>  vendors, disables the legacy boot option via firmware update. 
I haven't seen anyone arguing that Fedora should drop UEFI support and
enforce BIOS-booting even on brand new hardware, so I don't even
understand what you're arguing against here. Obviously buyers of new
computers whose bioses support only UEFI will have to use UEFI – and
hope that those UEFI implementations are capable of booting Fedora.

In case you meant to argue that bios updates will remove the need for
Fedora to support BIOS-booting, this example does not support that
position. The computer in question is at most a few months old. Twelve-
year-old computers that never had UEFI support get no more bios updates
and will never get UEFI support added.

Anyway, it's not clear that the computer was shipped with a working
legacy boot option. The forum post doesn't say that. It says only that
the legacy boot option is unavailable and that the bios has been
updated.

By the way, the forum post is an example of a user who is dissatisfied
with UEFI for some reason, and wants to boot in BIOS mode instead.
Dropping BIOS-boot support from Fedora would presumably not make that
person any happier.

Björn Persson