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


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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


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  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/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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, not 
that it *requires* the latest 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

If people are wondering how it looks like when Fedora's code of conduct 
is violated when people partaking in community discussions and receive 
attacks in private as an result of that here's an example of that.


This individual has already sent at least me death threats ( privately 
), been blocked on other projects ( non fedora related ) mailinglist ( 
not involving me in those ) shown questionable behavior on the ISC 
mailinglist and now two years later he's at it again.


Word of advice when attack like these happen in private the best way to 
deal with it first and foremost try not let it discourage you, secondly 
expose the attacker to the broader community ( which I'm doing with this 
post and did last time as well ) since Fedora CoC is powerless to deal 
with this ( Often these attackers frequently change email addresses ) 
and the attacker knows it, like his response to me in private when I 
exposed him last time here on devel.


"little idiot: the Fedora COC don't apply for pruvate mails just because 
the topic is fedora relevant"



On 14.4.2022 21:46, Reindl Harald (privat) wrote:



Am 14.04.22 um 22:49 schrieb Jóhann B. Guðmundsson:
"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?

are you mentally ill?

there are tons of physical hardware and virtual machines which don't 
give a shit and just work in BIOS mode


and smome are installed that way because UEFI has no fucking way to 
keep /boot on RAID1 over multiple disks



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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 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-how-to-enable-legacy-boot.374479/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

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


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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  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-how-to-enable-legacy-boot.374479/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Matthew Miller

On Thu, Apr 14, 2022 at 12:18:12PM +, 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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Justin Forbes

On Thu, Apr 14, 2022 at 6:39 AM Kevin Kofler via devel
 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Neal Gompa

On Thu, Apr 14, 2022 at 2:29 PM Peter Boy  wrote:
>
>
>
> > Am 14.04.2022 um 20:20 schrieb Chris Adams :
> >
> > Once upon a time, Robbie Harwood  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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

> Am 14.04.2022 um 20:02 schrieb Robbie Harwood :
> 
> 
> 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

Hi Robbie,

On 4/14/22 20:02, Robbie Harwood wrote:
> Hans de Goede  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

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



> Am 14.04.2022 um 20:20 schrieb Chris Adams :
> 
> Once upon a time, Robbie Harwood  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.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Chris Adams

Once upon a time, Robbie Harwood  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 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Robbie Harwood

Hans de Goede  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

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Gary Buhrmaster

On Thu, Apr 14, 2022 at 2:08 PM 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.

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


On 14.4.2022 15:53, Peter Boy wrote:



Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson :

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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  
> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Robbie Harwood

Hans de Goede  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

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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



> Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson :
> 
> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Vitaly Zaitsev via devel


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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Fabio Valentini

On Thu, Apr 14, 2022 at 5:09 PM Hans de Goede  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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_comaintainers_of_packages/#current_solution

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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
  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:

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

2022-04-14 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Vitaly Zaitsev via devel


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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Neal Gompa

On Thu, Apr 14, 2022 at 8:58 AM JadoNena  wrote:
>
> Hello,
>
> > On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa  
> > 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread JadoNena via devel

Hello,

> On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa  
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Neal Gompa

On Thu, Apr 14, 2022 at 8:18 AM JadoNena via devel
 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


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-computers-revealed-in-microsoft-study-more-than-4000-each/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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



> Am 14.04.2022 um 14:05 schrieb 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 :
>>> 
>>> 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? 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread JadoNena via devel

> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


On 14.4.2022 11:53, Peter Boy wrote:



Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson :

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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



> Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson :
> 
> 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Gary Buhrmaster

On Wed, Apr 13, 2022 at 9:12 PM Matthew Miller  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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


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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread Vitaly Zaitsev via devel


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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-14 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread Gary Buhrmaster

On Thu, Apr 14, 2022 at 12:38 AM Kevin Kofler via devel
 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread Kevin Kofler via devel

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread Neal Gompa

On Wed, Apr 13, 2022 at 8:45 PM Kevin Kofler via devel
 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread Kevin Kofler via devel

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread Kevin Kofler via devel

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread 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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread 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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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
> >>  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 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:

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

2022-04-13 Thread 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
>>  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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread 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?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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
>  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 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-04-13 Thread Michael Catanzaro

On Wed, Apr 13 2022 at 10:54:01 AM -0400, 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.


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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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