@ricounet Ok, so you can delete that one entry from the DB:

shell> mysql -u root -p Password: ... mysql> use fog; ... mysql> DELETE FROM hosts WHERE hostID = 410; ...

@mlawhun0114 As mentioned in the topic posted by @rockinhc you need to edit /tftpboot/default.ipxe on your FOG server. Make sure to check the settings file /opt/fog/.fogsettings as well. This is used if you re-run the FOG installer at some point.

@george1421 Thank you for the patience.

you are a good person 🙂

thanks for that, im not sure how i missed that, ha.

Thanks for that, i have migrated to the new server now, all groups, hosts and images moved over successfully.

I got below error during installation:

Stopping web service………………………………….Failed!

I installed apache/httpd service then re-run installation and everything was perfect.

If anyone gets error during apache/httpd installation then open epel.repo from below location and change https –> http in mirrorlist link.
vi /etc/yum.repos.d/epel.repo

Hope this helps everyone.

Since last week, I followed this topic

https://forums.fogproject.org/topic/13887/blank-install-page/36

Installed is now completed

Thank you for your help

@vanopy For reference here is the guidance on setting up a 2012 server for dynamic support for both bios and uefi systems: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

I would make sure you have filters for both type 0007 and 0009 uefi systems (bc and x64) because both are common in environments.

The tftp logs of course show that a bios file was requested, so that may be why the vm failed to pxe boot.

Marking as solved as we have addressed the size-reset to zero issue on client checkin already in dev-branch: https://github.com/FOGProject/fogproject/commit/9ff877627de44309f9eef8b07587efdb918d3d1e

@dsoden said in Blank Install Page:

firewall still not being detected after detection of SELinux and prompt to disable, which later causes problems non locally.

I ran into the same issue the second time I setup a centos 8 server, but I know from the fog install prerequisites that selinux needs to be set to permissive and firewalld needs to be stopped before FOG is installed. So when it got to that point in the installer I noted it, but it continued without complaints. When I have time I was going to reverse engineer why the firewall’s state wasn’t being detected in centos 8, but decided to spend my weekend not hovering around my computer (til now).

@Gilberto-Ferraz said in Upload Image From HDD 500GB to SSD 120GB:

will try to recover the system and install new centos.

First make sure you get this all back to running on Ubuntu. Don’t try to move to CentOS in a rush. There are more things that can go wrong when moving to a new Linux OS.

Solution was

filename "undionly.kpxe"; next-server 10.33.97.251;

VERSUS

filename undionly.kpxe; next-server 10.33.97.251;

@george1421 After fully patching the workstation it still run compatibility ok. I didn’t try imaging before but I completed imaging the VM after the update and it imaged but threw a strange error:
pc_img_err.png

It almost looks like a core dump but the system kept imaging. I have noticed several times that in the percent complete line it will post a message about balloon request will be partially <something>. And then several seconds later balloon floor reached. On both esxi and now on hyper-v. But I think that is a topic for a different thread and a different time.

Edit: Irrelevant follow up. I noticed that 4.19.48 was listed on the screen shot so I confirmed the version of bzImage and it was indeed 4.19.48. I put back 4.19.64 (which was shipped with fog 1.5.7 and that CPU core dump did not come back on a system reimage. So its possible the older bzImage had issues that were resolved in 4.19.64.

@viggo While you are right that my answer might not be of much help I don’t see why I should put in effort to help you sort this issue on a Linux OS FOG simply doesn’t support anymore.

@rockinhc OK thank you. We’ll just move forward. I’ll update the tutorial for LM 19.2 and we’ll call it all good then. Thank you for confirming.

@Adriano-Rocha said in I have this problem can someone help me?:

put the redimioneaval

I’m sorry I don’t understand that word. So lets try again. When you created the image definition for that 500GB image, did you pick the option for “single disk resizable”? FOG will compress the image onto the fog server even if you selected “single disk non-resizable” to save space on the fog server. We need to understand how the image was captured.

@rockinhc The tutorial has been updated to reflect the currently in use kernel options. Thank you for the feedback.

@dylan123 Reading a bit more about the apparmor stuff I found this: https://stackoverflow.com/a/49583958

I read in another SO thread comment that the apparmor=“DENIED” message probably isn’t the reason that MySQL (or in my case MariaDB) wasn’t starting, as it’s only a warning.

Confirmed by this bug report:

On the affected system, there was no noticeable impact (yet?) other than the denials, so I’d say it’s low impact.

Spinning up a VM with Ubuntu 18.04 I saw that quite true it has those log messages in /var/log/syslog on my VM as well but the DB is running perfectly fine. So just for the records: Those apparmor=“DENIED” message don’t cause an impact on the DB and can be ignored.

Check all the information George and Daniel posted as well as my suggestion on the mysql logs.

Thanks guys! You all have been so helpful. I figured out that you don’t have to select the FOG Boot screen to select the Hard drive boot. It goes right into pxe.

It’s cut our deploy time from an 1 hour and 15 - 30 minutes to like 10 minutes.

If it becomes a further issue I’ll keep the post deploy scripts in mind.

Thanks again!

Found them, yes transferring them worked but also resetting encryption data also worked.