@SPaceSkillz1 Did you solve this yet?

@Chris-Whiteley My fault. The new inits use a larger root filesystem. Please go to the FOG web UI -> FOG Configuration -> FOG Settings -> FTP Server and increase KERNEL RAMDISK SIZE from 127000 to 275000.

@DeRo93 said in Database connection unavailable - Login incorrect on FTP and Ubuntu:

But maybe you can tell me if this happened because the Ubuntu Server did an Upgrade or something?

Probably yes. But you may check the update log in /var/log/apt/history.log…

@DeRo93 I think we need to clear up some things here first. In FOG we have a couple of different accounts that you should be aware of and not mix up.

• Web UI login: This is an account within the database. So the password is usually different to the one you login via FTP!
• FTP login: This is a local Linux user account (called fogproject since 1.5.6 and fog in prior versions). It’s meant to be a system service account and shouldn’t be used to login via shell or GUI at the machine.
• Database “login”: FOG needs to talk to the database and uses credentials for that as well. Those are usually behind the scenes and you shouldn’t need to bother about those. But in this case I guess we need to look into this as well.

But first let’s see if we can get access to the machine again.

When i open the Ubuntu FOG VM he is asking me for the FOG Login and Password.

Can you please take a picture of that on screen and post here so we get an idea.

@Landy_Dan The FOG CA was introduced to secure the connection between fog-client software and the FOG server. We use certificate based state of the art encryption for that. But you need to know that it is a self signed CA and not derived from an official authority.

Not sure if it’s wise (and even possible) to use that for your RADIUS project. Give it a try and see how far you get. Start by taking a look at all the certificate stuff in /opt/fog/snapins/ssl/ on your FOG server.

@Chris-Whiteley See the chat bubble in the top right corner…

@pdit So it’s probably something that changed in the Linux kernel that is causing this issue. I’d like to track this down but I don’t think I’ll find the time to do so in the next months.

You should be able to switch between different kernels to see which version first had the issue. Find all the different kernel versions in the FOG web UI or here: https://fogproject.org/kernels/

@pdit Ohhhh, just reading your other post I can imagine updating the kernel would break your networking for the E73 desktops again!! So please be careful.

@Chris-Whiteley More good news. Seems like it’s not as problematic a change as I had first thought it would be. So I managed to fix this and do some (hopefully) appropriate testing just now. New fixed init files are building at the moment and should be ready to test tomorrow (late evening here already).

Many thanks to you for posting this here. I really wonder why not many more people ran into this issue. As far as I understand it every system having NVMe drives (Linux device filenames /dev/nvme0n1pX) should run into this.

@cary1102 said in Network boot working but not loading up the FOG file:

Enabling legacy mode will fix this issue

But that’s not a nice solution I suppose, right?

From the picture you posted it looks like it properly loads the ipxe.efi file (prints size in Bytes) and just hangs when trying to execute it.

Which version of FOG do you use? We just updated the iPXE binaries for 1.5.6 and possibly there was a change in their code that might cause this.

First you can try other binaries. Change your DHCP config and point it to snponly.efi or snp.efi instead for UEFI machines. If that hangs as well you might try older binaries. You can download the one we shipped with 1.5.5 here: https://github.com/FOGProject/fogproject/raw/1.5.5/packages/tftp/ipxe.efi

@pdit This has been fixed already. You only need to download the latest init files (64 bit and 32 bit) and put those in /var/www/html/fog/service/ipxe/. I recommend to rename the original files instead of just overwriting them. Just in case you run into an issue with those.

You might need to update the kernel binaries as well but I am not exactly sure.

@tgidwani Looking at out code more closely I noticed that most of those ftp_... warnings are perfectly fine. FTP is not able to remove a directory that isn’t empty yet. So we do some kind of recursive delete which leads to print out all of the “ftp_delete” and “ftp_rmdir” messages which are not important. I’ll still remove those in the next release we get less confusion.

But the “ftp_rename” and “ftp_put” warnings make me think there is something wrong with your NFS shares. Just guessing here but let’s give it a try. Please run exportfs -v as root on your FOG server and post output here. As well take a picture of the Storage Node setting in the web UI and post a picture here.

@Chris-Whiteley Good news is that I am pretty close to know why this is causing trouble for you. Bad news is that we’ll need to fix the script that does the resizing and I might need a bit more time to make sure I don’t break things for other layouts.

@tgidwani Ahhh, I see, got that wrong, sorry. I will take a look at our code again to see if I can figure out what might be causing this.

Just to be sure, Do you still get the full list of exact same ftp_… messages in the log everytime even when SELinux is disabled/permissive?

@Chris-Whiteley Ok, this partition layout looks fine as well. In the pictures we see that it seems to try to expand the partitions and doesn’t hit any obvious error but the outcome is not what we expect. So we need to dive into this even more. Please add the following as Kernel Parameters to this hosts’ settings and run another debug deploy: isdebug=yes ismajordebug=1

When you get to the “Attempting to expand/file partitions” (that’s before the blue partclone screens) pay attention and take pictures again. It should give us more details this time.

@Chris-Whiteley I can’t imagine this being the exact same image as you posted the files contents from. The partition layout below tells us it’s a GPT layout with four partitions. The pictures on the other hand show a legacy MBR layout with just two partitions. So either there is something going terribly wrong in our scripts or you got the wrong files.

@tgidwani said in Failing to Update Database after capture of image is complete on the client:

I cleared all three error log files today

Don’t you get new log entries when doing a new capture? There is no possible way we can help you without getting more evidence on what exactly is causing this. Logs are usually the best way to figure this out.

@tgidwani Alright, FTP is not an issue I am fairly sure now. Seems like I was miss-lead by the messages we saw in the php-fpm log file. Those probably came from the time before you disabled SELinux… I reckon.

So do you still see it failing on database update at the end of the task?

Please check the log files again but this time only take a look at the last 10 lines: tail -10 /var/log/php-fpm/www-error.log

@tgidwani Seems like we need to work this out manually. Use a ftp command line utility (Windows or Linux) and connect to the FOG server using the credentials you see in /var/www/html/fog/lib/fog/config.class.php.

Try connecting, then create and rename a directory just to see if things work like expected:

shell> ftp 192.168.2.5
Connected to 192.168.2.5.
220 (vsFTPd 3.0.3)
Name (192.168.2.5:roth): fogproject
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> pwd
257 "/home/fogproject" is the current directory
ftp> cd /images/dev
250 Directory successfully changed.
ftp> mkdir test12345
257 "/images/dev/test12345" created
ftp> rename test12345 12345test
350 Ready for RNTO.
250 Rename successful.
ftp> rm 12345test
250 Remove directory operation successful.
ftp> quit
221 Goodbye.

@tgidwani said in Failing to Update Database after capture of image is complete on the client:

with CentOS 7

Why didn’t I see this any earlier?!??!

Please run command getenforce on your FOG server and post output here.

Sure you wanna read this: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7#Continue_pre-config