Today OpenQA mostly runs on virtual machines, but it can get really tricky to find bugs triggered by real hardware. There are only few interfaces required to interact with a machine though:
1) HDMI
2) USB keyboard
3) CD-ROM
4) Remote Power Switching
For 1, I ordered a few HDMI frame grabbers that will only arrive after Hackweek. 2 and 3 should be possible to implement using the USB gadget support in Linux which a lot of ARM devices support - I can definitely donate a Beaglebone Black to whoever is interested. Power switching is a solved problem.
With all these bits in place and a bit of plumbing we should be able to run tests on actual hardware, hopefully extending our test coverage to more tricky scenarios.
Succeeded in emulating USB-mass-storage and USB-keyboard and serial. Also made a RPC for it, so you can use it in code running on any machine. See the demo video
Code is in a github branch
This allows to boot any machine off a virtual USB-CDROM and automate with keystrokes.
Still to do: emulate a tablet with absolute pointer coordinates and capture screen output.
This project is part of:
Hack Week 12
Activity
Comments
-
over 10 years ago by ancorgs | Reply
I guess you are aware of the IPMI and KVM2USB openQA backends and the discussions about real hardware support in the openQA mailing list (sorry, I don't know where to find the archives) that leaded to try IPMI as a first approach.
-
-
over 10 years ago by algraf | Reply
I just realized that we don't need to jump through hoops with the stm32 board or other cruftyness but instead we can just use the USB gadget support in Linux! So I guess the big task here would be to write a driver for the frame grabber, but that one will still take a few weeks to arrive :(.
That means for now, the main goal of this project would be to script up working USB hid and mass storage emulation by leveraging the already existing Linux infrastructure. Then add some plumbing to hook it up into OpenQA. Then wait until the hdmi grabber arrives ;).
-
-
over 10 years ago by bmwiedemann | Reply
Btw: from my experience with the kvm2usb, most hardware-specific bugs found are in the graphics drivers (apart from things like having 2 ethernet-ports with one being unconnected, which can be emulated in KVM)
-
Similar Projects
MCP Perl SDK by kraih
Description
We've been using the MCP Perl SDK to connect openQA with AI. And while the basics are working pretty well, the SDK is not fully spec compliant yet. So let's change that!
Goals
- Support for Resources
- All response types (Audio, Resource Links, Embedded Resources...)
- Tool/Prompt/Resource update notifications
- Dynamic Tool/Prompt/Resource lists
- New authentication mechanisms
Resources
openQA tests needles elaboration using AI image recognition by mdati
Description
In the openQA test framework, to identify the status of a target SUT image, a screenshots of GUI or CLI-terminal images,
the needles framework scans the many pictures in its repository, having associated a given set of tags (strings), selecting specific smaller parts of each available image. For the needles management actually we need to keep stored many screenshots, variants of GUI and CLI-terminal images, eachone accompanied by a dedicated set of data references (json).
A smarter framework, using image recognition based on AI or other image elaborations tools, nowadays widely available, could improve the matching process and hopefully reduce time and errors, during the images verification and detection process.
Goals
Main scope of this idea is to match a "graphical" image of the console or GUI status of a running openQA test, an image of a shell console or application-GUI screenshot, using less time and resources and with less errors in data preparation and use, than the actual openQA needles framework; that is:
- having a given SUT (system under test) GUI or CLI-terminal screenshot, with a local distribution of pixels or text commands related to a running test status,
- we want to identify a desired target, e.g. a screen image status or data/commands context,
- based on AI/ML-pretrained archives containing object or other proper elaboration tools,
- possibly able to identify also object not present in the archive, i.e. by means of AI/ML mechanisms.
- the matching result should be then adapted to continue working in the openQA test, likewise and in place of the same result that would have been produced by the original openQA needles framework.
- We expect an improvement of the matching-time(less time), reliability of the expected result(less error) and simplification of archive maintenance in adding/removing objects(smaller DB and less actions).
Hackweek POC:
Main steps
- Phase 1 - Plan
- study the available tools
- prepare a plan for the process to build
- Phase 2 - Implement
- write and build a draft application
- Phase 3 - Data
- prepare the data archive from a subset of needles
- initialize/pre-train the base archive
- select a screenshot from the subset, removing/changing some part
- Phase 4 - Test
- run the POC application
- expect the image type is identified in a good %.
Resources
First step of this project is quite identification of useful resources for the scope; some possibilities are:
- SUSE AI and other ML tools (i.e. Tensorflow)
- Tools able to manage images
- RPA test tools (like i.e. Robot framework)
- other.
Project references
- Repository: openqa-needles-AI-driven
openQA log viewer by mpagot
Description
*** Warning: Are You at Risk for VOMIT? ***
Do you find yourself staring at a screen, your eyes glossing over as thousands of lines of text scroll by? Do you feel a wave of text-based nausea when someone asks you to "just check the logs"?
You may be suffering from VOMIT (Verbose Output Mental Irritation Toxicity).
This dangerous, work-induced ailment is triggered by exposure to an overwhelming quantity of log data, especially from parallel systems. The human brain, not designed to mentally process 12 simultaneous autoinst-log.txt files, enters a state of toxic shock. It rejects the "Verbose Output," making it impossible to find the one critical error line buried in a 50,000-line sea of "INFO: doing a thing."
Before you're forced to rm -rf /var/log in a fit of desperation, we present the digital antacid.
No panic: we have The openQA Log Visualizer
This is the UI antidote for handling toxic log environments. It bravely dives into the chaotic, multi-machine mess of your openQA test runs, finds all the related, verbose logs, and force-feeds them into a parser.
Goals
Work on the existing POC openqa-log-visualizer about few specific tasks:
- add support for more type of logs
- extend the configuration file syntax beyond the actual one
- work on log parsing performance
Find some beta-tester and collect feedback and ideas about features
If time allow for it evaluate other UI frameworks and solutions (something more simple to distribute and run, maybe more low level to gain in performance).
Resources
OSHW USB token for Passkeys (FIDO2, U2F, WebAuthn) and PGP by duwe
Description
The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.
Meanwhile there are a few products available in that field, for example
yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.
nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !) Compute power is barely enough for Curve25519, Flash memory leaves room for only 3 keys.
solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it. Besides, NXP's support for open source toolchains for its devboards is extremely limited.
I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. Best OSS support seems to be for STM32-based products.
Goals
Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.
Resources
STM32 Nucleo, blackmagic probe, tropicsquare tropic01, arm-none cross toolchain