@FoSTerCyber This issue only happens after upgrading, not on fresh installs it seems.

@mlerch so just a hint here: the fog settings are kept in /opt/fog/.fogsettings file. That is where fog knows what the user account and password should be.

Worked with @keith75140 and we seem to have gotten things fully operational.

While it is true the OP used the fog user as an admin user, we were able to get things working properly. PXE Booting is now working as well after working with the network team to get things setup.

We had a couple of issues but we were able to work around them.

You’ve tried “EFI Exit” with rEFInd? This really doesn’t seem to be a problem with LVM or disk information, directly.

It really really feels like it’s trying to boot across incompatible types.

Please try network booting using EFI by enabling the Network Stack and PXE Network Stack. Then try setting the “EFI Exit” to rEFInd.

This will mean you need to use one of the EFI labeled boot files, but this can typically be automated.

@kleanthis Well, you have to write the scripts, so if they’re good to go, then yes.

@Cmid Yep.

Ubuntu decided that only “root” users can login with a password defined. You can’t even open mysql via terminal without sudo if there is no password set.

We can close this. Moving on.

@PerC I get this when deploying Windows images in brand new Hard Drivers, then I boot with a Live Linux and tell where to find the bootable partition.

I’m checking it out right now. will let you know.

Thanks!

@Tom-Elliott

response was
Query OK, 0 rows affected (0.00 sec)

It worked! Big thanks! I’m up and running in the browser again.

Thank you. that got me working.

@Skosvin Just for clarity you installed dnsmasq on your FOG server, used the configuration file as I posted, then commented out the port=0 as Wayne posted?

I’m just trying to close the loop here in case someone else has the same issue as you in the future.

@Junkhacker Thanks that worked.

@SuperMajestic Yes please.

I believe the issue was the start point was trying to be shifted around.

The resizing, at least for linux systems, has to try to get the data first. We have to see how far it can be shrunk.

@Artur I may be wrong, but I believe these use the rpcbind system. Is this set to enabled?

Typically, on redhat, there are services that are indirectly running. Meaning when a request comes in the service “hears” it and hands out whatever is needed. So a systemctl -l status tftp dnsmasq will likely be a more accurate thing to be displayed here. I’m going to guess that the ‘inderect’ portion is just a means to tell rpcbind to open the ‘listeners’.

Was there a problem doing or anything or just something you noticed?

Fog can’t help you here, you’re going to have to manually do this.

Best way is to boot both systems with live-boot media, mount both local disks to something like /mnt and then scp the contents of each mounted partition over to the new box.

You’ll have to edit the new box’s /etc/fstab file to mount the partitions as ext4 instead of ext3

No guarantees that will work, but it’ll for sure get the files moved.

As long as whatever partition that has /boot on it is marked as bootable with fdisk then it ought to work.

You can find an installation guide for CentOS 7 here: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

The best practices is always to stay patched.

Keep it updated. If your FOG Server is in a VM, snapshot before OS & FOG Updates.

I say set the fix in logrotate configuration. This is the correct answer and should fix the problems.

As I understand realize resizing a few partitions is difficult? I try explain. If I manually partitioning drive and change default filesystem to ext4 for root, installer CentOS7 changes order of partitions. May be this is bug. But in some cases this feature will be strongly useful.

I have one more question. Trouble with wrong UUID deployed swap partition is not solved?