Posts made by salted_cashews

@Sebastian-Roth I’m 100% positive it was captured using Zstd, the only thing I can think of is something we did on the image before capture or a network issue during.

@george1421 This is really interesting, is this why I’m able to almost-ssh into the box during an image/network boot?

@Junkhacker Thanks for the info!

@Junkhacker Oh I see, is FOS the preboot environment?

@Junkhacker

Am I reading this wrong? This is weirding me out. Is there a reason I don’t have a partclone log?

So I’ve set deployment tasks to run and they’ve been running for approximately 7hrs. The usual time is around 1hr.

I’ve observed that it keeps trying to deploy the same partition over and over again. The only thing that changed were the following settings under the Web GUI’s “Fog Settings”:
FOG_IMAGE_COMPRESSION_FORMAT_DEFAULT = PartClone Zstd
FOG_PIGZ_COMP = 19

The only thing that doesn’t make sense to me is all of our images are using that compression format and with a level of 19, so I don’t see why this would be a problem. Strangely, I was able to deploy 2 other images perfectly fine. Any ideas? Fog v 1.4.4.

I noticed it says look at /var/log/partclone.log but there doesn’t seem to be one.

@Sebastian-Roth Thanks!

@Sebastian-Roth Oh sounds promising. Is there an approximate ETA/date? I’m in no rush but we’re still on 1.4.4 and we just feel it’s time.

@george1421 I see, thanks!

I’ve read the following:
link1 link2 link3 link4 link5 link6

And I believe all I must do is install git at this point? Is that still the most accurate install guide? Is it possible to install without Git? Is there anything that I should look out for in doing this upgrade other than the stuff stated in the links posted? I’ll make backups of fog via the shell script, snapshot the vm, and backup the dhcpd.conf file (as it is not managed by FoG). Is there anything else?

Thanks as always!

@Sebastian-Roth Well I feel silly, I should’ve done that to start. Apologies for the stupid question, thanks and once backups are done updates are next on the list.

The command I ran is displayed at the bottom. The target is a NAS device mounted via the command “sudo mount -t cifs //IPadd/sharename /fogbackups/ -o username=name”. The mount point was created using “sudo mkdir /fogbackups/”.

What I’m trying to do is a full backup of the FOG server, while it still provides DHCP (via isc) to a network location using this script.

@Tom-Elliott @Sebastian-Roth Understood, thanks again guys!

@Sebastian-Roth

The client has a SSH server instance running. But you can’t connect to it without setting a password beforehand. So for debugging issues you could schedule a task as debug, start up the client, hit ENTER twice to get to the shell and then set root password and login via SSH to do fancy stuff.

Interesting, I’ve used debug mode before and I love it, I hadn’t thought about trying this though this could prove useful.

Surely old images that were not fully captured and moved to their destination path. But the name of the dir is not random. It’s the MAC address (without colons) of the client you captured the image from. Should be save to delete as long as there is no task running. If you run another capture for the same host this directory will be deleted (and reused) anyway.

Ah! That makes sense and I hadn’t thought about the MAC address.

You might think about updating at some point. As long as things are fine for you with 1.4.4 that’s ok. But if you hope to see something fixed you need to update to the latest version as we don’t backport any changes. Just so you know.

Indeed! We’ve been working on backups and updates but because our FOG server is used so frequently we’ve just not had the downtime available. I’ve ran tests on the newest FOG version, does it come with the option to revert to the old GUI? I know there’s an option in 1.4.4 to change the web interface style.

The task is removed from the Active Tasks GUI page, but if I reschedule another task or go to the host’s physically connected display it seems as if the task continues to run. Is there a way to prevent this from happening further, or is simply hard-rebooting the host the only option? Strangely a network scan reveals it’s accessible via SSH and I can get a login prompt when trying to connect over port 22 via SSH. What’s this about?

Also, within the /images/dev/ directory I find what seem to be remnants of old/cancelled tasks. They usually have a random string of characters like so: “/images/dev/b8ac6f942356/”. Are these safe to delete? I understand this is a sort of temporary proxy directory for image capture before completion and transfer to the /images/image-name/ directory.

The FOG version in use is 1.4.4, I apologize for the flurry of questions but appreciate the time taken to answer them.

@Wayne-Workman Interesting, I found our problem was the initial setup of the Ubuntu server that hosts FOG was set to allow auto-updates. This will come in handy for future installs, thanks!

@Wayne-Workman How so?

@Wayne-Workman Is this one any different or is it basically a synonym command?

@Sebastian-Roth Oh that’s delightfully simple, thanks!

@Sebastian-Roth So far I’ve tried a fresh Ubuntu 16.04 install, and I’ve even used LVM and just captured as non-resizable with 0 issues. Now while this wasn’t Ubuntu 18, I did notice the machine I had the issue on originally is unable to install this OS due to something being wrong with the “file system” on the disk which for some odd reason it couldn’t format, delete, or write to. It is an SSD, and I couldn’t recreate this issue on any other box. I ran various SSD diagnostics with no errors being found so I’m stumped. I haven’t gotten to try with the exact iso posted above just yet - doing production stuff lately since I’m alone in IT currently.