When an action changes and requires a re-build, do it as part of CI/CD. Today it is done manually by myself.

Expected Behaviour

At the moment, there are no command, dedicated only for wiping disks without partitioning it all over again. It would be really helpful to have a dedicated command, where user can only wipe disks without any partitioning, using the metadata of the Hardware.

Current Behaviour

Not possible to run disk wiping without partitioning the disks again.

Possible Solution

Extracting the Wipe functionality from the disk partition and use a dedicated command. Here is PR:

Steps to Reproduce (for bugs)

Context

This is very helpful, when the provisioned machine, are gonna be used by some storage specific services or SDS operator, as some of those operator don't use disks that are in a specific status(for example if the disks have partitions, the storage operator would considered this disk being in used by some other software and wouldn't use and utilize it).

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

EXEC/RUN action

This action will execute a command, or script. It will have the ability both mount and chroot before executing into the newly provisioned environment. The chroot will allow the execution to happen within the correct file paths and using the correct utilities.

Use-Cases

• grub-install into /boot
• Various things that cloud-init could do, but may not be present.

If you set an invalid/non-existant metadata server for the MIRROR_HOST env the rootio action will throw a nil pointer error.

Expected Behaviour

The rootio action should gracefully handle an incorrectly set MIRROR_HOST or if the metadata service does not respond with all the correct informaiton.

Current Behaviour

panic at line 48 of rootio/cmd/rootio.go

Possible Solution

Better error handling an nil pointer checking before usage of metadata.Instance.Storage.Disks on line 48.

Steps to Reproduce (for bugs)

1. Set incorrect MIRROR_HOST in template file when using the rootio action
2. PXE boot physical device
3. docker logs tink-worker --follow

Context

The issue is minor and using the correct MIRROR_HOST for the metadata service works as expected. It did cause confusion and debug time as it is not clear what MIRROR_HOST was used for and what was causing the panic.

Your Environment

Physical Intel NUC 11's with a Ubiquiti Router.

The disk model is missing in the output of command "fdisk -l" in tinkerbell action whose image has base of alpine.

Found valid GPT with protective MBR; using GPT

Disk /dev/sda: 937571968 sectors, 3142M
Logical sector size: 512
Disk identifier (GUID): d289196f-8852-4825-b457-733b65797b0a
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 937571934

Number Start (sector)  End (sector) Size Name
   1       34     1050815 513M EFI System Partition
   2     1050816    937571934 446G
Disk /dev/sdb: 1788 GB, 1919716163584 bytes, 3749445632 sectors
233392 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Disk /dev/sdb doesn't contain a valid partition table
Found valid GPT with protective MBR; using GPT

Disk /dev/sdc: 3749445632 sectors, 3968M
Logical sector size: 512
Disk identifier (GUID): d289196f-8852-4825-b457-733b65797b0a
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 12582878

Number Start (sector)  End (sector) Size Name
   1       34     1050815 513M EFI System Partition
   2     1050816    12582878 5630M

Expected Behaviour

The complete outout of command "fdisk -l" is as follows:

Disk /dev/sda: 1.76 TiB, 1919716163584 bytes, 3749445632 sectors
Disk model: PERC H755 Front 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 262144 bytes / 262144 bytes


Disk /dev/sdb: 1.76 TiB, 1919716163584 bytes, 3749445632 sectors
Disk model: PERC H755 Front 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 262144 bytes / 262144 bytes
Disklabel type: gpt
Disk identifier: D289196F-8852-4825-B457-733B65797B0A

Device       Start        End    Sectors   Size Type
/dev/sdb1       34    1050815    1050782 513.1M EFI System
/dev/sdb2  1050816 3749445598 3748394783   1.8T Linux filesystem

Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.


Disk /dev/sdc: 447.7 GiB, 480036847616 bytes, 937571968 sectors
Disk model: DELLBOSS VD     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D289196F-8852-4825-B457-733B65797B0A

Device       Start       End   Sectors   Size Type
/dev/sdc1       34   1050815   1050782 513.1M EFI System
/dev/sdc2  1050816 937571934 936521119 446.6G Linux filesystem

Partition 1 does not start on physical sector boundary.

Current Behaviour

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

To be written

Commands within cexec:v1.0.0 cannot resolve host, but image2disk:v1.0.0 can download files from the same host and path. The example below is with curl but the same happens with a yum install.

          version: "0.1"
          name: centos7
          global_timeout: 1800
          tasks:
            - name: os-installation
              worker: '{{.device_1}}'
              volumes:
                - "/dev:/dev"
                - "/dev/console:/dev/console"
                - "/lib/firmware:/lib/firmware:ro"
              actions:
                - name: "stream-os-image"
                  image: "image2disk:v1.0.0"
                  timeout: 600
                  environment:
                    DEST_DISK: /dev/sda
                    IMG_URL: https://foo.bar.com/filea.raw.gz
                    COMPRESSED: true
[... other actions ...]
                - name: "download-file"
                  image: cexec:v1.0.0
                  timeout: 90
                  environment:
                    BLOCK_DEVICE: /dev/sda4
                    FS_TYPE: xfs
                    CHROOT: y
                    DEFAULT_INTERPRETER: "/bin/sh -c"
                    CMD_LINE: "curl https://foo.bar.com/fileb.img -o /path/fileb.img"

Expected Behaviour

To be able to curl the file like in this example: https://docs.tinkerbell.org/deploying-operating-systems/examples-rhel-centos/ Am I doing something wrong?

Current Behaviour

