PXE support for image loading in Mass Production

peoplennpeoplenn Posts: 4New Member
edited December 2017 in UP board No Boot & Power up
I need to burn dozens of up-boards with the same image. What options do I have to do that at scale?

I am using clonezilla, but I still have to image them one-by-one. I saw that clonezilla has the option to burn multiple images by using network boot, but from what I see the upboard doesn't have network boot.

What are my options?

Thanks!

Comments

  • AlingAling Posts: 500Administrator, AAEON, UP reseller admin
    Hi,

    UP board supports PXE booting.
  • peoplennpeoplenn Posts: 4New Member

    Is PXE supported in the BIOS it comes from the factory, or do we need to flash a new BIOS?

    Thanks!

  • peoplennpeoplenn Posts: 4New Member

    I don't see an obvious way to enable network boot from the BIOS menu. My upboard's BIOS version is 2.17.1249

  • rogertsai(AAEON)rogertsai(AAEON) Posts: 122New Member ✭✭✭
    edited March 14

    Hi, please update your BIOS to Ver. UPC1BM0X, and you will find that PXE function in BIOS menu. UP Board UEFI Bios UPC1BM0X_EFI
    like below

  • ooglybooglyooglyboogly Posts: 1New Member

    Hello,

    I recently upgraded the BIOS to a version that supports PXE booting. I am unable to see any PXE boot related traffic from my PXE boot server when running tcpdump. I have other devices that PXE boot from this server and I see PXE boot traffic when i run a tcpdump from the PXE server. Am I doing something wrong with the upboard which is why I'm not seeing any traffic from my PXE server?

    When running this command while manually or automatically PXE booting via IPv4 I don't see any output

    [email protected]:~$ sudo tcpdump -i em0 udp port 69
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes

    ^C
    0 packets captured
    0 packets received by filter
    0 packets dropped by kernel

    When running this command from my PXE server while PXE booting a "working" embedded device i see the expected traffic:

    pxe0:/var/lib/tftpboot$ sudo tcpdump -i em0 udp port 69
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
    16:21:45.804539 IP 172.16.100.174.3335 > 172.16.5.5.tftp: 39 RRQ "enabled" octet timeout 5 blksize 1468
    16:21:45.859371 IP 172.16.100.174.3380 > 172.16.5.5.tftp: 65 RRQ "pxelinux.cfg/01-12-ae-4e-22-13-42" octet timeout 5 blksize 1468
    16:21:45.903477 IP 172.16.100.174.3431 > 172.16.5.5.tftp: 53 RRQ "pxelinux.cfg/AC1064AE" octet timeout 5 blksize 1468
    16:21:45.947479 IP 172.16.100.174.3475 > 172.16.5.5.tftp: 52 RRQ "pxelinux.cfg/AC1064A" octet timeout 5 blksize 1468
    16:21:45.991499 IP 172.16.100.174.3519 > 172.16.5.5.tftp: 51 RRQ "pxelinux.cfg/AC1064" octet timeout 5 blksize 1468
    16:21:46.035459 IP 172.16.100.174.3563 > 172.16.5.5.tftp: 50 RRQ "pxelinux.cfg/AC106" octet timeout 5 blksize 1468
    16:21:46.079498 IP 172.16.100.174.3607 > 172.16.5.5.tftp: 49 RRQ "pxelinux.cfg/AC10" octet timeout 5 blksize 1468
    16:21:46.123454 IP 172.16.100.174.3651 > 172.16.5.5.tftp: 48 RRQ "pxelinux.cfg/AC1" octet timeout 5 blksize 1468
    16:21:46.166548 IP 172.16.100.174.3694 > 172.16.5.5.tftp: 47 RRQ "pxelinux.cfg/AC" octet timeout 5 blksize 1468
    16:21:46.210624 IP 172.16.100.174.3737 > 172.16.5.5.tftp: 46 RRQ "pxelinux.cfg/A" octet timeout 5 blksize 1468
    16:21:46.254483 IP 172.16.100.174.3784 > 172.16.5.5.tftp: 62 RRQ "pxelinux.cfg/default-arm-sunxi" octet timeout 5 blksize 1468
    16:21:46.298655 IP 172.16.100.174.3827 > 172.16.5.5.tftp: 56 RRQ "pxelinux.cfg/default-arm" octet timeout 5 blksize 1468
    16:21:46.342536 IP 172.16.100.174.3870 > 172.16.5.5.tftp: 52 RRQ "pxelinux.cfg/default" octet timeout 5 blksize 1468
    16:21:46.420188 IP 172.16.100.174.3922 > 172.16.5.5.tftp: 70 RRQ "pcd3n/rootfs.cpio.uboot" octet timeout 5 blksize 1468
    16:21:52.437714 IP 172.16.100.174.3821 > 172.16.5.5.tftp: 49 RRQ "pcd3n/uImage" octet timeout 5 blksize 1468
    16:21:53.230638 IP 172.16.100.174.1544 > 172.16.5.5.tftp: 70 RRQ "pcd3n/device.dtb" octet timeout 5 blksize 1468

    The device download the files and boots successfully... I can not get the Upboard to do the same.

    Please see below Upboard BIOS settings:

    Advanced BIOS Settings:

    Network Stack: Enabled
    Ipv4 PXE Support: Enabled
    PXE boot wait time: 1
    Media Detect count: 1

    Boot BIOS Settings:

    Quiet Boot: Disabled
    OS IMAGE ID: Windows

    Boot Option Priorities:

    Boot Option 1: [ UEFI: IP4 Realtek P...]
    Boot Option 2: [Debian]

  • eduncan911eduncan911 Posts: 157Administrator, Moderator admin

    Btw, I am in nearly the same boat. Except it's for my home on a dedicated IoT VLAN. We have about 12 to 15 various UP and RPi projects and boards I want to convert to PXE.

    I'm working on the router now (Arch Linux + Xen on UP Squared with 5 or so VMs + small Kubernetes node). Next steps will be the VLANs and then the Router/DHCP/PXE daemons in docker.

    But that's still a ways off.. so I am unable to test out the UP board PXE just yet. But soon! (My current router is dying, daily, requiring reboots)

    My plan is to run a full remote kernel over PXE with tftp, set to read-only on all my UP devices - to save the eMMC writes and ship all metrics and logs off to my home server. Then eMMC will only be fore pure storage on each device. So it is a bit different than your idea, but still the same with PXE booting some type a kernel.

    I'll keep you up to date as I progress, sooner than later now.

    Eric Duncan - UP Evangelist - My thoughts are of my own free will

    Answered? Please remember to mark the posted answered to highlight it for future visitors!

Sign In or Register to comment.