Now that Fedora 25 is out of the door, I'd like to start a discussion about the future of officially-supported (meaning rigorously tested) optical media for future Fedora releases. Since I'm QA, I'm mainly interested in changes to our release criteria [1].
Let's start by saying I'm not asking for completely dropping optical media support. Even though hardware incapable of booting from USB is getting increasingly rare, I understand that there are still valid use cases from optical media, like pressing a bulk of DVDs for a very small price and handing it out at events or sending them into developing countries (that's how I started with Linux, after all, ~15 years ago). However, the world has moved on since then, I wonder whether some changes in decreasing the importance of optical media could be appropriate. All of that is, of course, motivated by trying to spend QA time more effectively. You can see the current coverage e.g. in this table [2], overall we burn 6 DVDs and perform 12 optical installation (BIOS + UEFI) for every release candidate published. We allow non-complete (yet still substantial) coverage for Alpha and Beta, but 100% coverage for Final for each candidate compose. That is quite time consuming, both burning and installation from optical media take a long time, it requires bare metal testing, and we can't use the machines for anything else during that time.
So, I wonder whether Fedora as a project thinks about de-emphasizing optical media a bit, and if it does, I'd make appropriate changes even in our QA processes. Here are a couple of ideas that I consider could be likely to happen in future Fedora releases.
Idea #1: Do not block on optical media issues for Alpha and Beta releases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In my guesstimation, the intersection between people able and willing to test pre-releases and people not able to boot from USB or PXE is getting very small. My reasoning for this is: a) PCs unable to boot from USB are becoming rare. They are probably only (or mostly) very old i386 machines. b) Users testing pre-releases usually have above-average technical skills and/or are technical enthusiasts, who tend to own newer hardware. c) We now have Fedora Media Writer for all major operating systems, which can burn the image onto a flash drive with a nice simple user interface, so even people who can boot from both optical drive and USB and used to prefer optical drive (because it was simpler for them) should be covered now with our super-easy USB writing tool.
Implementing this idea doesn't mean optical media would immediately get broken for Alphas and Betas. We would still care about such issues (it would be needed for Final, if nothing else) and we would still test it from time to time during the whole cycle (even though not that frequently - we would rely more on community involvement, e.g. similar to alternative architectures). But we wouldn't block the Alpha/Beta release on these issues, just the Final release.
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a bolder variant of the previous idea and can be done separately or combined with it. It makes optical media functionality not guaranteed even for Final release, but just for certain Fedora flavors or image types for which it makes sense (not all of them). Which images to cover, that's the heart of the discussion. If you look into our test matrix again, we currently block on 6 of them: * Workstation Live + netinst * KDE Live * Server DVD + netinst * Everything netinst
What comes first to my mind is Server (DVD + netinst). My guess is that people don't install Server from optical media, but rather from PXE or USB. I can't imagine installing Server boxes from DVDs. But I'd really like to hear from Server users how this is likely or not. Also, Server is most probably not given away at events. I don't know about sending Server DVDs to the developing world, we can make an inquiry about that.
Second idea would be netinst media. They require good network access, so there's no point in shipping them to developing countries, and I can hardly imagine giving them away at events. They are targeted at more professional audience, which is likely to use more modern hardware. We could make an exception of Everything netinst, which is universal and could be used for cases where Live images don't work (netinst can use text mode in case of severe graphical issues even with safe graphics mode on, or perhaps on ultra-low memory configurations).
What do you think? Does it make sense, or is it too early for such a change?
(CCing test list, but let's keep the discussion in a single list only, i.e. devel)
[1] https://fedoraproject.org/wiki/Fedora_Release_Criteria [2] https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Installation#De...
W dniu 06.12.2016 o 14:43, Kamil Paral pisze:
All of that is, of course, motivated by trying to spend QA time more effectively. You can see the current coverage e.g. in this table [2], overall we burn 6 DVDs and perform 12 optical installation (BIOS + UEFI) for every release candidate published. We allow non-complete (yet still substantial) coverage for Alpha and Beta, but 100% coverage for Final for each candidate compose. That is quite time consuming, both burning and installation from optical media take a long time, it requires bare metal testing, and we can't use the machines for anything else during that time.
Why not boot VM with virtual optical drive? You can choose BIOS/UEFI, 32/64bit and do not require bare metal hardware for it.
On Tue, 2016-12-06 at 15:00 +0000, Marcin Juszkiewicz wrote:
W dniu 06.12.2016 o 14:43, Kamil Paral pisze:
All of that is, of course, motivated by trying to spend QA time more effectively. You can see the current coverage e.g. in this table [2], overall we burn 6 DVDs and perform 12 optical installation (BIOS + UEFI) for every release candidate published. We allow non-complete (yet still substantial) coverage for Alpha and Beta, but 100% coverage for Final for each candidate compose. That is quite time consuming, both burning and installation from optical media take a long time, it requires bare metal testing, and we can't use the machines for anything else during that time.
Why not boot VM with virtual optical drive? You can choose BIOS/UEFI, 32/64bit and do not require bare metal hardware for it.
It's not a sufficient test. We have had real bugs in the past where a VM would boot from an ISO image, but real systems would not boot from the same ISO image burned to a real optical disc.
Virtual machines are great for convenience, but they are not real hardware and we cannot in good conscience release our product without testing it on real machines with real media.
On 06/12/2016 18:11, Adam Williamson wrote:
On Tue, 2016-12-06 at 15:00 +0000, Marcin Juszkiewicz wrote:
W dniu 06.12.2016 o 14:43, Kamil Paral pisze:
All of that is, of course, motivated by trying to spend QA time more effectively. You can see the current coverage e.g. in this table [2], overall we burn 6 DVDs and perform 12 optical installation (BIOS + UEFI) for every release candidate published. We allow non-complete (yet still substantial) coverage for Alpha and Beta, but 100% coverage for Final for each candidate compose. That is quite time consuming, both burning and installation from optical media take a long time, it requires bare metal testing, and we can't use the machines for anything else during that time.
Why not boot VM with virtual optical drive? You can choose BIOS/UEFI, 32/64bit and do not require bare metal hardware for it.
It's not a sufficient test. We have had real bugs in the past where a VM would boot from an ISO image, but real systems would not boot from the same ISO image burned to a real optical disc.
Virtual machines are great for convenience, but they are not real hardware and we cannot in good conscience release our product without testing it on real machines with real media.
It's still a good test to do. For example, Server and netinst ISO images are used a lot for VMs, but not for bare metal.
Paolo
Virtual machines are great for convenience, but they are not real hardware and we cannot in good conscience release our product without testing it on real machines with real media.
It's still a good test to do. For example, Server and netinst ISO images are used a lot for VMs, but not for bare metal.
I wasn't clear on this, so let me be more specific. My proposal is only related to bare-metal optical media support (physical CD, DVD, BD). It is not related to VM booting at all, so our existing criteria would remain to hold - i.e. all the images have to be bootable in VMs since Alpha/Beta (Beta strictly per current criteria wording, but effectively I believe this would be approved even as an Alpha blocker). This would not change.
On 12/07/2016 11:15 AM, Paolo Bonzini wrote:
On 06/12/2016 18:11, Adam Williamson wrote:
On Tue, 2016-12-06 at 15:00 +0000, Marcin Juszkiewicz wrote:
W dniu 06.12.2016 o 14:43, Kamil Paral pisze:
All of that is, of course, motivated by trying to spend QA time more effectively. You can see the current coverage e.g. in this table [2], overall we burn 6 DVDs and perform 12 optical installation (BIOS + UEFI) for every release candidate published. We allow non-complete (yet still substantial) coverage for Alpha and Beta, but 100% coverage for Final for each candidate compose. That is quite time consuming, both burning and installation from optical media take a long time, it requires bare metal testing, and we can't use the machines for anything else during that time.
Why not boot VM with virtual optical drive? You can choose BIOS/UEFI, 32/64bit and do not require bare metal hardware for it.
It's not a sufficient test. We have had real bugs in the past where a VM would boot from an ISO image, but real systems would not boot from the same ISO image burned to a real optical disc.
Virtual machines are great for convenience, but they are not real hardware and we cannot in good conscience release our product without testing it on real machines with real media.
It's still a good test to do. For example, Server and netinst ISO images are used a lot for VMs, but not for bare metal.
Well, your view - I have been using netinst-ISOs only, in recently years ;)
Ralf
On Wed, Dec 07, 2016 at 02:05:20PM +0100, Ralf Corsepius wrote:
It's still a good test to do. For example, Server and netinst ISO images are used a lot for VMs, but not for bare metal.
Well, your view - I have been using netinst-ISOs only, in recently years ;)
Do you burn them to actual physical spinning optical media?
On 12/07/2016 03:05 PM, Matthew Miller wrote:
On Wed, Dec 07, 2016 at 02:05:20PM +0100, Ralf Corsepius wrote:
It's still a good test to do. For example, Server and netinst ISO images are used a lot for VMs, but not for bare metal.
Well, your view - I have been using netinst-ISOs only, in recently years ;)
Do you burn them to actual physical spinning optical media?
Nowadays, I usually put them on USB-sticks or SDCards. However I also have to admit having resorted to using optical media on very rare exceptional conditions.
Ralf
On Wed, Dec 07, 2016 at 03:54:25PM +0100, Ralf Corsepius wrote:
Do you burn them to actual physical spinning optical media?
Nowadays, I usually put them on USB-sticks or SDCards. However I also have to admit having resorted to using optical media on very rare exceptional conditions.
Oh, good -- we're not talking about dropping the USB stick case (I don't think we test SD cards at all) — basically the question is how much time we should spend testing (and blocking!) on that rare exceptional condition.
On 12/07/2016 04:14 PM, Matthew Miller wrote:
On Wed, Dec 07, 2016 at 03:54:25PM +0100, Ralf Corsepius wrote:
Do you burn them to actual physical spinning optical media?
Nowadays, I usually put them on USB-sticks or SDCards. However I also have to admit having resorted to using optical media on very rare exceptional conditions.
Oh, good -- we're not talking about dropping the USB stick case (I don't think we test SD cards at all)
In most cases, I am using these SD cards with one of these "USB stick-like" adapters. So far, I've never had any boot/install related problems with these. Probably, the BIOS/UEFI sees them as USB sticks?
— basically the question is how much time we should spend testing (and blocking!) on that rare exceptional condition.
To me, these rare exceptional conditions come from 2 categories: - No spare USB stick at hand (e.g when travelling) - No USB or USB-boot available[1]
Ralf
[1] One of my machines (A very old one) doesn't support booting from USB. The only physical installation media available on this one is CDROMs.
On Wed, 2016-12-07 at 16:52 +0100, Ralf Corsepius wrote:
On 12/07/2016 04:14 PM, Matthew Miller wrote:
On Wed, Dec 07, 2016 at 03:54:25PM +0100, Ralf Corsepius wrote:
Do you burn them to actual physical spinning optical media?
Nowadays, I usually put them on USB-sticks or SDCards. However I also have to admit having resorted to using optical media on very rare exceptional conditions.
Oh, good -- we're not talking about dropping the USB stick case (I don't think we test SD cards at all)
In most cases, I am using these SD cards with one of these "USB stick-like" adapters. So far, I've never had any boot/install related problems with these. Probably, the BIOS/UEFI sees them as USB sticks?
Yes. To the system, an SD card in a USB adapter *is* a USB storage device.
The "get it installed or rescued" use cases: The most universal image for this is net install ISO, so one of those being the blocking image to test on baremetal makes sense to me.
The "live + read only + verifiable" use cases: I'd say either Workstation or Security spin could meet this use case. Since Security spin is not a release blocking image, the criterion could say it's met if either the Security spin or Workstation can boot UEFI and BIOS computers using optical media. (Security spin benefits from all three use cases.)
Chris Murphy
On 07/12/16 15:05, Matthew Miller wrote:
On Wed, Dec 07, 2016 at 02:05:20PM +0100, Ralf Corsepius wrote:
It's still a good test to do. For example, Server and netinst ISO images are used a lot for VMs, but not for bare metal.
Well, your view - I have been using netinst-ISOs only, in recently years ;)
Do you burn them to actual physical spinning optical media?
I do that. Last time I tried to make a bootable USB I destroyed my pendrive and it's not like a have them for tons. And it's not the first time this happens.
Cheers, Sylvia
On Sun, Dec 11, 2016 at 7:48 AM, Ms Sanchez bhkohane@gmail.com wrote:
On 07/12/16 15:05, Matthew Miller wrote:
On Wed, Dec 07, 2016 at 02:05:20PM +0100, Ralf Corsepius wrote:
It's still a good test to do. For example, Server and netinst ISO images are used a lot for VMs, but not for bare metal.
Well, your view - I have been using netinst-ISOs only, in recently years ;)
Do you burn them to actual physical spinning optical media?
I do that. Last time I tried to make a bootable USB I destroyed my pendrive and it's not like a have them for tons. And it's not the first time this happens.
OK being an expert in hyperbole... I recognize this as such. There's no way making a bootable USB stick destroys it. What you're probably experiencing is confusing elsewhere as a result of the whacky hybrid partition scheme that's used on Fedora ISOs. To clean it up you have to wipe the first 3 sectors to remove all three partition schemes; but you're maybe better off just zeroing the first 1MiB.
dd if=/dev/zero of=/dev/<stick> bs=1M count=1
The new Fedora Media Writer will recognize this hybrid partition scheme on a USB stick and offer to reset it for you.
On 11/12/16 19:21, Chris Murphy wrote:
On Sun, Dec 11, 2016 at 7:48 AM, Ms Sanchez bhkohane@gmail.com wrote:
On 07/12/16 15:05, Matthew Miller wrote:
On Wed, Dec 07, 2016 at 02:05:20PM +0100, Ralf Corsepius wrote:
It's still a good test to do. For example, Server and netinst ISO images are used a lot for VMs, but not for bare metal.
Well, your view - I have been using netinst-ISOs only, in recently years ;)
Do you burn them to actual physical spinning optical media?
I do that. Last time I tried to make a bootable USB I destroyed my pendrive and it's not like a have them for tons. And it's not the first time this happens.
OK being an expert in hyperbole... I recognize this as such. There's no way making a bootable USB stick destroys it. What you're probably experiencing is confusing elsewhere as a result of the whacky hybrid partition scheme that's used on Fedora ISOs. To clean it up you have to wipe the first 3 sectors to remove all three partition schemes; but you're maybe better off just zeroing the first 1MiB.
dd if=/dev/zero of=/dev/<stick> bs=1M count=1
The new Fedora Media Writer will recognize this hybrid partition scheme on a USB stick and offer to reset it for you.
No, impossible, now it's read only. I tried to format but there's problem with block sizes. If I try to format Gparted shows a warning "Block sizes are of xx bytes but Linux says they are xx bytes" and fails. For some reason, Media Writer failed middle way in the process of making it bootable. And it's not the first time it happens. The previous one I fixed it running a programme, but I don't remember which one. So, I know it's not physically destroyed but to me it's almost the same, I lost the only USB stick I had for this purpose. The other one is for backups.
Cheers, Sylvia
On Mon, Dec 12, 2016 at 3:35 AM, Ms Sanchez bhkohane@gmail.com wrote:
No, impossible, now it's read only.
This is one way flash drives die. It could also be a firmware bug. But in any case it's not due to writing Fedora installation media or we'd have a thousand complaints like this if it were happening even 1% of the time.
I tried to format but there's problem with block sizes. If I try to format Gparted shows a warning "Block sizes are of xx bytes but Linux says they are xx bytes" and fails.
This is an expected side effect of the unusual partitioning being used for ISOs. ISO 9660 defines a block size of 2048 bytes, where the USB stick is 512 bytes, and sometimes the disconnect causes confusion. Wiping the first 1M should fix it, or use the feature in FMW for this purpose.
For some reason, Media Writer failed middle way in the process of making it bootable.
*shrug* without kernel messages it's kinda hard to say what went wrong but in the absence of evidence I'll blame bad or dying media just because it's so common.
And it's not the first time it happens. The previous one I fixed it running a programme, but I don't remember which one. So, I know it's not physically destroyed but to me it's almost the same, I lost the only USB stick I had for this purpose. The other one is for backups.
Use the f3 package to see if it's fake flash. It's pretty common, as are transient problems.
On Wed, 2016-12-07 at 11:15 +0100, Paolo Bonzini wrote:
On 06/12/2016 18:11, Adam Williamson wrote:
On Tue, 2016-12-06 at 15:00 +0000, Marcin Juszkiewicz wrote:
W dniu 06.12.2016 o 14:43, Kamil Paral pisze:
All of that is, of course, motivated by trying to spend QA time more effectively. You can see the current coverage e.g. in this table [2], overall we burn 6 DVDs and perform 12 optical installation (BIOS + UEFI) for every release candidate published. We allow non-complete (yet still substantial) coverage for Alpha and Beta, but 100% coverage for Final for each candidate compose. That is quite time consuming, both burning and installation from optical media take a long time, it requires bare metal testing, and we can't use the machines for anything else during that time.
Why not boot VM with virtual optical drive? You can choose BIOS/UEFI, 32/64bit and do not require bare metal hardware for it.
It's not a sufficient test. We have had real bugs in the past where a VM would boot from an ISO image, but real systems would not boot from the same ISO image burned to a real optical disc.
Virtual machines are great for convenience, but they are not real hardware and we cannot in good conscience release our product without testing it on real machines with real media.
It's still a good test to do. For example, Server and netinst ISO images are used a lot for VMs, but not for bare metal.
Of course we already test the ISOs on VMs, all the time.
On Tue, Dec 06, 2016 at 09:43:18AM -0500, Kamil Paral wrote:
So, I wonder whether Fedora as a project thinks about de-emphasizing optical media a bit, and if it does, I'd make appropriate changes even in our QA processes. Here are a couple of ideas that I consider could be likely to happen in future Fedora releases.
I'm in favor overall.
Idea #1: Do not block on optical media issues for Alpha and Beta releases
My concern here is that if we don't make it a blocker for at least beta but do for final, it's setting us up for a scramble at final time.
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst)
+1 to this one. But is there likely to be a case where it fails on just those? I guess this primarily reduces what you need to _test_. So, yeah, +1.
On Tue, 2016-12-06 at 10:28 -0500, Matthew Miller wrote:
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst)
+1 to this one. But is there likely to be a case where it fails on just those? I guess this primarily reduces what you need to _test_. So, yeah, +1.
The nexus between 'test coverage' and 'blocker status' is a tricky one. On the one hand, we've generally held, ever since introducing the release criteria, that it's possible for something that's not covered in regular testing to block the release. This has always been a thing that could happen, and we've explicitly acknowledged the scenario at various times.
On the other hand, a standard question when a blocker is proposed very late is 'why wasn't this tested earlier?', and it always seems like a good question at the time.
So we could *in theory* say that we don't require testing of every release-blocking ISO as burned to an optical disc, but we would block on any one of them being broken if someone happens to find that it is. But we'd have to own that decision and not just refuse to grant blocker status on the grounds that 'it wasn't tested early enough', etc.
As for the issue of how likely failures are in different images, it is possible for bugs to affect some ISOs but not others, as the code paths by which the different images are built are quite different. It's certainly possible for an issue to affect lives but not traditional installer images, or vice versa. It's much less likely that one live image would be broken (in terms of actual bootability) but another would not. I think it's less likely, but *possible*, for DVD to work but netinst not (or vice versa) - I think we once actually had a case where one of them had isohybrid run on it but the other didn't (though that of course would affect *USB* boot, not optical media). I think it's very unlikely for one netinst to work but another not.
So an alternative to kparal's scheme would be to try and consider this, and say we test:
* Workstation live * Everything netinst * Server DVD
and consider those to be representative of the broad 'types' of ISOs in terms of the compose process. That way we don't have to test Workstation or Server netinsts, or the KDE live, on optical media.
I do have a kinda old-fashioned attachment to the idea that a real human being should boot and install, in at least *some* way, each of the release-blocking media we ship. But that might just be a personal bias.
On Tue, 2016-12-06 at 09:20 -0800, Adam Williamson wrote:
So an alternative to kparal's scheme would be to try and consider this, and say we test:
- Workstation live
- Everything netinst
- Server DVD
Or we could simply state that required coverage is 'one release- blocking live, one release-blocking netinst, one release-blocking DVD image', without specifying which ones precisely. That gives a bit more flexibility and is easier to write.
Hello all,
I would favour to make optical media issues blockers for beta so they'll be (hopefully) solved by the time of the final release.
My 2 cents.
Sylvia
On 06/12/16 16:28, Matthew Miller wrote:
On Tue, Dec 06, 2016 at 09:43:18AM -0500, Kamil Paral wrote:
So, I wonder whether Fedora as a project thinks about de-emphasizing optical media a bit, and if it does, I'd make appropriate changes even in our QA processes. Here are a couple of ideas that I consider could be likely to happen in future Fedora releases.
I'm in favor overall.
Idea #1: Do not block on optical media issues for Alpha and Beta releases
My concern here is that if we don't make it a blocker for at least beta but do for final, it's setting us up for a scramble at final time.
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst)
+1 to this one. But is there likely to be a case where it fails on just those? I guess this primarily reduces what you need to _test_. So, yeah, +1.
It sounds reasonable to take a while and think about, who use wich media, and why we make it.
1) As was said, ask server images users, how they prefer and how they actually install Fedora and make decision based on it.
2) Just a thought - would it be more efficient to test ISOs in VMs to some point? For example, till the Alpha release, evertyhing mentioned here as a subject of possible changes could be tested only on VMs. After Alpha release, test would change to manual on real HW. - again, it depends on how often QA come across bugs that occurs on real HW, but not in VMs.
On Tue, 2016-12-06 at 23:57 +0100, Michal Schorm wrote:
It sounds reasonable to take a while and think about, who use wich media, and why we make it.
- As was said, ask server images users, how they prefer and how they
actually install Fedora and make decision based on it.
- Just a thought - would it be more efficient to test ISOs in VMs to some
point?
For example, till the Alpha release, evertyhing mentioned here as a subject of possible changes could be tested only on VMs. After Alpha release, test would change to manual on real HW.
For Alpha and Beta, we already state:
"For Alpha and Beta, we expect a reasonable sampling of tests across the table, with at least some testing for all three media types, both firmware types, and each major class of deliverable (netinst, live and DVD)."
- Just a thought - would it be more efficient to test ISOs in VMs to some
point? For example, till the Alpha release, evertyhing mentioned here as a subject of possible changes could be tested only on VMs. After Alpha release, test would change to manual on real HW.
It might not be completely obvious from the [2] link I posted in my original email, but we already do that, we test images in VMs for Alpha/Beta/Final. We're expected to do the same for bare metal+optical drives, also for Alpha/Beta/Final. This proposal is about the latter part, trimming that down.
Idea #1: Do not block on optical media issues for Alpha and Beta releases
My concern here is that if we don't make it a blocker for at least beta but do for final, it's setting us up for a scramble at final time.
I understand the concern. However, is that really different from other Final-only criteria we already have, like Windows/macOS dual-boot (often broken due to grub/uefi), or "every tiniest app has to work" (surprises lurking everywhere)? Also, delaying Beta or delaying Final might end up as the same delay overall.
I think there are two things combined. The first one is blocking status. I'd like to have blocking status set exactly for that milestone which we believe it should block (and not an earlier one, just in case). The second thing is detection. We should be able to detect these issues early in the process, but we often don't, and we can talk about improvements here. I usually strive to avoid the situation where we test a Final test case for the first time only after Beta release (or with Final RC1). That's too late. If nothing blocks it, we should be able to test those e.g. with Alpha images. We don't have a good process designed there, and the missed test cases often come down to a lack of time, but if we improve that, I believe that would address your concern, right?
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst)
+1 to this one. But is there likely to be a case where it fails on just those? I guess this primarily reduces what you need to _test_. So, yeah, +1.
As Adam described, we had cases where only certain type of images were affected, due to compose misconfiguration. So it's possible (even though not that likely nor frequent). That's why I'm interested more in tweaking guarantees that Fedora as a project claims to have ("image XYZ must be bootable from DVD or USB"), rather than test coverage optimization (that's internal to QA team, we can discuss that in our test list).
We can of course decide here that we want to keep our "must boot from optical media" guarantee for all iso images we produce, but reduce the testing to just one image from each type (Live, DVD, netinst). But that makes me feel somewhat uneasy, similar to what Adam said. That's why I'm mainly interested in talking about criteria adjustments first.
Since you're +1 here, do you have any opinion which release flavors/image types should be exempt from optical boot guarantee/criteria, and for which we should keep it? You have far a better overall idea of the project than I do.
On Wed, Dec 07, 2016 at 08:49:12AM -0500, Kamil Paral wrote:
Since you're +1 here, do you have any opinion which release flavors/image types should be exempt from optical boot guarantee/criteria, and for which we should keep it? You have far a better overall idea of the project than I do.
I think: Workstation x86_64 Live, and at least one netinstall image of any flavor (from which, in a pinch, anything else can be installed via kickstart).
On Wed, 2016-12-07 at 08:49 -0500, Kamil Paral wrote:
I think there are two things combined. The first one is blocking status. I'd like to have blocking status set exactly for that milestone which we believe it should block (and not an earlier one, just in case). The second thing is detection. We should be able to detect these issues early in the process, but we often don't, and we can talk about improvements here. I usually strive to avoid the situation where we test a Final test case for the first time only after Beta release (or with Final RC1). That's too late.
Yeah, this is something I try to push every cycle. We do post repeated reminders that *all* tests should be run on Alpha / Beta composes, not only the tests for Alpha / Beta criteria.
On 6 Dec 2016, at 09:43, Kamil Paral wrote:
Which images to cover, that's the heart of the discussion. If you look into our test matrix again, we currently block on 6 of them:
- Workstation Live + netinst
- KDE Live
- Server DVD + netinst
- Everything netinst
What comes first to my mind is Server (DVD + netinst). My guess is that people don't install Server from optical media, but rather from PXE or USB. I can't imagine installing Server boxes from DVDs. But I'd really like to hear from Server users how this is likely or not. Also, Server is most probably not given away at events. I don't know about sending Server DVDs to the developing world, we can make an inquiry about that.
On 6 Dec 2016, at 12:20, Adam Williamson wrote:
So an alternative to kparal's scheme would be to try and consider this, and say we test:
- Workstation live
- Everything netinst
- Server DVD
and consider those to be representative of the broad 'types' of ISOs in terms of the compose process. That way we don't have to test Workstation or Server netinsts, or the KDE live, on optical media.
On 7 Dec 2016, at 09:13, Matthew Miller wrote:
I think: Workstation x86_64 Live, and at least one netinstall image of any flavor (from which, in a pinch, anything else can be installed via kickstart).
I use the Server netinstall image. Use cases include loop mounting the netinstall .iso on boxes with Grub2 -- works on remote boxes where there is no physical access and can be easier than setting up a remote PXE solution -- and burning a CD for local boxes without Grub2.
I would be fine with dropping the Server DVD.
Does anyone maintain a up-to-date list of the content differences between the Server and Everything netinstall discs? Is there any difference other than in default preferences? Is there a way to do a single disc with a choice of "give me Server defaults" or "give me Everything defaults"?
On Wed, 2016-12-07 at 13:56 -0500, Mike Pinkerton wrote:
I use the Server netinstall image. Use cases include loop mounting the netinstall .iso on boxes with Grub2 -- works on remote boxes where there is no physical access and can be easier than setting up a remote PXE solution -- and burning a CD for local boxes without Grub2.
I would be fine with dropping the Server DVD.
There is no proposal to *stop creating* any images here. We're only talking about the extent of testing the ISO files written to physical optical media in this thread.
On miércoles, 7 de diciembre de 2016 1:56:32 PM CST Mike Pinkerton wrote:
On 6 Dec 2016, at 09:43, Kamil Paral wrote:
Which images to cover, that's the heart of the discussion. If you look into our test matrix again, we currently block on 6 of them:
- Workstation Live + netinst
- KDE Live
- Server DVD + netinst
- Everything netinst
What comes first to my mind is Server (DVD + netinst). My guess is that people don't install Server from optical media, but rather from PXE or USB. I can't imagine installing Server boxes from DVDs. But I'd really like to hear from Server users how this is likely or not. Also, Server is most probably not given away at events. I don't know about sending Server DVDs to the developing world, we can make an inquiry about that.
On 6 Dec 2016, at 12:20, Adam Williamson wrote:
So an alternative to kparal's scheme would be to try and consider this, and say we test:
- Workstation live
- Everything netinst
- Server DVD
and consider those to be representative of the broad 'types' of ISOs in terms of the compose process. That way we don't have to test Workstation or Server netinsts, or the KDE live, on optical media.
On 7 Dec 2016, at 09:13, Matthew Miller wrote:
I think: Workstation x86_64 Live, and at least one netinstall image of any flavor (from which, in a pinch, anything else can be installed via kickstart).
I use the Server netinstall image. Use cases include loop mounting the netinstall .iso on boxes with Grub2 -- works on remote boxes where there is no physical access and can be easier than setting up a remote PXE solution -- and burning a CD for local boxes without Grub2.
There is the pxe iso to use boot.fedoraproject.org that would probably better suit your purposes.
I would be fine with dropping the Server DVD.
Does anyone maintain a up-to-date list of the content differences between the Server and Everything netinstall discs? Is there any difference other than in default preferences? Is there a way to do a single disc with a choice of "give me Server defaults" or "give me Everything defaults"?
The server netinst iso uses the server defaults, partitioning and filesystem selection. there is no way to do both with a single disk today. it would require who knows what work, I imagine the work is possible its just not an option today. probably your best bet again is bfo[1]
Dennis
On 12/08/2016 08:22 AM, Dennis Gilmore wrote:
On miércoles, 7 de diciembre de 2016 1:56:32 PM CST Mike Pinkerton wrote:
On 6 Dec 2016, at 09:43, Kamil Paral wrote:
Which images to cover, that's the heart of the discussion. If you look into our test matrix again, we currently block on 6 of them:
- Workstation Live + netinst
- KDE Live
- Server DVD + netinst
- Everything netinst
What comes first to my mind is Server (DVD + netinst). My guess is that people don't install Server from optical media, but rather from PXE or USB. I can't imagine installing Server boxes from DVDs. But I'd really like to hear from Server users how this is likely or not. Also, Server is most probably not given away at events. I don't know about sending Server DVDs to the developing world, we can make an inquiry about that.
On 6 Dec 2016, at 12:20, Adam Williamson wrote:
So an alternative to kparal's scheme would be to try and consider this, and say we test:
- Workstation live
- Everything netinst
- Server DVD
and consider those to be representative of the broad 'types' of ISOs in terms of the compose process. That way we don't have to test Workstation or Server netinsts, or the KDE live, on optical media.
On 7 Dec 2016, at 09:13, Matthew Miller wrote:
I think: Workstation x86_64 Live, and at least one netinstall image of any flavor (from which, in a pinch, anything else can be installed via kickstart).
I use the Server netinstall image. Use cases include loop mounting the netinstall .iso on boxes with Grub2 -- works on remote boxes where there is no physical access and can be easier than setting up a remote PXE solution -- and burning a CD for local boxes without Grub2.
There is the pxe iso to use boot.fedoraproject.org that would probably better suit your purposes.
I would be fine with dropping the Server DVD.
Does anyone maintain a up-to-date list of the content differences between the Server and Everything netinstall discs? Is there any difference other than in default preferences? Is there a way to do a single disc with a choice of "give me Server defaults" or "give me Everything defaults"?
The server netinst iso uses the server defaults, partitioning and filesystem selection. there is no way to do both with a single disk today. it would require who knows what work, I imagine the work is possible its just not an option today. probably your best bet again is bfo[1]
Dennis
[1] https://boot.fedoraproject.org/ [1]this points to f25 server
This points to everything: http://dl.fedoraproject.org/pub/alt/stage/25_RC-1.3/Everything/x86_64/iso/Fe...
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On jueves, 8 de diciembre de 2016 8:44:19 AM CST Thomas Gilliard wrote:
On 12/08/2016 08:22 AM, Dennis Gilmore wrote:
On miércoles, 7 de diciembre de 2016 1:56:32 PM CST Mike Pinkerton wrote:
On 6 Dec 2016, at 09:43, Kamil Paral wrote:
<snip>
[1] https://boot.fedoraproject.org/ [1]this points to f25 server
This points to everything: http://dl.fedoraproject.org/pub/alt/stage/25_RC-1.3/Everything/x86_64/iso/Fe dora-Everything-netinst-x86_64-25-1.3.iso
Where do you see that? none of the download links on boot.fedoraproject.org I could find point to it.
Dennis
On Thu, Dec 8, 2016 at 11:22 AM, Dennis Gilmore dennis@ausil.us wrote:
On miércoles, 7 de diciembre de 2016 1:56:32 PM CST Mike Pinkerton wrote:
On 6 Dec 2016, at 09:43, Kamil Paral wrote:
Which images to cover, that's the heart of the discussion. If you look into our test matrix again, we currently block on 6 of them:
- Workstation Live + netinst
- KDE Live
- Server DVD + netinst
- Everything netinst
What comes first to my mind is Server (DVD + netinst). My guess is that people don't install Server from optical media, but rather from PXE or USB. I can't imagine installing Server boxes from DVDs. But I'd really like to hear from Server users how this is likely or not. Also, Server is most probably not given away at events. I don't know about sending Server DVDs to the developing world, we can make an inquiry about that.
On 6 Dec 2016, at 12:20, Adam Williamson wrote:
So an alternative to kparal's scheme would be to try and consider this, and say we test:
- Workstation live
- Everything netinst
- Server DVD
and consider those to be representative of the broad 'types' of ISOs in terms of the compose process. That way we don't have to test Workstation or Server netinsts, or the KDE live, on optical media.
On 7 Dec 2016, at 09:13, Matthew Miller wrote:
I think: Workstation x86_64 Live, and at least one netinstall image of any flavor (from which, in a pinch, anything else can be installed via kickstart).
I use the Server netinstall image. Use cases include loop mounting the netinstall .iso on boxes with Grub2 -- works on remote boxes where there is no physical access and can be easier than setting up a remote PXE solution -- and burning a CD for local boxes without Grub2.
There is the pxe iso to use boot.fedoraproject.org that would probably better suit your purposes.
I would be fine with dropping the Server DVD.
Does anyone maintain a up-to-date list of the content differences between the Server and Everything netinstall discs? Is there any difference other than in default preferences? Is there a way to do a single disc with a choice of "give me Server defaults" or "give me Everything defaults"?
The server netinst iso uses the server defaults, partitioning and filesystem selection. there is no way to do both with a single disk today. it would require who knows what work, I imagine the work is possible its just not an option today. probably your best bet again is bfo[1]
Dennis
Admittedly, I have not gone through the whole thread, but I'd like to point out that I *do* use the DVD and netinstall ISOs for optical media boot on real hardware, though in a somewhat indirect manner. Many of the servers I use have IPMI, which allows me to have it boot a remote DVD device with an ISO or a real DVD drive. Due to certain bugs[1], I've increasingly relied on the DVD vs netinstall. From the system's perspective, it's a regular DVD startup, just like with VMs.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1228897
Admittedly, I have not gone through the whole thread, but I'd like to point out that I *do* use the DVD and netinstall ISOs for optical media boot on real hardware, though in a somewhat indirect manner. Many of the servers I use have IPMI, which allows me to have it boot a remote DVD device with an ISO or a real DVD drive. Due to certain
This is interesting. Does IPMI also allow you boot from a "remote USB device"?
bugs[1], I've increasingly relied on the DVD vs netinstall. From the system's perspective, it's a regular DVD startup, just like with VMs.
Well, unfortunately DVD boot on bare metal is different from DVD boot in VMs. The former is proposed to be less tested, the latter would remain fully tested. The question is what form of boot IPMI uses, and that information is probably difficult to find out.
I wonder, why do you prefer remote DVD boot over something like PXE boot, boot.fedoraproject.org or booting the iso directly from grub?
On Mon, Dec 12, 2016 at 8:22 AM, Kamil Paral kparal@redhat.com wrote:
Admittedly, I have not gone through the whole thread, but I'd like to point out that I *do* use the DVD and netinstall ISOs for optical media boot on real hardware, though in a somewhat indirect manner. Many of the servers I use have IPMI, which allows me to have it boot a remote DVD device with an ISO or a real DVD drive. Due to certain
This is interesting. Does IPMI also allow you boot from a "remote USB device"?
Not any of the servers I've worked with. Only remote DVD boot. I've never heard of anyone being able to do remote USB or disk device, as I think the ability to write over the network is considered not desirable...
bugs[1], I've increasingly relied on the DVD vs netinstall. From the system's perspective, it's a regular DVD startup, just like with VMs.
Well, unfortunately DVD boot on bare metal is different from DVD boot in VMs. The former is proposed to be less tested, the latter would remain fully tested. The question is what form of boot IPMI uses, and that information is probably difficult to find out.
I wonder, why do you prefer remote DVD boot over something like PXE boot, boot.fedoraproject.org or booting the iso directly from grub?
The environment I'm working in doesn't allow us to have a PXE boot server. boot.fedoraproject.org doesn't seem to work, and even if it did, that would likely be the equivalent of a netinstall, and netinstalls are broken until someone does something about how kernel package flavors are selected and installed. Booting the iso from grub implies I have something to boot from first (I usually don't), and also setting up grub is a non-trivial task for this stuff.
On Thu, Dec 15, 2016 at 07:31:29AM -0500, Neal Gompa wrote:
This is interesting. Does IPMI also allow you boot from a "remote USB device"?
Not any of the servers I've worked with. Only remote DVD boot. I've never heard of anyone being able to do remote USB or disk device, as I think the ability to write over the network is considered not desirable...
IBM Bladecenters can mount USB images remotely — although that's just a disk image file, same as you can do with an .ISO. No physical media involved in either case.
On Dec 15, 2016 08:09, "Matthew Miller" mattdm@fedoraproject.org wrote:
On Thu, Dec 15, 2016 at 07:31:29AM -0500, Neal Gompa wrote:
This is interesting. Does IPMI also allow you boot from a "remote USB device"?
Not any of the servers I've worked with. Only remote DVD boot. I've never heard of anyone being able to do remote USB or disk device, as I think the ability to write over the network is considered not desirable...
IBM Bladecenters can mount USB images remotely — although that's just a disk image file, same as you can do with an .ISO. No physical media involved in either case.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader ____________________________
All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and present it as optical media. The feature is basically only used for emergencies where regular networking won't do, like when I want the normal network environment for the process and don't want to bother the network folks to change routing and vlans in realtime.
Definitely an edge case, but I'm fairly sure that an image that won't boot from physical optical media also will not boot this way. It would be more important for RHEL users than Fedora users, I assume.
--Pete
All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and present it as optical media. The feature is basically only used for emergencies where regular networking won't do, like when I want the normal network environment for the process and don't want to bother the network folks to change routing and vlans in realtime.
Definitely an edge case, but I'm fairly sure that an image that won't boot from physical optical media also will not boot this way. It would be more important for RHEL users than Fedora users, I assume.
--Pete
Thanks for clarification. Just to be absolutely clear, this proposal doesn't affect RHEL release process in any way. This would be Fedora-only change. And it is a good remark that users of such systems are probably more likely to be installing RHEL/CentOS than Fedora due to a longer support period.
On Sat, Dec 17, 2016 at 6:22 AM, Kamil Paral kparal@redhat.com wrote:
All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and present it as optical media. The feature is basically only used for emergencies where regular networking won't do, like when I want the normal network environment for the process and don't want to bother the network folks to change routing and vlans in realtime.
Definitely an edge case, but I'm fairly sure that an image that won't boot from physical optical media also will not boot this way. It would be more important for RHEL users than Fedora users, I assume.
--Pete
Thanks for clarification. Just to be absolutely clear, this proposal doesn't affect RHEL release process in any way. This would be Fedora-only change. And it is a good remark that users of such systems are probably more likely to be installing RHEL/CentOS than Fedora due to a longer support period.
You'd be surprised. Given how much easier it has gotten to upgrade Fedora systems, and some people (like myself) prefer to have new software for various purposes and keep up to date with upstreams for security purposes, I would be very surprised if there weren't more Fedora servers being rolled out. Stuff like configuration management has made things much easier in that regard, too.
On Mon, Dec 19, 2016 at 10:36 AM, John Florian john.florian@dart.biz wrote:
On Fri, 2016-12-16 at 15:49 -0600, Pete Travis wrote:
All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and present it as optical media. The feature is basically only used for emergencies where regular networking won't do,
My co-workers use iDRAC installs for non-emergency cases. We need to ships servers around the world and sometimes the import laws are such a PITA that's easier to have the facility make the hardware purchase locally and then said co-workers install Fedora remotely via the DRAC.
I've not done it myself so I cannot speak at all as to how various media types work or fail, but just thought I'd mention that this type of scenario is very real, albeit admittedly much less common.
Indeed. There's also the matter of bandwidth availability. In my case, we're not afflicted by import laws quite like that, but our internal datacenter bandwidth is so much better than the local internet connection that it's just easier to install remotely. And in some cases, we don't have local hands that could do the install anyway...
On Fri, 2016-12-16 at 15:49 -0600, Pete Travis wrote:
All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and present it as optical media. The feature is basically only used for emergencies where regular networking won't do, like when I want the normal network environment for the process and don't want to bother the network folks to change routing and vlans in realtime.
Definitely an edge case, but I'm fairly sure that an image that won't boot from physical optical media also will not boot this way.
I suspect this is not necessarily the case. We've had a real bug in the past where the ISO images would boot when attached to virtual machines as virtual optical media, but would fail to boot on many/most systems when actually written to a physical optical disc. I have no idea which side of that split this system falls on, but it seems at least plausible that it would act more like the 'virtual disc' case than the 'physical disc' case...
On Fri, 2016-12-16 at 15:49 -0600, Pete Travis wrote: All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and present it as optical media. The feature is basically only used for emergencies where regular networking won't do,
My co-workers use iDRAC installs for non-emergency cases. We need to ships servers around the world and sometimes the import laws are such a PITA that's easier to have the facility make the hardware purchase locally and then said co-workers install Fedora remotely via the DRAC.
I've not done it myself so I cannot speak at all as to how various media types work or fail, but just thought I'd mention that this type of scenario is very real, albeit admittedly much less common.
On 19 December 2016 at 10:36, John Florian john.florian@dart.biz wrote:
On Fri, 2016-12-16 at 15:49 -0600, Pete Travis wrote:
All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and present it as optical media. The feature is basically only used for emergencies where regular networking won't do,
My co-workers use iDRAC installs for non-emergency cases. We need to ships servers around the world and sometimes the import laws are such a PITA that's easier to have the facility make the hardware purchase locally and then said co-workers install Fedora remotely via the DRAC.
The iDRAC/iLO/BMC/IMM mounting systems seems to work in the same way that the qemu uses the iso image to boot. Whatever causes 'real' hardware to fail in certain cases does not seem to affect the remote mounting systems or the qemu.
I have used the remote booting quite a lot and at least once with an image which wasn't supposed to work with a real DVD image. It worked fine in those cases. [The usual big problem is uploading howmany gigabyes over a DSL or cable modem to remote server in Germany versus the image]
I've not done it myself so I cannot speak at all as to how various media types work or fail, but just thought I'd mention that this type of scenario is very real, albeit admittedly much less common.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Mon, Dec 19, 2016 at 10:35 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 19 December 2016 at 10:36, John Florian john.florian@dart.biz wrote:
On Fri, 2016-12-16 at 15:49 -0600, Pete Travis wrote:
All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and present it as optical media. The feature is basically only used for emergencies where regular networking won't do,
My co-workers use iDRAC installs for non-emergency cases. We need to ships servers around the world and sometimes the import laws are such a PITA that's easier to have the facility make the hardware purchase locally and then said co-workers install Fedora remotely via the DRAC.
The iDRAC/iLO/BMC/IMM mounting systems seems to work in the same way that the qemu uses the iso image to boot. Whatever causes 'real' hardware to fail in certain cases does not seem to affect the remote mounting systems or the qemu.
Qemu CD/DVD device and actual optical drives should have the same dependency. I know the example case [1] it was a BIOS bug that syslinux was able to work around with an update. We'd never find such a thing unless someone runs into it with affected hardware, which did happen and that's how it ended up getting fixed in the same release cycle.
Whereas a more recent problem, where both ISO file attached to a qemu cd/dvd device and also burned to an optical disk would work, but imaged using dd to a USB stick would not, was due to a missing boot.img/stage 1 bootloader. If that same ISO were attached with a qemu hard drive device instead, it too would fail. How the bootloader is located by the firmware differs depending on whether it's an optical device (El Torito provides the hint) or a disk drive, and a USB stick is treated as a disk drive.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1148087
Qemu CD/DVD device and actual optical drives should have the same dependency. I know the example case [1] it was a BIOS bug that syslinux was able to work around with an update. We'd never find such a thing unless someone runs into it with affected hardware, which did happen and that's how it ended up getting fixed in the same release cycle.
If you're certain about this, that would be good news, because it would mean that limited bare-metal testing is not a big problem (generic problems would be detected by OpenQA). I believe it's still needed to do bare-metal testing at least with Final RC images, because the code paths are still different, and even if there was a specific firmware bug like in [1], we can still get "lucky" and hit it in our testing. But it also means we can limit our manual testing to just a single Live image, single netinst image, etc, and still trust the results reasonably well.
Whereas a more recent problem, where both ISO file attached to a qemu cd/dvd device and also burned to an optical disk would work, but imaged using dd to a USB stick would not, was due to a missing boot.img/stage 1 bootloader. If that same ISO were attached with a qemu hard drive device instead, it too would fail. How the bootloader is located by the firmware differs depending on whether it's an optical device (El Torito provides the hint) or a disk drive, and a USB stick is treated as a disk drive.
That is interesting. I poked Jan Sedlak and asked him to look whether we could mount some images as hdd devices in OpenQA, so that potential dd-related problems are discovered immediately.
On Wed, 2017-01-04 at 09:50 -0500, Kamil Paral wrote:
That is interesting. I poked Jan Sedlak and asked him to look whether we could mount some images as hdd devices in OpenQA, so that potential dd-related problems are discovered immediately.
We planned to do this at the time, just that no-one's got around to it yet. https://phab.qa.fedoraproject.org/T789
The iDRAC/iLO/BMC/IMM mounting systems seems to work in the same way that the qemu uses the iso image to boot. Whatever causes 'real' hardware to fail in certain cases does not seem to affect the remote mounting systems or the qemu.
I have used the remote booting quite a lot and at least once with an image which wasn't supposed to work with a real DVD image. It worked fine in those cases.
This is great info, thanks a lot.
On Thu, 2016-12-15 at 07:31 -0500, Neal Gompa wrote:
and even if it did, that would likely be the equivalent of a netinstall, and netinstalls are broken until someone does something about how kernel package flavors are selected and installed.
Sorry, what do you mean by this? And how is it different on DVDs?
On Thu, Dec 15, 2016 at 1:03 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-12-15 at 07:31 -0500, Neal Gompa wrote:
and even if it did, that would likely be the equivalent of a netinstall, and netinstalls are broken until someone does something about how kernel package flavors are selected and installed.
Sorry, what do you mean by this? And how is it different on DVDs?
I mean this bug[1] that became a thing ever since we split up the kernel into lots of subpackages. Anaconda/DNF will install the wrong variant (like debug instead of regular) of any kernel subpackage because they all provide (and rightfully so) the same name. It breaks stuff as simple as having Wi-Fi in Fedora Workstation after netinstall, or makes it so that you can't rely on the "kernel-devel" requirement for dkms. It's a natural consequence of how our kernel packaging works, and how yum and dnf cannot infer the correct default flavor of kernel packages from the environment.
I haven't installed from the DVD in a while, but last I recall, something about DVD installs prevents this from happening. It may very well occur now with DVD installs, too.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1228897
On Thu, 2016-12-15 at 13:22 -0500, Neal Gompa wrote:
On Thu, Dec 15, 2016 at 1:03 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-12-15 at 07:31 -0500, Neal Gompa wrote:
and even if it did, that would likely be the equivalent of a netinstall, and netinstalls are broken until someone does something about how kernel package flavors are selected and installed.
Sorry, what do you mean by this? And how is it different on DVDs?
I mean this bug[1] that became a thing ever since we split up the kernel into lots of subpackages. Anaconda/DNF will install the wrong variant (like debug instead of regular) of any kernel subpackage because they all provide (and rightfully so) the same name. It breaks stuff as simple as having Wi-Fi in Fedora Workstation after netinstall, or makes it so that you can't rely on the "kernel-devel" requirement for dkms. It's a natural consequence of how our kernel packaging works, and how yum and dnf cannot infer the correct default flavor of kernel packages from the environment.
Oh, right, that one. Isn't it basically the same as https://bugzilla.redhat.com/show_bug.cgi?id=1192189 ?
I haven't installed from the DVD in a while, but last I recall, something about DVD installs prevents this from happening. It may very well occur now with DVD installs, too.
The difference would just be in which of the kernel packages are present on the DVD for it to install, I suppose.
On Thu, Dec 15, 2016 at 1:49 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-12-15 at 13:22 -0500, Neal Gompa wrote:
On Thu, Dec 15, 2016 at 1:03 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-12-15 at 07:31 -0500, Neal Gompa wrote:
and even if it did, that would likely be the equivalent of a netinstall, and netinstalls are broken until someone does something about how kernel package flavors are selected and installed.
Sorry, what do you mean by this? And how is it different on DVDs?
I mean this bug[1] that became a thing ever since we split up the kernel into lots of subpackages. Anaconda/DNF will install the wrong variant (like debug instead of regular) of any kernel subpackage because they all provide (and rightfully so) the same name. It breaks stuff as simple as having Wi-Fi in Fedora Workstation after netinstall, or makes it so that you can't rely on the "kernel-devel" requirement for dkms. It's a natural consequence of how our kernel packaging works, and how yum and dnf cannot infer the correct default flavor of kernel packages from the environment.
Oh, right, that one. Isn't it basically the same as https://bugzilla.redhat.com/show_bug.cgi?id=1192189 ?
It is essentially the same core issue, yes. It can happen with Yum, but for some reason, it happens less often.
I haven't installed from the DVD in a while, but last I recall, something about DVD installs prevents this from happening. It may very well occur now with DVD installs, too.
The difference would just be in which of the kernel packages are present on the DVD for it to install, I suppose.
Most likely.
On Thu, 2016-12-15 at 14:37 -0500, Neal Gompa wrote:
It is essentially the same core issue, yes. It can happen with Yum, but for some reason, it happens less often.
yum had rather different logic for resolving ambiguous dependencies than libsolv does.
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
On Thu, 2016-12-15 at 14:37 -0500, Neal Gompa wrote:
It is essentially the same core issue, yes. It can happen with Yum, but for some reason, it happens less often.
yum had rather different logic for resolving ambiguous dependencies than libsolv does.
Is the current behavior documented? IIRC yum used the shortest package name, and then an alphabetic sort. For the particular case of the kernel vs. kernel-debug packages, shortest package name would solve the issue.
On Thu, 2016-12-15 at 14:04 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
On Thu, 2016-12-15 at 14:37 -0500, Neal Gompa wrote:
It is essentially the same core issue, yes. It can happen with Yum, but for some reason, it happens less often.
yum had rather different logic for resolving ambiguous dependencies than libsolv does.
Is the current behavior documented? IIRC yum used the shortest package name, and then an alphabetic sort. For the particular case of the kernel vs. kernel-debug packages, shortest package name would solve the issue.
I don't think it is, no. You could possibly find it with the clue that it changed substantially between 0.6.13 and 0.6.14 (see https://bugzilla.redhat.com/show_bug.cgi?id=1192182 ). I've looked at it before, but don't remember where it is any more. The libsolv repo is https://github.com/openSUSE/libsolv .
I mean this bug[1] that became a thing ever since we split up the kernel into lots of subpackages. Anaconda/DNF will install the wrong variant (like debug instead of regular) of any kernel subpackage because they all provide (and rightfully so) the same name. It breaks stuff as simple as having Wi-Fi in Fedora Workstation after netinstall,
If you can provide a simple reproducer for some essential part of GNOME/KDE/Server breaking (like wifi) when installing from netinst, we can propose it as a release blocker for Fedora 26. The bigger impact, and the larger audience affected, the better. Maybe start a new thread for this, so that we don't go too off topic here, thanks.
On 8 Dec 2016, at 11:22, Dennis Gilmore wrote:
On miércoles, 7 de diciembre de 2016 1:56:32 PM CST Mike Pinkerton wrote:
I use the Server netinstall image. Use cases include loop mounting the netinstall .iso on boxes with Grub2 -- works on remote boxes where there is no physical access and can be easier than setting up a remote PXE solution -- and burning a CD for local boxes without Grub2.
There is the pxe iso to use boot.fedoraproject.org that would probably better suit your purposes.
How does that work on a remote box with no physical access, no DHCP and no console access?
Does anyone maintain a up-to-date list of the content differences between the Server and Everything netinstall discs? Is there any difference other than in default preferences? Is there a way to do a single disc with a choice of "give me Server defaults" or "give me Everything defaults"?
The server netinst iso uses the server defaults, partitioning and filesystem selection. there is no way to do both with a single disk today. it would require who knows what work, I imagine the work is possible its just not an option today.
Aren't the server defaults just a matter of package selection?
On Fri, Dec 9, 2016 at 5:31 PM, Mike Pinkerton pselists@mindspring.com wrote:
On 8 Dec 2016, at 11:22, Dennis Gilmore wrote:
On miércoles, 7 de diciembre de 2016 1:56:32 PM CST Mike Pinkerton wrote:
I use the Server netinstall image. Use cases include loop mounting the netinstall .iso on boxes with Grub2 -- works on remote boxes where there is no physical access and can be easier than setting up a remote PXE solution -- and burning a CD for local boxes without Grub2.
There is the pxe iso to use boot.fedoraproject.org that would probably better suit your purposes.
How does that work on a remote box with no physical access, no DHCP and no console access?
How does netinstall work on that same box?
Bigger issue as I see it, is the lack of UEFI support for BFO. None of my hardware has BIOS firmware.
Does anyone maintain a up-to-date list of the content differences between the Server and Everything netinstall discs? Is there any difference other than in default preferences? Is there a way to do a single disc with a choice of "give me Server defaults" or "give me Everything defaults"?
The server netinst iso uses the server defaults, partitioning and filesystem selection. there is no way to do both with a single disk today. it would require who knows what work, I imagine the work is possible its just not an option today.
Aren't the server defaults just a matter of package selection?
Nope, it's part of the productimg file, which is what sets the default package selection and also defines what is default partitioning. So this is netinstall image specific.
Now that Fedora 25 is out of the door, I'd like to start a discussion about the future of officially-supported (meaning rigorously tested) optical media for future Fedora releases.
The discussion died off, so let me summarize and propose a plan.
We haven't received as much feedback as I hoped for. Maybe people don't care enough about optical disks to even respond, or it might be a different reason. But we also didn't receive as much negative feedback as I feared. So hopefully this does not negatively impact too many people. The comments under the Phoronix article [1] weren't too helpful either, a few rants but no-one cared to follow up with some explanation or system specification which would be negatively affected for his/her use case. Some of them, I believe, just read the article title without realizing this only affects Alpha/Beta media or certain flavors of Final media.
[1] http://phoronix.com/scan.php?page=news_item&px=Fedora-Post-25-Optical-Fu...
Idea #1: Do not block on optical media issues for Alpha and Beta releases
This is the less controversial idea, I believe. We received a concern from Matthew, who was worried that we might find out too late if we don't check it for Alpha/Beta. I partly agree, but believe we should solve it with an improved QA processes, instead of bumping the release criteria to apply earlier. He did not object to this, and nobody else did, so I assume everyone agrees :-) If there are no further concerns, I'll prepare a criterion adjustment proposal for this.
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst)
This is a bolder variant of the previous idea and can be done separately or combined with it. It makes optical media functionality not guaranteed even for Final release, but just for certain Fedora flavors or image types for which it makes sense (not all of them). Which images to cover, that's the heart of the discussion. If you look into our test matrix again, we currently block on 6 of them: * Workstation Live + netinst * KDE Live * Server DVD + netinst * Everything netinst
This was received with reasonably positive reception as well. But it's harder to compile a list which images should be covered by criteria and which not. - Workstation Live will be covered, that's clear - we give out these DVDs at events, it's sent out to the developing world - Everything netinst is the most universal and generic netinst, so covering that one means we don't need to cover Workstation netinst and Server netinst. People seem to agree to this. - Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs. If we cover Workstation Live, it's improbable that only KDE Live would break, but not impossible. If such thing happens, are people OK with releasing Fedora XX KDE Live only bootable over USB? - Server DVD is a mixed bag. Matthew didn't include it in his block-list, Adam did. Neal uses it over IMPI (but netinst would be good enough for him IIUIC, sans some package deps issue which can be solved using a kickstart). I would appreciate more feedback from Server folks. Again, we'll cover netinst so it's improbable DVD would break, but not impossible. Are people OK releasing it only bootable over USB (and PXE)?
Thanks.
On Thu, Dec 15, 2016 at 07:08:13AM -0500, Kamil Paral wrote:
Idea #1: Do not block on optical media issues for Alpha and Beta releases
This is the less controversial idea, I believe. We received a concern from Matthew, who was worried that we might find out too late if we don't check it for Alpha/Beta. I partly agree, but believe we should solve it with an improved QA processes, instead of bumping the release criteria to apply earlier. He did not object to this, and nobody else did, so I assume everyone agrees :-) If there are no further concerns, I'll prepare a criterion adjustment proposal for this.
+1
This was received with reasonably positive reception as well. But it's harder to compile a list which images should be covered by criteria and which not.
- Workstation Live will be covered, that's clear - we give out these DVDs at events, it's sent out to the developing world
- Everything netinst is the most universal and generic netinst, so covering that one means we don't need to cover Workstation netinst and Server netinst. People seem to agree to this.
+1
- Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs. If we cover Workstation Live, it's improbable that only KDE Live would break, but not impossible. If such thing happens, are people OK with releasing Fedora XX KDE Live only bootable over USB?
I continue to believe we need the ability to release Spins independent of the main release cycle. If there's a KDE-specific problem, rather than that holding up the release *or* waiting six to eight months for it to work again, there should be the ability to have it fixed a week later. Or for that matter, if Workstation slips a month and KDE doesn't want to, should be fine.
I know that we're not there yet, but I'll keep repeating it as a desired state. :)
- Server DVD is a mixed bag. Matthew didn't include it in his block-list, Adam did. Neal uses it over IMPI (but netinst would be good enough for him IIUIC, sans some package deps issue which can be solved using a kickstart). I would appreciate more feedback from Server folks. Again, we'll cover netinst so it's improbable DVD would break, but not impossible. Are people OK releasing it only bootable over USB (and PXE)?
I think netinst + USB covers the Server case well enough.
Kamil Paral wrote:
- Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs.
If we cover Workstation Live, it's improbable that only KDE Live would break, but not impossible. If such thing happens, are people OK with releasing Fedora XX KDE Live only bootable over USB?
Yet another step towards making Fedora KDE a second-class citizen. :-(
Either we continue supporting DVD media for all spins/editions or for none.
Kevin Kofler
On December 15, 2016 9:32:36 PM PST, Kevin Kofler kevin.kofler@chello.at wrote:
Kamil Paral wrote:
- Nobody argued for KDE Live. We probably don't bulk press KDE Live
DVDs.
If we cover Workstation Live, it's improbable that only KDE Live
would
break, but not impossible. If such thing happens, are people OK with releasing Fedora XX KDE Live only bootable over USB?
Yet another step towards making Fedora KDE a second-class citizen. :-(
Either we continue supporting DVD media for all spins/editions or for none.
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I don't see why we can't just say the requirement is that we test "at least one release blocking live image". I can't see any reason we have to specify which one we test.
On December 15, 2016 9:32:36 PM PST, Kevin Kofler kevin.kofler@chello.at wrote:
Kamil Paral wrote:
- Nobody argued for KDE Live. We probably don't bulk press KDE Live
DVDs.
If we cover Workstation Live, it's improbable that only KDE Live
would
break, but not impossible. If such thing happens, are people OK with releasing Fedora XX KDE Live only bootable over USB?
Yet another step towards making Fedora KDE a second-class citizen. :-(
Either we continue supporting DVD media for all spins/editions or for none.
Why all-or-nothing approach? My original proposal talks about 'all' being quite time consuming and probably losing the "worth the time" ratio quickly. But isn't "something" better than "nothing"? That's exactly what we're talking about here - having a set of "guaranteed to be working" media, ideally those generic enough to be widely usable (KDE can be installed from netinst, even if KDE Live doesn't boot from a spinning disc), or those mostly used in this scenario (that would be Workstation Live).
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I don't see why we can't just say the requirement is that we test "at least one release blocking live image". I can't see any reason we have to specify which one we test.
Which images we test and how often is an internal QA process that we can decide ourselves according to our resources. But I'm trying to figure out here on which images we *block*. "At least one Live image" is probably something people wouldn't like if KDE turned out to be working and Workstation not (in terms of optical boot). And I don't want to belittle KDE here, but Workstation is the main face of Fedora (at least by looking at getfedora.org, and reading the reviews).
On Fri, Dec 16, 2016 at 06:32:36AM +0100, Kevin Kofler wrote:
- Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs.
If we cover Workstation Live, it's improbable that only KDE Live would break, but not impossible. If such thing happens, are people OK with releasing Fedora XX KDE Live only bootable over USB?
Yet another step towards making Fedora KDE a second-class citizen. :-(
Note "nobody argued for". A close corollary is: "Nobody said: hey, I depend on physical KDE optical media, so I promise to test it for each Fedora Alpha, Beta, and release."
On 12/16/2016 04:04 PM, Matthew Miller wrote:
On Fri, Dec 16, 2016 at 06:32:36AM +0100, Kevin Kofler wrote:
- Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs.
If we cover Workstation Live, it's improbable that only KDE Live would break, but not impossible. If such thing happens, are people OK with releasing Fedora XX KDE Live only bootable over USB?
Yet another step towards making Fedora KDE a second-class citizen. :-(
Note "nobody argued for". A close corollary is: "Nobody said: hey, I depend on physical KDE optical media, so I promise to test it for each Fedora Alpha, Beta, and release."
What you say only confirms Kevin.
Matthew Miller wrote:
Note "nobody argued for". A close corollary is: "Nobody said: hey, I depend on physical KDE optical media, so I promise to test it for each Fedora Alpha, Beta, and release."
That's because of the previous step of making Fedora KDE a second-class citizen, the discontinuation of pressed KDE live media.
I really don't see why we cannot go back to doing multi-desktop pressed media. As I understand it, they cost the same as or only marginally more (small surcharge for dual-layer) than Workstation-only, they offer the exact same Workstation experience, but they also give the user the other options.
That, or finally give up on pressing DVDs entirely (where EMEA has now said for 1 or 2 releases that they'd stop doing DVDs in the next release, but then ended up producing more Workstation DVDs each time). If you think people will want DVDs, then do them right (multi-desktop), if you think they won't, then don't do them.
Kevin Kofler
Let's close this up.
Idea #1: Do not block on optical media issues for Alpha and Beta releases
Nobody argued against this since last time, so I'm going to propose criterion adjustment on the test list.
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst)
The outcome seems to be we should block on Workstation Live and Everything netinst. Stephen confirmed his "remote DVD drive" installation was not affected by the firmware issue causing some optical disks failing to boot. Also just testing one Live and one netinst should give us a high probability to detect all such issues, because all the Live and DVD+netinst images are created the same way. I'll again propose a criterion adjustment on the test list.
Thanks everyone for providing valuable feedback.
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst)
The outcome seems to be we should block on Workstation Live and Everything netinst. Stephen confirmed his "remote DVD drive" installation was not affected by the firmware issue causing some optical disks failing to boot. Also just testing one Live and one netinst should give us a high probability to detect all such issues, because all the Live and DVD+netinst images are created the same way. I'll again propose a criterion adjustment on the test list.
Thanks everyone for providing valuable feedback.
Sigh, I found a minor setback. We agreed Everything netinst is the best candidate for release blocking as an optical medium, but today I found out Everything netinst is marked as *not* release blocking at all [1]. Which some somewhat funny, because I always considered it as such (and I think more of us did), and this is quite a surprise for me. And if we don't block on it, we can't obviously block on it when it's burned to a spinning disc.
One solution here is to make Everything netinst release blocking. There is a good use case for that, it's the most universal install medium we have (you can install anything from it). A different solution is to mark e.g. Server netinst as blocking for optical media, but that will cover only Server (so no Workstation or KDE support in case optical boot is really broken).
Thoughts?
[1] https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed...
On Wed, 2017-01-11 at 08:44 -0500, Kamil Paral wrote:
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst)
The outcome seems to be we should block on Workstation Live and Everything netinst. Stephen confirmed his "remote DVD drive" installation was not affected by the firmware issue causing some optical disks failing to boot. Also just testing one Live and one netinst should give us a high probability to detect all such issues, because all the Live and DVD+netinst images are created the same way. I'll again propose a criterion adjustment on the test list.
Thanks everyone for providing valuable feedback.
Sigh, I found a minor setback. We agreed Everything netinst is the best candidate for release blocking as an optical medium, but today I found out Everything netinst is marked as *not* release blocking at all [1]. Which some somewhat funny, because I always considered it as such (and I think more of us did), and this is quite a surprise for me. And if we don't block on it, we can't obviously block on it when it's burned to a spinning disc.
One solution here is to make Everything netinst release blocking. There is a good use case for that, it's the most universal install medium we have (you can install anything from it). A different solution is to mark e.g. Server netinst as blocking for optical media, but that will cover only Server (so no Workstation or KDE support in case optical boot is really broken).
Thoughts?
+1 for that. I believe the sticking point before has been the question of what team/WG/SIG/whatever is 'responsible' for the image, but that seems a kind of overly-theoretical concern.
On Wed, Jan 11, 2017 at 6:44 AM, Kamil Paral kparal@redhat.com wrote:
One solution here is to make Everything netinst release blocking. There is a good use case for that, it's the most universal install medium we have (you can install anything from it). A different solution is to mark e.g. Server netinst as blocking for optical media, but that will cover only Server (so no Workstation or KDE support in case optical boot is really broken).
Thoughts?
The productimg is media specific and is what determines default partitioning, not what product you pick in software selection. If you pick Server or Cloud Edition using Everything netinstall, you get ext4 on LVM with a massive /home volume rather unsuitable for servers, and no free space in the VG for docker-storage-setup to configure for itself. Everything netinstall's partitioning is the same as Workstation's.
I see the candidate options for optical installations as: Workstation-Live ISO, Atomic host ISO, and Server dvd ISO. Those will all be release blocking for Fedora 26. So the question to ask their respective WG's is if the inability to optically boot is blocking. And then I'd say skip the netinstalls for optical boot criteria entirely.
On Thu, Jan 12, 2017 at 1:11 PM, Chris Murphy lists@colorremedies.com wrote:
If you pick Server or Cloud Edition using Everything netinstall, you get ext4 on LVM with a massive /home volume rather unsuitable for servers, and no free space in the VG for docker-storage-setup to configure for itself. Everything netinstall's partitioning is the same as Workstation's.
That's wrong. Everything does something no other product does. It's ext4 on LVM, with just root and swap LV's, with root taking up all the space not reserved for swap. So...it'd work for Workstation and Server, but it's not the WG intended layout where /home is separate for Workstation, and for Server they want XFS and reserve space in the VG for other purposes (separate /var possibly or space for docker-storage-setup for containers). So I'd say while non-fatal, it's also not ideal for any of the products and thus not worth blocking on.
On Thu, Jan 12, 2017 at 1:11 PM, Chris Murphy lists@colorremedies.com wrote:
If you pick Server or Cloud Edition using Everything netinstall, you get ext4 on LVM with a massive /home volume rather unsuitable for servers, and no free space in the VG for docker-storage-setup to configure for itself. Everything netinstall's partitioning is the same as Workstation's.
That's wrong. Everything does something no other product does. It's ext4 on LVM, with just root and swap LV's, with root taking up all the space not reserved for swap. So...it'd work for Workstation and Server, but it's not the WG intended layout where /home is separate for Workstation, and for Server they want XFS and reserve space in the VG for other purposes (separate /var possibly or space for docker-storage-setup for containers). So I'd say while non-fatal, it's also not ideal for any of the products and thus not worth blocking on.
I lived under the impression that Workstation netinst only offers you Workstation package set by default, and Server netinst the Server package set. That was my major concern, not partitioning layout. But I tried it again today, and I see all package sets on both images. So I was clearly wrong.
The partitioning setup on Everything netinst seems to me to be actually the best universal choice for any use case (it's not the intended setup for any flavor, yes, but still better than e.g. having a Workstation with Server partitioning layout, or vice versa). For Workstation users, the only case where you need to install from Everything netinst is when a) your hardware can't boot Workstation Live b) Workstation netinst has optical boot broken c) you can't boot from USB. That's such an edge case, that I don't think it's a problem to have a different partitioning setup. It's a last resort help and you can be expected to manually setup the partitioning differently if you don't like the universal one. For Server, you'll need to use Everything netinst if a) both Server DVD and Server netinst have optical boot broken b) you can't boot from USB or PXE (or some of those remote CDROM methods). Since Server people are more technical, I hope setting up a custom layout (if the universal one doesn't fit) is not such a big problem. The most likely use case here goes to KDE (or any of the non-release-blocking spins). If your hardware can't boot KDE Live or the image has its optical boot broken, your immediate next choice is Everything netinst. And in this case, the universal partition layout is again better than e.g. if you booted Server netinst.
So after considering this, I'd still like to keep Everything netinst as the universal fallback if the flavored images have their optical boot broken.