curl: (6) Could not resolve host: foo.bar.com.
FATA[0011] Error running [/bin/bash [-c curl curl https://foo.bar.com/fileb.img -o /path/fileb.img]] [exit status 6]`

Your Environment

Linuxkit: https://github.com/linuxkit/linuxkit

While reviewing #74, it came up in a community meeting that we do not enforce either unit tests or functional tests. It would be beneficial both add unit and functional tests, as well as mandating some kind of test coverage or increasing test coverage for hub actions.

Expected Behaviour

Readme and implementation of archive2disk to match

Current Behaviour

The readme references DEST_DISK, but the code looks for BLOCK_DEVICE

Possible Solution

Either update the documentation or update the implementation to match. DEST_DISK seems to align better with other actions, but would technically be a breaking change from the current implementation.

Context

I noticed it when trying to create a new action and using the existing actions as reference

Your Environment

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

• How are you running Tinkerbell? Using Vagrant & Libvirt

Hi there!
I'm considering contributing to this repository!
It seems I need to DCO sign off, but I can't find DCO.md:(

Expected Behaviour

DCO.md is correctly refferenced from CONTRIBUTING.md

Current Behaviour

DCO.md not found.

Possible Solution

Maybe, tinkerbell/tink/blob/main/docs/DCO.md is correct refference?

Context

rootio partition command leaves huge blank spaces between partitions

Expected Behaviour

rootio partition command do not leave huge blank spaces between partitions

Current Behaviour

rootio partition command leaves huge blank spaces between partitions

Possible Solution

Problem is there.
It's enough to change:
sectorStart += sectorEnd
to:
sectorStart = sectorEnd + 1

And result looks good:
New Partition Name=EFI Start=2048 End=493568 New Partition Name=ROOT Start=493569 End=210208769 New Partition Name=HOME Start=210208770 End=315066370 New Partition Name=LOG Start=315066371 End=419923971 New Partition Name=DOCKER Start=419923972 End=1875382960

Steps to Reproduce (for bugs)

For example we have following disks configuration:
{ "metadata": { "instance": { "storage": { "disks": [ { "device": "/dev/sda", "partitions": [ { "label": "EFI", "number": 1, "size": 491520 }, { "label": "ROOT", "number": 2, "size": 209715200 }, { "label": "HOME", "number": 3, "size": 104857600 }, { "label": "LOG", "number": 4, "size": 104857600 }, { "label": "DOCKER", "number": 5, "size": 0 } ], "wipe_table": true } ], "filesystems": [ { "mount": { "create": { "Options": [ "-n", "EFI" ] }, "device": "/dev/sda1", "format": "vfat", "point": "/boot/efi" } }, { "mount": { "create": { "Options": [ "-L", "ROOT" ] }, "device": "/dev/sda2", "format": "ext4", "point": "/" } }, { "mount": { "create": { "Options": [ "-L", "HOME" ] }, "device": "/dev/sda3", "format": "ext4", "point": "/home" } }, { "mount": { "create": { "Options": [ "-L", "LOG" ] }, "device": "/dev/sda4", "format": "ext4", "point": "/var/log" } }, { "mount": { "create": { "Options": [ "-L", "DOCKER" ] }, "device": "/dev/sda5", "format": "ext4", "point": "/var/lib/docker" } } ] } } } }

As a result we get following partition list for disk size 894GB:
New Partition Name=EFI Start=2048 End=493568 New Partition Name=ROOT Start=495616 End=210210816 New Partition Name=HOME Start=210706432 End=315564032 New Partition Name=LOG Start=526270464 End=631128064 New Partition Name=DOCKER Start=1157398528 End=1875382960
As you can there is a huge spaces between HOME-LOG-DOCKER partitions.

Your Environment

Debian Stretch

When a host has multiple disks, the disk names depends on the order of being detected during system boot.
How to handle this in tinkerbell actions which usually depend on DEVICE/DISK name?

Expected Behaviour

There should be a stable way to define tinkerbell actions.

Current Behaviour

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

Some boards do not support netbooting natively, such as the Rock Pi X. A current workaround is to supply a bootloader USB with the following folder structure:

/dev/sdxy/
└─ efi/
      └─ boot/
            └─ bootx64.efi

The bootx64.efi in this case is the renamed version of ipxe. I barely know anything about netbooting and bootloaders, but I suspect there is a better way.

It would be useful if there was an action, that would configure the boot partition to attempt to PXE boot first (to allow deprovisioning) and then to attempt to boot via the configured hard disk. This feature could be part of rootio, but I suspect that it should be a seperate action.

This would also greatly improve compatibility with devices, that do not have a UEFI to configure boot options, such as older Raspberry Pis or other single board computers.

Currently, we have a CI/CD mechanism to create and publish the YAML manifests used by ArtifactHub

https://github.com/tinkerbell/hub/blob/main/cmd/gen/cmd/gen.go

It works fine and it will work even better when #5 will be implemented.

We do not have a way to figure out changes in the code that require a docker image to be built (or re built) and published to quay.io (right now we use https://quay.io/organization/tinkerbell-actions/ ).

This process is something I do manually. Before merging a PR that requires an image to be built I run:

docker buildx build ....

And I push the image to Quay. I would like to automate myself with a few lines of Go that use buildkit directly for example. The image has to be multi-arch.

Expected Behaviour

We have an action that contains the capability of installing grub to a block device.

Current Behaviour

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

Expected Behaviour

The pgzip library implemented "parallel" gzip, this would be useful where image2disk or oci2disk hit areas of compressed data.. it wont speed up writing actual data to disk. -> https://github.com/klauspost/pgzip

Current Behaviour

We decompress in a single stream, this should decompress multiple chunks in parallel.

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

Expected Behaviour

Use the file package to examine the extension of the URL and use the correct decompressor for streaming compressed data to a block device.

.gz ==> gz streamer
.xz ==> xz streamer

Current Behaviour

if COMPRESSED=y then data is ran through the gz streamer.

Possible Solution

switch filepath.Ext("URL") {
case "gz":
case "xz":
}

Steps to Reproduce (for bugs)

Context

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

Expected Behaviour

Expected all the messages to be written to the logger.

tickerProgress directly writes to stdout and assumes its an interactive terminal that is being consumed by an human, which is something that I would expect to not be applicable to a Tinkerbell action, which is executed by a machine.

Current Behaviour

While trying to send all logs to a central place, this is what happens:

Possible Solution

Use the logger to output the progress report as its already being used at:

https://github.com/tinkerbell/hub/blob/9dbfd747f8754314e03441bd91aa8093dcc851f4/actions/image2disk/v1/pkg/image/image.go#L88

Also make the progress report less verbose (e.g. every 5 seconds and only if there is something new to report; the current 500ms is too much verbose).

Steps to Reproduce (for bugs)

Observe the logs in a file instead of a terminal.

Expected Behaviour

This should pull the grub2disk image

docker pull quay.io/tinkerbell-actions/grub2disk

Current Behaviour

This is what I see when I try to pull

root@tinkerbellubuntu:~/sandbox-0.5.0/deploy/scripts# docker pull quay.io/tinkerbell-actions/grub2disk
Using default tag: latest
Error response from daemon: manifest for quay.io/tinkerbell-actions/grub2disk:latest not found: manifest unknown: manifest unknown
root@tinkerbellubuntu:~/sandbox-0.5.0/deploy/scripts# docker pull quay.io/tinkerbell-actions/grub2disk:v1.0.0
Error response from daemon: manifest for quay.io/tinkerbell-actions/grub2disk:v1.0.0 not found: manifest unknown: manifest unknown
root@tinkerbellubuntu:~/sandbox-0.5.0/deploy/scripts# 

Steps to Reproduce (for bugs)

root@tinkerbellubuntu:~/sandbox-0.5.0/deploy/scripts# docker pull quay.io/tinkerbell-actions/grub2disk
Using default tag: latest
Error response from daemon: manifest for quay.io/tinkerbell-actions/grub2disk:latest not found: manifest unknown: manifest unknown
root@tinkerbellubuntu:~/sandbox-0.5.0/deploy/scripts# docker pull quay.io/tinkerbell-actions/grub2disk:v1.0.0
Error response from daemon: manifest for quay.io/tinkerbell-actions/grub2disk:v1.0.0 not found: manifest unknown: manifest unknown
root@tinkerbellubuntu:~/sandbox-0.5.0/deploy/scripts# 

Context

I'm able to pull all of the other images from here just fine. I copied the pull command that is failing from here.

Your Environment

I tried pulling with docker on:

root@tinkerbellubuntu:~/sandbox-0.5.0/deploy/scripts# cat /etc/os-release 
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

And with podman on:

NAME=Fedora
VERSION="34.20210525.0 (Silverblue)"
ID=fedora
VERSION_ID=34
VERSION_CODENAME=""
PLATFORM_ID="platform:f34"
PRETTY_NAME="Fedora 34.20210525.0 (Silverblue)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:34"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-silverblue/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=34
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=34
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Silverblue"
VARIANT_ID=silverblue
OSTREE_VERSION='34.20210525.0'

Maybe this is just a temporary problem? Or, I guess it is possible I'm doing something wrong, but the other images pull just fine.
Thank you.

According to https://github.com/tinkerbell/hub/blob/main/actions/rootio/v1/pkg/types.go/metadata.go#L14:L27 it would expect the storage block to be at the root of the returned metadata, but hegel returns everything wrapped in metadata":{...}. As a result rootio doesn't format/mount partitions as specified in the hardware config.

Expected Behaviour

rootio should partition and format the disks if host metadata has a storage block.

Current Behaviour

I get either Succesfully parsed the MetaData, Found [0] Disks or segfault in rootio.go:49.

Possible Solution

PR will follow.

Steps to Reproduce (for bugs)

run rootio partition action (image: /rootio:v1.0.1, command: ["partition"] in the template) against the following metadata returned for the box:

{
  "id": "f9f56dff-098a-4c5f-a51c-19ad35de85d4",
  "metadata": {
    "facility": {
      "facility_code": "onprem"
    },
    "instance": {},
    "storage": {
      "disks": [
        {
          "device": "/dev/sda",
          "partitions": [
            {
              "label": "BIOS",
              "number": 1,
              "size": 4096
            },
            {
              "label": "ROOT",
              "number": 2,
              "size": 8936000
            }
          ],
          "wipe_table": true
        }
      ]
    }
  },
  "network": {
....
}

When going through the sandbox and then experimenting with different actions, I went to pull down the grub2disk action and it said the tag was deleted

Expected Behaviour

$ docker pull quay.io/tinkerbell-actions/grub2disk:v1.0.0
v1.0.0: Pulling from tinkerbell-actions/grub2disk:v1.0.0
...

Current Behaviour

$ docker pull quay.io/tinkerbell-actions/grub2disk:v1.0.0
Error response from daemon: unknown: Tag v1.0.0 was deleted or has expired. To pull, revive via time machine

Possible Solution

restore the image on quay.io

Steps to Reproduce (for bugs)

1. docker pull quay.io/tinkerbell-actions/grub2disk:v1.0.0

kexec auto detect doesn’t appear to be parsing the grub.cfg correctly.

Expected Behaviour

Current Behaviour

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

I've tried the basic deployment examples for Ubuntu (20.04), Debian, and cluster-api-provider-tink, and in every case kexec hangs indefinitely for me.

My device no longer respond to the power button, and no longer responds to keyboard input.

After manually unplugging the power on my device and then pressing the power button, the provisioned OS boots.

Expected Behaviour

I'd expect kexec to boot a kernel after a few seconds, and come up with the provisioned operating system

Current Behaviour

The machine hangs after the kexec action starts

Possible Solution

Help! I'd love to be told I'm holding it wrong or doing something dumb.

Steps to Reproduce (for bugs)

1. Create hardware with mac address of worker tink hardware create < nuc03-hardware.json
2. Create template for debian install using disk /dev/nvme0n1 and partition /dev/nvme0n1p1

version: "0.1"
name: debian
global_timeout: 1800
tasks:
  - name: "os-installation"
    worker: "{{.device_1}}"
    volumes:
      - /dev:/dev
      - /dev/console:/dev/console
      - /lib/firmware:/lib/firmware:ro
    actions:
      - name: "stream-debian-image"
        image: quay.io/tinkerbell-actions/image2disk:v1.0.0
        timeout: 600
        environment:
          DEST_DISK: /dev/nvme0n1
          IMG_URL: "http://10.1.1.11:8080/debian-10-openstack-amd64.raw.gz"
          COMPRESSED: true
      - name: "kexec-debian"
        image: quay.io/tinkerbell-actions/kexec:v1.0.0
        timeout: 90
        pid: host
        environment:
          BLOCK_DEVICE: /dev/nvme0n1p1
          FS_TYPE: ext4

3. Create workflow

tink workflow create -t $TEMPLATE_ID -r '{"device_1": "$NUC03_MAC"}'

Prior to creating a workflow, I'm able to use the terminal and run the following commands:

nsenter -a -t `pidof dockerd`
docker ps -a 
docker logs -f $TINK_WORKER_CONTAINER

I see the following kernel messages just prior to the kexec call

EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Opts: (null)
kexec_core: Starting new kernel

I see the following log messages

IMAGE2DISK - Cloud image streamer
------------------------
INFO[0000] Beginning write of image [debian-10-openstack-amd64.raw.gz] to disk [/dev/nvme0n1] 
Downloading... 1.7 GB complete     
INFO[0010] Successfully written [http://10.1.1.11:8080/debian-10-openstack-amd64.raw.gz] to [/dev/nvme0n1] 
KEXEC - Kernel Exec
------------------------
INFO[0000] Mounted [/dev/nvme0n1p1] -> [/mountAction]   

$ tink workflow events 3efc93ac-d07b-11eb-ba8d-0242ac120004
+--------------------------------------+-----------------+-------------------------------+----------------+---------------------------------+---------------+
| WORKER ID                            | TASK NAME       | ACTION NAME                   | EXECUTION TIME | MESSAGE                         | ACTION STATUS |
+--------------------------------------+-----------------+-------------------------------+----------------+---------------------------------+---------------+
| ce2e62ed-826f-4485-a39f-a82bb74338e2 | os-installation | stream-debian-image           |              0 | Started execution               | STATE_RUNNING |
| ce2e62ed-826f-4485-a39f-a82bb74338e2 | os-installation | stream-debian-image           |             10 | finished execution successfully | STATE_SUCCESS |
| ce2e62ed-826f-4485-a39f-a82bb74338e2 | os-installation | add-tink-cloud-init-config    |              0 | Started execution               | STATE_RUNNING |
| ce2e62ed-826f-4485-a39f-a82bb74338e2 | os-installation | add-tink-cloud-init-config    |              0 | finished execution successfully | STATE_SUCCESS |
| ce2e62ed-826f-4485-a39f-a82bb74338e2 | os-installation | add-tink-cloud-init-ds-config |              0 | Started execution               | STATE_RUNNING |
| ce2e62ed-826f-4485-a39f-a82bb74338e2 | os-installation | add-tink-cloud-init-ds-config |              0 | finished execution successfully | STATE_SUCCESS |
| ce2e62ed-826f-4485-a39f-a82bb74338e2 | os-installation | kexec-debian                  |              0 | Started execution               | STATE_RUNNING |
+--------------------------------------+-----------------+-------------------------------+----------------+---------------------------------+---------------+
$ tink workflow state 3efc93ac-d07b-11eb-ba8d-0242ac120004
+----------------------+--------------------------------------+
| FIELD NAME           | VALUES                               |
+----------------------+--------------------------------------+
| Workflow ID          | 3efc93ac-d07b-11eb-ba8d-0242ac120004 |
| Workflow Progress    | 75%                                  |
| Current Task         | os-installation                      |
| Current Action       | kexec-debian                         |
| Current Worker       | ce2e62ed-826f-4485-a39f-a82bb74338e2 |
| Current Action State | STATE_RUNNING                        |
+----------------------+--------------------------------------+

Context

I can't get anything to provision properly.

Your Environment

Hardware:

• Intel NUC BNUC11TNHi3
• WD 500GB NVME SSD

Network setup:

• Running Tink sandbox on a separate NUC (nuc01 on VLAN 3)
• Tink worker NUC (nuc03 on VLAN 9) has it's network's DHCP server pointing to nuc01's IP

I've built a custom hook image using this gist

I followed the above guides in the Tinkerbell docs and my worker consistently hangs on kexec.

Could be related to/duplicate of #35?

I try to setup the the disk encryption for directory like /var in a tinkerbell action (right before tinkerbell action reboot).
Everything looks good in following areas:

1. /dev/mapper/ has cryption target name "sda1_crypt"
2. /etc/fstab maps "/var" to "/dev/mapper/sda1_crypt" with type "ext4"
3. /etc/crypttab maps target "sda1_crypt" to partition "/dev/sda1", which is consistent with output of "fdisk -l"

Only interesting thing is that, after command "cryptsetup luksOpen /dev/sda1 sda1_crypt" in the tinkerbell action, dummy file /etc/crypttab is not generated (if we run the command in command line, we will see /etc/crypttab shows up with a comment line).

However, tinkerbell action "reboot" doesn't ask for passphrase, and after reboot, all the cryption setting mentioned above disappears.

Expected Behaviour

reboot asks for encryption passphrase, and after reboot, the disk encryption setting will stay

Current Behaviour

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

While using rootio and want to create the FS as xfs, gettting an error message.
storage: disks: - device: /dev/sda partitions: - label: ROOT number: 1 size: 4096 wipe_table: true filesystems: - mount: create: options: - '-L' - ROOT - '-f' device: /dev/sda1 format: xfs point: "/"

Expected Behaviour

Partition as xfs must be created with no error.

Current Behaviour

Getting error:
2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.193668,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"82130aff0b25","facility":"daemon","host":"10.42.0.211","msg":{"actionName":"format","caller":"worker/container_manager.go:96","containerID":"190673fc0eeb186ff5016b4bb8377683c32ba2ece0def1f9fd6065584d3a90ab","level":"info","logger":"github.com/tinkerbell/tink","msg":"starting container","taskName":"partition-configuration","ts":1720701903.1876214,"workerID":"00:16:3e:ff:33:83","workflowID":"install-disp-vm7"},"procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.3270297,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"190673fc0eeb","facility":"daemon","host":"10.42.0.211","msg":"Successfully parsed the MetaData, Found [1] Disks\r\n","procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.3271115,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"190673fc0eeb","facility":"daemon","host":"10.42.0.211","msg":"ROOTIO - Disk Manager\r\n","procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.327148,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"190673fc0eeb","facility":"daemon","host":"10.42.0.211","msg":"------------------------\r\n","procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.32728,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"190673fc0eeb","facility":"daemon","host":"10.42.0.211","msg":"Parsing MetaData\r\n","procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.327505,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"190673fc0eeb","facility":"daemon","host":"10.42.0.211","msg":"\u001b[31mERRO\u001b[0m[0000] command [] Filesystem [fork/exec /sbin/mkfs.xfs: no such file or directory] \r\n","procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.3325045,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"82130aff0b25","facility":"daemon","host":"10.42.0.211","msg":"Successfully parsed the MetaData, Found [1] Disks\n","procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.3325477,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"82130aff0b25","facility":"daemon","host":"10.42.0.211","msg":"ROOTIO - Disk Manager\n","procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.3325639,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"82130aff0b25","facility":"daemon","host":"10.42.0.211","msg":"------------------------\n","procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.332583,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"82130aff0b25","facility":"daemon","host":"10.42.0.211","msg":"Parsing MetaData\n","procid":"1569","severity":"INFO"}} 2024-07-11T14:45:03+02:00 {"level":"info","ts":1720701903.3328114,"caller":"syslog/receiver.go:160","msg":"msg","msg":{"app-name":"82130aff0b25","facility":"daemon","host":"10.42.0.211","msg":"\u001b[31mERRO\u001b[0m[0000] command [] Filesystem [fork/exec /sbin/mkfs.xfs: no such file or directory] \n","procid":"1569","severity":"INFO"}}

Possible Solution

missed inside of container

Steps to Reproduce (for bugs)

1.create hardware.yaml with xfs format
2.run creating
3.
4.

Context

Using tinkerbell to setup new data center for CTAO project. There will be installed new telescopes for observatories and we would like to use tinkerbell to do the OS installation on the servers.

Your Environment

• Operating System and version (e.g. Linux, Windows, MacOS):
  Linux
• How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:
  VM
• Link to your project or a code example to reproduce issue:
  https://github.com/tinkerbell/actions/tree/main/rootio

To be written

Expected Behaviour

If Quay auth fails the command hub build should fail with an exit code != 0

Current Behaviour

it reports an error but it has exit-code=0

Possible Solution

Probably we do not handle the error in the right way because we loop over all the actions that need to be re-built.

Expected Behaviour

Operating System images may require LVM support on mounting (examples here -> https://github.com/plunder-app/BOOTy/blob/master/pkg/realm/disk.go)

Requires running a scan operation to populate /dev with the lvm dev nodes, once populated we can mount these LVM device nodes.

Current Behaviour

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

I am using the hardware and template examples as outlined on the tinkerbell.org documentation page. I have found that when rootio requests metadata from hegel, it is expecting it in a format that is different from the Tinkerbell hardware json format. Rootio is looking for types.Metadata which, when comparing it to a Tinkerbell hardware json, is an instance within the metadata structure.

As a test, I modified a local copy of rootio to read in a Tinkerbell hardware json and return the correct metadata instance.

Expected Behaviour

Rootio should correctly parse the returned metadata and process the storage structure correctly.

Current Behaviour

Unmodified, rootio states that zero disks were found in the metadata.

Possible Solution

Configure rootio to process the metadata as a hardware json. Or modify the call to hegel to return the correct structure via something like /metadata/storage.

Steps to Reproduce (for bugs)

1. Set up a docker-compose instance of Tinkerbell
2. Create a hardware json as outlined on https://docs.tinkerbell.org/hardware-data/
3. Create a template yaml as outlined on the bottom of https://docs.tinkerbell.org/deploying-operating-systems/examples-ubuntu/
4. Run a pxeboot on the machine to be provisioned, review the rootio logs to show that it states zero disks found.

Context

I am unable to use rootio to process my storage array, this prevents me from using Tinkerbell as intended.

Your Environment

• Operating System and version (e.g. Linux, Windows, MacOS):
  The provisioner is running Ubuntu 20.04 on a VM on ESXi. The machine being provisioned is on the same ESXi server. So both VM's.
• How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:
  Running Tinkerbell with docker-compose
• Link to your project or a code example to reproduce issue:

Modifying rootio to read in the metadata into the following structure makes it work correctly:
I was able to limit all changes to rootio/v1/pkg/types.go/metadata.go

type ExportedCacher struct {
	ID                                 string                   `json:"id"`
	Metadata                           Metadata                 `jsonm:"metadata"`
}

type Metadata struct {
	Arch                               string                   `json:"arch"`
	State                              string                   `json:"state"`
	EFIBoot                            bool                     `json:"efi_boot"`
	Instance                           Instance                 `json:"instance,omitempty"`
	PreinstalledOperatingSystemVersion interface{}              `json:"preinstalled_operating_system_version"`
	NetworkPorts                       []map[string]interface{} `json:"network_ports"`
	PlanSlug                           string                   `json:"plan_slug"`
	Facility                           string                   `json:"facility_code"`
	Hostname                           string                   `json:"hostname"`
	BondingMode                        int                      `json:"bonding_mode"`
}


type Instance struct {
	ID       string `json:"id,omitempty"`
	State    string `json:"state,omitempty"`
	Hostname string `json:"hostname,omitempty"`
	AllowPXE bool   `json:"allow_pxe,omitempty"`
	Rescue   bool   `json:"rescue,omitempty"`

	IPAddresses []map[string]interface{} `json:"ip_addresses,omitempty"`
	OS          OperatingSystem         `json:"operating_system_version,omitempty"`
	UserData    string                   `json:"userdata,omitempty"`

	CryptedRootPassword string `json:"crypted_root_password,omitempty"`

	Storage      Storage `json:"storage,omitempty"`
	SSHKeys      []string `json:"ssh_keys,omitempty"`
	NetworkReady bool     `json:"network_ready,omitempty"`
}

type OperatingSystem struct {
	Slug     string `json:"slug"`
	Distro   string `json:"distro"`
	Version  string `json:"version"`
	ImageTag string `json:"image_tag"`
	OsSlug   string `json:"os_slug"`
}



type File struct {
	Path     string `json:"path"`
	Contents string `json:"contents,omitempty"`
	Mode     int    `json:"mode,omitempty"`
	UID      int    `json:"uid,omitempty"`
	GID      int    `json:"gid,omitempty"`
}

type FilesystemOptions struct {
	Force   bool     `json:"force,omitempty"`
	Options []string `json:"options,omitempty"`
}

type Raid struct {
	Name    string   `json:"name"`
	Level   string   `json:"level"`
	Devices []string `json:"devices"`
	Spares  int      `json:"spares,omitempty"`
}

type Storage struct {
	Disks       []Disk       `json:"disks,omitempty"`
	RAID        []Raid       `json:"raid,omitempty"`
	Filesystems []Filesystem `json:"filesystems,omitempty"`
}

//Filesystem defines the organisation of a filesystem
type Filesystem struct {
		Mount struct {
		Create struct {
			Options []string `json:"options"`
		} `json:"create"`
		Device string `json:"device"`
		Format string `json:"format"`
		Point  string `json:"point"`
	} `json:"mount"`
}

//Disk defines the configuration for a disk
type Disk struct {
	Device     string       `json:"device"`
	Partitions []Partitions `json:"partitions"`
	WipeTable  bool         `json:"wipe_table"`
}

//Partitions details the architecture
type Partitions struct {
	Label  string `json:"label"`
	Number int    `json:"number"`
	Size   uint64 `json:"size"`
}



//I also configured RetreiveData to return the appropriate nested object:
func RetreieveData() (*Instance, error) {
	metadataURL := os.Getenv("MIRROR_HOST")
	if metadataURL == "" {
		return nil, fmt.Errorf("Unable to discover the metadata server from environment variable [MIRROR_HOST]")
	}

	metadataClient := http.Client{
		Timeout: time.Second * 60, // Timeout after 60 seconds (seems massively long is this dial-up?)
	}

	req, err := http.NewRequest(http.MethodGet, fmt.Sprintf("http://%s:50061/metadata", metadataURL), nil)
	if err != nil {
		return nil, err
	}

	req.Header.Set("User-Agent", "bootkit")

	res, getErr := metadataClient.Do(req)
	if getErr != nil {
		return nil, err
	}

	if res.Body != nil {
		defer res.Body.Close()
	}

	body, readErr := ioutil.ReadAll(res.Body)
	if readErr != nil {
		return nil, err
	}

	var exportedcacher ExportedCacher
	//var mdata Metadata

	jsonErr := json.Unmarshal(body, &exportedcacher)
	if jsonErr != nil {
		return nil, jsonErr
	}

	return &exportedcacher.Metadata.Instance, nil
}

Expected Behaviour

It should build for all supported architectures.

Current Behaviour

https://github.com/tinkerbell/hub/runs/3830474226#step:9:3870

Possible Solution

Make it more agnostic about how it finds libc.

Document the support for the Zstandard decompression and rename the extension from .zs to .zst in https://github.com/tinkerbell/hub/search?q=zstd.

To be written

Even with both #59 and #68 having been merged, it doesn't appear that the container was pushed up to Quay.
I thought the CI/CD process would have done that.

Expected Behaviour

Merges that create/update actions cause new images to be pushed to Quay.

Current Behaviour

https://quay.io/repository/tinkerbell-actions/qemuimg2disk appears empty.

Its quite hard to go from a image, say, image2disk:v1.0.0 to its source code, as there are no tags in this repository nor a git revision in the artifacthub page.

Can these be included in the release process?

Expected Behaviour

Commands requiring sysfs inside the chroot should work.

Current Behaviour

Currently cexec mounts /dev and /proc filesystems inside the chroot before running commands, however there are some commands that also require sysfs presence.

Possible Solution

Add code to mount sysfs in the MountSpecialDirs function.

I try to use cexec to install cryptsetup as follows:

- environment:
     BLOCK_DEVICE: /dev/sda2
     CHROOT: "y"
     CMD_LINE: apt -y update && apt -y install openssl cryptsetup
     DEFAULT_INTERPRETER: /bin/sh -c
     FS_TYPE: ext4
    image: public.ecr.aws/eks-anywhere/tinkerbell/hub/cexec:6c0f0d437bde2c836d90b000312c8b25fa1b65e1-eks-a-41
    name: install-openssl-crypt
    timeout: 90

However, I get this error in boots log (openssl is fine):

{"level":"info","ts":1708196321.6035774,"caller":"syslog/receiver.go:113","msg":"host=10.20.22.211 facility=daemon severity=INFO app-name=6ab16e7894a1 procid=2998 msg=\"\\x1b[1;31mE: \\x1b[0mUnable to locate package cryptsetup\\x1b[0m\\n\"","service":"github.com/tinkerbell/boots","pkg":"syslog"}
{"level":"info","ts":1708196321.6040635,"caller":"syslog/receiver.go:113","msg":"host=10.20.22.211 facility=daemon severity=INFO app-name=5e73ff8c10e3 procid=2998 msg=\"\\x1b[31mFATA\\x1b[0m[0000] Error running [/bin/sh [-c apt -y update && apt -y install openssl cryptsetup]] [exit status 100] \\r\\n\"","service":"github.com/tinkerbell/boots","pkg":"syslog"}

Expected Behaviour

I expect cryptsetup will be installed successfully

Current Behaviour

The tinkerbell workflow failed due to the error mentioned above

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

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

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

• Link to your project or a code example to reproduce issue:

Using the Tinkerbell documentation as an example (links below), I am unable to use the cexec action for any commands as it returns an exec format error. In googling, this is related to not having "#!/bin/sh" at the top of a script, but I am not calling from a script, so I a not sure if this is indirectly how to fix this, or if I am using cexec incorrectly.

Expected Behaviour

I expect cexec to run the commands as expected with the default interpreter.

Current Behaviour

Cexec errors out and the workflow fails to continue executing

Possible Solution

Steps to Reproduce (for bugs)

1. Set up a docker-compose instance of Tinkerbell
2. Create a hardware json as outlined on https://docs.tinkerbell.org/hardware-data/
3. Create a template yaml as outlined on the bottom of https://docs.tinkerbell.org/deploying-operating-systems/examples-ubuntu/
4. Run a pxeboot on the machine to be provisioned, review the tink-worker logs to show that cexec failed with an exec format error

Context

This is preventing me from using cexec.

Your Environment

• Operating System and version (e.g. Linux, Windows, MacOS):
  The provisioner is running Ubuntu 20.04 on a VM on ESXi. The machine being provisioned is on the same ESXi server. So both VM's.
• How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:
  Running Tinkerbell with docker-compose
• Link to your project or a code example to reproduce issue:

#notes: using a locally modified version of rootio which can process the metadata correctly as a Tinkerbell hardware json file.
version: "0.1"
name: ubuntu_provisioning
global_timeout: 1800
tasks:
  - name: "os-installation"
    worker: "{{.device_1}}"
    volumes:
      - /dev:/dev
      - /dev/console:/dev/console
      - /lib/firmware:/lib/firmware:ro
    actions:
      - name: "disk-wipe-partition"
        image: thebsdbox/rootio:1.0
        timeout: 90
        command: ["partition"]
        environment:
            MIRROR_HOST: [redacted]
      - name: "format"
        image: thebsdbox/rootio:1.0
        timeout: 90
        command: ["format"]
        environment:
            MIRROR_HOST: [redacted]
      - name: "expand-ubuntu-filesystem-to-root"
        image: quay.io/tinkerbell-actions/archive2disk:v1.0.0
        timeout: 90
        environment:
            ARCHIVE_URL: http://[redacted]:8080/ubuntu_rootfs.tar.gz
            ARCHIVE_TYPE: targz
            DEST_DISK: /dev/sda3
            FS_TYPE: ext4
            DEST_PATH: /
      - name: "apt-update"
        image: quay.io/tinkerbell-actions/cexec:v1.0.0
        timeout: 90
        environment:
            BLOCK_DEVICE: /dev/sda3
            FS_TYPE: ext4
            DEFAULT_INTERPRETER: "/usr/bin/sh -c"
            CHROOT: y
            CMD_LINE: "apt-get -y update"

After archive2disk runs, looking at the root directory, symbolic links show up as zero length files. This makes the partition unusable, and the actions after archive2disk fail. I discovered this issue trying to use cexec.

Expected Behaviour

archive2disk should check the header type of each file and process the files per the respective header type.

Current Behaviour

Symlinks get created as zero length files.

Possible Solution

Review all of the header types and process according to the type, including TypeSymlink

Steps to Reproduce (for bugs)

1. Set up a docker-compose instance of Tinkerbell
2. Create a hardware json as outlined on https://docs.tinkerbell.org/hardware-data/
3. Create a template yaml as outlined on the bottom of https://docs.tinkerbell.org/deploying-operating-systems/examples-ubuntu/
4. Run a pxeboot on the machine to be provisioned, the cexec will fail, manually mount the partition in the LinuxKit env, in this case /dev/sda3, and look at the root directory and to see bin, lib, lib32, lib64, libx32 and sbin all as zero length files instead of symlinks. This is what was giving me the cexec 'exec format erro'r.

Context

I was trying to use archive2disk to untar an ubuntu_rootfs.tar.gz image. Since the tar file does not process symlinks correctly, the actions after archive2disk fail.

Manually extracting the file onto the partition works, and allows a cexec container to run.
In looking at other uses of golangs tar package, files are processed based off the header.typeflag which includes TypeSymLlink

const (
	// Type '0' indicates a regular file.
	TypeReg  = '0'
	TypeRegA = '\x00' // Deprecated: Use TypeReg instead.

	// Type '1' to '6' are header-only flags and may not have a data body.
	TypeLink    = '1' // Hard link
	TypeSymlink = '2' // Symbolic link
	TypeChar    = '3' // Character device node
	TypeBlock   = '4' // Block device node
	TypeDir     = '5' // Directory
	TypeFifo    = '6' // FIFO node

	// Type '7' is reserved.
	TypeCont = '7'

	// Type 'x' is used by the PAX format to store key-value records that
	// are only relevant to the next file.
	// This package transparently handles these types.
	TypeXHeader = 'x'

	// Type 'g' is used by the PAX format to store key-value records that
	// are relevant to all subsequent files.
	// This package only supports parsing and composing such headers,
	// but does not currently support persisting the global state across files.
	TypeXGlobalHeader = 'g'

	// Type 'S' indicates a sparse file in the GNU format.
	TypeGNUSparse = 'S'

	// Types 'L' and 'K' are used by the GNU format for a meta file
	// used to store the path or link name for the next file.
	// This package transparently handles these types.
	TypeGNULongName = 'L'
	TypeGNULongLink = 'K'
)

Your Environment

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

• The provisioner is running Ubuntu 20.04 on a VM on ESXi. The machine being provisioned is on the same ESXi server. So both VM's.

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

• Link to your project or a code example to reproduce issue:

#notes: using a locally modified version of rootio which can process the metadata correctly as a Tinkerbell hardware json file.
version: "0.1"
name: ubuntu_provisioning
global_timeout: 1800
tasks:
  - name: "os-installation"
    worker: "{{.device_1}}"
    volumes:
      - /dev:/dev
      - /dev/console:/dev/console
      - /lib/firmware:/lib/firmware:ro
    actions:
      - name: "disk-wipe-partition"
        image: thebsdbox/rootio:1.0
        timeout: 90
        command: ["partition"]
        environment:
            MIRROR_HOST: [redacted]
      - name: "format"
        image: thebsdbox/rootio:1.0
        timeout: 90
        command: ["format"]
        environment:
            MIRROR_HOST: [redacted]
      - name: "expand-ubuntu-filesystem-to-root"
        image: quay.io/tinkerbell-actions/archive2disk:v1.0.0
        timeout: 90
        environment:
            ARCHIVE_URL: http://[redacted]:8080/ubuntu_rootfs.tar.gz
            ARCHIVE_TYPE: targz
            DEST_DISK: /dev/sda3
            FS_TYPE: ext4
            DEST_PATH: /
      - name: "apt-update"
        image: quay.io/tinkerbell-actions/cexec:v1.0.0
        timeout: 90
        environment:
            BLOCK_DEVICE: /dev/sda3
            FS_TYPE: ext4
            DEFAULT_INTERPRETER: "/usr/bin/sh -c"
            CHROOT: y
            CMD_LINE: "apt-get -y update"

The artifact hub manifest has the concept of Digest:

https://github.com/tinkerbell/hub/blob/9cba84d79d14be55c67ac75062d12ce7d42fe65e/pkg/artifacthub/manifest.go#L29-L33

I exposed it but it is not used. The Digest is super important to tell ArtifactHub that our manifest changed and it has to be updated. (look at the bullet points here https://artifacthub.io/docs/topics/repositories/#oci-experimental-support)

We should figure out how to calculate the digest and how to set it properly to tell ArtifactHub when an image OR the README.md changed.

A possible implementation is to checksum the action directory and set the value as part of the manifest.

image2disk workflow swallows some of the errors which are returned once the workflow is executed.

Expected Behaviour

When an error occurs, it should be printed out in the logs

Current Behaviour

No error is being printed out.

Possible Solution

Add the errors in the fmt.Errorf() function

Steps to Reproduce (for bugs)

1.Run the workflow
2.If an error has been encountered during partitions re-probing, error message won't be there
3.
4.

Context

Your Environment

• Operating System and version (e.g. Linux, Windows, MacOS):
  OSIE
• How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:
  OnPrem
• Link to your project or a code example to reproduce issue:

Add the following actions to the hub:

• Reboot
• Power off
• Re DHCP