Build x86_64 Backend Issues

[keithkk]

Thanks for providing these docs and tutorials. Much appreciated!

I followed through the instructions starting from the top. For the most part, all was clear and easy to work through. Things began to fall apart though once I got to the Build x86_64 Backend(s) section. That's where I left off and was not successfully able to continue. It seemed like the the main issue was that the PXE Boot files would not install correctly. I'm new to CoreOS and RPM syntax, but the past few years using Ubuntu are pretty similar which allowed me to try a few different install variations. I couldn't get any to stick that allowed me to proceed to the next step of copying the image files to the /tftpboot/pxelinux/ directory. These three were unable to be ran with a response of the source files not existing for the first two nor the entire /syslinux directory:

# cp /opt/stack/images/vmlinuz-4.0_20170414_c4aff2a-7.x-x86_64 /tftpboot/pxelinux/
# cp /opt/stack/images/initrd.img-4.0_20170414_c4aff2a-7.x-x86_64 /tftpboot/pxelinux/
# cp -r /usr/share/syslinux/* /tftpboot/pxelinux/

I do have a successful frontend machine up and running in a VM with a few backend hosts in VMs as well. Those are in Hyper-V on a Windows Server 2016 DC x86 system. That install and configuration was smooth and straight forward. To try and get past the above three steps, I found that both image files and the /syslinux directory were installed in the same locations that were suppose to be present on the Pi's drive. So, I copied them from that frontend machine to the Pi's Micro SD card.

I was not able to proceed with the following step either which is where I gave up for now. After copy/paste this step, I continued to get argument errors that didn't make sense at first until I found the host information was now missing.

[root@stacki ~]# stack add bootaction stacki action=install_x86 args="ip=bootif:dhcp inst.ks=https://10.10.10.1/install/sbin/profile.cgi inst.geoloc=0 inst.noverifyssl inst.ks.sendmac ramdisk_size=300000" kernel="vmlinuz-4.0_20170414_c4aff2a-7.x-x86_64" ramdisk="initrd.img-4.0_20170414_c4aff2a-7.x-x86_64"
error - "host" argument is required
{host ...} [action=string]

I found that "stack list host" was now returning blank/zero results. I also received this error for "stack list bootaction" when trying to see if I could pickup on anything:

[root@stacki ~]# stack list bootaction
  File "/opt/stack/bin/stack", line 402, in run_command
    rc = command.runWrapper(name, args[i:])
  File "/opt/stack/lib/python2.6/site-packages/stack/commands/command.py", line 2324, in runWrapper
    rc = self.run(self._params, self._args)
  File "/opt/stack/lib/python2.6/site-packages/stack/commands/list/bootaction/__init__.py", line 106, in run
    for row in self.db.fetchall():
stack.commands.list.bootaction: TypeError -- 'NoneType' object is not iterable

Prior to the x86_64 backend steps, the above commands would return results correctly when I had only the Pi 3 frontend machine and another Pi 3 as a backend machine.

Please let me know how I can best troubleshoot this to get things working. I'd like to have the Pi 3 frontend machine controlling a combination of my backend Pi 3s, VMs on different OSs, and physical machines.

Separate from above and minor, but did cause an error, I had to add "pallet" to the following step as it is currently published:

Add/enable the os pallet for the x86_64 box:

# stack add os-7.3_11122da-7.x.x86_64.disk1.iso
# stack enable pallet os arch=x86_64 box=x86_64

Thanks,
Keith

[jlkaiser]

Hi Keith, So you're doing all this on a raspberry pi? I'm not sure what you mean by CoreOS. CoreOS is not supported - yet.

That's where I left off and was not successfully able to continue. It seemed like the the main issue was that the PXE Boot files would not install correctly. I'm new to CoreOS and RPM syntax, but the past few years using Ubuntu are pretty similar which allowed me to try a few different install variations. I couldn't get any to stick that allowed me to proceed to the next step of copying the image files to the /tftpboot/pxelinux/ directory. These three were unable to be ran with a response of the source files not existing for the first two nor the entire /syslinux directory: # cp /opt/stack/images/vmlinuz-4.0_20170414_c4aff2a-7.x-x86_64 /tftpboot/pxelinux/ # cp /opt/stack/images/initrd.img-4.0_20170414_c4aff2a-7.x-x86_64 /tftpboot/pxelinux/ # cp -r /usr/share/syslinux/* /tftpboot/pxelinux/

The files above exist after you've run this set of instructions. From the ACE wiki. You need the x86_64 pallets and rpms to do the rest of the instructions successfully. - # wget http://stacki.s3.amazonaws.com/public/pallets/4.0/open-source/stacki-4.0_20170414_c4aff2a-7.x.x86_64.disk1.iso # wget http://stacki.s3.amazonaws.com/public/pallets/4.0/open-source/os-7.3_11122da-7.x.x86_64.disk1.iso - Add x86_64 box. # stack add box x86_64 - Add/enable the os pallet for the x86_64 box: # stack add os-7.3_11122da-7.x.x86_64.disk1.iso # stack enable pallet os arch=x86_64 box=x86_64 - Now add/enable the stacki pallet: # stack add pallet stacki-4.0_20170414_c4aff2a-7.x.x86_64.disk1.iso # stack enable pallet stacki arch=x86_64 box=x86_64 - Install the files needed for pxeboot # rpm -ivh --force --nodeps --ignorearch /export/stack/pallets/stacki/4.0_20170414_c4aff2a/7.x/redhat/x86_64/RPMS/stack-images-4.0_20170414_c4aff2a-7.x.x86_64.rpm # rpm -ivh --force --nodeps --ignorearch /export/stack/pallets/os/7.3_11122da/7.x/redhat/x86_64/RPMS/syslinux-4.05-13.el7.x86_64.rpm

