Posts made by danboid

Does FOG currently offer any support for restoring images onto specific disks when the target machine(s) have two or more internal (SATA/NVME) disks?

I think at the moment the user would have to disable or remove all of the drives from the machines being imaged with FOG except the disk they want the image to be restored to right? If they wanted to restore to the second or third disk.

The way I’d like to see this work is there would be a way to enter a preferred device name for the target disk or optionally the user would get presented with a list of disks on each machine before the restore starts so that the user would have to manually pick the disk they wish to restore the image to.

Thanks

PS I’ve got FOG running great on a £30 X96 Air TV box running Armbian with gigabit ethernet and a nippy internal eMMC disk etc that fits in your pocket. Its very cool!

Oh so you can already configure the udpcast max wait in the current stable release? That’s good news. I have closed my github ticket because it focused on adding the max wait timeout. I’m happy enough with it being a global setting, I don’t need to change it per task.

I didn’t know to look for this setting until raising this problem here. I have mostly stuck to FOGs presets every time I’ve used it up until now, I just up the max number of clients, update the FOG kernel and tweak the DHCP config if required.

There doesn’t seem to be a guide to setting up multicast tasks in the official docs? Am I missing it? If there is such a guide it should mention adjusting this setting to suit your situation first.

I have created a gh ticket for this feature request:

https://github.com/FOGProject/fogproject/issues/496

Thinking about it, if you’re manually booting 50/60 machines all with passwords, I think 20 minutes is cutting it a bit fine. 30 minutes seems much more doable for that size of task so I think I’d prefer to use a 1800 second timeout as default.

@george1421

Hi George

I would say 20 minutes / 1200 seconds would make a good default timeout, if you have a lab of 50 machines that don’t support WoL and you have to manually PXE boot every one and enter a BIOS password to use the boot menu. Notice I say default because I’d prefer that the timeout was configurable when you create the multicast task.

As you say, it would be best if those machines that don’t make the timeout would shut themselves down rather than reboot because this works out for the best if you are using WoL.

Do you want me to open a github ticket for this?

@george1421

Yes, being able to start multicast tasks with a timeout would do the trick. I’m surprised FOGs lack of support for a receive timeout hasn’t been raised until now.

@sebastian-roth

I woke up thinking about this today and I know one potential way we could mostly fix this problem.

If a big FOG multicast task fails then, unless the user has AMT or whatever the AMD equivalent of that might be, they have to manually turn off many computers before they can start the next FOG task. Therefore it would be handy if there was a way to shutdown FOG clients that have booted and started partclone so that they can be remotely powered down by just ticking a checkbox next to that machine in the FOG web UI’s task list then choosing a ‘Shutdown selected hosts’ option.

This feature would ideally work with Intel, AMD and ARM based clients so it wouldn’t rely upon Intel-specific AMT for example. It would use a FOG client service to perform the shutdown. It’s not quite a full fix for my original stated problem but it would mostly heal the pain of dealing with large failed FOG multicast tasks in a way that fits the current workflow. Does this sound viable?

I’ve had it happen a couple of times this week where I’ve started a FOG multicast task with up to 50 machines and then I won’t be able to get one or two machines to boot into FOG (or, as happened earlier, one machine started writing the image early for some unknown reason) and then I’ve been forced to stop all of the tasks and start over, rebooting all of the machines etc because FOG is waiting on one or two last machines to appear before it will start the multicast.

I have tried to cancel/remove individual machines from a multicast task but it seems to stop/remove all of the existing tasks. Is there a way to fix this situation and to get FOG to start a multicast task without cancelling all of the tasks and starting over?

I also seem to be having an issue with machines not changing their hostname to match what they’re known as to the FOG server. We’re using Windows 10 on the clients. I’ve installed the FOG client, set the address of the FOG server for the client and it has worked for most of the machines but not all. They’re all on the same network / switch but there are two types of PC with different network adapters if that could make a difference?

Oops!

Turns out I can delete groups OK. I suspect what was going on is I’d had a long and stressful day and the password it was autofilling that I was mindlessly accepting was wrong. Today I manually typed the password of the FOG user and it worked.

Please excuse my noise!

I’m running the latest git version of FOG with the latest FOG kernel (5.15) under Ubuntu 20.04 and I’m unable to delete FOG groups with its web UI. When I try, it prompts me for a username and password. I enter my fog user credentials (which are the same as Linux users, so there’s only one set of responses here) but then it fails to delete the group(s).

