On 27 March 2017 at 14:54, Ковалёв Сергей SKovalev@ptsecurity.com wrote:
Thank you Neil for you reply.
Please keep the list in CC:
Compare with: https://staging.validation.linaro.org/scheduler/job/168802
I have tried https://staging.validation.linaro.org/scheduler/job/168802/definition but iPXE stuck on it. I have amd64 machine with UEFI.
"stuck" ? This is a standard amd64 Debian kernel with modules and initramfs. It is already UEFI-aware. Does the machine run Debian natively? Is there a Debian kernel you can use in your LAVA submissions (with modules and ramdisk)?
First step is to replace these files with images which work on the x86 DUT on staging.validation.linaro.org
I perform kernel development with my colleagues so I have to load our kernels.
Yes, however, to debug what is going on, you should switch to known working files so that you have a valid comparison with known working test jobs. Once debugging has produced some results, then switch back to the locally built kernels. Change one thing at a time.
That just isn't going to work. The initrd needs to come via TFTP but this is an absolute path.
'initrd' is come via TFTP. In context I supply additional kernel boot options.
Your original email quoted:
context: extra_kernel_args: initrd=/rootfs.cpio.gz root=/dev/ram0
rootfs.cpio.gz does not exist when the machine boots. The initramfs will have been downloaded by TFTP and loaded directly into memory, it simply does not exist as a cpio.gz any longer. /dev/ram0 shouldn't be needed with modern kernels. At best, it would seem that these options are ignored.
Debian initramfs log:
Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. Warning: fsck not present, so skipping unknown file system mount: can't find /root in /etc/fstab done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed: No such file or directory mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory run-init: current directory on the same filesystem as the root: error 0 Target filesystem doesn't have requested /sbin/init. run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 No init found. Try passing init= bootarg. BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash) Enter 'help' for a list of built-in commands. Matched prompt #5: (initramfs)
This boot option have been detected before effort to automate the process with LAVA. Without it we could see kernel panic. With it we successfully load kernel and rootfs (from Buildroot). May be in Linaro you embed that boot options in compile time?
No, we do not embed anything in V2 (it's one of the key changes from V1, we don't hid magic like that anymore.)
The files were prepared with: https://git.linaro.org/lava-team/refactoring.git/tree/scripts/x86_64-nfs.sh
You can also see the build log for the original Debian kernel package if relevant.
https://tracker.debian.org/pkg/linux-signed
https://buildd.debian.org/status/fetch.php?pkg=linux-signed&arch=amd64&a...
Running x86_64-nfs.sh in an empty directory will provide access to the config of the kernel itself as well as the initramfs and supporting tools.
It's possible these context arguments are hiding some other problem in the kernel but, as described so far, the options seem to make no sense.
The command line used in our tests is simply: Command line: ip=dhcp console=ttyS0,115200n8 lava_mac={LAVA_MAC} (where LAVA_MAC does not need to be defined for these devices.)