Re: [Test-Announce] Fedora 27 Branched 20170817.n.3 nightly compose nominated for testing
On Fri, Aug 18, 2017 at 04:59:50AM +, rawh...@fedoraproject.org wrote: > Announcing the creation of a new nightly release validation test event > for Fedora 27 Branched 20170817.n.3. Please help run some tests for this > nightly compose if you have time. For more information on nightly > release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Notable package version changes: > lorax - 20170811.n.2: lorax-27.5-1.fc27.src, 20170817.n.3: > lorax-27.6-1.fc27.src > python-blivet - 20170811.n.2: python-blivet-2.1.9-3.fc27.src, 20170817.n.3: > python-blivet-2.1.10-1.fc27.src > anaconda - 20170811.n.2: anaconda-27.19-6.fc27.src, 20170817.n.3: > anaconda-27.20-1.fc27.src > > Test coverage information for the current release can be seen at: > https://www.happyassassin.net/testcase_stats/27 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170817.n.3_Summary > > The individual test result pages are: > > https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170817.n.3_Installation Hey, I noticed that the page for network install only has the legacy method (PXE). To make it work in the new world of UEFI I've been using iPXE (which works fine with rawhide), but I didn't see a test-case for that. Hence wondering if that was by mistake or if just nobody got to doing it? Thanks. > https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170817.n.3_Base > https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170817.n.3_User:Adamwill/NoMoreAlpha/Server > https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170817.n.3_Server > https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170817.n.3_Cloud > https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170817.n.3_Desktop > https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170817.n.3_Security_Lab > > Thank you for testing! > -- > Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer > ___ > test-announce mailing list -- test-annou...@lists.fedoraproject.org > To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: [Xen-devel] Criteria / validation proposal: drop Xen
Posting from gmail, so hopefully it doesn't send it as HTML.. On Thu, Jul 6, 2017 at 3:45 PM, Adam Williamson wrote: > On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote: >> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote: >> > Hi, folks! A while ago, Xen virtualization functionality was added to >> > the criteria and the validation test case set, on the understanding >> > that Oracle would provide testing for it (and help fix bugs as they >> > arose). >> > >> > For the last couple of releases we really have not had any such testing >> >> We had been doing the testing, it just that we (or rather me and >> Dariof) seem to get a wind of this at the last minute. Not sure exactly >> how to fix that thought. > > Well, I mean, every few *days* a compose gets nominated for validation > testing, and a mail is sent to test-announce. Just check your test- > announce archives for mails with "nominated for testing" in their > subject lines, and you'll see dozens. Is this not sufficient > notification? That is it. I just hadn't know about it. > >> > from Oracle. On that basis, I'm proposing we remove this Final >> > criterion: >> >> s/Oracle/Xen Project/ I believe? > > Perhaps, it's just that it always seemed to be you doing the testing, > so they got a bit conflated :) > >> > "The release must boot successfully as Xen DomU with releases providing >> > a functional, supported Xen Dom0 and widely used cloud providers >> > utilizing Xen." >> > >> > and change the 'milestone' for the test case - >> > https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt - >> > from Final to Optional. >> > >> > Thoughts? Comments? Thanks! >> >> I would prefer for it to remain as it is. > > This is only practical if it's going to be tested, and tested regularly > - not *only* on the final release candidate, right before we sign off > on the release. It needs to be tested regularly throughout the release > cycle, on the composes that are "nominated for testing". Right, which is why I am happy that you have pointed me to the right place so I can be up-to-date. > > Thanks! > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > > ___ > Xen-devel mailing list > xen-de...@lists.xen.org > https://lists.xen.org/xen-devel ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Criteria / validation proposal: drop Xen
> Hi, folks! A while ago, Xen virtualization functionality was added to > the criteria and the validation test case set, on the understanding > that Oracle would provide testing for it (and help fix bugs as they > arose). > > For the last couple of releases we really have not had any such testing > from Oracle. On that basis, I'm proposing we remove this Final We had been doing the testing, it just that we (or rather me and Dariof) seem to get a wind of this at the last minute. Not sure exactly how to fix that thought. Also s/Oracle/Xen Project/ I believe? > criterion: > > "The release must boot successfully as Xen DomU with releases providing > a functional, supported Xen Dom0 and widely used cloud providers > utilizing Xen." > > and change the 'milestone' for the test case - > https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt - > from Final to Optional. > I would prefer to remain as is. And now that I've subscribed to te...@lists.fedoraproject.org that should be easier. > Thoughts? Comments? Thanks! ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Nouveau fails with F17 Beta on GeForce 6150 (NV4E)
On Thu, Apr 19, 2012 at 01:38:01PM +0200, Marcel Oliver wrote: > Hi, > > I am having worsening problems with the nouveau driver on GeForce 6150 > (NV4E), this is the onboard graphics on the ASUS M2NPV-VM. So I tried > F17 Beta (x86) yesterday to see what the status is. Result: total > failure - the screen goes to a very dark blue and the keyboard appears > also dead. > > This same problem already shows up on F16 with any of the 3.3 kernels > (last working kernel is 3.2.10-3 without acceleration, acceleration > never worked on this chip), see > > https://bugzilla.redhat.com/show_bug.cgi?id=810490 > > Question: > > - Should I file another bug report on F17 beta? Can you just add the serial/dmesg output with drm.info=255 to the bug? > > - If so, what are the chances that someone looks at it? > > - Is there any easy way to extract the requested debug information > from the system in the failing configuration? Ideally, I'd like to > write out to USB stick without installing the system, but since no > user interaction is possible, that seems too much to ask? > Alternatively, if I install on a scratch partition, is there a way > to instrument the startup code to write the necessary debug > information to disk for later inspection from a working system? > Networking would be a bit of a pain to bring up... You could boot in text mode (so recovery) with 'nouveau.modeset=0'. Set up your network, SSH in the box, and then 'exec /sbin/init 5' to start X. Then from your SSH session run 'dmesg' to get that output. Oh, you should also have 'debug loglevel=8' on your Linux command line. > > Any comments appreciated, also an estimate of the chances of being > able to use Fedora on this machine again... > > Regards, > Marcel > -- > test mailing list > test@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Fedora 17 Beta Go/No-Go Meeting, Wednesday, April 4, @17:00 Eastern
On Mon, Apr 02, 2012 at 09:57:23AM -0700, Robyn Bergeron wrote: > Please join us on irc.freenode.net in #fedora-meeting-1 for this > important meeting. This will be Round 2 of this meeting for the Beta > release of F17. > > Wednesday, April 4, 2012 @21:00 UTC (17:00 EDT/14:00 PDT) > > "Before each public release Development, QA and Release Engineering > meet to determine if the release criteria are met for a particular > release. This meeting is called the Go/No-Go Meeting." > > "Verifying that the Release criteria are met is the responsibility > of the QA Team." > > For more details about this meeting see: > https://fedoraproject.org/wiki/Go_No_Go_Meeting > > In the meantime, keep an eye on the Fedora 17 Beta Blocker list: > http://fedoraproject.org/wiki/Current_Release_Blockers Can I suggest https://bugzilla.redhat.com/show_bug.cgi?id=808152 as well. > > Ongoing Beta RC test results can be seen here: > https://fedoraproject.org/wiki/Category:Fedora_17_Beta_RC_Test_Results > > See you there, Wednesday, in #fedora-meeting-1 (1, 1, !!!111, make a > note of it!) > > -Robyn > ___ > test-announce mailing list > test-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/test-announce > -- > test mailing list > test@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: EC2 AMI Test Case Review Request
On Mon, Jan 09, 2012 at 08:10:42AM -0700, Tim Flink wrote: > Now that EC2 functionality is a release requirement, I've written up a > draft test case for EC2 AMIs. I tried to keep it straight forward > without writing a "how to use EC2" guide. > > https://fedoraproject.org/wiki/User:Tflink/QA:Testcase_EC2_AMI_Validation_%28draft%29 > > I'd appreciate any suggestions or comments before moving it from a > draft page and adding it to the release validation matrices. Looks good to me.. thought as a first time user of AWS, the process of creating an account and the verification was a bit slow. Also, when finally creating an account I've had no idea what to actually select. I saw something about free Amazon Micro EC2 but no idea how to use it. Finally figured out that I am suppose to use the "Classic" workflow. Perhaps adding in a comment saying: "As setting up a first-time AWS account can take sometimes a few hours, it is recommended that the user create this in advance." Also perhaps a link to do when nothing shows up. For example I just created an ami-5f16d836 and all lights are green but I can't connect to it. Perhaps some link to "how to get debug/bootup logs" from the instance? Or how to add 'debug loglevel=8' to the kernel bootup? IF that is is possible? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Is there a need for more Xen test cases for Fedora?
On Tue, Nov 29, 2011 at 04:54:05PM -0800, Adam Williamson wrote: > On Tue, 2011-11-29 at 17:47 -0700, Stephen John Smoogen wrote: > > On 29 November 2011 17:40, Adam Williamson wrote: > > > Hey, folks. I'm working through the f16 QA retrospective, and one of the > > > suggestions is: > > > > > > "might need improved / more Xen test cases" > > > > > > > Does this mean various DomU tests or Dom0 tests? > > That's sort of the question, I'm asking, really! It would be nice to expand the tests, and it kind of boils down to: 1) Does it boot 2) Does it work The complexity is that there are three modes of this: HVM (so similar to the KVM test-case), PV (we got that covered now), and the Dom0 (which is mostly - does it boot and you kind of implicitly need to do this before you can do the other two). So I think it makes sense to add the HVM case in the test-matrix - it is pretty simple and similar to the KVM one. The dom0 is a bit more complex, but we already have it outlined in the http://fedoraproject.org/wiki/Features/XenPvopsDom0 in the Documentation part - so it should be fairly easy to lift it out of there. (adn the stuff about the bridge is not needed anymore). > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > test mailing list > test@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release Criteria Proposal: Xen DomU
On Thu, Oct 13, 2011 at 12:46:12PM -0700, Adam Williamson wrote: > On Thu, 2011-10-13 at 15:35 -0400, Josh Boyer wrote: > > On Thu, Oct 13, 2011 at 3:24 PM, Tim Flink wrote: > > > On Thu, 13 Oct 2011 13:18:39 -0600 > > > Tim Flink wrote: > > > > > >> My intention was to include issues with DomU running locally (with an > > >> already functional Fedora Dom0) or on a Xen based cloud provider. My > > >> implicit assumption was that Dom0 would already be working but since > > >> F16 is the first supported Dom0 since F8, that could be problematic. > > >> For F17 and later, I imagine that we could just say that it needs to > > >> run with a previous release as Dom0. > > > > > > How about: > > > - The release must boot successfully as Xen DomU with releases > > >providing a functional, supported Xen Dom0 and cloud providers > > >utilizing Xen. This does not include any issues limited to the > > >release functioning as Xen Dom0. > > > > Do you have a test plan to go along with this criteria? > > Well, er: > > https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt > > it could use some, let's say, expansion. =) Is there a good template for these QA test-cases? I can flesh it a bit and provide local-type QA, which is: 1). Install Dom0 2). Install DomU 3). Do stuff. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Pre-Final TC1 Testing Request
> x86_64 minimal boot.iso: > http://tflink.fedorapeople.org/iso/20111011_preTC1.x64.boot.iso Installed that as Xen DomU (fully virtualized - HVM) and it installs fine and boots fine. Albeit the network seems to have gone away - had to run /etc/init.d/network restart to get it back. > http://tflink.fedorapeople.org/iso/20111011_preTC1.x64.boot.iso.sha256 > > Raw initrd/kernel for Xen/PXE testing: > http://tflink.fedorapeople.org/iso/20111011_preTC1/initrd.img > http://tflink.fedorapeople.org/iso/20111011_preTC1/vmlinuz Install it as Xen DomU (PV) guest works now. Booting up the guest afterwards.. well that is a new bug :-) # 745335 - pygrub cannot start F16 PV guests (GPT partition) under Xen 4.1.1 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Final Release Criterion for Xen DomU
On Tue, Oct 04, 2011 at 10:05:31PM -0700, Adam Williamson wrote: > On Tue, 2011-10-04 at 03:00 +0100, Andy Burns wrote: > > On 30 September 2011 20:23, Adam Williamson wrote: > > > > > So this discussion seems to have stalled. Tim and I are both ambivalent, > > > and we got three responses that were positive but tentative or from > > > 'interested parties' (no offence :>). Does anyone who doesn't have skin > > > in the game have an opinion either way? > > > > I'll just mention that as far as I'm concernd Fedora 16 boots and runs > > *VERY* well as a dom0 and a domU, the sticking point is the actual > > installation as a domU (the paravirtual device driver issue, probably > > grub2 issues) I can get around this for my own purposes by "knife and That particular bug I believe has been fixed. Just needs to test it when it shows up in the install image (look for the install image having lorax-16.4.5-1 rpm) (https://bugzilla.redhat.com/show_bug.cgi?id=741950) > > forking" together a system image copied from a non-xen installation, > > it would be a shame to not have this feature mor easily available ... > > What's necessary to make it a release blocker is not so much 'it'd be > nice if it worked' arguments - I think in general everyone agrees it'd > be nice if it worked :) - but more 'it would be terrible to release > without it working, because' arguments. That's the level of impact we > need for release criteria, because something being in the release > criteria means that if it's not working, we don't ship. Which is a > pretty high bar to get over. There are kernel developers who are willing to write and test code. There is also a community of folks who are willing to test install/provide patches for grub/grub2/grubby/etc. However, I am ignorant in the ways of making a release go out the door - so I am not seeing the full picture. What are the missing pieces? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Final Release Criterion for Xen DomU
On Sun, Oct 02, 2011 at 01:22:38PM +1100, Norman Gaywood wrote: > On Fri, Sep 30, 2011 at 12:23:08PM -0700, Adam Williamson wrote: > > On Mon, 2011-09-26 at 10:41 -0600, Tim Flink wrote: > > > Specifically, do we want to have Xen DomU support as a final release > > > criteria? > > Just my 2c. I use Fedora Xen DomU and will be hoping to run F16 that way > when it's released. > > Currently using F14 and it's solid after the awful start with: > > Bug 550724 - xen PV guest kernel 2.6.32 processes lock up in D state .. which is fixed in 2.6.39 IMHO. > > What would be also useful is to be able to have guests larger than 32G > without rebuilding the kernel. Hm, that ought to work (2.6.39 and later) ? Do you have a BZ for this? The default limit is 128G: CONFIG_XEN_MAX_DOMAIN_MEMORY=128 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Final Release Criterion for Xen DomU
On Mon, Sep 26, 2011 at 10:41:00AM -0600, Tim Flink wrote: > During the discussion around Xen DomU support as a beta release > criterion in the Fedora QA meeting today, the question of blocking for > DomU came up. > > Specifically, do we want to have Xen DomU support as a final release > criteria? > > I can think of two arguments for making it a release criterion: > > 1. If install as DomU doesn't work at final release, it becomes much >more difficult to install as DomU for that release without spinning >custom install media. > > 2. Amazon EC2 is based on Xen, DomU support could affect our ability to >release on EC2. > > Another thought is that Fedora 16 is going to be the first release in a > while that supports running as Xen Dom0. It seems a bit silly to have > support for Dom0 and not have the ability to run as DomU. > > Anyhow, thoughts around making DomU support a final release criterion? Hey Tim, I just subscribed to the mailing b/c of this question coming up. A bit of introduction is probably necessary before I say "please do". Along with Jeremy Fitzhardinge we maintain the Xen subsystem in the upstream Linux kernel. The last couple of releases (kernel ones) we have been upstreaming features to make Linux work as Dom0 and naturally fixing outstanding bugs for DomU support. So in terms of kernel developer to fix bugs - that is covered - if any user/QA opens bugs for Dom0, DomU please CC me on the bug (ketuzs...@darnok.org). There is also a bunch of enthuastic folks what have been using the latest rawhide and have had openned bugs (with patches!) against user land tools - so there are folks in the community who can help. I've CC-ed the ones I've been in correspondence in case they are not on this mailing list and want to provide some feedback. Coming back to the question - I think DomU support should be on the release criterion - I don't know know enough about the Fedora processes to know whether it should be in final or beta or what not - leaving that to folks who know more about this. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