I did end up re-installing FOG on this machine because I wanted to try using a different IP/subnet than the one I used at first. I tried to fully remove my old old FOG install by dropping its DB, removing /opt/fog etc but maybe this error is caused by me re-installing FOG and not doing the best job of uninstalling it first? It seems to be working fine apart from not being able to delete groups.

I’m sure I’ve not had this problem with FOG before. Hopefully someone knows how to fix it without a complete re-install of the OS and FOG?

@george1421

Thanks George!

I had seen people talking about updating the kernel on here but I presumed they meant the FOG server kernel but now I realise that the FOG kernel is distinct from the kernel used by the FOG server. After updating the FOG kernel via the web UI FOG seems to be working on our new machines.

I’ve just had a look on the FOG wiki and I’m disappointed to see there is not a list of FOG (in)compatible PCI(e) network cards. We should create one, or maybe the inverse ie a list of network cards known NOT to work with FOG. Users could list which OS version(s) they know a certain chipset does (not) work with.

I suspect most PCI(e) and onboard NICs over a certain age will work but we just got 15 new desktop machines and their onboard NICs don’t work with FOG. It would be nice to know the NIC is FOG friendly if we’re buying 15+ so can anyone confirm that the Intel Gigabit PRO EXPI9301CTBLK 1000CT works with FOG?

Thanks

@george1421

Yeah that’s what I expected. Thanks for the quick reply!

First, why is there so little content on the FOG wiki FAQ page?

https://wiki.fogproject.org/wiki/index.php/FAQ

?

I think my question would be a good candidate for going on the FAQ page. If I have a sysprepped Windows 10 image took from a BIOS VM or physical machine, can I restore such an image onto a UEFI machine or can you only install BIOS images onto other BIOS machines?

Thanks

It seems it is possible to image mdadm/mdraid arrays using Clonezilla but you have to create the array manually to restore the image, if the array doesn’t already exist.

https://sourceforge.net/p/clonezilla/discussion/Clonezilla_live/thread/447b64e1f2/

Maybe I should’ve called it mdadm instead of mdraid?

Sorry, I thought I was being specific by calling it mdraid, is that not its name? Its the all software RAID built into the Linux kernel, as configurable by the Ubuntu server installer etc.

I have read it should be possible to capture and deploy Linux images using Linux software mdraid here:

https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

Has anyone successfully captured and restored a Linux mdraid RAID-10 array using FOG? I have only read discussion on here of people capturing RAID-1 arrays.

I have created a Windows VM under virt-manager/qemu and now I want the easiest/ most direct method to transfer this VM (after running sysprep on it) to my FOG server, which is on a different, isolated network.

I would imagine the easiest/ most direct method would be to boot something like systemrescuecd on my VM then use partclone to make an image of my VM onto a samba share, running on the same machine as qemu in my case. I should hopefully then be able to copy this image into the correct dir on my FOG server and get it deployed but I haven’t found instructions on exactly how to do this, specifically:

What partclone command should I use to image a single disk Windows 10 VM? Another thread on here suggests it would be something like:

partclone.ntfs -fsck-src-part -c -s $part -O $fifoname -N -f 1

I’m not sure what to use for $fifoname and then the real uncertain bit for me is what to do to get that imported into FOG correctly. I’m hoping it involves little more than registering a machine (without uploading an image) and then copying the partclone files into the correct dir?

Failing that, I’ll be using clonezilla to image my VM before restoring that onto a physical machine and then importing that into FOG the usual way.

Also, is it not possible to install the Windows FOG service without being connected to the same network as your FOG server? I tried all 4 of the Windows FOG service installers but they all gave the same error “Unable to install CA Certificate”

@george1421

Hi George!

Thanks for your feedback!

1. I think I made this pretty clear in the first couple of paragraphs but I could add a bit more to say “note this is not the easiest way to install FOG”. I explain the reason for doing it in a VM in the second paragraph:

“FOG and its required services (like DHCP and DNS servers) are things I don’t usually want to be running on my laptop or workstation which is why it’s useful to have FOG running inside of a VM so you can quickly fire it up as and when it’s needed.”

The guide is titled “Configuring a standalone FOG VM” the VM bit being key here.

2. Yes, I should definitely change it to use the git repo instead. Good suggestion.

3. Thanks - useful advice

4. Yes - that would be another good thing to highlight but I do mention the role of /images already

I’m happy to make these changes but unfortunately the current forum settings don’t allow you to edit posts an hour after you’ve posted them. I just tried to edit the first post but I was denied. Could we ditch this rule please, at least for this post?