A large computer vendor with whom we have a friendly relationship would like to update the image they're shipping on their systems so that 1) new users don't have quite so many updates immediately and 2) auiu newer kernel helps with some upcoming things *vague vague handwavy vague*.
I can think of four possibilities:
1. Sure, use the live-respins!
2. The live-respins are unofficial, but we have run [this specific workstation iso] through our standard validation tests and we recommend it for your use.
3. Use the netinstall and choose "apply updates" (or whatever that option is called) when making your distribution image.
4. Uh, sorry, we got nothin'.
In all cases, they will run through their own internal testing and validation. And, because of calendar things, they'd really love an answer before the 26th of this month, which I know is short notice.
Of the above, I think #2 is the best, but requires someone other than me to do significant work. Sooooo, I'm raising it here. :)
On Tue, Jan 19, 2021 at 3:50 PM Matthew Miller mattdm@fedoraproject.org wrote:
A large computer vendor with whom we have a friendly relationship would like to update the image they're shipping on their systems so that 1) new users don't have quite so many updates immediately and 2) auiu newer kernel helps with some upcoming things *vague vague handwavy vague*.
I can think of four possibilities:
Sure, use the live-respins!
The live-respins are unofficial, but we have run [this specific workstation iso] through our standard validation tests and we recommend it for your use.
Use the netinstall and choose "apply updates" (or whatever that option is called) when making your distribution image.
Uh, sorry, we got nothin'.
In all cases, they will run through their own internal testing and validation. And, because of calendar things, they'd really love an answer before the 26th of this month, which I know is short notice.
Of the above, I think #2 is the best, but requires someone other than me to do significant work. Sooooo, I'm raising it here. :)
If they're doing the QE the #2 option isn't too hard, what artifact do they need, the iso installer or the live image, something else?
Good morning,
21/1/19 16:52(e)an, Peter Robinson igorleak idatzi zuen:
On Tue, Jan 19, 2021 at 3:50 PM Matthew Miller mattdm@fedoraproject.org wrote:
A large computer vendor with whom we have a friendly relationship would like to update the image they're shipping on their systems so that 1) new users don't have quite so many updates immediately and 2) auiu newer kernel helps with some upcoming things *vague vague handwavy vague*.
I can think of four possibilities:
Sure, use the live-respins!
The live-respins are unofficial, but we have run [this specific workstation iso] through our standard validation tests and we recommend it for your use.
Use the netinstall and choose "apply updates" (or whatever that option is called) when making your distribution image.
Uh, sorry, we got nothin'.
In all cases, they will run through their own internal testing and validation. And, because of calendar things, they'd really love an answer before the 26th of this month, which I know is short notice.
Of the above, I think #2 is the best, but requires someone other than me to do significant work. Sooooo, I'm raising it here. :)
If they're doing the QE the #2 option isn't too hard, what artifact do they need, the iso installer or the live image, something else?
Actually we already test the respins: https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=33...
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
On Tue, Jan 19, 2021 at 10:50 AM Matthew Miller mattdm@fedoraproject.org wrote:
A large computer vendor with whom we have a friendly relationship would like to update the image they're shipping on their systems so that 1) new users don't have quite so many updates immediately and 2) auiu newer kernel helps with some upcoming things *vague vague handwavy vague*.
I can think of four possibilities:
Sure, use the live-respins!
The live-respins are unofficial, but we have run [this specific workstation iso] through our standard validation tests and we recommend it for your use.
Use the netinstall and choose "apply updates" (or whatever that option is called) when making your distribution image.
Uh, sorry, we got nothin'.
Is there a reason we can't make option 4 to be: officially create OEM images and create an OEM preload guide? I don't personally know how preloads work, even though I'm trying to figure out how to improve "preloaded Fedora" experience over the next couple of cycles for Fedora KDE.
It might also make sense to make either monthly or quarterly full recomposes with updates for downstreams with all the artifacts, similar to how Microsoft used to do "rollup images" to support OEM preloads.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Tue, Jan 19, 2021 at 11:12:29AM -0500, Neal Gompa wrote:
Is there a reason we can't make option 4 to be: officially create OEM images and create an OEM preload guide? I don't personally know how preloads work, even though I'm trying to figure out how to improve "preloaded Fedora" experience over the next couple of cycles for Fedora KDE.
It might also make sense to make either monthly or quarterly full recomposes with updates for downstreams with all the artifacts, similar to how Microsoft used to do "rollup images" to support OEM preloads.
We totally _could_, if someone is willing to add that commitment to their workload. Depending on the scope (x86_64 Workstation only, say) it isn't *gigantic* but it's not like it's trivial.
On Tue, Jan 19, 2021 at 11:14 AM Neal Gompa ngompa13@gmail.com wrote:
Is there a reason we can't make option 4 to be: officially create OEM images and create an OEM preload guide?
Timeline mostly. It's certainly something we could do in the future.
On Tue, 2021-01-19 at 10:50 -0500, Matthew Miller wrote:
A large computer vendor with whom we have a friendly relationship would like to update the image they're shipping on their systems so that 1) new users don't have quite so many updates immediately and 2) auiu newer kernel helps with some upcoming things *vague vague handwavy vague*.
I can think of four possibilities:
Sure, use the live-respins!
The live-respins are unofficial, but we have run [this specific
workstation iso] through our standard validation tests and we recommend it for your use.
- Use the netinstall and choose "apply updates" (or whatever that option is
called) when making your distribution image.
- Uh, sorry, we got nothin'.
In all cases, they will run through their own internal testing and validation. And, because of calendar things, they'd really love an answer before the 26th of this month, which I know is short notice.
Of the above, I think #2 is the best, but requires someone other than me to do significant work. Sooooo, I'm raising it here. :)
So we kicked this around in the internal team meeting today, and we have a thought and a question:
1. We're not too keen on just using the respins as-is. They're really pretty unofficial: they're not built by infra, and they're not built the same way we build 'official' images. That's fine for something we just kinda let sit there and say "hey use it if you want to", but it's not really appropriate for something a Large Computer Vendor would be deploying on thousands of boxes sold to the public. It seems better to be deploying actually-official Fedora bits on those.
2. What's the expected cadence, here? Are they wanting a respin every week or maybe one per cycle? Because that seems likely to affect what we do. If it's just a once-per-cycle thing, we could maybe just have releng manually fire a post-release compose with a live image profile in it, and I can manually schedule openQA tests for that compose.
Thanks!
On 19/01/2021 12:20, Adam Williamson wrote:
On Tue, 2021-01-19 at 10:50 -0500, Matthew Miller wrote:
A large computer vendor with whom we have a friendly relationship would like to update the image they're shipping on their systems so that 1) new users don't have quite so many updates immediately and 2) auiu newer kernel helps with some upcoming things *vague vague handwavy vague*.
I can think of four possibilities:
Sure, use the live-respins!
The live-respins are unofficial, but we have run [this specific
workstation iso] through our standard validation tests and we recommend it for your use.
- Use the netinstall and choose "apply updates" (or whatever that option is
called) when making your distribution image.
- Uh, sorry, we got nothin'.
In all cases, they will run through their own internal testing and validation. And, because of calendar things, they'd really love an answer before the 26th of this month, which I know is short notice.
Of the above, I think #2 is the best, but requires someone other than me to do significant work. Sooooo, I'm raising it here. :)
So we kicked this around in the internal team meeting today, and we have a thought and a question:
- We're not too keen on just using the respins as-is. They're really
pretty unofficial: they're not built by infra, and they're not built the same way we build 'official' images. That's fine for something we just kinda let sit there and say "hey use it if you want to", but it's not really appropriate for something a Large Computer Vendor would be deploying on thousands of boxes sold to the public. It seems better to be deploying actually-official Fedora bits on those.
- What's the expected cadence, here? Are they wanting a respin every
week or maybe one per cycle? Because that seems likely to affect what we do. If it's just a once-per-cycle thing, we could maybe just have releng manually fire a post-release compose with a live image profile in it, and I can manually schedule openQA tests for that compose.
Thanks!
I think it's fine to note that this request is from Lenovo...and guessing which platform it's for shouldn't be a stretch of the imagination.
Some background: We need the latest kernel/alsa/pulse/libfprint and their dependencies for supporting the new 2021 HW - and as we'll be (hopefully) releasing before F34 is available we're looking for F33+updates and the best way to provide that in a way that works for the community and our preload process.
We'll definitely be doing testing on it - from my experience rather a lot of testing. We've been doing a bunch of that already (and as an aside so far it's looking good - still some issues to resolve but they're more in the firmware space).
I'm confirming with the team (I don't do much myself with preloads) but I think the Live image gives us everything we need so is a good candidate - but of course thumbs up from the Fedora community would be great and recommendations are appreciated.
My aim is to keep the image as "Fedora official" as possible. We stand by the fact that we don't release modified Fedora - there aren't Lenovo add-ins. Everything must come from the Fedora repository - but it's just we need the most recent updates and hope to deliver that cleanly.
Release cadence is once. We just can't update our preload images that often - there's a long test cycle, and energy certification that goes with that image. It's one of the reasons the X1C8 is still shipping with Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The only reason to update would be a critical bug that couldn't be fixed with an update once the platform was received.
We're happy to go with whatever the community recommends - and my apologies for the short time frame. It's always going to be a little bit of a balancing act as fixes come in upstream at the last minute and I want the release that goes on the HW to be as good as it can possibly be.
Hope that makes sense. Holler if I've missed anything - my aim is not to dump more work on you guys either :)
Mark
On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson markpearson@lenovo.com wrote:
Release cadence is once. We just can't update our preload images that often - there's a long test cycle, and energy certification that goes with that image. It's one of the reasons the X1C8 is still shipping with Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The only reason to update would be a critical bug that couldn't be fixed with an update once the platform was received.
If the cadence is once in a long time (related to new hardware introductions, so possibly once a year or similar), I think the best approach here is to have releng manually trigger an F33 Workstation Live image compose using the current updates repo. Assuming it's not a problem for them. We (the QA) can then trigger an OpenQA test run on it, create the release validation test matrices for it, and even ask the community in large to perform some manual tests if they have time. I believe some of us would devote some time to make sure at least the basics work correctly. I'm not sure if all the plumbing for this one-off compose is ready (in fedfind, relval, openqa and wherever else needed), but Adam will know more.
I don't want to just repeat Adam's words, but I'd like to stress out that from the security perspective, such a compose should really be created using the proper Fedora Infra tooling (or Lenovo itself using official Fedora bits). I don't want to belittle the people standing behind the unofficial Live respins, they are doing a great and useful work, but if this is going to be shipped preinstalled to thousands of customers, the whole process should be as verifiable as with our official releases.
On 20/01/2021 11:11, Kamil Paral wrote:
On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson <markpearson@lenovo.com mailto:markpearson@lenovo.com> wrote:
Release cadence is once. We just can't update our preload images that often - there's a long test cycle, and energy certification that goes with that image. It's one of the reasons the X1C8 is still shipping with Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The only reason to update would be a critical bug that couldn't be fixed with an update once the platform was received.
If the cadence is once in a long time (related to new hardware introductions, so possibly once a year or similar), I think the best approach here is to have releng manually trigger an F33 Workstation Live image compose using the current updates repo. Assuming it's not a problem for them. We (the QA) can then trigger an OpenQA test run on it, create the release validation test matrices for it, and even ask the community in large to perform some manual tests if they have time. I believe some of us would devote some time to make sure at least the basics work correctly. I'm not sure if all the plumbing for this one-off compose is ready (in fedfind, relval, openqa and wherever else needed), but Adam will know more.
I don't want to just repeat Adam's words, but I'd like to stress out that from the security perspective, such a compose should really be created using the proper Fedora Infra tooling (or Lenovo itself using official Fedora bits). I don't want to belittle the people standing behind the unofficial Live respins, they are doing a great and useful work, but if this is going to be shipped preinstalled to thousands of customers, the whole process should be as verifiable as with our official releases.
Thanks Kamil,
My preference would be to have a build that comes from Fedora with Fedora's blessing rather than something we put together :) Partly so we don't screw it up but also as part of the "we don't mess with the Fedora image" thing - if we get the image from you then it reinforces that.
I know our timelines right now are quite tight - I'd like to get the image into test before Chinese New Year happens - though I'm looking at the calendar and wondering how optimistic I'm being.... How big a deal is creating an official compose? Is it days/weeks/months? At the moment I'd like it by start of Feb (with a bit of wriggle room)
As Matthew mentioned - 5.10.8 is coming out soon and whether that ties into this too? Any recommendations from the community as to which fixes are important etc happy to take on board. The HW testing we've done so far looks good - but that's not the whole story.
Thanks! Mark
On Wed, Jan 20, 2021 at 1:04 PM Mark Pearson markpearson@lenovo.com wrote:
On 20/01/2021 11:11, Kamil Paral wrote:
On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson <markpearson@lenovo.com mailto:markpearson@lenovo.com> wrote:
Release cadence is once. We just can't update our preload images that often - there's a long test cycle, and energy certification that goes with that image. It's one of the reasons the X1C8 is still shipping with Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The only reason to update would be a critical bug that couldn't be fixed with an update once the platform was received.
If the cadence is once in a long time (related to new hardware introductions, so possibly once a year or similar), I think the best approach here is to have releng manually trigger an F33 Workstation Live image compose using the current updates repo. Assuming it's not a problem for them. We (the QA) can then trigger an OpenQA test run on it, create the release validation test matrices for it, and even ask the community in large to perform some manual tests if they have time. I believe some of us would devote some time to make sure at least the basics work correctly. I'm not sure if all the plumbing for this one-off compose is ready (in fedfind, relval, openqa and wherever else needed), but Adam will know more.
I don't want to just repeat Adam's words, but I'd like to stress out that from the security perspective, such a compose should really be created using the proper Fedora Infra tooling (or Lenovo itself using official Fedora bits). I don't want to belittle the people standing behind the unofficial Live respins, they are doing a great and useful work, but if this is going to be shipped preinstalled to thousands of customers, the whole process should be as verifiable as with our official releases.
Thanks Kamil,
My preference would be to have a build that comes from Fedora with Fedora's blessing rather than something we put together :) Partly so we don't screw it up but also as part of the "we don't mess with the Fedora image" thing - if we get the image from you then it reinforces that.
I know our timelines right now are quite tight - I'd like to get the image into test before Chinese New Year happens - though I'm looking at the calendar and wondering how optimistic I'm being.... How big a deal is creating an official compose? Is it days/weeks/months? At the moment I'd like it by start of Feb (with a bit of wriggle room)
As Matthew mentioned - 5.10.8 is coming out soon and whether that ties into this too? Any recommendations from the community as to which fixes are important etc happy to take on board. The HW testing we've done so far looks good - but that's not the whole story.
While there are hardware fixes, the main reason for 5.10.8 being important is that the Btrfs performance regression introduced in 5.10.0 was fixed in that release. With this release, Btrfs I/O performance is at least 50% higher than 5.9 across virtually all workloads.
On 20/01/2021 13:05, Neal Gompa wrote:
On Wed, Jan 20, 2021 at 1:04 PM Mark Pearson markpearson@lenovo.com wrote:
As Matthew mentioned - 5.10.8 is coming out soon and whether that ties into this too? Any recommendations from the community as to which fixes are important etc happy to take on board. The HW testing we've done so far looks good - but that's not the whole story.
While there are hardware fixes, the main reason for 5.10.8 being important is that the Btrfs performance regression introduced in 5.10.0 was fixed in that release. With this release, Btrfs I/O performance is at least 50% higher than 5.9 across virtually all workloads.
Nice! Looks like it's already landed in stable (and it's now running on my P15...)
Picking that up sounds good to me
Mark
On Wed, 2021-01-20 at 17:11 +0100, Kamil Paral wrote:
On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson markpearson@lenovo.com wrote:
Release cadence is once. We just can't update our preload images that often - there's a long test cycle, and energy certification that goes with that image. It's one of the reasons the X1C8 is still shipping with Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The only reason to update would be a critical bug that couldn't be fixed with an update once the platform was received.
If the cadence is once in a long time (related to new hardware introductions, so possibly once a year or similar), I think the best approach here is to have releng manually trigger an F33 Workstation Live image compose using the current updates repo. Assuming it's not a problem for them. We (the QA) can then trigger an OpenQA test run on it, create the release validation test matrices for it, and even ask the community in large to perform some manual tests if they have time. I believe some of us would devote some time to make sure at least the basics work correctly. I'm not sure if all the plumbing for this one-off compose is ready (in fedfind, relval, openqa and wherever else needed), but Adam will know more.
Yeah, I don't think that should be really tricky for anyone. I'd suggest we just run it as a post-release nightly compose rather than a candidate and don't give it any kind of label. I don't think it should be hard for releng to run that, and I should be able to run openQA tests and even create a validation event if necessary, I might need to metaphorically whang a few things with a hammer because it won't quite fit the normal flows but it shouldn't be a big deal.
Also, I forgot to mention it'll obviously be completely impossible for this to work without Lenovo shipping me some hardware for, uh...testing. Yup. That's definitely non-negotiable. Two of everything. :D
On 20/01/2021 15:30, Adam Williamson wrote:
On Wed, 2021-01-20 at 17:11 +0100, Kamil Paral wrote:
On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson markpearson@lenovo.com wrote:
Release cadence is once. We just can't update our preload images that often - there's a long test cycle, and energy certification that goes with that image. It's one of the reasons the X1C8 is still shipping with Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The only reason to update would be a critical bug that couldn't be fixed with an update once the platform was received.
If the cadence is once in a long time (related to new hardware introductions, so possibly once a year or similar), I think the best approach here is to have releng manually trigger an F33 Workstation Live image compose using the current updates repo. Assuming it's not a problem for them. We (the QA) can then trigger an OpenQA test run on it, create the release validation test matrices for it, and even ask the community in large to perform some manual tests if they have time. I believe some of us would devote some time to make sure at least the basics work correctly. I'm not sure if all the plumbing for this one-off compose is ready (in fedfind, relval, openqa and wherever else needed), but Adam will know more.
Yeah, I don't think that should be really tricky for anyone. I'd suggest we just run it as a post-release nightly compose rather than a candidate and don't give it any kind of label. I don't think it should be hard for releng to run that, and I should be able to run openQA tests and even create a validation event if necessary, I might need to metaphorically whang a few things with a hammer because it won't quite fit the normal flows but it shouldn't be a big deal.
That would be awesome and very much appreciated :) Let me know anything we can do to help
Mark
On Wed, Jan 20, 2021 at 3:30 PM Adam Williamson adamwill@fedoraproject.org wrote:
Yeah, I don't think that should be really tricky for anyone. I'd suggest we just run it as a post-release nightly compose rather than a candidate and don't give it any kind of label. I don't think it should be hard for releng to run that,
Yes, RelEng can create a live media with updates repo included, it wont be a huge deal and we can sign the checksums manually making it official. But I notice that the cadence hasn't been finalized yet, I would really appreciate if we know how often do we have to run this, I understand it is subjected to change, but having a schedule really helps.
and I should be able to run openQA tests and even create a validation event if necessary, I might need to metaphorically whang a few things with a hammer because it won't quite fit the normal flows but it shouldn't be a big deal.
Also, I forgot to mention it'll obviously be completely impossible for this to work without Lenovo shipping me some hardware for, uh...testing. Yup. That's definitely non-negotiable. Two of everything. :D
I hope one of them is for RelEng or else it will be three of everything :D
-- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
On 21/01/2021 10:46, Mohan Boddu wrote:
On Wed, Jan 20, 2021 at 3:30 PM Adam Williamson adamwill@fedoraproject.org wrote:
Yeah, I don't think that should be really tricky for anyone. I'd suggest we just run it as a post-release nightly compose rather than a candidate and don't give it any kind of label. I don't think it should be hard for releng to run that,
Yes, RelEng can create a live media with updates repo included, it wont be a huge deal and we can sign the checksums manually making it official. But I notice that the cadence hasn't been finalized yet, I would really appreciate if we know how often do we have to run this, I understand it is subjected to change, but having a schedule really helps.
From Lenovo perspective we'd like the image now (or next week) ready for the 2021 Carbon. If there was a blocker issue then running it again would be useful (but so far test results are good and I'll know in the next couple week(ish) if there are any red flags.
We have some other platforms that come out later in the year with Fedora - around the end of the summer. Last year because of various things it worked out really well that we were ready for testing just as F33 released so we of course used that. I'm focusing right now on improving how we get our releases out much more quickly (now I know where many of the issues lie) so I'm not sure everything will line up quite as well, and that's probably worthy of discussion. Is it better to have the new Fedora out but a later release of a platform? Or earlier HW with older Fedora? Generally the biggest criticisms I get are cost (whether I have no control over) and release dates after Windows (where we have sucked and I have lots of scope for improvement).
Sorry - long answer to say "once or at worst twice a year"
and I should be able to run openQA tests and even create a validation event if necessary, I might need to metaphorically whang a few things with a hammer because it won't quite fit the normal flows but it shouldn't be a big deal.
Also, I forgot to mention it'll obviously be completely impossible for this to work without Lenovo shipping me some hardware for, uh...testing. Yup. That's definitely non-negotiable. Two of everything. :D
I hope one of them is for RelEng or else it will be three of everything :D
I have noted the request ;)
Mark
On Thu, Jan 21, 2021 at 11:06 AM Mark Pearson markpearson@lenovo.com wrote:
On 21/01/2021 10:46, Mohan Boddu wrote:
On Wed, Jan 20, 2021 at 3:30 PM Adam Williamson adamwill@fedoraproject.org wrote:
Yeah, I don't think that should be really tricky for anyone. I'd suggest we just run it as a post-release nightly compose rather than a candidate and don't give it any kind of label. I don't think it should be hard for releng to run that,
Yes, RelEng can create a live media with updates repo included, it wont be a huge deal and we can sign the checksums manually making it official. But I notice that the cadence hasn't been finalized yet, I would really appreciate if we know how often do we have to run this, I understand it is subjected to change, but having a schedule really helps.
From Lenovo perspective we'd like the image now (or next week) ready for the 2021 Carbon. If there was a blocker issue then running it again would be useful (but so far test results are good and I'll know in the next couple week(ish) if there are any red flags.
I will start building an image asap, expect something by the end of the day today (hopefully).
We have some other platforms that come out later in the year with Fedora
- around the end of the summer. Last year because of various things it
worked out really well that we were ready for testing just as F33 released so we of course used that. I'm focusing right now on improving how we get our releases out much more quickly (now I know where many of the issues lie) so I'm not sure everything will line up quite as well, and that's probably worthy of discussion. Is it better to have the new Fedora out but a later release of a platform? Or earlier HW with older Fedora? Generally the biggest criticisms I get are cost (whether I have no control over) and release dates after Windows (where we have sucked and I have lots of scope for improvement).
Sorry - long answer to say "once or at worst twice a year"
Thank you very much Mark, once or twice a year is gonna be fine for us.
and I should be able to run openQA tests and even create a validation event if necessary, I might need to metaphorically whang a few things with a hammer because it won't quite fit the normal flows but it shouldn't be a big deal.
Also, I forgot to mention it'll obviously be completely impossible for this to work without Lenovo shipping me some hardware for, uh...testing. Yup. That's definitely non-negotiable. Two of everything. :D
I hope one of them is for RelEng or else it will be three of everything :D
I have noted the request ;)
Hehe :)
Mark _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
On Thu, 2021-01-21 at 11:42 -0500, Mohan Boddu wrote:
On Thu, Jan 21, 2021 at 11:06 AM Mark Pearson markpearson@lenovo.com wrote:
On 21/01/2021 10:46, Mohan Boddu wrote:
On Wed, Jan 20, 2021 at 3:30 PM Adam Williamson adamwill@fedoraproject.org wrote:
Yeah, I don't think that should be really tricky for anyone. I'd suggest we just run it as a post-release nightly compose rather than a candidate and don't give it any kind of label. I don't think it should be hard for releng to run that,
Yes, RelEng can create a live media with updates repo included, it wont be a huge deal and we can sign the checksums manually making it official. But I notice that the cadence hasn't been finalized yet, I would really appreciate if we know how often do we have to run this, I understand it is subjected to change, but having a schedule really helps.
From Lenovo perspective we'd like the image now (or next week) ready for the 2021 Carbon. If there was a blocker issue then running it again would be useful (but so far test results are good and I'll know in the next couple week(ish) if there are any red flags.
I will start building an image asap, expect something by the end of the day today (hopefully).
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it: https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
On 21/01/2021 14:31, Adam Williamson wrote:
On Thu, 2021-01-21 at 11:42 -0500, Mohan Boddu wrote:
On Thu, Jan 21, 2021 at 11:06 AM Mark Pearson markpearson@lenovo.com wrote:
On 21/01/2021 10:46, Mohan Boddu wrote:
On Wed, Jan 20, 2021 at 3:30 PM Adam Williamson adamwill@fedoraproject.org wrote:
Yeah, I don't think that should be really tricky for anyone. I'd suggest we just run it as a post-release nightly compose rather than a candidate and don't give it any kind of label. I don't think it should be hard for releng to run that,
Yes, RelEng can create a live media with updates repo included, it wont be a huge deal and we can sign the checksums manually making it official. But I notice that the cadence hasn't been finalized yet, I would really appreciate if we know how often do we have to run this, I understand it is subjected to change, but having a schedule really helps.
From Lenovo perspective we'd like the image now (or next week) ready for the 2021 Carbon. If there was a blocker issue then running it again would be useful (but so far test results are good and I'll know in the next couple week(ish) if there are any red flags.
I will start building an image asap, expect something by the end of the day today (hopefully).
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it: https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
Wow - thank you!
I've grabbed it and it looks good so far, we'll start kicking the tires on it and let you know if we find any issues.
Mark
On Thu, 2021-01-21 at 15:41 -0500, Mark Pearson wrote:
On 21/01/2021 14:31, Adam Williamson wrote:
On Thu, 2021-01-21 at 11:42 -0500, Mohan Boddu wrote:
On Thu, Jan 21, 2021 at 11:06 AM Mark Pearson markpearson@lenovo.com wrote:
On 21/01/2021 10:46, Mohan Boddu wrote:
On Wed, Jan 20, 2021 at 3:30 PM Adam Williamson adamwill@fedoraproject.org wrote:
Yeah, I don't think that should be really tricky for anyone. I'd suggest we just run it as a post-release nightly compose rather than a candidate and don't give it any kind of label. I don't think it should be hard for releng to run that,
Yes, RelEng can create a live media with updates repo included, it wont be a huge deal and we can sign the checksums manually making it official. But I notice that the cadence hasn't been finalized yet, I would really appreciate if we know how often do we have to run this, I understand it is subjected to change, but having a schedule really helps.
From Lenovo perspective we'd like the image now (or next week) ready for the 2021 Carbon. If there was a blocker issue then running it again would be useful (but so far test results are good and I'll know in the next couple week(ish) if there are any red flags.
I will start building an image asap, expect something by the end of the day today (hopefully).
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it: https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
Wow - thank you!
I've grabbed it and it looks good so far, we'll start kicking the tires on it and let you know if we find any issues.
The failures are...odd. This is what they seem to have in common: they're all in tests where we try to open something from the top bar after a while. For the desktop notifications tests we click where the time is, to open the notifications panel. For the switch_user test we're trying to click the top-right menu.
In all three cases, it seems like the click just doesn't do anything. I've re-run all the tests and they failed again the same way second time, so it doesn't *just* seem like a blip.
I'm currently downloading the ISO to test locally and see if I can reproduce this sort of behaviour...
I'm currently downloading the ISO to test locally and see if I can reproduce this sort of behaviour...
I could not reproduce it locally on this respin.
-- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Today I performed the Desktop tests on the above mentioned respin and I believe there are no big flaws in it. Going through the usual testing stuff, I have not stumbled on anything. The combination Alt-N in the Intro still does not work, but since this was not blocking for F33, I consider this to be a cosmetic issue.
The list of tests I went through:
PASS QA:Testcase_desktop_browser PASS QA:Testcase_desktop_app_basic - terminal emulator PASS QA:Testcase_desktop_login PASS QA:Testcase_audio_basic PASS QA:Testcase_desktop_panel_basic PASS QA:Testcase_desktop_automount PASS QA:Testcase_workstation_core_applications PASS QA:Testcase_desktop_update_graphical PASS QA:Testcase_Printing_New_Printer - real printer PASS QA:Testcase_Printing_New_Printer - virtual printer PASS QA:Testcase_desktop_update_notification PASS QA:Testcase_desktop_error_checks PASS QA:Testcase_desktop_panel_advanced PASS QA:Testcase_desktop_keyring PASS QA:Testcase_desktop_user_switching PASS QA:Testcase_desktop_app_basic - file manager PASS QA:Testcase_desktop_app_basic - package manager PASS QA:Testcase_desktop_app_basic - image viewer PASS QA:Testcase_desktop_app_basic - document viewer PASS QA:Testcase_desktop_app_basic - text editor PASS QA:Testcase_desktop_app_basic - archive manager PASS QA:Testcase_desktop_app_basic - problem reporter PASS QA:Testcase_desktop_app_basic - help viewer PASS QA:Testcase_desktop_app_basic - system settings
On Thu, Jan 21, 2021 at 10:27 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2021-01-21 at 15:41 -0500, Mark Pearson wrote:
On 21/01/2021 14:31, Adam Williamson wrote:
On Thu, 2021-01-21 at 11:42 -0500, Mohan Boddu wrote:
On Thu, Jan 21, 2021 at 11:06 AM Mark Pearson <
markpearson@lenovo.com> wrote:
On 21/01/2021 10:46, Mohan Boddu wrote:
On Wed, Jan 20, 2021 at 3:30 PM Adam Williamson adamwill@fedoraproject.org wrote: > > Yeah, I don't think that should be really tricky for anyone.
I'd
> suggest we just run it as a post-release nightly compose
rather than a
> candidate and don't give it any kind of label. I don't think
it should
> be hard for releng to run that,
Yes, RelEng can create a live media with updates repo included,
it
wont be a huge deal and we can sign the checksums manually
making it
official. But I notice that the cadence hasn't been finalized
yet, I
would really appreciate if we know how often do we have to run
this, I
understand it is subjected to change, but having a schedule
really
helps.
From Lenovo perspective we'd like the image now (or next week)
ready for
the 2021 Carbon. If there was a blocker issue then running it again would be useful (but so far test results are good and I'll know in
the
next couple week(ish) if there are any red flags.
I will start building an image asap, expect something by the end of the day today (hopefully).
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it:
https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
Wow - thank you!
I've grabbed it and it looks good so far, we'll start kicking the tires on it and let you know if we find any issues.
The failures are...odd. This is what they seem to have in common: they're all in tests where we try to open something from the top bar after a while. For the desktop notifications tests we click where the time is, to open the notifications panel. For the switch_user test we're trying to click the top-right menu.
In all three cases, it seems like the click just doesn't do anything. I've re-run all the tests and they failed again the same way second time, so it doesn't *just* seem like a blip.
I'm currently downloading the ISO to test locally and see if I can reproduce this sort of behaviour... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
On Thu, Jan 21, 2021 at 2:32 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2021-01-21 at 11:42 -0500, Mohan Boddu wrote:
On Thu, Jan 21, 2021 at 11:06 AM Mark Pearson markpearson@lenovo.com wrote:
On 21/01/2021 10:46, Mohan Boddu wrote:
On Wed, Jan 20, 2021 at 3:30 PM Adam Williamson adamwill@fedoraproject.org wrote:
Yeah, I don't think that should be really tricky for anyone. I'd suggest we just run it as a post-release nightly compose rather than a candidate and don't give it any kind of label. I don't think it should be hard for releng to run that,
Yes, RelEng can create a live media with updates repo included, it wont be a huge deal and we can sign the checksums manually making it official. But I notice that the cadence hasn't been finalized yet, I would really appreciate if we know how often do we have to run this, I understand it is subjected to change, but having a schedule really helps.
From Lenovo perspective we'd like the image now (or next week) ready for the 2021 Carbon. If there was a blocker issue then running it again would be useful (but so far test results are good and I'll know in the next couple week(ish) if there are any red flags.
I will start building an image asap, expect something by the end of the day today (hopefully).
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it: https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
Please let me know what you find, I can re-run the build again if needed (provided the fixes are in the updates repo). And once the testing is done, I will push the iso to /pub/alt/offical-respins/ for future consumption and also with signed checksums as the scratch builds only live for 14 days in the build system.
-- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
On Fri, 2021-01-22 at 11:12 -0500, Mohan Boddu wrote:
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it: https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
Please let me know what you find, I can re-run the build again if needed (provided the fixes are in the updates repo). And once the testing is done, I will push the iso to /pub/alt/offical-respins/ for future consumption and also with signed checksums as the scratch builds only live for 14 days in the build system.
Well the openQA failures are still happening and I'm damned if I can figure out why, but Lukas said they test out fine in manual testing, so it's probably just some very weird glitch. Unless anyone can reproduce the top bar just...not responding...after the system has been up for a while, we can probably call the image good.
-----Original Message----- From: Adam Williamson adamwill@fedoraproject.org Sent: Friday, January 22, 2021 7:57 PM To: For testing and quality assurance of Fedora releases test@lists.fedoraproject.org Subject: Re: [External] Re: Respins for OEM preloads
On Fri, 2021-01-22 at 11:12 -0500, Mohan Boddu wrote:
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it: https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
NOREPORT&version=33&distri=fedora&groupid=1
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
Please let me know what you find, I can re-run the build again if needed (provided the fixes are in the updates repo). And once the testing is done, I will push the iso to /pub/alt/offical-respins/ for future consumption and also with signed checksums as the scratch builds only live for 14 days in the build system.
Well the openQA failures are still happening and I'm damned if I can figure out why, but Lukas said they test out fine in manual testing, so it's probably just some very weird glitch. Unless anyone can reproduce the top bar just...not responding...after the system has been up for a while, we can probably call the image good.
So far we've not seen that issue either - it's looking good. We have one minor issue with the mic mute LED not working on this version where it did before and we'll need to dig into, but it isn't a blocker (assuming we figure out what the issue is and how to make the fix available before the release).
Thanks for doing all this - very much appreciated. Happy weekend all 😊 Mark
Just checking, should I push the image to /pub/alt/official-respins/ or should I wait?
On Sat, Jan 23, 2021 at 10:48 AM Mark RH Pearson markpearson@lenovo.com wrote:
-----Original Message----- From: Adam Williamson adamwill@fedoraproject.org Sent: Friday, January 22, 2021 7:57 PM To: For testing and quality assurance of Fedora releases <
test@lists.fedoraproject.org>
Subject: Re: [External] Re: Respins for OEM preloads
On Fri, 2021-01-22 at 11:12 -0500, Mohan Boddu wrote:
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it:
https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
NOREPORT&version=33&distri=fedora&groupid=1
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
Please let me know what you find, I can re-run the build again if needed (provided the fixes are in the updates repo). And once the testing is done, I will push the iso to /pub/alt/offical-respins/ for future consumption and also with signed checksums as the scratch builds only live for 14 days in the build system.
Well the openQA failures are still happening and I'm damned if I can figure out why, but Lukas said they test out fine in manual testing, so it's probably just some very weird glitch. Unless anyone can reproduce the top bar just...not responding...after the system has been up for a while, we can probably call the image good.
So far we've not seen that issue either - it's looking good. We have one minor issue with the mic mute LED not working on this version where it did before and we'll need to dig into, but it isn't a blocker (assuming we figure out what the issue is and how to make the fix available before the release).
Thanks for doing all this - very much appreciated. Happy weekend all 😊 Mark
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Hi Mohan,
From my point of view - yes please. The image is off to the test team, and I don’t have any feedback yet but fingers crossed for a smooth passage 😊 All the fundamentals are looking good from what we’ve tried
Mark
From: Mohan Boddu mboddu@bhujji.com Sent: Tuesday, January 26, 2021 11:24 AM To: For testing and quality assurance of Fedora releases test@lists.fedoraproject.org Subject: Re: [External] Re: Respins for OEM preloads
Just checking, should I push the image to /pub/alt/official-respins/ or should I wait?
On Sat, Jan 23, 2021 at 10:48 AM Mark RH Pearson <markpearson@lenovo.commailto:markpearson@lenovo.com> wrote:
-----Original Message----- From: Adam Williamson <adamwill@fedoraproject.orgmailto:adamwill@fedoraproject.org> Sent: Friday, January 22, 2021 7:57 PM To: For testing and quality assurance of Fedora releases <test@lists.fedoraproject.orgmailto:test@lists.fedoraproject.org> Subject: Re: [External] Re: Respins for OEM preloads
On Fri, 2021-01-22 at 11:12 -0500, Mohan Boddu wrote:
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it: https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
NOREPORT&version=33&distri=fedora&groupid=1
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
Please let me know what you find, I can re-run the build again if needed (provided the fixes are in the updates repo). And once the testing is done, I will push the iso to /pub/alt/offical-respins/ for future consumption and also with signed checksums as the scratch builds only live for 14 days in the build system.
Well the openQA failures are still happening and I'm damned if I can figure out why, but Lukas said they test out fine in manual testing, so it's probably just some very weird glitch. Unless anyone can reproduce the top bar just...not responding...after the system has been up for a while, we can probably call the image good.
So far we've not seen that issue either - it's looking good. We have one minor issue with the mic mute LED not working on this version where it did before and we'll need to dig into, but it isn't a blocker (assuming we figure out what the issue is and how to make the fix available before the release).
Thanks for doing all this - very much appreciated. Happy weekend all 😊 Mark
_______________________________________________ test mailing list -- test@lists.fedoraproject.orgmailto:test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.orgmailto:test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Hi Mark,
The image has been synced to https://dl.fedoraproject.org/pub/alt/official-respins/ and the future images will be available in the same location. If in case you need to provide the image to your users, they can verify the image by the signed checksum available in the above link as well.
On Tue, Jan 26, 2021 at 11:26 AM Mark RH Pearson markpearson@lenovo.com wrote:
Hi Mohan,
From my point of view - yes please. The image is off to the test team, and I don’t have any feedback yet but fingers crossed for a smooth passage 😊 All the fundamentals are looking good from what we’ve tried
Mark
*From:* Mohan Boddu mboddu@bhujji.com *Sent:* Tuesday, January 26, 2021 11:24 AM *To:* For testing and quality assurance of Fedora releases < test@lists.fedoraproject.org> *Subject:* Re: [External] Re: Respins for OEM preloads
Just checking, should I push the image to /pub/alt/official-respins/ or should I wait?
On Sat, Jan 23, 2021 at 10:48 AM Mark RH Pearson markpearson@lenovo.com wrote:
-----Original Message----- From: Adam Williamson adamwill@fedoraproject.org Sent: Friday, January 22, 2021 7:57 PM To: For testing and quality assurance of Fedora releases <
test@lists.fedoraproject.org>
Subject: Re: [External] Re: Respins for OEM preloads
On Fri, 2021-01-22 at 11:12 -0500, Mohan Boddu wrote:
So the image is built now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60156482
I ran the openQA tests on it:
https://openqa.fedoraproject.org/tests/overview?build=Fedora-33-Lenovo-20210...
NOREPORT&version=33&distri=fedora&groupid=1
there were a few failures that all basically related to the GNOME top bar and/or notifications. I'm re-running the tests, and will also download the ISO and poke it a bit locally.
Please let me know what you find, I can re-run the build again if needed (provided the fixes are in the updates repo). And once the testing is done, I will push the iso to /pub/alt/offical-respins/ for future consumption and also with signed checksums as the scratch builds only live for 14 days in the build system.
Well the openQA failures are still happening and I'm damned if I can figure out why, but Lukas said they test out fine in manual testing, so it's probably just some very weird glitch. Unless anyone can reproduce the top bar just...not responding...after the system has been up for a while, we can probably call the image good.
So far we've not seen that issue either - it's looking good. We have one minor issue with the mic mute LED not working on this version where it did before and we'll need to dig into, but it isn't a blocker (assuming we figure out what the issue is and how to make the fix available before the release).
Thanks for doing all this - very much appreciated. Happy weekend all 😊 Mark
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
From: Mohan Boddu mboddu@bhujji.com Sent: Tuesday, January 26, 2021 5:41 PM Subject: Re: [External] Re: Respins for OEM preloads
Hi Mark,
The image has been synced to https://dl.fedoraproject.org/pub/alt/official-respins/ and the future images will be available in the same location. If in case you need to provide the image to your users, they can verify the image by the signed checksum available in the above link as well.
Perfect - thanks Mohan! Mark
On Tue, Jan 26, 2021 at 05:41:13PM -0500, Mohan Boddu wrote:
The image has been synced to https://dl.fedoraproject.org/pub/alt/official-respins/ and the future images will be available in the same location. If in case you need to provide the image to your users, they can verify the image by the signed checksum available in the above link as well.
Hey Mohan, I notice the CHECKSUM file here is not readable.
On Sun, Feb 07, 2021 at 03:54:53PM -0500, Matthew Miller wrote:
On Tue, Jan 26, 2021 at 05:41:13PM -0500, Mohan Boddu wrote:
The image has been synced to https://dl.fedoraproject.org/pub/alt/official-respins/ and the future images will be available in the same location. If in case you need to provide the image to your users, they can verify the image by the signed checksum available in the above link as well.
Hey Mohan, I notice the CHECKSUM file here is not readable.
Fixed.
kevin
On Tue, Jan 19, 2021 at 10:43 AM Mark Pearson markpearson@lenovo.com wrote:
Some background: We need the latest kernel/alsa/pulse/libfprint and their dependencies for supporting the new 2021 HW - and as we'll be (hopefully) releasing before F34 is available we're looking for F33+updates and the best way to provide that in a way that works for the community and our preload process.
We need to coordinate a shim update, one that's signed with new world keys (post-BootHole) which doesn't yet exist.
Specifically, if the new hardware will come with UEFI Secure Boot enabled, it will need a preloaded image containing either pre-BootHole revocation database. Shim needs to be updated before the revocation database or the system will not boot.
If this preload image is also going to form the basis for a recovery partition, this is a bigger concern because it'd be rendered unbootable once the revocation database is pushed. Fedora hasn't decided to push the revocation database automatically, but other distros do so aggressively. Microsoft has thus far delayed pushing the post-BootHole revocation db, but eventually they will sometime this year.
Hi Chris
On 20/01/2021 17:06, Chris Murphy wrote:
On Tue, Jan 19, 2021 at 10:43 AM Mark Pearson markpearson@lenovo.com wrote:
Some background: We need the latest kernel/alsa/pulse/libfprint and their dependencies for supporting the new 2021 HW - and as we'll be (hopefully) releasing before F34 is available we're looking for F33+updates and the best way to provide that in a way that works for the community and our preload process.
We need to coordinate a shim update, one that's signed with new world keys (post-BootHole) which doesn't yet exist.
Specifically, if the new hardware will come with UEFI Secure Boot enabled, it will need a preloaded image containing either pre-BootHole revocation database. Shim needs to be updated before the revocation database or the system will not boot.
If this preload image is also going to form the basis for a recovery partition, this is a bigger concern because it'd be rendered unbootable once the revocation database is pushed. Fedora hasn't decided to push the revocation database automatically, but other distros do so aggressively. Microsoft has thus far delayed pushing the post-BootHole revocation db, but eventually they will sometime this year.
We still have secure boot disabled by default for Linux systems - it's something I want to turn on but every time we look at it there are a few headaches and there's some process in manufacturing too to resolve and it just never quite makes it high enough in the list to become a priority.
I'm not going to get that solved for this round so I don't think it has to block this effort. Something I'm happy to look at for platforms later in the year with F34/F35?
Let me know if I'm missing something important.
Mark
On Tue, Jan 19, 2021 at 09:20:54AM -0800, Adam Williamson wrote:
we do. If it's just a once-per-cycle thing, we could maybe just have releng manually fire a post-release compose with a live image profile in it, and I can manually schedule openQA tests for that compose.
I actually have an unrelated use-case: we're getting some higher-end USB sticks for swag and I'd love to also put an updated image on those.
If we can use the same one, that'd be super-extra bonus. It'd be kind of nice to wait for 5.8.10 to exit updates-testing but I'm not sure how that works with Mark's timeline.