@george1421 wont

@Rebelman said in Fog Menu loop:

s

What’s the output of mysql statement:

SELECT settingKey,settingValue FROM globalSettings WHERE settingKey IN ('FOG_EFI_BOOT_EXIT_TYPE','FOG_KERNEL_ARGS','FOG_KERNEL_DEBUG','FOG_KERNEL_LOGLEVEL','FOG_KERNEL_RAMDISK_SIZE','FOG_KEYMAP','FOG_KEY_SEQUENCE','FOG_MEMTEST_KERNEL','FOG_PXE_BOOT_IMAGE','FOG_PXE_BOOT_IMAGE_32','FOG_PXE_HIDDENMENU_TIMEOUT','FOG_PXE_MENU_HIDDEN','FOG_PXE_MENU_TIMEOUT','FOG_TFTP_PXE_KERNEL','FOG_TFTP_PXE_KERNEL_32') ORDER BY settingKey;

There should be 15 values returned, and I’m suspecting one of these keys is missing. Please copy and paste the statement into your shell to get the return, then copy and paste the return values into a posting so we can see what’s going on a little easier.

To make things easier to see (and for us to easily view the items more directly) the values in order would be something like:

1. FOG_EFI_BOOT_EXIT_TYPE
2. FOG_KERNEL_ARGS
3. FOG_KERNEL_DEBUG
4. FOG_KERNEL_LOGLEVEL
5. FOG_KERNEL_RAMDISK_SIZE
6. FOG_KEYMAP
7. FOG_KEY_SEQUENCE
8. FOG_MEMTEST_KERNEL
9. FOG_PXE_BOOT_IMAGE
10. FOG_PXE_BOOT_IMAGE_32
11. FOG_PXE_HIDDENMENU_TIMEOUT
12. FOG_PXE_MENU_HIDDEN
13. FOG_PXE_MENU_TIMEOUT
14. FOG_TFTP_PXE_KERNEL
15. FOG_TFTP_PXE_KERNEL_32

I suspect something between 1-12 is actually missing, causing the MENU_TIMEOUT value to to be put in place of the MENU_HIDDEN value (timeout is usually defaulted to 3 - 5 seconds) which is triggering the boot menu to think it is a hidden item.

@george1421 I’m using ipxe.pxe as the boot file. Not replacing the version VB’s NIC’s are set too. (Though I imagine that would work well too.)

@salted_cashews and @Sebastian-Roth

I believe the problem is coming from the second -d

Particularly in the naming of the image, it appears to be doing:

zstdmt -d /images/PPS_v9.0R2 Then get’s a second -d from the -dev_CentOS/d1p1.image

So it’s literally, I think, doing:

zstdmt -d ev_CentOS/d1p1.img

Does this make sense?

I think the - in the image name is causing issues parsing into the zstdmt command. The reason it doesn’t impact the Ciara_CentOS-BASEmk3 is because, likely, there is no argument for -B is it just uses it like a normal string.

Maybe we need to add some quoting to the scripting?

It can open .gz, but you’re right. By default, we use XZ compression for the init’s.

Even more odd is the fog/images/init.gz being the configuration path from the old 0.32 versions (and earlier) when it referenced the init from /tftpboot/fog/images/init.gz

Did you follow configuration from a very old tutorial?

@Sebastian-Roth If my memory serves me correctly we did encode all of this for a little while, but too my knowledge we’ve moved away from encoding special characters in preference of using proper sanitization of inputs into the database. That’s not to say everything was fixed, but I’m pretty sure we moved away from this particularly because the & would get encoded as &amp, then the & in the &amp would get encoded, and so on and so forth.

The radio buttons are accurate. If you choose Reboot when Shutdown was chosen, it unselects Shutdown. If you Select Shutdown when Reboot was selected, Shutdown gets unselected.

The reason you can unselect them at all basically means that you don’t require it to restart or shutdown.

@Sebastian-Roth, @TBuzaTechnician

If you run mysqladm --user root password "newpassword", you should not do it as a part of the installation script (eventually yes, but as of right now no.)

After you set the password, then you can run it with snmysqlpass='newpassword' ./installfog.sh -y

Eventually, I know we want to create a separate user and password pair for mysql for security reasons, but in the mean time, the above should work.

Another option that doesn’t seem to loop forever:

head /dev/urandom | tr -dc '0-9a-zA-Z!#$%&()*+,-./:;<=>?@[]^_{|}~' | fold -w12 | shuf -n1

What this one does, it breaks at the first new line urandom gives (so much faster return and not infinite loop), pipes that output to tr, folds it to a width of 12 characters, and shuffles the data returned from the fold.

Hopefully this may help?

The other method is to use most of the stuff but for removing packages, source in the .fogsettings file before you remove the /opt/fog/ folder. Then you can use packagemanager-uninstallcmd $packages

Note this will simply remove the packages fog installs. All the other bits of service removal and what not should work as indicated.

I kind of side with @Sebastian-Roth however because removing all the installed packages can sometimes uninstall elements unexpectedly and out of “fogs” control. I’ve seen occasionally some like like installing python then uninstalling it breaking package manager tools like yum or apt

@george1421 That is because the separate storage group has a master. It’s a “work around” to the “Images are always captured to the master node” because you, quite literally, are making the storage node, now, a master node. It works of course for this reason.

@Sebastian-Roth I think we just need to refine the code a bit more. I don’t know why it’s getting the error, I just know what we did int he past for the passwords. I’m sure we can make a more proper fix without limiting what passwords an admin can use.

@Sebastian-Roth Thank you for finding and fixing the issue.
@Greg-Plamondon Thanks for reporting. This fix is also set for 1.6 now too.

Awesome job everybody!

Thank you,

I found and believe I may have fixed the issue. It was actually pretty simple. The error was coming from the unpacking of information.

Hopefully it helps. Just repull the dev-branch and install and all should be back to normal.

I’m really confused by all of this.

Your Image definition displays as /images/05_09_2019_si_essa, but the warning message from the machine you’re having issues with is displaying /images/28_10_2019_si/ as the image location.

Too me, this seems like the host you’re imaging has a different image assigned to it.

So the setup per redhat documentation:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options

In particular, remove the // as the installer documentation shows it’s not to be set with nfs://

inst.repo=nfs:${fog-ip}:/images/os/centos7-dvd

@rockinhc At one time, maybe the nfs:// worked fine, but it’s since been deprecated and as a part of that, i imagine when @george1421 created that article, the OS version wasn’t at the version it is now. Even though it’s still CentOS 7, its incremental upgrades may have removed the deprecated options as well.

On Ubuntu 18.04 it’s mariadb-server I think

@dsoden @Sebastian-Roth @george1421

Please provide the error log from : /var/log/php-fpm/www-error.log

This will provide the error causing your White Screen.

The issue with CentOS 8 is being addressed, but we need information.

You’re right that opensource works when it works, and believe me, we want to help and get this fixed.

Changing the hostname, for fog, does not change the hostname for the machine. This is more related to updating the SSL certificates based on the DNS Server.

The installer tries to do everything it can for you, but there are areas we try not to change, such as the physical machine hostname as there could be any number of reasons this is setup as such.

Can you explain how it’s things are worse?

I want to help, and I’m 100% sure we can get this fixed and running for you. I just need information to be able to do that. I actually have a CentOS 8 server running for testing at work.

No amount of bickering, backtalk, or anything (from anyone) is going to help that.

@Keating178 The Invalid Storage Group error you were seeing should be fixed if you can upgrade to the latest within the dev-branch from GIT.

Hopefully this will fix the issue you were seeing too.