Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boots panics I presume because hardware data is not as it expects #61

Closed
gianarb opened this issue Jul 29, 2020 · 1 comment · Fixed by #67
Closed

Boots panics I presume because hardware data is not as it expects #61

gianarb opened this issue Jul 29, 2020 · 1 comment · Fixed by #67
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. size/S estimate of the amount of work to address the issue

Comments

@gianarb
Copy link
Contributor

gianarb commented Jul 29, 2020

Expected Behaviour

The worker boots correctly and exec the workflow

Current Behaviour

I am using the vagrant setup with this hardware:

$ docker exec -i deploy_tink-cli_1 tink  hardware  id 0eba0bf8-3772-4b4a-ab9f-6ebe93b90a94 | jq
{
  "id": "0eba0bf8-3772-4b4a-ab9f-6ebe93b90a94",
  "network": {
    "interfaces": [
      {
        "dhcp": {
          "arch": "x86_64",
          "ip": {
            "address": "192.168.1.5",
            "gateway": "192.168.1.1",
            "netmask": "255.255.255.248"
          },
          "mac": "08:00:27:00:00:01"
        },
        "netboot": {
          "allow_pxe": true,
          "allow_workflow": true
        }
      }
    ]
  }
}

Boots panics:

{"level":"info","ts":1596012796.4664223,"caller":"dhcp4-go@v0.0.0-20190402165401-39c137f31ad3/handler.go:105","msg":"","service":"github.com/tinkerbell/boots","pkg":"dhcp","pkg":"dhcp","event":"recv","mac":"08:00:27:00:00:01","via":"0.0.0.0","iface":"eth1","xid":"\"f8:75:02:6d\"","type":"DHCPDISCOVER","secs":16}
{"level":"info","ts":1596012796.4665282,"caller":"src/dhcp.go:71","msg":"parsed option82/circuitid","service":"github.com/tinkerbell/boots","pkg":"main","mac":"08:00:27:00:00:01","circuitID":""}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x9d2f31]

goroutine 41 [running]:
github.com/tinkerbell/boots/packet.DiscoveryTinkerbellV1.Hostname(...)
        /drone/src/packet/models_tinkerbell.go:92
github.com/tinkerbell/boots/job.(*Job).setup(0xc00001dab0, 0xd1ef40, 0xc0003b1360, 0xc00041e018, 0x4)
        /drone/src/job/job.go:160 +0x63c
github.com/tinkerbell/boots/job.CreateFromDHCP(0xc0002d16a0, 0x6, 0x10, 0xc00041e018, 0x4, 0x164, 0x0, 0x0, 0x0, 0x0, ...)
        /drone/src/job/job.go:63 +0x229
main.dhcpHandler.serveDHCP(0xc000152880, 0xd04620, 0xc000416960, 0xc0003b1800)
        /drone/src/dhcp.go:74 +0x859
main.dhcpHandler.ServeDHCP.func1()
        /drone/src/dhcp.go:45 +0x45
github.com/gammazero/workerpool.(*WorkerPool).dispatch.func1(0xc000152880, 0xc000404ae0)
        /go/pkg/mod/github.com/gammazero/workerpool@v0.0.0-20200311205957-7b00833861c6/workerpool.go:169 +0x27
created by github.com/gammazero/workerpool.(*WorkerPool).dispatch
        /go/pkg/mod/github.com/gammazero/workerpool@v0.0.0-20200311205957-7b00833861c6/workerpool.go:167 +0x4c2

Possible Solution

I presume the recent change made with user-defined metadata #58 is involved here. Because I am not sending any of them by purpose. Technically I should be able to do it because they are not an unstructured object.

Steps to Reproduce (for bugs)

  1. Follow the vagrant workflow and create the hardware as I pasted here
  2. Create a workflow and start a worker

Your Environment

  • Operating System and version (e.g. Linux, Windows, MacOS):

MacOS

  • How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:

Vagrant with Virtualbox

@gianarb gianarb added kind/bug Categorizes issue or PR as related to a bug. size/S estimate of the amount of work to address the issue labels Jul 29, 2020
@Cbkhare
Copy link
Contributor

Cbkhare commented Aug 21, 2020

raised PR #67

@Cbkhare Cbkhare self-assigned this Aug 21, 2020
Cbkhare added a commit that referenced this issue Aug 24, 2020
Signed-off-by: cbkhare <Chitrabasukhare89@gmail.com>

fix for hardware data without metdata #61 #28

Signed-off-by: cbkhare <Chitrabasukhare89@gmail.com>
@mergify mergify bot closed this as completed in #67 Aug 26, 2020
mergify bot added a commit that referenced this issue Aug 26, 2020
Signed-off-by: cbkhare <Chitrabasukhare89@gmail.com>

## Description

If hardware data without metadata is inserted into the Tinkerbell, then during tftp boot of the worker node boots container panics. 

## Why is this needed

Fixes: #61
Panic is due to the reference to the `Instance` field in the `Metadata` which has the `Hostname`. Since metadata is not given, call to `Hostname` panics. 

## How Has This Been Tested?
- [x] tested with hardware data without metadata.
- [x] tested with hardware data with metadata.
- [x] Added unit test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. size/S estimate of the amount of work to address the issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants