I have a minnowboard turbot device that I want lava to boot, flash, reboot to flashed image, and then run tests. I would like to boot the device via PXE networking to an initramfs where I will flash an image to permanent storage. I can use efibootmgr within the initramfs image to set next-boot to the permanent storage device. Once booted from the permanent storage device, lava tests will run as per normal.
It appears that many of the ipxe examples I have found simply run tests on the initramfs itself. Is it possible to flash the device once the initramfs has booted? It seems like it would be simple for lava-dispatcher to run wget http://someurl/foo.img | dd of=/dev/sda once the initramfs has reached login. However, I do not know if there is such a deploy mechanism.
Does anything already exist within lava to help achieve this model? Is there a better way? Any feedback would be appreciated.
-Kevron
On 25 October 2017 at 22:05, Rees, Kevron kevron.m.rees@intel.com wrote:
I have a minnowboard turbot device that I want lava to boot, flash, reboot to flashed image, and then run tests.
First, make sure you have read: https://staging.validation.linaro.org/static/docs/v2/device-integration.html
What you are asking for essentially boils down to:
boot method pxe commands: ramdisk test shell to run wget & dd or secondary media deployment to flash the image boot method pxe commands: sata test shell on persistent storage.
Alternatively, use grub boot method in each case - depends on which set of commands you want to configure.
The x86 device-type in staging uses PXE. The mustang-uefi device-type in staging uses grub-efi, downloading a grub binary using PXE which is configured in UEFI.
https://staging.validation.linaro.org/scheduler/job/195134 - x86
https://staging.validation.linaro.org/scheduler/job/195134 - mustang
I would like to boot the
device via PXE networking to an initramfs where I will flash an image to permanent storage.
That could be done using a test shell running in the initramfs. Just make sure the kernel has the relevant configuration to write to the required storage device.
I can use efibootmgr within the initramfs image to set next-boot to the permanent storage device.
No. Avoid changing things in bootloaders with which you are not interacting on every test job. That breaks persistence and will cause the device to be unreliable.
Let the device continue to boot using PXE (which can then possibly download Grub) which can be interrupted and can boot from whatever media you choose.
Only change things like boot order if you have BMC which allows you to change it every time, even if the current order happens to be the right one.
Once booted from the permanent storage device, lava tests will run as per normal.
It appears that many of the ipxe examples I have found simply run tests on the initramfs itself. Is it possible to flash the device once the initramfs has booted?
Yes - but you have to do this on the device, not on the dispatcher.
It seems like it would be simple for lava-dispatcher to run wget http://someurl/foo.img | dd of=/dev/sda once the initramfs has reached login. However, I do not know if there is such a deploy mechanism.
Secondary media can support this, as long as the device is booted into a system which can write to the storage.
Alternatively, you can use a test shell to do the write and then specify different commands to the next boot action to boot from that storage. (What Secondary Media gives you is some independence from the enumeration problems of which storage device when there are a number of devices of the same device-type.)
Does anything already exist within lava to help achieve this model? Is there a better way? Any feedback would be appreciated.
-Kevron _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
On Thu, Oct 26, 2017 at 2:55 AM, Neil Williams neil.williams@linaro.org wrote:
On 25 October 2017 at 22:05, Rees, Kevron kevron.m.rees@intel.com wrote:
I have a minnowboard turbot device that I want lava to boot, flash, reboot to flashed image, and then run tests.
First, make sure you have read: https://staging.validation.linaro.org/static/docs/v2/device-integration.html
What you are asking for essentially boils down to:
boot method pxe commands: ramdisk test shell to run wget & dd or secondary media deployment to flash the image boot method pxe commands: sata test shell on persistent storage.
Alternatively, use grub boot method in each case - depends on which set of commands you want to configure.
The x86 device-type in staging uses PXE. The mustang-uefi device-type in staging uses grub-efi, downloading a grub binary using PXE which is configured in UEFI.
https://staging.validation.linaro.org/scheduler/job/195134 - x86
https://staging.validation.linaro.org/scheduler/job/195134 - mustang
I found the "definition" for that job here: https://staging.validation.linaro.org/scheduler/job/195485/definition
I change mine to match: - boot: timeout: minutes: 4 method: grub-efi auto_login: {login_prompt: 'login:', username: root} commands: ramdisk prompts: - "root@intel-corei7-64:"
But I get a "error_msg: None of the boot strategies accepted your boot parameters"
I just updated to the latest packages from the linaro production stretch-backports repository. Attached is my job.yaml as extracted from the "resubmit job" page:
I would like to boot the device via PXE networking to an initramfs where I will flash an image to permanent storage.
That could be done using a test shell running in the initramfs. Just make sure the kernel has the relevant configuration to write to the required storage device.
I can use efibootmgr within the initramfs image to set next-boot to the permanent storage device.
No. Avoid changing things in bootloaders with which you are not interacting on every test job. That breaks persistence and will cause the device to be unreliable.
Let the device continue to boot using PXE (which can then possibly download Grub) which can be interrupted and can boot from whatever media you choose.
Only change things like boot order if you have BMC which allows you to change it every time, even if the current order happens to be the right one.
Once booted from the permanent storage device, lava tests will run as per normal.
It appears that many of the ipxe examples I have found simply run tests on the initramfs itself. Is it possible to flash the device once the initramfs has booted?
Yes - but you have to do this on the device, not on the dispatcher.
It seems like it would be simple for lava-dispatcher to run wget http://someurl/foo.img | dd of=/dev/sda once the initramfs has reached login. However, I do not know if there is such a deploy mechanism.
Secondary media can support this, as long as the device is booted into a system which can write to the storage.
Alternatively, you can use a test shell to do the write and then specify different commands to the next boot action to boot from that storage. (What Secondary Media gives you is some independence from the enumeration problems of which storage device when there are a number of devices of the same device-type.)
Does anything already exist within lava to help achieve this model? Is there a better way? Any feedback would be appreciated.
-Kevron _______________________________________________ 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 28 October 2017 at 00:32, Rees, Kevron kevron.m.rees@intel.com wrote:
On Thu, Oct 26, 2017 at 2:55 AM, Neil Williams neil.williams@linaro.org wrote:
On 25 October 2017 at 22:05, Rees, Kevron kevron.m.rees@intel.com
wrote:
I have a minnowboard turbot device that I want lava to boot, flash, reboot to flashed image, and then run tests.
First, make sure you have read: https://staging.validation.linaro.org/static/docs/v2/
device-integration.html
What you are asking for essentially boils down to:
boot method pxe commands: ramdisk test shell to run wget & dd or secondary media deployment to flash the
image
boot method pxe commands: sata test shell on persistent storage.
Alternatively, use grub boot method in each case - depends on which set
of
commands you want to configure.
The x86 device-type in staging uses PXE. The mustang-uefi device-type in staging uses grub-efi, downloading a grub binary using PXE which is configured in UEFI.
https://staging.validation.linaro.org/scheduler/job/195134 - x86
https://staging.validation.linaro.org/scheduler/job/195134 - mustang
I found the "definition" for that job here: https://staging.validation.linaro.org/scheduler/job/195485/definition
I change mine to match:
- boot:
timeout: minutes: 4 method: grub-efi auto_login: {login_prompt: 'login:', username: root} commands: ramdisk prompts:
- "root@intel-corei7-64:"
But I get a "error_msg: None of the boot strategies accepted your boot parameters"
This will be dependent on the jinja2 template for the device-type you are using. It will need to define the relevant boot method and have a commands block for how to load the ramdisk.
Note: the majority of those commands will be device-specific, you'll need to work out which commands this device needs and how to parameterise those commands with paths to the kernel etc.
https://git.linaro.org/lava/lava-server.git/tree/lava_scheduler_app/tests/de...
I just updated to the latest packages from the linaro production stretch-backports repository. Attached is my job.yaml as extracted from the "resubmit job" page:
I would like to boot the device via PXE networking to an initramfs where I will flash an image to permanent storage.
That could be done using a test shell running in the initramfs. Just make sure the kernel has the relevant configuration to write to the required storage device.
I can use efibootmgr within the initramfs image to set next-boot to the permanent storage device.
No. Avoid changing things in bootloaders with which you are not
interacting
on every test job. That breaks persistence and will cause the device to
be
unreliable.
Let the device continue to boot using PXE (which can then possibly
download
Grub) which can be interrupted and can boot from whatever media you
choose.
Only change things like boot order if you have BMC which allows you to change it every time, even if the current order happens to be the right
one.
Once booted from the permanent storage device, lava tests will run as per normal.
It appears that many of the ipxe examples I have found simply run tests on the initramfs itself. Is it possible to flash the device once the initramfs has booted?
Yes - but you have to do this on the device, not on the dispatcher.
It seems like it would be simple for lava-dispatcher to run wget http://someurl/foo.img | dd of=/dev/sda once the initramfs has reached login. However, I do not know if there is such a deploy mechanism.
Secondary media can support this, as long as the device is booted into a system which can write to the storage.
Alternatively, you can use a test shell to do the write and then specify different commands to the next boot action to boot from that storage.
(What
Secondary Media gives you is some independence from the enumeration
problems
of which storage device when there are a number of devices of the same device-type.)
Does anything already exist within lava to help achieve this model? Is there a better way? Any feedback would be appreciated.
-Kevron _______________________________________________ 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 Mon, Oct 30, 2017 at 12:09 AM, Neil Williams neil.williams@linaro.org wrote:
On 28 October 2017 at 00:32, Rees, Kevron kevron.m.rees@intel.com wrote:
On Thu, Oct 26, 2017 at 2:55 AM, Neil Williams neil.williams@linaro.org wrote:
On 25 October 2017 at 22:05, Rees, Kevron kevron.m.rees@intel.com wrote:
I have a minnowboard turbot device that I want lava to boot, flash, reboot to flashed image, and then run tests.
First, make sure you have read:
https://staging.validation.linaro.org/static/docs/v2/device-integration.html
What you are asking for essentially boils down to:
boot method pxe commands: ramdisk test shell to run wget & dd or secondary media deployment to flash the image boot method pxe commands: sata test shell on persistent storage.
So if I use grub ans secondary media... the flow would look like: boot method grub commands: ramdisk deploy to: usb boot method grub commands: usb test shell on persistent storage
Does that look about right?
Alternatively, use grub boot method in each case - depends on which set of commands you want to configure.
The x86 device-type in staging uses PXE. The mustang-uefi device-type in staging uses grub-efi, downloading a grub binary using PXE which is configured in UEFI.
https://staging.validation.linaro.org/scheduler/job/195134 - x86
https://staging.validation.linaro.org/scheduler/job/195134 - mustang
I found the "definition" for that job here: https://staging.validation.linaro.org/scheduler/job/195485/definition
I change mine to match:
- boot:
timeout: minutes: 4 method: grub-efi auto_login: {login_prompt: 'login:', username: root} commands: ramdisk prompts:
- "root@intel-corei7-64:"
But I get a "error_msg: None of the boot strategies accepted your boot parameters"
This will be dependent on the jinja2 template for the device-type you are using. It will need to define the relevant boot method and have a commands block for how to load the ramdisk.
Note: the majority of those commands will be device-specific, you'll need to work out which commands this device needs and how to parameterise those commands with paths to the kernel etc.
https://git.linaro.org/lava/lava-server.git/tree/lava_scheduler_app/tests/de...
Thank you. This was very helpful as the default x86 jinja2 template doesn't have grub support.
I just updated to the latest packages from the linaro production stretch-backports repository. Attached is my job.yaml as extracted from the "resubmit job" page:
I would like to boot the device via PXE networking to an initramfs where I will flash an image to permanent storage.
That could be done using a test shell running in the initramfs. Just make sure the kernel has the relevant configuration to write to the required storage device.
I can use efibootmgr within the initramfs image to set next-boot to the permanent storage device.
No. Avoid changing things in bootloaders with which you are not interacting on every test job. That breaks persistence and will cause the device to be unreliable.
Let the device continue to boot using PXE (which can then possibly download Grub) which can be interrupted and can boot from whatever media you choose.
Only change things like boot order if you have BMC which allows you to change it every time, even if the current order happens to be the right one.
Once booted from the permanent storage device, lava tests will run as per normal.
It appears that many of the ipxe examples I have found simply run tests on the initramfs itself. Is it possible to flash the device once the initramfs has booted?
Yes - but you have to do this on the device, not on the dispatcher.
It seems like it would be simple for lava-dispatcher to run wget http://someurl/foo.img | dd of=/dev/sda once the initramfs has reached login. However, I do not know if there is such a deploy mechanism.
Secondary media can support this, as long as the device is booted into a system which can write to the storage.
Alternatively, you can use a test shell to do the write and then specify different commands to the next boot action to boot from that storage. (What Secondary Media gives you is some independence from the enumeration problems of which storage device when there are a number of devices of the same device-type.)
Does anything already exist within lava to help achieve this model? Is there a better way? Any feedback would be appreciated.
-Kevron _______________________________________________ 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/
-
Neil Williams -
Rees, Kevron