Hi, In a previous thread where I was getting help to do a serial connection, I also needed help with the deploy action towards the end, so I'm just continuing that here.
I have been trying to do a deploy action for a couple of days now, and have been unsuccessful thus far. The obvious first hurdle is the image URLs for the various things needed for a tftp deploy action. I have compiled a u-boot kernel, and a DTB came with it, and I managed to sort the few errors I got with those (for now at least). I'm not sure modules are necessary, but I can figure that out later. The biggest issue I'm having is with the ramdisk.
There are many resources online for creating a ramdisk, but it is just a space in the ram for things to be stored temporarily (which I don't mind). But this does not work for lava, as it seems to require a file. I have tried compressing the directory created, and passing that, but because it is still just a directory lava won't accept it after I start the job. So I'm assuming I have to acquire some kind of image somehow, how can I do this? Is there an online source I can download from? Or if I have to make it, how?
Best regards, Michael
Hey Michael,
as far as I understood you just compiled U-Boot. You will have to compile a Linux kernel too - this will yield either an image with a root filesystem, or the individual files (where the root file system can be mounted as ramdisk).
How you get these largely depends on your build system. Here are two links explaining it somehow (but for specific boards/environments): https://yuhei1-horibe.medium.com/booting-linux-with-ramdisk-f6f2d59780dc https://trac.gateworks.com/wiki/buildroot
The first one sums it up:
To boot Linux OS, 4 things listed below will be needed;
1. Boot image (includes FSBL, Hardware bitstream and U-Boot) 2. Linux kernel image (uImage or zImage) 3. Flattened Device Tree 4. Root file system image
There might be online sources to get those files - but they will have to fit your specific board and the Linux Kernel version you want to test. Usually you are building them yourself, because that's the image you want to test using LAVA.
To be able to help you better, we would need this information: - Which board are you using? - Which build system are you using?
Best regards, Stefan
On 2024-02-15 02:11, Michael Peddie wrote:
Hi, In a previous thread where I was getting help to do a serial connection, I also needed help with the deploy action towards the end, so I'm just continuing that here.
I have been trying to do a deploy action for a couple of days now, and have been unsuccessful thus far. The obvious first hurdle is the image URLs for the various things needed for a tftp deploy action. I have compiled a u-boot kernel, and a DTB came with it, and I managed to sort the few errors I got with those (for now at least). I'm not sure modules are necessary, but I can figure that out later. The biggest issue I'm having is with the ramdisk.
There are many resources online for creating a ramdisk, but it is just a space in the ram for things to be stored temporarily (which I don't mind). But this does not work for lava, as it seems to require a file. I have tried compressing the directory created, and passing that, but because it is still just a directory lava won't accept it after I start the job. So I'm assuming I have to acquire some kind of image somehow, how can I do this? Is there an online source I can download from? Or if I have to make it, how?
Best regards, Michael _______________________________________________ lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Hi Stefan,
I did manage to get it to run successfully, now the issue lies with where it's looking for tests, it's looking on the DUT. You mentioned in my previous thread on Serial Connection you load the image onto a ramdisk and boot from there. Does that mean you run the test *from* that ramdisk? Or run it *on* the ramdisk?
Because though tangentially related to that last thread, the issue now is the overlay that lava uses to get the tests on the device for testing, which gets applied in the deploy (as far as I understand). I was hoping I would be able to get that overlay applied to this ramdisk and run the tests on the DUT from there, over serial.
Currently it appears the overlay is getting applied on the ramdisk as I don't have any errors about the filesystem being read-only, but lava is still looking on my DUT for the files/scripts. If where it looks can be changed, that would be great to know, because I can't find anything about it in the docs.
Best regards, Michael
I have checked the ramdisk during a test run, and the overlay is definitely applied to the ramdisk and the test scripts and stuff are there. But LAVA is looking for them on the DUT, do you know of any way to get LAVA to run it from the ramdisk to the DUT? I'm not sure you remember but the DUT uses a read-only fs, so I can't have the overlay there nor can I copy the files there. I need to be able to run the script from the ramdisk that is mounted on the worker over telnet. I can't find any test job configuration setting anywhere for tftp, and nothing in the device dictionary/template. Is it possible that it is supposed to run from the ramdisk but the ramdisk isn't actually getting mounted? Because nothing changes when I run df before and after I start the test job. However, when I run htop, the only thing that changes is memory, but it only increases by about 60-100 MB for a 1GB allocated ramdisk when the job starts and goes back down afterwards.
Best regards, Michael
I found out the /tmp/ directory is writable, so I want to try using transfer_overlay to move the tests and stuff from the ramdisk there. However I've run into an issue with the default mount_dir being at the root (read-only). The DUT doesn't have wget or curl installed, nor am I able/allowed to install them, so that isn't an option. Looking through the source code, do you think it might be possible to change that mount_dir value directly? For reference, this is the source code: https://gitlab.com/lava/lava/-/blob/master/lava_dispatcher/actions/boot/__in...
On Mon, Feb 19, 2024 at 4:26 AM Michael Peddie michael.peddie@gallagher.com wrote:
I found out the /tmp/ directory is writable, so I want to try using transfer_overlay to move the tests and stuff from the ramdisk there. However I've run into an issue with the default mount_dir being at the root (read-only). The DUT doesn't have wget or curl installed, nor am I able/allowed to install them, so that isn't an option. Looking through the source code, do you think it might be possible to change that mount_dir value directly? For reference, this is the source code: https://gitlab.com/lava/lava/-/blob/master/lava_dispatcher/actions/boot/__in...
yes. The variable name is lava_test_results_dir. You set it as a part of job context. Example: context: lava_test_results_dir: /tmp/lava-%s
context is a top level key in the LAVA job definition. This setting affects overlay paths for all deployment types.
If you don't have a way to download to DUT, you might consider some other deployments, like scp (if you have ssh daemon running on DUT).
Best Regards, Milosz
lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Hi Milosz,
I didn't realise it was possible to use the context to change that sort of stuff, thank you for letting me know. Unfortunately that directory is not the one I am after. When transferring the overlay, there is a specific directory it creates using mkdir, and the directory is as seen in the link I previously sent for the source code. The one you showed is the results directory, not the one the actual tests get moved to. It doesn't look like context can change that though, unless there is someplace I can look to find all the options for that? If the context really can't be used to, how could I go about modifying the source code on my worker/server to make it happen? Would I have to go to the lava-devel mailing list to find out?
Best regards, Michael
Hi Milosz,
I've talked with someone who knows more about the DUT than I do, and they've presented me with a couple options. Make and add something like wget or add the actual wget back in. Or try scp option you've mentioned here. How would I go about using scp for deployment of tests to the DUT? There is an ssh daemon running on the DUT, so that much is already sorted.
Best regards, Michael
On Mon, Feb 19, 2024 at 12:39 AM Michael Peddie michael.peddie@gallagher.com wrote:
I have checked the ramdisk during a test run, and the overlay is definitely applied to the ramdisk and the test scripts and stuff are there. But LAVA is looking for them on the DUT, do you know of any way to get LAVA to run it from the ramdisk to the DUT?
I'm not sure we're on the same page here. Ramdisk in this case should be used as a rootfs for booting DUT. Is this the case?
Best Regards, Milosz
I'm not sure you remember but the DUT uses a read-only fs, so I can't have the overlay there nor can I copy the files there. I need to be able to run the script from the ramdisk that is mounted on the worker over telnet. I can't find any test job configuration setting anywhere for tftp, and nothing in the device dictionary/template. Is it possible that it is supposed to run from the ramdisk but the ramdisk isn't actually getting mounted? Because nothing changes when I run df before and after I start the test job. However, when I run htop, the only thing that changes is memory, but it only increases by about 60-100 MB for a 1GB allocated ramdisk when the job starts and goes back down afterwards.
Best regards, Michael _______________________________________________ lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
I'm not actually sure, sorry. Still quite new to this stuff, how would I be able to tell?
I'm pretty sure lava_test_results_dir changes the path to the overlay. Look at actions/deploy/overlay.py for more details. You might also set lava_test_sh_cmd. These are not documented, so the only way is to check in the code.
For transfer_overlay you can change the path yourself like this:
transfer_overlay: download_command: cd /tmp ; wget unpack_command: tar -C /tmp -xzf
Best Regards, Milosz
On Mon, Feb 19, 2024 at 7:53 PM Michael Peddie michael.peddie@gallagher.com wrote:
I'm not actually sure, sorry. Still quite new to this stuff, how would I be able to tell? _______________________________________________ lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Changing the download command to have a cd hasn't worked, and the context change hasn't worked either. I am using the nfs transfer as the DUT can't use wget or curl (as stated previously), so if that is the reason either of them won't work, then I need to find another way to do it. Would it be possible to change directory right after login? Before the transfer takes place, and before testing starts. However, I don't think the use of nfs and mount cause any issues, because of the way the line is constructed for the command containing mkdir. This is the command with both of those changes implemented together (please ignore hostname placeholder): mkdir -p /lava-overlay-l8exzifv; cd /tmp ; mount -t nfs -o nolock <hostname>:/var/lib/lava/dispatcher/tmp/260/lava-overlay-l8exzifv /lava-overlay-l8exzifv What I need is that first directory changed, as LAVA is trying to create it at root, but I can only have it under /tmp/. And since that one can't be created, none of the other stuff actually works.
Looking at the documentation there is a list of the directories/stuff that can be changed, and it looks like lava_test_results_dir is something that needs changing anyways. The other 2 shouldn't need changing, but I know what to change if they do.
Best regards, Michael
On Mon, Feb 19, 2024 at 9:02 PM Michael Peddie michael.peddie@gallagher.com wrote:
Changing the download command to have a cd hasn't worked, and the context change hasn't worked either. I am using the nfs transfer as the DUT can't use wget or curl (as stated previously), so if that is the reason either of them won't work, then I need to find another way to do it. Would it be possible to change directory right after login? Before the transfer takes place, and before testing starts. However, I don't think the use of nfs and mount cause any issues, because of the way the line is constructed for the command containing mkdir. This is the command with both of those changes implemented together (please ignore hostname placeholder): mkdir -p /lava-overlay-l8exzifv; cd /tmp ; mount -t nfs -o nolock <hostname>:/var/lib/lava/dispatcher/tmp/260/lava-overlay-l8exzifv /lava-overlay-l8exzifv What I need is that first directory changed, as LAVA is trying to create it at root, but I can only have it under /tmp/. And since that one can't be created, none of the other stuff actually works.
I think you're confusing things here. The NFS is used as rootfs and the board should boot from it. Overlay is added during deployment. https://lava.infra.foundries.io/static/docs/v2/actions-deploy.html#nfsrootfs
Best Regards, Milosz
Looking at the documentation there is a list of the directories/stuff that can be changed, and it looks like lava_test_results_dir is something that needs changing anyways. The other 2 shouldn't need changing, but I know what to change if they do.
Best regards, Michael _______________________________________________ lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
I am aware of nfsrootfs as an option in deploy, but the nfs I was talking about is a transfer_method of the transfer_overlay feature in the boot action. It is an alternative to the (seemingly default) http method, and I had thought I could use it due to my DUT not having wget or curl. I may have needed to add the nfsrootfs to my deploy to get that to work though.
But I may not have to continue attempting that method though, as I have someone looking into my DUT to see about enabling wget. Until that gets done or otherwise, I was intending on seeing if I could get that nfs to work, but it may really be that I need to add an nfsrootfs to my tftp deploy.
Best regards, Michael
On Tue, Feb 20, 2024 at 8:30 PM Michael Peddie michael.peddie@gallagher.com wrote:
I am aware of nfsrootfs as an option in deploy, but the nfs I was talking about is a transfer_method of the transfer_overlay feature in the boot action. It is an alternative to the (seemingly default) http method, and I had thought I could use it due to my DUT not having wget or curl. I may have needed to add the nfsrootfs to my deploy to get that to work though.
Do you mean to mount nfs volume in the transfer_overlay? Sounds interesting, but I don't think anyone tried that before. Also LAVA would need to prepare the overlay to be mounted on the other side and I'm pretty sure there is no code for that.
Best Regards, Milosz
But I may not have to continue attempting that method though, as I have someone looking into my DUT to see about enabling wget. Until that gets done or otherwise, I was intending on seeing if I could get that nfs to work, but it may really be that I need to add an nfsrootfs to my tftp deploy.
Best regards, Michael _______________________________________________ lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
I see, thank you for letting me know.
Would I be able to bring your attention to a reply I made later yesterday (can be found at this link https://lists.lavasoftware.org/archives/list/lava-users@lists.lavasoftware.o...) in response to you mentioning the use of scp as a deploy method. If you want to see what you said then, the link to that message is here https://lists.lavasoftware.org/archives/list/lava-users@lists.lavasoftware.o...
Best Regards, Michael
lava-users@lists.lavasoftware.org
-
Michael Peddie -
Milosz Wasilewski -
Stefan