----- "Ryan Harper" <ry...@us.ibm.com> wrote: > * Michael Goldish <mgold...@redhat.com> [2009-03-11 03:02]: > > > We've also been creating stepfiles for Linux guests as well that > > > aren't > > > here, various SLES and RHEL installs -- and I've repeatedly seen > the > > > same issue where the cropped region *should* match but isn't, and > it > > > isn't a result of any of the very correct reasons you've listed > below > > > as > > > to why the stepfiles might fail. > > [snip] > > > > > Regarding the stepfiles you created for Linux -- I can't help much > > with those since I don't have the data. I do believe that if I had > the > > data and the stepfiles I could quickly identify the problem, so if > you > > think those can be sent to us, I'd like to have them. > > I created a stepfile for RHEL5 and what I'm seeing is that one of the > screens I captured in stepmaker ended up having a focus ring around > something and on replay the focus isn't there. This situation isn't > something that a new algo will fix as you pointed out. I'm wondering > if > this is something you've seen. I don't quite understand how it would > happen since stepmaker and the replace send the same keystrokes. I > also > don't see how in general this can be avoided.
The problem sounds familiar. Does the ring appear around one of the GNOME menubars, i.e. around "Applications" or "System"? GNOME seems to be somewhat indeterministic with those rings. If you run the stepfile several times, you'll notice that in most cases you'll see a focus ring (or no focus ring, I don't quite remember) and the rest of the time you'll get the other case. This can be avoided either with experience, or a good wiki entry on picking the right barriers (which we plan to create). But you don't have to avoid making mistakes with stepmaker -- most types of mistakes are fixed very quickly and easily with stepeditor. The fix depends on exactly what you were trying to do: - If you sent "alt-f1" to open the menu, and in the following step picked the open menu (including the "Applications" caption itself) to make sure it was open -- use stepeditor to modify the barrier so that it doesn't include the "Applications" caption or anything that might have a ring around it. - If you encountered the ring before sending "alt-f1" (I don't quite remember exactly when the ring tends to appear), and you picked the menubar in a barrier in order to make sure you've reached the desktop after the boot process, you may want to pick the little icons right next to the menubar instead (those typically include Firefox and/or Evolution icons) without including the ring in the barrier (it's also good practice not to include the desktop background in a barrier if it tends to change ). - If you encountered the ring somewhere else altogether, for example around a button during installation, then I don't remember seeing this case -- installations are usually quite deterministic -- but you can try picking the text inside the button, without including the ring, or if you need the button's surroundings as well, you can pick some tiny part of the button that is _outside_ the ring (I believe you have an outer ring there that is at least one or two pixels wide), as well as the surroundings, or you can use two consecutive barriers -- the first one picking the surroundings and the other picking text inside the button. All these can be done easily with stepeditor without having to run stepmaker all over again. If you place the stepmaker data in the right place (as I mentioned in a previous e-mail) it'll save you the time it takes to find what went wrong with the step. The following text was copied from your previous e-mail: > I do have the debug dir data from these runs. Looking at the cropped > ppm and screendump ppm is how I determined that there must be > something > wrong with how the image is rendered since the cropped ppm matches > the > screendump output, but with whatever subtle difference that generates > a > different md5sum. I'm not sure my previous e-mail was clear enough, so just in case it wasn't, let me rephrase: The cropped ppm is generated from the screendump ppm every time the stepfile running module receives a screendump from the guest in order to see if it matches a barrier. This is done for debugging purposes. If you somehow check, you'll see there is no subtle difference between those two files. It wouldn't make sense to find a subtle difference between them, and if you did find one, it certainly wouldn't indicate a stepfile problem, but rather a very strange bug in the framework. You should be looking for subtle differences between the screendump ppm and the reference screendump ppm, as well as between the cropped screendump ppm and the reference cropped screendump ppm. By "reference" I mean coming from the stepmaker data. If you don't have the stepmaker data, you have no way of knowing what caused the difference in the md5sums. There are two other things I forgot to mention in my previous e-mail: The Windows failures you're seeing might be caused by KVM bugs other than the one I mentioned. KVM-84 has a very strong tendency to crash during Windows installations. You can use the logs to find out if that happened in your case. If you have the latest git HEAD the exception info will look something like "Barrier timed out at step ... (VM is dead)", and if you have a slightly older version, you'll probably see "(guest is stuck)" at the end of the info string. You should also see the system consistently complaining that it can't fetch any screendumps from the guest (this will appear in stdout). The other thing has to do with the ISO files. kvm_runtest has a very important feature that we innocently forgot to implement in kvm_runtest_2 -- md5sum verification of the ISO files. This means that the framework currently makes no use of the "md5sum" and "md5sum_1m" parameters in the config file. This means you might be using different ISOs than the ones we made our stepfiles with. In that case I wouldn't expect any stepfile to succeed. However, if you used these same ISOs with kvm_runtest then they should be fine. In any case, I'll add the feature ASAP to the git repository. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
