@Tom-Elliott Hey so did a lot of verifying and no one changed it but there WAS a filesystem issue on the /images drive (due to storage failure)

So now /images is back and it can read images off the mount but I get ftp_put() -> Could not create file., Host: xxxx, Username: fogproject

However theres is plenty of space on the /images volume and its mapped and works for regular file operations

All passwords updated, ftp storage, fogproject user, and the credentials are updated credentials in file for ftp.

Hi I am facing a block due to this error I am receiving after captures on our new fog server (migrated from debian to rocky)

bzImage kernel downloads are No problem since I set the tftp password.

Can anyone please tell me why it is logging into FTP at the end of a capture, after it captures over 120GB… Strange but I’d like to understand!

Original post

/etc/pam.d/vsftpd looks fine

#%PAM-1.0
session    optional     pam_keyinit.so    force revoke
auth       required     pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed
auth       required     pam_shells.so
auth       include      password-auth
account    include      password-auth
session    required     pam_loginuid.so
session    include      password-auth

ftpusers file:

# Users that are not allowed to login via ftp
root
bin
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
nobody

I migrated from old fog server. Can’t figure out where I should look for this fix.

Whether I downloaded a bzImage (via fog gui) or capture a new image, I got an ftp credential kind of error.

So I tried passwd fogproject
and set that, then updated the tftp password… so now bzImage kernels upgrade works perfectly.

However, once captured the image is failing to copy:

Great. bzImage 6.1.89 fixed it. Will test newer ones to see where it breaks.

@Scraggly8046 I have this same problem on our new fog server. I made sure the storage was set to master node.

I keep trying to find something about initrd or this message in /var/www/html/fog/service/ipxe/

but theres no reference.

@sebastian-roth OK thanks, we’re on Latest from 25.07.2021, so we’ll update and try. Thank you for your time. Fog really is amazing software and saved us big time!!

@sebastian-roth Hi thanks!

Read a bit on here:
https://forums.fogproject.org/topic/14822/nvme-madness/25?lang=en-US&page=2
and tried to get the file listed in one of your posts in that thread:
https://fogproject.org/inits/init-disk-size.xz
but the link is dead. Not sure if thats critical or not?

We ran blockdev --getsize64 /dev/nmveblabla
and got this value:
500107862016

We put the drive size in bytes (above) into the “Host Primary disk” field.

On boot after ipxe start, it says “Failed to read back partitions”
and “Args Passed: 500107862016”
Then it reboots.

Is it possible that blockdev --getsize64 is outputting a slightly incorrect number so that it wouldn’t work?

Hi I’m writing to some nvme systems. They have two nvme’s each.

We remove the secondary 250GB drive from the boot order and just left the 400s in right after IBM CL PXE boot option. So only two boot options… not that that would really help I guess.
There are no hard drive BBS options in this BIOS. Dont know if that helps anything.

The deploy keeps going on the wrong drives sometimes!

Do you know how we can force it to deploy to a particular drive?