Hi,
For the last couple of days I’ve been trying to setup a device in our lab for deployment and installation of a Linux OS. However, I’ve came across a few issues and lots of questions and hopefully I can get some answers here.
Considerations:
1. I’ve decided to give it a go with LAVA v2 and try using the pipeline model 2. I’m not testing any “boards”, so it’s hard to find a similar example 3. I am not deploying any Linaro images (not even debian based) 4. My team develops and supports a reference Linux OS, based on RHEL, so that means we have total control of our images, kickstarter scripts, etc. 5. We already have a PXE server in our network, which is where our servers (the targets in this context) get booted from by default 6. Once booted from PXE, we get a PXE menu, where we can either select an option, or press ESC and add a custom command (at this syslinux is running) 7. We have access to the serial console of every device via serial port server (telnet <ipaddr> <port>) 8. We have power control over every device via IPMI
Issues:
1. I couldn’t find the documentation for how to add devices and device types to the server (which location to add the file, which format - yaml/conf) 2. In the above described environment, I suppose we would skip the deployment phase, since the devices already boot into syslinux from PXE (is this correct?). Either way, it would be nice to be able to run ‘ipmitool chassis booted pxe’ before rebooting the system. 3. Either way (via boot or deploy), how can I make sure to detect the PXE (syslinux) menu, send the ESC key, and send the command I need to trigger the kickstart installation?
To sum-up, the Workflow I’m trying to achieve after having completed the whole setup sort of goes like this:
1. Reboot target device into PXE (the PXE itself will download and start syslinux here) 2. Wait for PXE menu (expect some sort of string) 3. Send ESC key (to get into the boot shell) 4. Send command (this will trigger our kickstarter script and the installation will take around 5 minutes). The images that are needed are fetched automatically from our sftp server. 5. Wait for boot prompt after system installation succeeds 6. Login using credentials (username, password) 7. Run whatever tests we need from here
Any help here would be much appreciated. Thanks in advance! -- matallui
On 14 May 2016 at 01:32, Luís Matallui matallui@gmail.com wrote:
Hi,
For the last couple of days I’ve been trying to setup a device in our lab for deployment and installation of a Linux OS. However, I’ve came across a few issues and lots of questions and hopefully I can get some answers here.
Considerations:
- I’ve decided to give it a go with LAVA v2 and try using the pipeline model
- I’m not testing any “boards”, so it’s hard to find a similar example
This is a common misconception. Anything which runs tests as part of LAVA is a board/device. A DUT - device under test, even if it is a virtual machine running on a dispatcher.
- I am not deploying any Linaro images (not even debian based)
For that to be true, you would be testing only the bootloader or firmware, e.g. UEFI, Grub etc. There is a system deployed to that device - something that looks like POSIX. That system can be considered an image (it could be slowly copied off using dd) and it can be re-deployed as such when things go wrong. If you get to a login prompt and a POSIX shell once the device has booted, that device has had an image deployed.
LAVA V2 does away with the concept of a "Linaro" image - if the booted device provides a POSIX shell and it is on a machine other than the dispatcher - it's a deployment.
- My team develops and supports a reference Linux OS, based on RHEL, so that means we have total control of our images, kickstarter scripts, etc.
RPM based testing is not common in LAVA and the support scripts are not routinely tested. This may mean that you need to use some wrapper scripts to ensure that the correct dependencies are installed but you are still running tests on a deployment after booting a device. You have control over the images, so presumably those images are updated from time to time - that is an image deployment that LAVA can do.
- We already have a PXE server in our network, which is where our servers (the targets in this context) get booted from by default
- Once booted from PXE, we get a PXE menu, where we can either select an option, or press ESC and add a custom command (at this syslinux is running)
- We have access to the serial console of every device via serial port server (telnet <ipaddr> <port>)
- We have power control over every device via IPMI
Issues:
- I couldn’t find the documentation for how to add devices and device types to the server (which location to add the file, which format - yaml/conf)
In LAVA V2, all configuration lives on the server. The device type template is a jinja2 file which is parsed to output YAML.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
Adding devices to V2: https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
- In the above described environment, I suppose we would skip the deployment phase, since the devices already boot into syslinux from PXE (is this correct?).
Not necessarily.
https://staging.validation.linaro.org/static/docs/v2/dispatcher-design.html#...
You are better considering if you should actually deploy a fresh copy of the image each time to ensure you know what you are actually testing. Hint: only ever change one element at a time - it may sound obvious but you need to be obsessive about this.
Either way, it would be nice to be able to run ‘ipmitool chassis booted pxe’ before rebooting the system.
That is effectively your hard_reset_command in the Device Dictionary.
https://staging.validation.linaro.org/static/docs/v2/glossary.html#term-devi... https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre... https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
There are examples of x86 device dictionary entries but those particular x86 devices are rather specialised and the device dictionary includes lots of potentially confusing elements.
- Either way (via boot or deploy), how can I make sure to detect the PXE (syslinux) menu, send the ESC key, and send the command I need to trigger the kickstart installation?
LAVA V2 has iPXE support.
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
To sum-up, the Workflow I’m trying to achieve after having completed the whole setup sort of goes like this:
- Reboot target device into PXE (the PXE itself will download and start syslinux here)
- Wait for PXE menu (expect some sort of string)
- Send ESC key (to get into the boot shell)
- Send command (this will trigger our kickstarter script and the installation will take around 5 minutes). The images that are needed are fetched automatically from our sftp server.
This installation *is* a deployment. LAVA V2 has support for the Debian Installer (because most LAVA instances are based on Debian) but that support isn't going to work for a Linux OS installer which is not Debian-based. You might be able to support this with a simple (long) timeout or you could look at the Debian Installer support and implement something related for your installer.
- Wait for boot prompt after system installation succeeds
- Login using credentials (username, password)
auto_login:
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
- Run whatever tests we need from here
Any help here would be much appreciated. Thanks in advance!
Documentation for these steps is currently being updated and reviewed.
Currently, LAVA (V1 and V2) require a Debian based system - are you implementing such support or is your team interested in porting the Debian packaging to RHEL /RPM support? Note that there will be a *lot* of dependencies which would also need to be packaged before starting on the LAVA codebase. You will also need to maintain those dependencies, update them and keep them inline with the LAVA software which is tested on a Debian system.
Your use case is supportable but it will need work at your end as we are testing on a different environment.
On 16 May 2016 at 11:17, Neil Williams neil.williams@linaro.org wrote:
On 14 May 2016 at 01:32, Luís Matallui matallui@gmail.com wrote:
Hi,
For the last couple of days I’ve been trying to setup a device in our lab for deployment and installation of a Linux OS. However, I’ve came across a few issues and lots of questions and hopefully I can get some answers here.
Considerations:
- I’ve decided to give it a go with LAVA v2 and try using the pipeline model
- I’m not testing any “boards”, so it’s hard to find a similar example
This is a common misconception. Anything which runs tests as part of LAVA is a board/device. A DUT - device under test, even if it is a virtual machine running on a dispatcher.
- I am not deploying any Linaro images (not even debian based)
For that to be true, you would be testing only the bootloader or firmware, e.g. UEFI, Grub etc. There is a system deployed to that device - something that looks like POSIX. That system can be considered an image (it could be slowly copied off using dd) and it can be re-deployed as such when things go wrong. If you get to a login prompt and a POSIX shell once the device has booted, that device has had an image deployed.
LAVA V2 does away with the concept of a "Linaro" image - if the booted device provides a POSIX shell and it is on a machine other than the dispatcher - it's a deployment.
- My team develops and supports a reference Linux OS, based on RHEL, so that means we have total control of our images, kickstarter scripts, etc.
RPM based testing is not common in LAVA and the support scripts are not routinely tested. This may mean that you need to use some wrapper scripts to ensure that the correct dependencies are installed but you are still running tests on a deployment after booting a device. You have control over the images, so presumably those images are updated from time to time - that is an image deployment that LAVA can do.
- We already have a PXE server in our network, which is where our servers (the targets in this context) get booted from by default
- Once booted from PXE, we get a PXE menu, where we can either select an option, or press ESC and add a custom command (at this syslinux is running)
- We have access to the serial console of every device via serial port server (telnet <ipaddr> <port>)
- We have power control over every device via IPMI
Issues:
- I couldn’t find the documentation for how to add devices and device types to the server (which location to add the file, which format - yaml/conf)
In LAVA V2, all configuration lives on the server. The device type template is a jinja2 file which is parsed to output YAML.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
Adding devices to V2: https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
- In the above described environment, I suppose we would skip the deployment phase, since the devices already boot into syslinux from PXE (is this correct?).
Not necessarily.
https://staging.validation.linaro.org/static/docs/v2/dispatcher-design.html#...
You are better considering if you should actually deploy a fresh copy of the image each time to ensure you know what you are actually testing. Hint: only ever change one element at a time - it may sound obvious but you need to be obsessive about this.
Either way, it would be nice to be able to run ‘ipmitool chassis booted pxe’ before rebooting the system.
That is effectively your hard_reset_command in the Device Dictionary.
https://staging.validation.linaro.org/static/docs/v2/glossary.html#term-devi... https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre... https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
There are examples of x86 device dictionary entries but those particular x86 devices are rather specialised and the device dictionary includes lots of potentially confusing elements.
- Either way (via boot or deploy), how can I make sure to detect the PXE (syslinux) menu, send the ESC key, and send the command I need to trigger the kickstart installation?
LAVA V2 has iPXE support.
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Can I just jump in here and state, like I do rather often, that the fact this board uses PXE to load syslinux, has nothing to do whatsoever with iPXE support. PXE != iPXE, iPXE is just another bootloader. How the board gets to that bootloader is largely irrelevant. The real support needed here is "syslinux", but V2 doesn't yet have a generic bootloader support which would mean this could be driven by just config files.
You could of course use iPXE to boot your installer, replacing syslinux, but I would imagine that's part of the things they are trying to test.
To sum-up, the Workflow I’m trying to achieve after having completed the whole setup sort of goes like this:
- Reboot target device into PXE (the PXE itself will download and start syslinux here)
- Wait for PXE menu (expect some sort of string)
- Send ESC key (to get into the boot shell)
- Send command (this will trigger our kickstarter script and the installation will take around 5 minutes). The images that are needed are fetched automatically from our sftp server.
This installation *is* a deployment. LAVA V2 has support for the Debian Installer (because most LAVA instances are based on Debian) but that support isn't going to work for a Linux OS installer which is not Debian-based. You might be able to support this with a simple (long) timeout or you could look at the Debian Installer support and implement something related for your installer.
- Wait for boot prompt after system installation succeeds
- Login using credentials (username, password)
auto_login:
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
- Run whatever tests we need from here
Any help here would be much appreciated. Thanks in advance!
Documentation for these steps is currently being updated and reviewed.
Currently, LAVA (V1 and V2) require a Debian based system - are you implementing such support or is your team interested in porting the Debian packaging to RHEL /RPM support? Note that there will be a *lot* of dependencies which would also need to be packaged before starting on the LAVA codebase. You will also need to maintain those dependencies, update them and keep them inline with the LAVA software which is tested on a Debian system.
Your use case is supportable but it will need work at your end as we are testing on a different environment.
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/ _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
On 16 May 2016 at 11:25, Matt Hart matthew.hart@linaro.org wrote:
On 16 May 2016 at 11:17, Neil Williams neil.williams@linaro.org wrote:
On 14 May 2016 at 01:32, Luís Matallui matallui@gmail.com wrote:
Hi,
For the last couple of days I’ve been trying to setup a device in our lab for deployment and installation of a Linux OS. However, I’ve came across a few issues and lots of questions and hopefully I can get some answers here.
Considerations:
- I’ve decided to give it a go with LAVA v2 and try using the pipeline model
- I’m not testing any “boards”, so it’s hard to find a similar example
This is a common misconception. Anything which runs tests as part of LAVA is a board/device. A DUT - device under test, even if it is a virtual machine running on a dispatcher.
- I am not deploying any Linaro images (not even debian based)
For that to be true, you would be testing only the bootloader or firmware, e.g. UEFI, Grub etc. There is a system deployed to that device - something that looks like POSIX. That system can be considered an image (it could be slowly copied off using dd) and it can be re-deployed as such when things go wrong. If you get to a login prompt and a POSIX shell once the device has booted, that device has had an image deployed.
LAVA V2 does away with the concept of a "Linaro" image - if the booted device provides a POSIX shell and it is on a machine other than the dispatcher - it's a deployment.
- My team develops and supports a reference Linux OS, based on RHEL, so that means we have total control of our images, kickstarter scripts, etc.
RPM based testing is not common in LAVA and the support scripts are not routinely tested. This may mean that you need to use some wrapper scripts to ensure that the correct dependencies are installed but you are still running tests on a deployment after booting a device. You have control over the images, so presumably those images are updated from time to time - that is an image deployment that LAVA can do.
- We already have a PXE server in our network, which is where our servers (the targets in this context) get booted from by default
- Once booted from PXE, we get a PXE menu, where we can either select an option, or press ESC and add a custom command (at this syslinux is running)
- We have access to the serial console of every device via serial port server (telnet <ipaddr> <port>)
- We have power control over every device via IPMI
Issues:
- I couldn’t find the documentation for how to add devices and device types to the server (which location to add the file, which format - yaml/conf)
In LAVA V2, all configuration lives on the server. The device type template is a jinja2 file which is parsed to output YAML.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
Adding devices to V2: https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
- In the above described environment, I suppose we would skip the deployment phase, since the devices already boot into syslinux from PXE (is this correct?).
Not necessarily.
https://staging.validation.linaro.org/static/docs/v2/dispatcher-design.html#...
You are better considering if you should actually deploy a fresh copy of the image each time to ensure you know what you are actually testing. Hint: only ever change one element at a time - it may sound obvious but you need to be obsessive about this.
Either way, it would be nice to be able to run ‘ipmitool chassis booted pxe’ before rebooting the system.
That is effectively your hard_reset_command in the Device Dictionary.
https://staging.validation.linaro.org/static/docs/v2/glossary.html#term-devi... https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre... https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
There are examples of x86 device dictionary entries but those particular x86 devices are rather specialised and the device dictionary includes lots of potentially confusing elements.
- Either way (via boot or deploy), how can I make sure to detect the PXE (syslinux) menu, send the ESC key, and send the command I need to trigger the kickstart installation?
LAVA V2 has iPXE support.
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Can I just jump in here and state, like I do rather often, that the fact this board uses PXE to load syslinux, has nothing to do whatsoever with iPXE support. PXE != iPXE, iPXE is just another bootloader. How the board gets to that bootloader is largely irrelevant. The real support needed here is "syslinux", but V2 doesn't yet have a generic bootloader support which would mean this could be driven by just config files.
True - I end up using syslinux for other projects and it can be a pain to drive properly. Grub (specifically grub2) is a lot easier - if you are open to that level of change in your tests, it is worth doing.
You could of course use iPXE to boot your installer, replacing syslinux, but I would imagine that's part of the things they are trying to test.
To sum-up, the Workflow I’m trying to achieve after having completed the whole setup sort of goes like this:
- Reboot target device into PXE (the PXE itself will download and start syslinux here)
- Wait for PXE menu (expect some sort of string)
- Send ESC key (to get into the boot shell)
- Send command (this will trigger our kickstarter script and the installation will take around 5 minutes). The images that are needed are fetched automatically from our sftp server.
This installation *is* a deployment. LAVA V2 has support for the Debian Installer (because most LAVA instances are based on Debian) but that support isn't going to work for a Linux OS installer which is not Debian-based. You might be able to support this with a simple (long) timeout or you could look at the Debian Installer support and implement something related for your installer.
- Wait for boot prompt after system installation succeeds
- Login using credentials (username, password)
auto_login:
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
- Run whatever tests we need from here
Any help here would be much appreciated. Thanks in advance!
Documentation for these steps is currently being updated and reviewed.
Currently, LAVA (V1 and V2) require a Debian based system - are you implementing such support or is your team interested in porting the Debian packaging to RHEL /RPM support? Note that there will be a *lot* of dependencies which would also need to be packaged before starting on the LAVA codebase. You will also need to maintain those dependencies, update them and keep them inline with the LAVA software which is tested on a Debian system.
Your use case is supportable but it will need work at your end as we are testing on a different environment.
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/ _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
First of all, thanks so much for the (really fast) reply.
About adding devices, I got the formats now (yaml, jinja2). However, I still couldn't figure out how to actually add those files into the database. In the web administration panel, if I try to add a new device, it doesn't allow me to add a jinja or yaml file, even though I can see those options under advanced options.
Nevertheless, about the whole process... I guess I'm still trying to understand how the whole Lava workflow goes. I get the part about syslinux, and you're right, if the target system boots syslinux (no matter where that came from), that's our bootloader, which Lava doesn't support.
Just so I understand the difference between "deploy" and "boot". In this scenario, is "deploy" the part where syslinux gets deployed into the system, and "boot" the part where the system would boot once syslinux commands select what to boot? Also, if syslinux triggers an installer, is that still part of boot?
From what I got from Neil, I could simply consider that as "boot" process,
and add a long boot timeout.
One thing that I haven't been able to get (yet another thing!): I've heard/read in a few places about the "Lava Overlay". Can I ask what this is? How would I fit this into the picture?
Thanks in advance, matallui
On 16 May 2016 at 11:32, Neil Williams neil.williams@linaro.org wrote:
On 16 May 2016 at 11:25, Matt Hart matthew.hart@linaro.org wrote:
On 16 May 2016 at 11:17, Neil Williams neil.williams@linaro.org wrote:
On 14 May 2016 at 01:32, Luís Matallui matallui@gmail.com wrote:
Hi,
For the last couple of days I’ve been trying to setup a device in our
lab for deployment and installation of a Linux OS.
However, I’ve came across a few issues and lots of questions and
hopefully I can get some answers here.
Considerations:
- I’ve decided to give it a go with LAVA v2 and try using the
pipeline model
- I’m not testing any “boards”, so it’s hard to find a similar example
This is a common misconception. Anything which runs tests as part of LAVA is a board/device. A DUT - device under test, even if it is a virtual machine running on a dispatcher.
- I am not deploying any Linaro images (not even debian based)
For that to be true, you would be testing only the bootloader or firmware, e.g. UEFI, Grub etc. There is a system deployed to that device - something that looks like POSIX. That system can be considered an image (it could be slowly copied off using dd) and it can be re-deployed as such when things go wrong. If you get to a login prompt and a POSIX shell once the device has booted, that device has had an image deployed.
LAVA V2 does away with the concept of a "Linaro" image - if the booted device provides a POSIX shell and it is on a machine other than the dispatcher - it's a deployment.
- My team develops and supports a reference Linux OS, based on RHEL,
so that means we have total control of our images, kickstarter scripts, etc.
RPM based testing is not common in LAVA and the support scripts are not routinely tested. This may mean that you need to use some wrapper scripts to ensure that the correct dependencies are installed but you are still running tests on a deployment after booting a device. You have control over the images, so presumably those images are updated from time to time - that is an image deployment that LAVA can do.
- We already have a PXE server in our network, which is where our
servers (the targets in this context) get booted from by default
- Once booted from PXE, we get a PXE menu, where we can either select
an option, or press ESC and add a custom command (at this syslinux is running)
- We have access to the serial console of every device via serial
port server (telnet <ipaddr> <port>)
- We have power control over every device via IPMI
Issues:
- I couldn’t find the documentation for how to add devices and device
types to the server (which location to add the file, which format - yaml/conf)
In LAVA V2, all configuration lives on the server. The device type template is a jinja2 file which is parsed to output YAML.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
Adding devices to V2:
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
- In the above described environment, I suppose we would skip the
deployment phase, since the devices already boot into syslinux from PXE (is this correct?).
Not necessarily.
https://staging.validation.linaro.org/static/docs/v2/dispatcher-design.html#...
You are better considering if you should actually deploy a fresh copy of the image each time to ensure you know what you are actually testing. Hint: only ever change one element at a time - it may sound obvious but you need to be obsessive about this.
Either way, it would be nice to be able to run ‘ipmitool chassis
booted pxe’ before rebooting the system.
That is effectively your hard_reset_command in the Device Dictionary.
https://staging.validation.linaro.org/static/docs/v2/glossary.html#term-devi...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
There are examples of x86 device dictionary entries but those particular x86 devices are rather specialised and the device dictionary includes lots of potentially confusing elements.
- Either way (via boot or deploy), how can I make sure to detect the
PXE (syslinux) menu, send the ESC key, and send the command I need to trigger the kickstart installation?
LAVA V2 has iPXE support.
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Can I just jump in here and state, like I do rather often, that the fact this board uses PXE to load syslinux, has nothing to do whatsoever with iPXE support. PXE != iPXE, iPXE is just another bootloader. How the board gets to that bootloader is largely irrelevant. The real support needed here is "syslinux", but V2 doesn't yet have a generic bootloader support which would mean this could be driven by just config files.
True - I end up using syslinux for other projects and it can be a pain to drive properly. Grub (specifically grub2) is a lot easier - if you are open to that level of change in your tests, it is worth doing.
You could of course use iPXE to boot your installer, replacing syslinux, but I would imagine that's part of the things they are trying to test.
To sum-up, the Workflow I’m trying to achieve after having completed
the whole setup sort of goes like this:
- Reboot target device into PXE (the PXE itself will download and
start syslinux here)
- Wait for PXE menu (expect some sort of string)
- Send ESC key (to get into the boot shell)
- Send command (this will trigger our kickstarter script and the
installation will take around 5 minutes). The images that are needed are fetched automatically from our sftp server.
This installation *is* a deployment. LAVA V2 has support for the Debian Installer (because most LAVA instances are based on Debian) but that support isn't going to work for a Linux OS installer which is not Debian-based. You might be able to support this with a simple (long) timeout or you could look at the Debian Installer support and implement something related for your installer.
- Wait for boot prompt after system installation succeeds
- Login using credentials (username, password)
auto_login:
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
- Run whatever tests we need from here
Any help here would be much appreciated. Thanks in advance!
Documentation for these steps is currently being updated and reviewed.
Currently, LAVA (V1 and V2) require a Debian based system - are you implementing such support or is your team interested in porting the Debian packaging to RHEL /RPM support? Note that there will be a *lot* of dependencies which would also need to be packaged before starting on the LAVA codebase. You will also need to maintain those dependencies, update them and keep them inline with the LAVA software which is tested on a Debian system.
Your use case is supportable but it will need work at your end as we are testing on a different environment.
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/ _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On 16 May 2016 at 13:03, Luís Matallui matallui@gmail.com wrote:
First of all, thanks so much for the (really fast) reply.
About adding devices, I got the formats now (yaml, jinja2). However, I still couldn't figure out how to actually add those files into the database.
The files do not live in the database, they live in the codebase and are referenced by entries in the database. So create a device_type in the database as normal, create a device in the database (and mark it as a pipeline device), then that entry will be used with the files.
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#add... https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre...
In the web administration panel, if I try to add a new device, it doesn't allow me to add a jinja or yaml file, even though I can see those options under advanced options.
Correct. The database is no place for arbitrarily long lumps of text / templates. The contents of the device dictionary are displayed in the device detail page in the admin interface for reference.
The mapping is:
Database: device_type:name -> filename.jinja2 (file in /etc/lava-server/dispatcher-config/device-types/
The device dictionary is best in a file (for version control reasons) and is updated in the database using the command line.
Nevertheless, about the whole process... I guess I'm still trying to understand how the whole Lava workflow goes. I get the part about syslinux, and you're right, if the target system boots syslinux (no matter where that came from), that's our bootloader, which Lava doesn't support.
Just so I understand the difference between "deploy" and "boot". In this scenario, is "deploy" the part where syslinux gets deployed into the system, and "boot" the part where the system would boot once syslinux commands select what to boot? Also, if syslinux triggers an installer, is that still part of boot?
Can be - it depends on the use case. For simplicity, you can simply have a very long boot where the installer operates and then the end of the boot is determined by the installer getting to a login shell. If you want to track messages from the installer or particularly to track the booting of the device into the installed system as a boot action, then that becomes installer-specific.
From what I got from Neil, I could simply consider that as "boot" process, and add a long boot timeout.
You can, yes. It does change how you view the details of that install but it depends what is your priority - are you primarily testing the installer or the installed system? Remember: if you say both, that needs to be TWO separate jobs, not one. Test one element at a time.
One thing that I haven't been able to get (yet another thing!): I've heard/read in a few places about the "Lava Overlay". Can I ask what this is? How would I fit this into the picture?
The LAVA overlay is a tarball containing the lava helper scripts and your lava test shell definitions. e.g. https://staging.validation.linaro.org/scheduler/job/146127/complete_log?debu...
In order to run the lava test shell scripts, this overlay needs to be unpacked into the relevant location. If you are testing the installed system, then there needs to be some way of getting that into the installed system. That may involve code changes for installers other than Debian.
Thanks in advance, matallui
On 16 May 2016 at 11:32, Neil Williams neil.williams@linaro.org wrote:
On 16 May 2016 at 11:25, Matt Hart matthew.hart@linaro.org wrote:
On 16 May 2016 at 11:17, Neil Williams neil.williams@linaro.org wrote:
On 14 May 2016 at 01:32, Luís Matallui matallui@gmail.com wrote:
Hi,
For the last couple of days I’ve been trying to setup a device in our lab for deployment and installation of a Linux OS. However, I’ve came across a few issues and lots of questions and hopefully I can get some answers here.
Considerations:
- I’ve decided to give it a go with LAVA v2 and try using the
pipeline model 2. I’m not testing any “boards”, so it’s hard to find a similar example
This is a common misconception. Anything which runs tests as part of LAVA is a board/device. A DUT - device under test, even if it is a virtual machine running on a dispatcher.
- I am not deploying any Linaro images (not even debian based)
For that to be true, you would be testing only the bootloader or firmware, e.g. UEFI, Grub etc. There is a system deployed to that device - something that looks like POSIX. That system can be considered an image (it could be slowly copied off using dd) and it can be re-deployed as such when things go wrong. If you get to a login prompt and a POSIX shell once the device has booted, that device has had an image deployed.
LAVA V2 does away with the concept of a "Linaro" image - if the booted device provides a POSIX shell and it is on a machine other than the dispatcher - it's a deployment.
- My team develops and supports a reference Linux OS, based on RHEL,
so that means we have total control of our images, kickstarter scripts, etc.
RPM based testing is not common in LAVA and the support scripts are not routinely tested. This may mean that you need to use some wrapper scripts to ensure that the correct dependencies are installed but you are still running tests on a deployment after booting a device. You have control over the images, so presumably those images are updated from time to time - that is an image deployment that LAVA can do.
- We already have a PXE server in our network, which is where our
servers (the targets in this context) get booted from by default 6. Once booted from PXE, we get a PXE menu, where we can either select an option, or press ESC and add a custom command (at this syslinux is running) 7. We have access to the serial console of every device via serial port server (telnet <ipaddr> <port>) 8. We have power control over every device via IPMI
Issues:
- I couldn’t find the documentation for how to add devices and device
types to the server (which location to add the file, which format - yaml/conf)
In LAVA V2, all configuration lives on the server. The device type template is a jinja2 file which is parsed to output YAML.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
Adding devices to V2:
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
- In the above described environment, I suppose we would skip the
deployment phase, since the devices already boot into syslinux from PXE (is this correct?).
Not necessarily.
https://staging.validation.linaro.org/static/docs/v2/dispatcher-design.html#...
You are better considering if you should actually deploy a fresh copy of the image each time to ensure you know what you are actually testing. Hint: only ever change one element at a time - it may sound obvious but you need to be obsessive about this.
Either way, it would be nice to be able to run ‘ipmitool chassis booted pxe’ before rebooting the system.
That is effectively your hard_reset_command in the Device Dictionary.
https://staging.validation.linaro.org/static/docs/v2/glossary.html#term-devi...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
There are examples of x86 device dictionary entries but those particular x86 devices are rather specialised and the device dictionary includes lots of potentially confusing elements.
- Either way (via boot or deploy), how can I make sure to detect the
PXE (syslinux) menu, send the ESC key, and send the command I need to trigger the kickstart installation?
LAVA V2 has iPXE support.
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Can I just jump in here and state, like I do rather often, that the fact this board uses PXE to load syslinux, has nothing to do whatsoever with iPXE support. PXE != iPXE, iPXE is just another bootloader. How the board gets to that bootloader is largely irrelevant. The real support needed here is "syslinux", but V2 doesn't yet have a generic bootloader support which would mean this could be driven by just config files.
True - I end up using syslinux for other projects and it can be a pain to drive properly. Grub (specifically grub2) is a lot easier - if you are open to that level of change in your tests, it is worth doing.
You could of course use iPXE to boot your installer, replacing syslinux, but I would imagine that's part of the things they are trying to test.
To sum-up, the Workflow I’m trying to achieve after having completed the whole setup sort of goes like this:
- Reboot target device into PXE (the PXE itself will download and
start syslinux here) 2. Wait for PXE menu (expect some sort of string) 3. Send ESC key (to get into the boot shell) 4. Send command (this will trigger our kickstarter script and the installation will take around 5 minutes). The images that are needed are fetched automatically from our sftp server.
This installation *is* a deployment. LAVA V2 has support for the Debian Installer (because most LAVA instances are based on Debian) but that support isn't going to work for a Linux OS installer which is not Debian-based. You might be able to support this with a simple (long) timeout or you could look at the Debian Installer support and implement something related for your installer.
- Wait for boot prompt after system installation succeeds
- Login using credentials (username, password)
auto_login:
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
- Run whatever tests we need from here
Any help here would be much appreciated. Thanks in advance!
Documentation for these steps is currently being updated and reviewed.
Currently, LAVA (V1 and V2) require a Debian based system - are you implementing such support or is your team interested in porting the Debian packaging to RHEL /RPM support? Note that there will be a *lot* of dependencies which would also need to be packaged before starting on the LAVA codebase. You will also need to maintain those dependencies, update them and keep them inline with the LAVA software which is tested on a Debian system.
Your use case is supportable but it will need work at your end as we are testing on a different environment.
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/ _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
Thanks again Neil!
I will try setting this up once again. As for the LAVA overlay, we can easily modify our installer for that.
Still about the boot loaders: what makes each boot loader support so different? If I was to use, say iPXE, but tweaked the expected prompt, and added a couple of syslinux commands to run instead of iPXE commands (e.g., trigger our installer), what would be the problem with that?
-- matallui
On 16 May 2016 at 13:22, Neil Williams neil.williams@linaro.org wrote:
On 16 May 2016 at 13:03, Luís Matallui matallui@gmail.com wrote:
First of all, thanks so much for the (really fast) reply.
About adding devices, I got the formats now (yaml, jinja2). However, I still couldn't figure out how to actually add those files into the database.
The files do not live in the database, they live in the codebase and are referenced by entries in the database. So create a device_type in the database as normal, create a device in the database (and mark it as a pipeline device), then that entry will be used with the files.
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#add...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre...
In the web administration panel, if I try to add a new device, it doesn't allow me to add a jinja or yaml file, even though I can see those options under advanced options.
Correct. The database is no place for arbitrarily long lumps of text / templates. The contents of the device dictionary are displayed in the device detail page in the admin interface for reference.
The mapping is:
Database: device_type:name -> filename.jinja2 (file in /etc/lava-server/dispatcher-config/device-types/
The device dictionary is best in a file (for version control reasons) and is updated in the database using the command line.
Nevertheless, about the whole process... I guess I'm still trying to understand how the whole Lava workflow goes. I get the part about syslinux, and you're right, if the target system
boots
syslinux (no matter where that came from), that's our bootloader, which
Lava
doesn't support.
Just so I understand the difference between "deploy" and "boot". In this scenario, is "deploy" the part where syslinux gets deployed into
the
system, and "boot" the part where the system would boot once syslinux commands select what to boot? Also, if syslinux triggers an installer, is that still part of boot?
Can be - it depends on the use case. For simplicity, you can simply have a very long boot where the installer operates and then the end of the boot is determined by the installer getting to a login shell. If you want to track messages from the installer or particularly to track the booting of the device into the installed system as a boot action, then that becomes installer-specific.
From what I got from Neil, I could simply consider that as "boot"
process,
and add a long boot timeout.
You can, yes. It does change how you view the details of that install but it depends what is your priority - are you primarily testing the installer or the installed system? Remember: if you say both, that needs to be TWO separate jobs, not one. Test one element at a time.
One thing that I haven't been able to get (yet another thing!): I've heard/read in a few places about the "Lava Overlay". Can I ask what this is? How would I fit this into the picture?
The LAVA overlay is a tarball containing the lava helper scripts and your lava test shell definitions. e.g.
https://staging.validation.linaro.org/scheduler/job/146127/complete_log?debu...
In order to run the lava test shell scripts, this overlay needs to be unpacked into the relevant location. If you are testing the installed system, then there needs to be some way of getting that into the installed system. That may involve code changes for installers other than Debian.
Thanks in advance, matallui
On 16 May 2016 at 11:32, Neil Williams neil.williams@linaro.org wrote:
On 16 May 2016 at 11:25, Matt Hart matthew.hart@linaro.org wrote:
On 16 May 2016 at 11:17, Neil Williams neil.williams@linaro.org
wrote:
On 14 May 2016 at 01:32, Luís Matallui matallui@gmail.com wrote:
Hi,
For the last couple of days I’ve been trying to setup a device in
our
lab for deployment and installation of a Linux OS. However, I’ve came across a few issues and lots of questions and hopefully I can get some answers here.
Considerations:
- I’ve decided to give it a go with LAVA v2 and try using the
pipeline model 2. I’m not testing any “boards”, so it’s hard to find a similar example
This is a common misconception. Anything which runs tests as part of LAVA is a board/device. A DUT - device under test, even if it is a virtual machine running on a dispatcher.
- I am not deploying any Linaro images (not even debian based)
For that to be true, you would be testing only the bootloader or firmware, e.g. UEFI, Grub etc. There is a system deployed to that device - something that looks like POSIX. That system can be considered an image (it could be slowly copied off using dd) and it can be re-deployed as such when things go wrong. If you get to a
login
prompt and a POSIX shell once the device has booted, that device has had an image deployed.
LAVA V2 does away with the concept of a "Linaro" image - if the
booted
device provides a POSIX shell and it is on a machine other than the dispatcher - it's a deployment.
- My team develops and supports a reference Linux OS, based on
RHEL,
so that means we have total control of our images, kickstarter
scripts, etc.
RPM based testing is not common in LAVA and the support scripts are not routinely tested. This may mean that you need to use some wrapper scripts to ensure that the correct dependencies are installed but you are still running tests on a deployment after booting a device. You have control over the images, so presumably those images are updated from time to time - that is an image deployment that LAVA can do.
- We already have a PXE server in our network, which is where our
servers (the targets in this context) get booted from by default 6. Once booted from PXE, we get a PXE menu, where we can either
select
an option, or press ESC and add a custom command (at this syslinux
is
running) 7. We have access to the serial console of every device via serial port server (telnet <ipaddr> <port>) 8. We have power control over every device via IPMI
Issues:
- I couldn’t find the documentation for how to add devices and
device
types to the server (which location to add the file, which format - yaml/conf)
In LAVA V2, all configuration lives on the server. The device type template is a jinja2 file which is parsed to output YAML.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
Adding devices to V2:
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
- In the above described environment, I suppose we would skip the
deployment phase, since the devices already boot into syslinux from
PXE (is
this correct?).
Not necessarily.
https://staging.validation.linaro.org/static/docs/v2/dispatcher-design.html#...
You are better considering if you should actually deploy a fresh copy of the image each time to ensure you know what you are actually testing. Hint: only ever change one element at a time - it may sound obvious but you need to be obsessive about this.
Either way, it would be nice to be able to run ‘ipmitool chassis booted pxe’ before rebooting the system.
That is effectively your hard_reset_command in the Device Dictionary.
https://staging.validation.linaro.org/static/docs/v2/glossary.html#term-devi...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
There are examples of x86 device dictionary entries but those particular x86 devices are rather specialised and the device dictionary includes lots of potentially confusing elements.
- Either way (via boot or deploy), how can I make sure to detect
the
PXE (syslinux) menu, send the ESC key, and send the command I need
to
trigger the kickstart installation?
LAVA V2 has iPXE support.
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Can I just jump in here and state, like I do rather often, that the fact this board uses PXE to load syslinux, has nothing to do whatsoever with iPXE support. PXE != iPXE, iPXE is just another bootloader. How the board gets to that bootloader is largely irrelevant. The real support needed here is "syslinux", but V2 doesn't yet have a generic bootloader support which would mean this could be driven by just config files.
True - I end up using syslinux for other projects and it can be a pain to drive properly. Grub (specifically grub2) is a lot easier - if you are open to that level of change in your tests, it is worth doing.
You could of course use iPXE to boot your installer, replacing syslinux, but I would imagine that's part of the things they are trying to test.
To sum-up, the Workflow I’m trying to achieve after having completed the whole setup sort of goes like this:
- Reboot target device into PXE (the PXE itself will download and
start syslinux here) 2. Wait for PXE menu (expect some sort of string) 3. Send ESC key (to get into the boot shell) 4. Send command (this will trigger our kickstarter script and the installation will take around 5 minutes). The images that are
needed are
fetched automatically from our sftp server.
This installation *is* a deployment. LAVA V2 has support for the Debian Installer (because most LAVA instances are based on Debian)
but
that support isn't going to work for a Linux OS installer which is
not
Debian-based. You might be able to support this with a simple (long) timeout or you could look at the Debian Installer support and implement something related for your installer.
- Wait for boot prompt after system installation succeeds
- Login using credentials (username, password)
auto_login:
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
- Run whatever tests we need from here
Any help here would be much appreciated. Thanks in advance!
Documentation for these steps is currently being updated and
reviewed.
Currently, LAVA (V1 and V2) require a Debian based system - are you implementing such support or is your team interested in porting the Debian packaging to RHEL /RPM support? Note that there will be a
*lot*
of dependencies which would also need to be packaged before starting on the LAVA codebase. You will also need to maintain those dependencies, update them and keep them inline with the LAVA software which is tested on a Debian system.
Your use case is supportable but it will need work at your end as we are testing on a different environment.
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/ _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
Hi again,
So today I was able to trigger our installer, which was a really good step for me. I'm currently playing around with uefi-menu parameters, which so far seems like the best option for what I need. Anyway, the issue is at least no longer the subject of this thread, so we can close this one.
Thanks a lot for all the info! -- matallui
On 16 May 2016 at 13:34, Luís Matallui matallui@gmail.com wrote:
Thanks again Neil!
I will try setting this up once again. As for the LAVA overlay, we can easily modify our installer for that.
Still about the boot loaders: what makes each boot loader support so different? If I was to use, say iPXE, but tweaked the expected prompt, and added a couple of syslinux commands to run instead of iPXE commands (e.g., trigger our installer), what would be the problem with that?
-- matallui
On 16 May 2016 at 13:22, Neil Williams neil.williams@linaro.org wrote:
On 16 May 2016 at 13:03, Luís Matallui matallui@gmail.com wrote:
First of all, thanks so much for the (really fast) reply.
About adding devices, I got the formats now (yaml, jinja2). However, I still couldn't figure out how to actually add those files
into
the database.
The files do not live in the database, they live in the codebase and are referenced by entries in the database. So create a device_type in the database as normal, create a device in the database (and mark it as a pipeline device), then that entry will be used with the files.
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#add...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre...
In the web administration panel, if I try to add a new device, it
doesn't
allow me to add a jinja or yaml file, even though I can see those
options
under advanced options.
Correct. The database is no place for arbitrarily long lumps of text / templates. The contents of the device dictionary are displayed in the device detail page in the admin interface for reference.
The mapping is:
Database: device_type:name -> filename.jinja2 (file in /etc/lava-server/dispatcher-config/device-types/
The device dictionary is best in a file (for version control reasons) and is updated in the database using the command line.
Nevertheless, about the whole process... I guess I'm still trying to understand how the whole Lava workflow goes. I get the part about syslinux, and you're right, if the target system
boots
syslinux (no matter where that came from), that's our bootloader, which
Lava
doesn't support.
Just so I understand the difference between "deploy" and "boot". In this scenario, is "deploy" the part where syslinux gets deployed
into the
system, and "boot" the part where the system would boot once syslinux commands select what to boot? Also, if syslinux triggers an installer,
is
that still part of boot?
Can be - it depends on the use case. For simplicity, you can simply have a very long boot where the installer operates and then the end of the boot is determined by the installer getting to a login shell. If you want to track messages from the installer or particularly to track the booting of the device into the installed system as a boot action, then that becomes installer-specific.
From what I got from Neil, I could simply consider that as "boot"
process,
and add a long boot timeout.
You can, yes. It does change how you view the details of that install but it depends what is your priority - are you primarily testing the installer or the installed system? Remember: if you say both, that needs to be TWO separate jobs, not one. Test one element at a time.
One thing that I haven't been able to get (yet another thing!): I've heard/read in a few places about the "Lava Overlay". Can I ask what this is? How would I fit this into the picture?
The LAVA overlay is a tarball containing the lava helper scripts and your lava test shell definitions. e.g.
https://staging.validation.linaro.org/scheduler/job/146127/complete_log?debu...
In order to run the lava test shell scripts, this overlay needs to be unpacked into the relevant location. If you are testing the installed system, then there needs to be some way of getting that into the installed system. That may involve code changes for installers other than Debian.
Thanks in advance, matallui
On 16 May 2016 at 11:32, Neil Williams neil.williams@linaro.org
wrote:
On 16 May 2016 at 11:25, Matt Hart matthew.hart@linaro.org wrote:
On 16 May 2016 at 11:17, Neil Williams neil.williams@linaro.org
wrote:
On 14 May 2016 at 01:32, Luís Matallui matallui@gmail.com wrote: > Hi, > > For the last couple of days I’ve been trying to setup a device in
our
> lab for deployment and installation of a Linux OS. > However, I’ve came across a few issues and lots of questions and > hopefully I can get some answers here. > > Considerations: > > 1. I’ve decided to give it a go with LAVA v2 and try using the > pipeline model > 2. I’m not testing any “boards”, so it’s hard to find a similar > example
This is a common misconception. Anything which runs tests as part of LAVA is a board/device. A DUT - device under test, even if it is a virtual machine running on a dispatcher.
> 3. I am not deploying any Linaro images (not even debian based)
For that to be true, you would be testing only the bootloader or firmware, e.g. UEFI, Grub etc. There is a system deployed to that device - something that looks like POSIX. That system can be considered an image (it could be slowly copied off using dd) and it can be re-deployed as such when things go wrong. If you get to a
login
prompt and a POSIX shell once the device has booted, that device has had an image deployed.
LAVA V2 does away with the concept of a "Linaro" image - if the
booted
device provides a POSIX shell and it is on a machine other than the dispatcher - it's a deployment.
> 4. My team develops and supports a reference Linux OS, based on
RHEL,
> so that means we have total control of our images, kickstarter
scripts, etc.
RPM based testing is not common in LAVA and the support scripts are not routinely tested. This may mean that you need to use some
wrapper
scripts to ensure that the correct dependencies are installed but
you
are still running tests on a deployment after booting a device. You have control over the images, so presumably those images are updated from time to time - that is an image deployment that LAVA can do.
> 5. We already have a PXE server in our network, which is where our > servers (the targets in this context) get booted from by default > 6. Once booted from PXE, we get a PXE menu, where we can either
select
> an option, or press ESC and add a custom command (at this syslinux
is
> running) > 7. We have access to the serial console of every device via serial > port server (telnet <ipaddr> <port>) > 8. We have power control over every device via IPMI > > Issues: > > 1. I couldn’t find the documentation for how to add devices and
device
> types to the server (which location to add the file, which format - > yaml/conf)
In LAVA V2, all configuration lives on the server. The device type template is a jinja2 file which is parsed to output YAML.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
Adding devices to V2:
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
> 2. In the above described environment, I suppose we would skip the > deployment phase, since the devices already boot into syslinux
from PXE (is
> this correct?).
Not necessarily.
https://staging.validation.linaro.org/static/docs/v2/dispatcher-design.html#...
You are better considering if you should actually deploy a fresh
copy
of the image each time to ensure you know what you are actually testing. Hint: only ever change one element at a time - it may sound obvious but you need to be obsessive about this.
> Either way, it would be nice to be able to run ‘ipmitool chassis > booted pxe’ before rebooting the system.
That is effectively your hard_reset_command in the Device
Dictionary.
https://staging.validation.linaro.org/static/docs/v2/glossary.html#term-devi...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#cre...
https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#
There are examples of x86 device dictionary entries but those particular x86 devices are rather specialised and the device dictionary includes lots of potentially confusing elements.
> 3. Either way (via boot or deploy), how can I make sure to detect
the
> PXE (syslinux) menu, send the ESC key, and send the command I need
to
> trigger the kickstart installation?
LAVA V2 has iPXE support.
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Can I just jump in here and state, like I do rather often, that the fact this board uses PXE to load syslinux, has nothing to do whatsoever with iPXE support. PXE != iPXE, iPXE is just another bootloader. How the board gets to that bootloader is largely irrelevant. The real support needed here is "syslinux", but V2 doesn't yet have a generic bootloader support which would mean this could be driven by just config files.
True - I end up using syslinux for other projects and it can be a pain to drive properly. Grub (specifically grub2) is a lot easier - if you are open to that level of change in your tests, it is worth doing.
You could of course use iPXE to boot your installer, replacing syslinux, but I would imagine that's part of the things they are trying to test.
> To sum-up, the Workflow I’m trying to achieve after having
completed
> the whole setup sort of goes like this: > > 1. Reboot target device into PXE (the PXE itself will download and > start syslinux here) > 2. Wait for PXE menu (expect some sort of string) > 3. Send ESC key (to get into the boot shell) > 4. Send command (this will trigger our kickstarter script and the > installation will take around 5 minutes). The images that are
needed are
> fetched automatically from our sftp server.
This installation *is* a deployment. LAVA V2 has support for the Debian Installer (because most LAVA instances are based on Debian)
but
that support isn't going to work for a Linux OS installer which is
not
Debian-based. You might be able to support this with a simple (long) timeout or you could look at the Debian Installer support and implement something related for your installer.
> 5. Wait for boot prompt after system installation succeeds > 6. Login using credentials (username, password)
auto_login:
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
> 7. Run whatever tests we need from here > > Any help here would be much appreciated. > Thanks in advance!
Documentation for these steps is currently being updated and
reviewed.
Currently, LAVA (V1 and V2) require a Debian based system - are you implementing such support or is your team interested in porting the Debian packaging to RHEL /RPM support? Note that there will be a
*lot*
of dependencies which would also need to be packaged before starting on the LAVA codebase. You will also need to maintain those dependencies, update them and keep them inline with the LAVA
software
which is tested on a Debian system.
Your use case is supportable but it will need work at your end as we are testing on a different environment.
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/ _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
lava-users@lists.lavasoftware.org
-
Luís Matallui -
Matt Hart -
Neil Williams