I would like to see the ability to select NFS as the method for booting a MACHINE and have it do the right thing. I see this benefiting real hardware targets in a lab scenario. Some use cases: 1) NFS on local build system 2) NFS on shared file system 3) NFS on remote system 4) NFS using native NFS server like nfs-genesha 4) NFS via SDK/eSDK
One of the existing manual test which could be automated: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/manual/sdk.json
Looking at this from NFS side quickly caused a too many scenarios so I started from the Machine side. I have a few u-boot based arm boards that can now boot from mmc or over nfs. I now need to add tftp and/or pxe boot support for the kernel.
Well here is what I have done so far and where I went a bit mental. I a doing all my work in a BSP I maintain. NFS: https://github.com/akuster/meta-odroid/blob/master-next/classes/image_types_nfs.bbclass # NFS_LOCATION: # local: NFS mount on this machine # remote: NFS exported from a remote system not mounted on this system # # NFS_EXPORT_DIR - location where to copy things to # NFS_SERVERIP - your remote NFS server host # NFS_SERVERIP_USER - User account on remote NFS server # NFS_SERVERIP_PSWDFILE - Password used for NFS_SERVERIP_USER on NFS_SERVERIP # NFS_MACHINE_NAME - main filename used as the common mounted dir from machine # # NFS_DEST_DIR - Name of where new builds are copied too. # # SSHPASS - where to find the sshpass binary, defaults to the systme one It uses NFS_EXPORT_DIR/NFS_MACHINE_NAME to be symlinked your last build image that is copied over to where NFS is being hosted. I have not done the NATIVE which should be what we have now with QEMU. I went mental here: NETBOOT: Basic same idea for local and remote as above. I need to doc it and currently is supports TFTP.
I also have some u-boot glue, I have had u-boot env config class. If one configs TFTP and NFS U-boot parms , it will create the correct values so that u-boot will tftp the kernel and nfs mount the right rootfs. https://github.com/akuster/meta-odroid/blob/master-next/classes/uboot-boot-scr.bbclass # UBOOT_FDT_FILE: default device tree. e.g., "KERNEL_DEVICETREE" # # UBOOT_FDT_LOADADDR: default Device tree load address, e.g., "0x01000000" # # UBOOT_INITRD_NAME: default initrd image name, e.g., "uInitrd" # # UBOOT_INITRD_ADDR: default initrd image load address, e.g., "0x2000000" # # UBOOT_CONSOLE: default console, e.g., "ttyttySAC2,115200" # # UBOOT_LOAD_CMD: default partition, e.g., "load" # # UBOOT_BOOTARGS: # # UBOOT_BOOTDEV: default boot device # # # UBOOT_BOOTPART: default boot partition # # # UBOOT_BOOTTYPE: default mmc # # UBOOT_ROOTDEV: default root device # # # UBOOT_ROOTPART: default root device # # # UBOOT_ROOTTYPE: default mmcblk1p # # UBOOT_FILE_TITLE: default partition, e.g., "UBOOT-CONFIG" # # UBOOT_EXTRA_ENV: default add extra env vars , e.g., "vout,'vga'"
I also added a power-controller class to power cycle a network powered device. https://github.com/akuster/meta-odroid/blob/master-next/classes/power-contoller.bbclass needs more doc.
example local.conf NETBOOT = "tftp" UBOOT_NETBOOT = "tftp" NETBOOT_DIR = "/tftpboot/" NETBOOT_LOCATION = "remote" NETBOOT_SERVERIP ="192.168.9.51" NETBOOT_RUSER ="akuster" NETBOOT_PSWDFILE = "/home/akuster/tftpboot/.pswd" NFS_ROOT = "/srv/oe/" UBOOT_IPADDR_odroid-c2 ="192.168.9.20" UBOOT_ETHADDR_odroid-c2 = "42:ae:30:69:fa:c8" UBOOT_SERVERIP ="192.168.9.51" UBOOT_GATEWATIP = "192.168.9.1" UBOOT_NETMASK ="255.255.255.000" UBOOT_BOOT_TYPE = " nfs" NFS_LOCATION = "remote" NFS_EXPORT_DIR = "/srv/oe/" IMAGE_FSTYPES_append = " nfs" NFS_SERVERIP ="192.168.9.51" NFS_SERVERIP_PSWDFILE = "/home/akuster/tftpboot/.pswd" NFS_SERVERIP_USER ="akuster" INHERIT += "power-contoller" PWR_CNTL_NODE_odroid-c2 ?= "p61" PWR_CNTL_TYPE = "ipower" PWR_CNTL_SERVER_IP_ipower = "192.168.9.30" PWR_CNTL_CMD_ipower = "wget -O/dev/null -q --http-user=admin --http-password=12345678 " NETBOOT_AUTO = "1"
Armin said in email that this should be 3.2M3.
3.3 development is closed, move to 3.4
Build move to 5.0 -- ../Randy
Bulk move of 5.0 medium importance issues to 5.99. Move to 5.1 if you want to actively work on an issue.
Build move to 5.1
Bulk move of all unassigned 5.2 medium importance bugs to 5.3.
Adrian, could you check if this has already been done?