I do have a successful frontend machine up and running in a VM with a few backend hosts in VMs as well. Those are in Hyper-V on a Windows Server 2016 DC x86 system. That install and configuration was smooth and straight forward. To try and get past the above three steps, I found that both image files and the /syslinux directory were installed in the same locations that were suppose to be present on the Pi's drive. So, I copied them from that frontend machine to the Pi's Micro SD card. I was not able to proceed with the following step either which is where I gave up for now. After copy/paste this step, I continued to get argument errors that didn't make sense at first until I found the host information was now missing. ***@***.*** ~]# stack add bootaction stacki action=install_x86 args="ip=bootif:dhcp inst.ks=https://10.10.10.1/install/sbin/profile.cgi inst.geoloc=0 inst.noverifyssl inst.ks.sendmac ramdisk_size=300000" kernel="vmlinuz-4.0_20170414_c4aff2a-7.x-x86_64" ramdisk="initrd.img-4.0_20170414_c4aff2a-7.x-x86_64" error - "host" argument is required {host ...} [action=string]

Okay, you shouldn't have to use a hostname for the "stack add bootaction" command. So that's a weird error message. I'll look into it.

I found that "stack list host" was now returning blank/zero results. I also received this error for "stack list bootaction" when trying to see if I could pickup on anything: ***@***.*** ~]# stack list bootaction File "/opt/stack/bin/stack", line 402, in run_command rc = command.runWrapper(name, args[i:]) File "/opt/stack/lib/python2.6/site-packages/stack/commands/command.py", line 2324, in runWrapper rc = self.run(self._params, self._args) File "/opt/stack/lib/python2.6/site-packages/stack/commands/list/bootaction/__init__.py", line 106, in run for row in self.db.fetchall(): stack.commands.list.bootaction: TypeError -- 'NoneType' object is not iterable

This is clearly messed up. Check to make sure your disk is not full. "df -h" nothing should be 100%. Reboot the frontend and see if you can do a "stack list host" and a "stack list pallet" and if you can, we'll get you going.

Prior to the x86_64 backend steps, the above commands would return results correctly when I had only the Pi 3 frontend machine and another Pi 3 as a backend machine. Please let me know how I can best troubleshoot this to get things working. I'd like to have the Pi 3 frontend machine controlling a combination of my backend Pi 3s, VMs on different OSs, and physical machines.

I've been able to do precisely this with the latest stacki-ace release. So I'm pretty sure we can get yout there.

Separate from above and minor, but did cause an error, I had to add "pallet" to the following step as it is currently published: Add/enable the os pallet for the x86_64 box: # stack add os-7.3_11122da-7.x.x86_64.disk1.iso # stack enable pallet os arch=x86_64 box=x86_64 You should also add/enable the stacki x86_64 pallet as well to the x86_64

box. Thanks, Joe

[gregorybruno]

Keith,

I think you caught us in between updating the Stacki-Ace ISOs and updating the Stacki-Ace documentation. The documentation is up-to-date and the files that match that documentation are below.

Try reinstalling your Raspberry Pi frontend with the files below, then re-execute the procedure to install x86_64 backend nodes.

Let us know how it goes.

---

The new release can be found here:

stacki-centos.img:

http://stacki.s3.amazonaws.com/public/pallets/4.1/open-source/ace/stacki-centos.img

frontend-install.py:

http://stacki.s3.amazonaws.com/public/pallets/4.1/open-source/ace/frontend-install.py

ISOs:

http://stacki.s3.amazonaws.com/public/pallets/4.1/open-source/ace/stacki-4.1-7.x.armv7hl.disk1.iso

http://stacki.s3.amazonaws.com/public/pallets/4.1/open-source/ace/stacki-ace-4.1-7.x.armv7hl.disk1.iso

http://stacki.s3.amazonaws.com/public/pallets/4.1/open-source/ace/os-7.3-7.x.armv7hl.disk1.iso

MD5 checksums:

http://stacki.s3.amazonaws.com/public/pallets/4.1/open-source/ace/md5sum.txt

[keithkk]

Thanks for the replies and input. To be safe with storage when re-installing everything, I used 32gb micro SD this time instead of an 8gb. After downloading all the above images again which now look to be the most updated versions, all went smooth with the installation and all steps and sections.

I'll do some x86 machine and VM boot testing in the next few days and report back if any issues that come up.

So far, the ARM booting and process has worked successfully with Pi 3 and Pi 2 Model B boards. I couldn't get a Zero to work. I know the Zero and 2 are not supported, but I figured I'd give them a shot since I had a couple laying around.

Thanks again!

[gregorybruno]

Glad you have a working solution.

Keep us posted on your progress!