Posts made by Tom Elliott

@MarkG So that leaves me with a few notes already:

1. Need a storage for global arm Kernel and Init
2. Need to associate architecture to appropriate kernel/init.
3. Later we need to get kernel/init actually loading/booting?

@Fog_Newb

Manually moving a directory (which couldn’t possibly fit on vda) from /images/dev (vdc) to /images (vdb) caused the virtual disk size on vdb to increase. IMHO, it seems clear the directory was initially stored on vdc. Am I wrong in assuming this confirms that the mounts are correctly configured and functioning?

Yes. vdb is /images, so moving a file from /images/dev (vdc) to /images (vdb) should cause the disk to increase on vdb? The sice on vdc wouldn’t decrease but the amount of usable space off vdc should be increased by the amount of the file that was moved to now vdb?

That’s what I’m understanding here. I don’t know if this means there is an issue or if this is working as intended, but it seems like it is?

@adam1972 With the task in debug now, that you’ve done the e2fsck:
Now run fog from the blue prompt and it should run though the normal process just pausing as it goes along.

@Fog_Newb You seem to have the same uuid for both vdb and vdc

@Fog_Newb I’m not sure I follow th eproblem.

Your directory structure looks correct to me?

Now, there is a piece to be thinking of first:

Your mounts seem to be correct and even a df -h seems to show up properly (lsblk if you want use that which is displayed)

The only way I could think of how this should occur.

You should:

1. Unmount vdc1
2. move vdb’s dev folder to your /root/folder for backup purposes temporarily (completely remove it from the /images
3. create a new dev folder in your /images
4. Mount vdc1 to /images/dev
5. Copy back the items in /root/dev/ to the new /images/dev
6. Make sure the requisite .mntcheck file exists touch /images/.mntcheck; touch /images/dev/.mntcheck
7. Change the ownership back to chown -R fogproject:fogproject /images; chmod 775 -R /images

This should allow your system to work without issues.

Your FSTAB needs to have the mount set correctly too so that dev gets mounted appropriately on subsequent boots which I presume is already happening?

@Fog_Newb did you make sure the /images/dev is owned by fogproject:fogproject user and that there’s the ever useful (needed) .mntcheck file?

@adam1972 you should run the e2fsck command FROM the blue window

and you should reschedule your task, but with the debug option.

@LLamaPie Based on what I see of the issue is it possible the server is this service too?
https://sarperavci.com/Froxlor-Authenticated-RCE/

I don’t know what Froxlor is, but the lol.php and .systmd that you saw seems to point that somebody was trying to do some bitcoin mining possibly?

@george1421 Running Fog Version: 1.5.10.15

@LLamaPie If you can get the backup db and images of course. I don’t think they’re affected, but whatever is relaying is using a ton of CPU. so at least not a full startover I think.

@LLamaPie I am pretty sure this isn’t something FOG is doing. I don’t know of a command named .systmd and seems questionable at best. The fact that it’s being used and spawned by www-data is real hmmm if you ask me.

@adam1972 have you tried running this capture in debug mode and attempt the e2fsck -f /dev/sda2 as suggested?

@mentaluproar The error code you see is 2732 which is coming from the Domain controller. If your account is the one indeed being used, and isn’t locked, I don’t know what else to look into.

Basically 2732 is the code from MS, not from FOG.

@Fog_Newb Then I have no idea and apologize for not having much more to give you…

If i’m mistaken, however, the value of the UTC for the imagine time might just be exactly presented instead of transformed to local timings?

and you’re 100% certain your instance of FOG is using php8.3? I know that seems an odd question but if you restarted php-fpm and apache2 there should be 0 references as the instantiation of php is using the date.timezone.

@Fog_Newb Under debian there’s 2 points:

/etc/php/8.3/cli/php.ini and the apache2/php.ini I believe

@Fog_Newb /etc/php.ini’s date.timezone should be defined as well unfortunately.

@mentaluproar

Seems maybe the account is locked?

@AUTH-IT-Center Subree is updated to be properly listed as Subtree

@AUTH-IT-Center Roger and it is much appreciated