This conversation was started on Monday in the QA meeting but I forgot to send anything out to the list. We're a bit short on time, so a quick vote would be appreciated
Tim
As currently written, the Fedora 20 alpha release requirements [1] state that optical media must boot:
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with at least one of the officially supported methods.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
The question was whether it was important to have this requirement at alpha when the isos aren't required to be the correct size until beta. As it currently stands, the DVD isos can't be burned to single-sided DVDs.
I propose that we modify that we do two things:
1) modify the alpha criterion so that it only requires optical media to work if the isos are correctly sized
2) require booting from optical media at beta when the isos are required to be properly sized
Proposed change to the "supported media types" section of the release blocking media criterion [1] :
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable and the images are correctly sized) and when written to a USB stick with at least one of the officially supported methods. Release-blocking ARM disk images must boot when written to a medium bootable by the platform under test, according to the instructions for the platform under test.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
Proposed change to the beta release blocking image criterion [2]:
Difference from Alpha: This criterion differs from the similar Alpha criterion in that it requires optical media to boot and that all supported methods of writing a Fedora USB stick to work, not just any single one.
[2]http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Release-blocki...
This conversation was started on Monday in the QA meeting but I forgot to send anything out to the list. We're a bit short on time, so a quick vote would be appreciated
Tim
As currently written, the Fedora 20 alpha release requirements [1] state that optical media must boot:
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with at least one of the officially supported methods.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
The question was whether it was important to have this requirement at alpha when the isos aren't required to be the correct size until beta. As it currently stands, the DVD isos can't be burned to single-sided DVDs.
I propose that we modify that we do two things:
- modify the alpha criterion so that it only requires optical media
to work if the isos are correctly sized
- require booting from optical media at beta when the isos are
required to be properly sized
Proposed change to the "supported media types" section of the release blocking media criterion [1] :
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable and the images are correctly sized) and when written to a USB stick with at least one of the officially supported methods. Release-blocking ARM disk images must boot when written to a medium bootable by the platform under test, according to the instructions for the platform under test.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
Proposed change to the beta release blocking image criterion [2]:
Difference from Alpha: This criterion differs from the similar Alpha criterion in that it requires optical media to boot and that all supported methods of writing a Fedora USB stick to work, not just any single one.
[2]http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Release-blocki...
I agree.
However, there's one corner case to consider. Due to some licensing issues we still can't test UEFI in VMs. That means we can't really test UEFI boot and installation of Live/DVD/netinst other than burning it (or doing a USB conversion, but then we don't test the vanilla ISO). If Live/netinst burning is broken for some reason (other than being oversize, which is not very likely for these two images), we might have troubles verifying that UEFI works. OTOH this is a very unlikely situation to occur. I'm mentioning it for completeness.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/19/2013 05:26 AM, Kamil Paral wrote:
This conversation was started on Monday in the QA meeting but I forgot to send anything out to the list. We're a bit short on time, so a quick vote would be appreciated
Tim
As currently written, the Fedora 20 alpha release requirements [1] state that optical media must boot:
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with at least one of the officially supported methods.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
The question was whether it was important to have this requirement at
alpha when the isos aren't required to be the correct size until beta. As it currently stands, the DVD isos can't be burned to single-sided DVDs.
I propose that we modify that we do two things:
- modify the alpha criterion so that it only requires optical
media to work if the isos are correctly sized
- require booting from optical media at beta when the isos are
required to be properly sized
Proposed change to the "supported media types" section of the release blocking media criterion [1] :
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable and the images are correctly sized) and when written to a USB stick with at least one of the officially supported methods. Release-blocking ARM disk images must boot when written to a medium bootable by the platform under test, according to the instructions for the platform under test.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
Proposed change to the beta release blocking image criterion [2]:
Difference from Alpha: This criterion differs from the similar Alpha criterion in that it requires optical media to boot and that all supported methods of writing a Fedora USB stick to work, not just any single one.
[2]http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Release-blocki...
I agree.
However, there's one corner case to consider. Due to some licensing issues we still can't test UEFI in VMs. That means we can't really test UEFI boot and installation of Live/DVD/netinst other than burning it (or doing a USB conversion, but then we don't test the vanilla ISO). If Live/netinst burning is broken for some reason (other than being oversize, which is not very likely for these two images), we might have troubles verifying that UEFI works. OTOH this is a very unlikely situation to occur. I'm mentioning it for completeness.
The rewrite sounds good to me. Just one possible improvement. I work almost exclusively with VM for testing so iso size doesn't matter. Should it be an alpha requirement that the isos we're talking about boot and install in the VM environment which has no care for size? Does this gain us any sanity checking?
Bob
The rewrite sounds good to me. Just one possible improvement. I work almost exclusively with VM for testing so iso size doesn't matter. Should it be an alpha requirement that the isos we're talking about boot and install in the VM environment which has no care for size?
I think that should be implicitly covered by "All release-blocking images must boot in their supported configurations. ". But it's true we could explicitly mention VMs as a supported "architecture" (or something).
On Thu, 2013-09-19 at 06:43 -0400, Kamil Paral wrote:
The rewrite sounds good to me. Just one possible improvement. I work almost exclusively with VM for testing so iso size doesn't matter. Should it be an alpha requirement that the isos we're talking about boot and install in the VM environment which has no care for size?
I think that should be implicitly covered by "All release-blocking images must boot in their supported configurations. ". But it's true we could explicitly mention VMs as a supported "architecture" (or something).
In fact, we don't technically require the images to work in a virtualized environment at all until Beta. There's an explicit pair of criteria there.
On Thu, 19 Sep 2013 06:23:04 -0400 Bob Lightfoot boblfoot@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/19/2013 05:26 AM, Kamil Paral wrote:
This conversation was started on Monday in the QA meeting but I forgot to send anything out to the list. We're a bit short on time, so a quick vote would be appreciated
Tim
As currently written, the Fedora 20 alpha release requirements [1] state that optical media must boot:
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with at least one of the officially supported methods.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
The question was whether it was important to have this requirement at
alpha when the isos aren't required to be the correct size until beta. As it currently stands, the DVD isos can't be burned to single-sided DVDs.
I propose that we modify that we do two things:
- modify the alpha criterion so that it only requires optical
media to work if the isos are correctly sized
- require booting from optical media at beta when the isos are
required to be properly sized
Proposed change to the "supported media types" section of the release blocking media criterion [1] :
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable and the images are correctly sized) and when written to a USB stick with at least one of the officially supported methods. Release-blocking ARM disk images must boot when written to a medium bootable by the platform under test, according to the instructions for the platform under test.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
Proposed change to the beta release blocking image criterion [2]:
Difference from Alpha: This criterion differs from the similar Alpha criterion in that it requires optical media to boot and that all supported methods of writing a Fedora USB stick to work, not just any single one.
[2]http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Release-blocki...
I agree.
However, there's one corner case to consider. Due to some licensing issues we still can't test UEFI in VMs. That means we can't really test UEFI boot and installation of Live/DVD/netinst other than burning it (or doing a USB conversion, but then we don't test the vanilla ISO). If Live/netinst burning is broken for some reason (other than being oversize, which is not very likely for these two images), we might have troubles verifying that UEFI works. OTOH this is a very unlikely situation to occur. I'm mentioning it for completeness.
The rewrite sounds good to me. Just one possible improvement. I work almost exclusively with VM for testing so iso size doesn't matter. Should it be an alpha requirement that the isos we're talking about boot and install in the VM environment which has no care for size? Does this gain us any sanity checking?
That's an good point. In practice, we seem to be doing a lot if not most of the testing for alpha in VMs and it might be worth looking into moving the "must work in a VM" criterion to alpha for f21.
I'd rather not mess with the criteria any more than we have to this far into alpha, though. VMs are working at the moment and I think we can get away with not formalizing the desire for them to work at alpha for f20.
Tim
Bob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSOtCHAAoJEKqgpLIhfz3XFRMH/30aiKVVMOMtQHPujSUNvzaZ L+ukAflPlXguMe0jFIUNt9J6fBIkKpTA2QZeupO0yFQF42kaFCALAGdmZYvK4Iiv iGmY0UffTJqlxYVOsJtFtJ1iUEuRwvPlyByLMyycX9F+rlXYnuSooZpqz6Fi2Zuf CLCB83rcLPxOgH1cYKxYWg8mcISvG01HXjwn5DZJcr5rto48SFLeiVdmPtn/SNtQ fHfLW51i3qENli48lXjIPhj0trTw1u3pfQK0+UCijSB/kFU3EFi/yul3U9WbfqNG 3ul+FbtTKwxk80eRJtHiepPCdIrF1XCBW80iw+4RWiPTCCMEWkNpY1SVFh2c4tE= =L/mM -----END PGP SIGNATURE-----
On Thu, 19 Sep 2013 05:26:03 -0400 (EDT) Kamil Paral kparal@redhat.com wrote:
This conversation was started on Monday in the QA meeting but I forgot to send anything out to the list. We're a bit short on time, so a quick vote would be appreciated
Tim
As currently written, the Fedora 20 alpha release requirements [1] state that optical media must boot:
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with at least one of the officially supported methods.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
The question was whether it was important to have this requirement at alpha when the isos aren't required to be the correct size until beta. As it currently stands, the DVD isos can't be burned to single-sided DVDs.
I propose that we modify that we do two things:
- modify the alpha criterion so that it only requires optical
media to work if the isos are correctly sized
- require booting from optical media at beta when the isos are
required to be properly sized
Proposed change to the "supported media types" section of the release blocking media criterion [1] :
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable and the images are correctly sized) and when written to a USB stick with at least one of the officially supported methods. Release-blocking ARM disk images must boot when written to a medium bootable by the platform under test, according to the instructions for the platform under test.
[1]http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Release-block...
Proposed change to the beta release blocking image criterion [2]:
Difference from Alpha: This criterion differs from the similar Alpha criterion in that it requires optical media to boot and that all supported methods of writing a Fedora USB stick to work, not just any single one.
[2]http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Release-blocki...
I agree.
However, there's one corner case to consider. Due to some licensing issues we still can't test UEFI in VMs. That means we can't really test UEFI boot and installation of Live/DVD/netinst other than burning it (or doing a USB conversion, but then we don't test the vanilla ISO). If Live/netinst burning is broken for some reason (other than being oversize, which is not very likely for these two images), we might have troubles verifying that UEFI works. OTOH this is a very unlikely situation to occur. I'm mentioning it for completeness.
Yeah, we can't test more of the dvd iso than what a dd prepared usb stick gives us but if the thing is oversized anyways, I don't think we're losing much.
The way that I interpret this change, netinstall isos are still required to work @ alpha so long as they fit on a CD. In this case, we still have usable optical media but we don't require the DVD optical media to work unless it's properly sized. UEFI testing is still possible with the netinstall iso and one of the USB methods which is what I imagine users would be doing as well.
I know you mentioned it for completeness, just expanding on why I don't think it's a huge issue.
Tim
On 09/19/2013 06:49 AM, Tim Flink wrote:
On Thu, 19 Sep 2013 05:26:03 -0400 (EDT) Kamil Paral kparal@redhat.com wrote:
....
- modify the alpha criterion so that it only requires optical
media to work if the isos are correctly sized
- require booting from optical media at beta when the isos are
required to be properly sized
....
However, there's one corner case to consider. Due to some licensing issues we still can't test UEFI in VMs. That means we can't really test UEFI boot and installation of Live/DVD/netinst other than burning it (or doing a USB conversion, but then we don't test the vanilla ISO). If Live/netinst burning is broken for some reason (other than being oversize, which is not very likely for these two images), we might have troubles verifying that UEFI works. OTOH this is a very unlikely situation to occur. I'm mentioning it for completeness.
....
I know you mentioned it for completeness, just expanding on why I don't think it's a huge issue.
Am I being dense, or missing something? What "licensing issues"?
I have a new Intel "Haswell" (i5-4430/z87) achitecture machine and do both VM and bare-metal testing, is there something I should be aware of and add tot the testing procedures?
On 09/19/2013 06:53 AM, Greg Woodbury wrote:
However, there's one corner case to consider. Due to some licensing issues we still can't test UEFI in VMs.
Am I being dense, or missing something? What "licensing issues"?
I have a new Intel "Haswell" (i5-4430/z87) achitecture machine and do both VM and bare-metal testing, is there something I should be aware of and add tot the testing procedures?
Given the current state of the art, all known UEFI implementations for VMs require the use of a FAT driver whose license forbids redistribution for general purpose use, which means Fedora cannot ship it. You can test UEFI on bare metal, and you can test UEFI on VMs if you download the software and build it yourself, but Fedora cannot ask you to test UEFI on VMs until someone steps forward and writes a new license-unencumbered FAT driver.
For more interesting reading, see: https://lists.gnu.org/archive/html/qemu-devel/2013-05/msg04762.html
On Sep 19, 2013, at 8:56 AM, Eric Blake eblake@redhat.com wrote:
Given the current state of the art, all known UEFI implementations for VMs require the use of a FAT driver whose license forbids redistribution for general purpose use, which means Fedora cannot ship it.
I don't understand this.
First, there is already a FAT driver that works out of the box in Fedora for general purpose use.
And second, the UEFI spec in section 12.3 considers the EFI file system to be distinct from, although based on, FAT. And the spec includes long file name support, using UCS-2 encoding. Microsoft only have patent claims on FAT that relate to long file names. This is in effect not Microsoft's FAT, but rather an EFI file system maintained by the UEFI spec and is unchanging from Microsoft FAT variants.
We probably ought to have a mkfs variant for ESP's to ensure it's created per the UEFI spec and is guaranteed to not evolve with mkdosfs|mkfs.msdos|mkfs.vfat.
Chris Murphy
Chris Murphy (lists@colorremedies.com) said:
On Sep 19, 2013, at 8:56 AM, Eric Blake eblake@redhat.com wrote:
Given the current state of the art, all known UEFI implementations for VMs require the use of a FAT driver whose license forbids redistribution for general purpose use, which means Fedora cannot ship it.
I don't understand this.
Not speaking to any issues of legality or non-legality, but fairly sure he's referring to the FAT driver in the EFI bios itself, which would have to be distributed in the EFI bios used by QEMU/KVM for virtual systems. It's not the linux kernel driver.
Bill
On Sep 19, 2013, at 4:01 PM, Bill Nottingham notting@redhat.com wrote:
Not speaking to any issues of legality or non-legality, but fairly sure he's referring to the FAT driver in the EFI bios itself, which would have to be distributed in the EFI bios used by QEMU/KVM for virtual systems. It's not the linux kernel driver.
I understand that distinction but as there is a FAT driver in the linux kernel distributed with Fedora, I don't see why it's suddenly a problem for an EFI virtual firmware that needs a FAT driver to ship with Fedora.
Also, Virtualbox includes a UEFI virtual firmware that can read EFI FAT and it's also open source and isn't run afoul of licensing issues insofar as I'm aware.
Chris Murphy
On Sep 19, 2013, at 4:13 PM, Chris Murphy lists@colorremedies.com wrote:
I understand that distinction but as there is a FAT driver in the linux kernel distributed with Fedora, I don't see why it's suddenly a problem for an EFI virtual firmware that needs a FAT driver to ship with Fedora.
Also, Virtualbox includes a UEFI virtual firmware that can read EFI FAT and it's also open source and isn't run afoul of licensing issues insofar as I'm aware.
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Edk2-fat-dri...
License addition reads in part (simplification mine): used for and designed only to read and/or write to an EFI/UEFI file system only as necessary to emulate an implementation of the UEFI Specifications; and to create firmware, applications, utilities and/or drivers.
So I guess it's this limitation of the driver for a non-general purpose that's running afoul of Fedora's requirements, not that Fedora is running afoul of the driver license? If so, this is a problem for the Fedora license to be unable to ever ship with a virtualized UEFI firmware. One day we're going to want to securely boot VM's.
Chris Murphy
On 09/19/2013 03:53 PM, Chris Murphy wrote:
On Sep 19, 2013, at 8:56 AM, Eric Blake eblake@redhat.com wrote:
Given the current state of the art, all known UEFI implementations for VMs require the use of a FAT driver whose license forbids redistribution for general purpose use, which means Fedora cannot ship it.
I don't understand this.
First, there is already a FAT driver that works out of the box in Fedora for general purpose use.
The kernel FAT driver is GPL. But state of the art for UEFI is the OVMF code base, which is mostly BSD, but contains a non-open FAT driver. Meanwhile, the OVMF folks have explicitly stated they are unwilling to incorporate GPL code (which would make their entire project GPL, and cut them off from proprietary vendors that currently rely on the looseness of BSD licensing). So far, no one has forked the open portions of OVMF to mix in an alternative FAT module (such as providing a GPL UEFI solution by reusing the kernel's fat driver), and as no other VM boot loader code understands UEFI (Fedora ships SeaBIOS, but that is BIOS not UEFI), then there is currently no way to boot a VM under UEFI while still being able to distribute that loader in Fedora.
And second, the UEFI spec in section 12.3 considers the EFI file system to be distinct from, although based on, FAT. And the spec includes long file name support, using UCS-2 encoding. Microsoft only have patent claims on FAT that relate to long file names. This is in effect not Microsoft's FAT, but rather an EFI file system maintained by the UEFI spec and is unchanging from Microsoft FAT variants.
We probably ought to have a mkfs variant for ESP's to ensure it's created per the UEFI spec and is guaranteed to not evolve with mkdosfs|mkfs.msdos|mkfs.vfat.
What the kernel FAT drivers do is independent of what a VM loader has to be able to do to emulate UEFI to the guest. Although you are probably right that the kernel folks should take care that their UEFI interactions don't break, that is independent of the licensing issue at hand for VM booting.