@Sebastian-Roth I totally understand why you would not want that in the official release 
But I think that this really sounds like a great solution for my case! I will test it as soon as possible:)
Something I need to be careful about regarding the git FOS version? When I use FOG 1.5.9 the latest master branch is ok I guess?
Best, Markus
Hello FOG Team,
I am using the postdownload scripts a lot after our ubuntu installations for hostname change, setting up fixed ips, adding the machine to the AD and very basic settings setup.
Now we would like to use those scripts on already imaged machines to update those as well after imaging.
So my thought was to create a git repository containing the scripts and either the postdownload script would pull the latest code and run it or we can pull it and run it manually.
Do you have an idea how to make git work within FOS in case it is possible?
My alternative idea would be to make the git repository available via nfs and on the FOG server install a cronjob updating the repo every 5 minutes or so. But I don’t really like that workaround since the update frequency is quite low
I am also open for alternatives
Best,
Markus
@Sebastian-Roth I had the chance to test things a bit earlier and it works now.
It was a bit irritating though:
When logging into the Debug mode and run:
ethtool enp7s0 <- Name of the network interface
It shows that the current WoL mode is g, which means wake on magic package.
But when shutting down the PC WoL is not working.
However, when I again manually set the WoL function via ethtool:
ethtool -s enp7s0 wol g
It is working after a shutdown!!!
Hence my solution was to edit the /images/dev/postinitscripts/fog.postinit to rerun the WoL assignment at the beginning of any task:
#!/bin/bash
## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post init scripts are
#. ${postinitpath}<SCRIPTNAME>
echo ''
for interface_name in /sys/class/net/*
do
echo "Setting WoL for interface: $(basename ${interface_name})"
ethtool -s $(basename ${interface_name}) wol g
done
This seems to work great and no matter which task I deploy the Laptop is able to WoL afterwards without an issue
Thank you for pushing me in the right direction 
If you think that this is not the most optimal solution (e.g., it should work out of the box since ethtool shows the correct state of the network interface from the beginning), I am also willing to look deeper into the problem to fix this issue for future releases.
Best,
Markus
@Sebastian-Roth Sorry for that question, it turned out that I was just too impatient and did not wait long enough for the reboot to happen…
Rebooting works great now
On monday I will provide a short feedback if the wake-on-lan function is working properly
Have a great weekend!
Best,
Markus
@Sebastian-Roth I will definitely look into that on Monday, thank you very much
It would be amazing if that worked!
For the next steps( assuming this will work, but I am quite confident 
) :
Do you think it is possible to chain the tasks:
Schedule with PowerManagement Reboot Next to Schuedule with shutdown or create a New Task FullWipe - Reboot?Best,
Markus
Hello FOG Team,
We have 31 identical laptops which are handed out to different customers on a regular basis with different images based on the situation. We have a laptop storage and synchronization case which keeps the Laptops connected to the network and electricity.
I would love to achieve the following scenario:
While steps 1 to 3 are totally fine, I have the following problem with step 4 and 5:
I came up with several ideas how this could be achieved using TaskTypeEdit plugin, but I am not sure which would be the easiest from the implementation point of view. (Ideally the “Coming home” task can only be performed on specific host names, I guess this might be possible via postinitscripts?)
I tried to start with the Tasktypeedit, but unfortunately I am kind of lost in how to set one up.
I tried to look at existing tasks to copy the syntax and play around with it, but all Tasktypeedit entries are empty except for Name and Description, even though they show content in the overview (At least Kernel Args):
Do you think it is possible to go with either 1 or 2?
I am also open for alternative suggestions that could achieve my goal
FOG server version: 1.5.9
Hello @sebastian-roth ,
So far I did not encounter any problems imaging and deploying resizable BTRFS images
However, I “only” tested simple examples, i.e., one SSD with EFI, BTRFS, SWAP partitioning.
But no problems with this setup.
However, more complex examples will follow soon and I will come back to you in case I encounter some problems.
@Tom-Elliott I have to thank you for the fast response
I will keep the modifications intact for now and when I encounter problems using it I will come back to you 
Hello everybody,
I needed to get myself into the FOS environment yesterday, BUT it works now (At least for my usecase )
Are you using a FOS Linux USB boot drive? I would expect to only see the “Unknown request type :: Null” when booted from a USB stick into FOS Linux without having a corresponding task scheduled on the FOG server. I also noticed that your kernel parameters are incomplete for a capture or deploy (which would also lead to that error message).
This happened because I used the normal Debug task and not the Capture - Debug task.
Using the Caputer - Debug made things work as you described them
@Tom-Elliott
I needed to make some minor changes to your suggested changes, but it was amazingly helpful to know which parts to look at
funcs.sh (based on what you send me):
--- funcs.sh_ori 2021-02-10 13:25:08.000000000 +0100
+++ funcs.sh 2021-02-11 09:08:31.660652070 +0100
@@ -255,15 +255,15 @@
fi
echo "Done"
;;
esac
;;
- extfs)
+ btrfs)
# Based on info from @mstabrin on forums.fogproject.org
if [[ ! -d /tmp/btrfs ]]; then
mkdir /tmp/btrfs >>/tmp/btfrslog.txt 2>&1
- if [[$? -gt 0 ]]; then
+ if [[ $? -gt 0 ]]; then
echo "Failed"
debugPause
handleError "Could not create /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*"
fi
fi
@@ -625,11 +625,11 @@
btrfs)
# Based on info from @mstabrin on forums.fogproject.org
# https://forums.fogproject.org/topic/15159/btrfs-postdownloadscript/3
if [[ ! -d /tmp/btrfs ]]; then
mkdir /tmp/btrfs >>/tmp/btfrslog.txt 2>&1
- if [[$? -gt 0 ]]; then
+ if [[ $? -gt 0 ]]; then
echo "Failed"
debugPause
handleError "Could not create /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*"
fi
fi
@@ -638,16 +638,18 @@
echo "Failed"
debugPause
handleError "Could not mount $part to /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*"
fi
local free_size_original=$(btrfs filesystem usage -b /tmp/btrfs | grep unallocated | grep -Eo '[0-9]+')
- local mult_val=0.95
- local free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l)
- while ! btrfs filesystem resize -${free_size} /tmp/btrfs; do
- [[ ${mult_val} -le 0 ]] && break || mult_val=$(${mult_val} - 0.05)
- free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l)
+ local fsize_pct=$(calculate_float "${percent}/100")
+ local mult_val=$(calculate_float "1-${fsize_pct}")
+ local free_size=$(calculate "${mult_val}*${free_size_original}")
+ while ! btrfs filesystem resize -${free_size} /tmp/btrfs >>/tmp/btrfslog.txt 2>&1; do
+ [[ $(echo "${mult_val} <= 0" | bc -l) -gt 0 ]] && break || mult_val=$(calculate_float "${mult_val}-0.05")
+ free_size=$(calculate "${mult_val}*${free_size_original}")
done
+ umount /tmp/btrfs >>/tmp/btrfslog.txt 2>&1
;;
*)
echo " * Not shrinking ($part $fstype)"
;;
esac
@@ -2421,5 +2423,8 @@
}
# Calculates information
calculate() {
echo $(awk 'BEGIN{printf "%.0f\n", '$*'}')
}
+calculate_float() {
+ echo $(awk 'BEGIN{printf "%f\n", '$*'}')
+}
Small changelog:
calculate_float function to make the float calculations workcalculate and calculate_float instead of my suggested bc -lpercent value as possible. Otherwise the mechanism would break if the percent value is large.fog.sh (based on what you send me):
--- fog.upload_ori 2021-02-10 13:22:20.000000000 +0100
+++ fog.upload 2021-02-11 08:44:34.415100613 +0100
@@ -42,11 +42,12 @@
part_number=0
for part in $parts; do
fsTypeSetting "$part"
getPartitionNumber "$part"
case $fstype in
- ntfs|extfs)
+ ntfs|extfs|btrfs)
+ #ntfs|extfs)
continue
;;
*)
fixed_size_partitions="$fixed_size_partitions:$part_number"
;;
Thank you for all the help
If you need more information from me, feel free to ask
Hello @Sebastian-Roth ,
Populating /dev using udev: udevd[3160]: failed to execute ‘/lib/udev/${exec_prefix}/bin/udevadm’ ‘${exec_prefix}/bin/udevadm trigger -s block -p ID_BTRFS_READY=0’: No such file or directory.
I realised that there are similiar udev related messages in the logs of our VMs and I checked the other VMs and this seems to be a vmware related issue but should not cause too much trouble
Feb 10 08:22:40 fog-server2021 multipathd[745]: sda: add missing path
Feb 10 08:22:40 fog-server2021 multipathd[745]: sda: failed to get udev uid: Invalid argument
Feb 10 08:22:40 fog-server2021 multipathd[745]: sda: failed to get sysfs uid: Invalid argument
Feb 10 08:22:40 fog-server2021 multipathd[745]: sda: failed to get sgio uid: No such file or directory
Maybe it is related?
Regarding while ! btrfs filesystem resize ...:
My reasoning was simply based on the assumption that it happens more often that the unallocated value is not too far away from the truth than the other way around.
Therefore, it would require less steps to reduce the value of provided unallocated free space to a value that it works, than incrementally decreasing the overall free space until it no longer works, i.e., I am asking for: do you have 4GB free? no? Do you have 3 GB free? instead of: do you still have 200MB free? yes? do you still have 200 MB free? As suggested in the post.
While the latter method ensures that you really shrink the partition to its minimum (with a 200MB margin in this case) for my Ubuntu golden image with 5GB occupied on an at least 50GB hard drive I thought that even 10GB occupied should be enough for imaging (and later deployment on other at least 50GB hard drives) since it is expanded anyway during deployment.
As @Tom-Elliott said, shrinking is usually not what btrfs is good at due to fragmentation of snapshots in the images as far as I know. Therefore, I fear that an incremental search is the way to go in this case and a loop unavoidable.
But of course it makes sense to optimise the space usage since 95% of a huge drive can of course be larger than the total capacity of a small one.
I did not know about the global CAPTURERESIZEPCT value though and that makes things more consistent
So we should be able to refine the method once things are working properly from the shrink / expand perspective to optimise the workflow
@Tom-Elliott Thank you for the coding, I will give it a try now fingers crossed
@Tom-Elliott Thank you for this amazing information I will directly try it tomorrow!
Regarding the 95%: Yes it seems that when I used 100% it could not resize it. 95% seemed to work in my case though. Possibly due to some overhead when the data is fragmented on the drive. This incremental test to resize was recommended in the post I linked.
Looking forward to work with you on the topic
@george1421 I asked for a debug task on the machine and it is booting into it.
I am using a virtual machine from vmware, maybe that is the reason for the missing information?
Ok at least I figures out where my problem comes from by reading the code:
https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload#L62
So btrfs is not yet enabled for possible resizing.
I will see if I can modify the FOS to see what is going on
Hello @Sebastian-Roth and @george1421 ,
Thank you for all the information!
I am using FOG version 1.5.9.
Before I did any further testing I resolved my partition mess:
The allocation of the discs sectors was actually in the correct order, just the naming was messed up by a random allocation order during installation.
sda1 - EFI
sda2 - btrfs
sda3 - swap
However I still get a similar error with - No resizable partitions found):
(I looked at a lot of related threads and those people also posted screenshots of their problems and solutions. However, most of them are unavailable nowadays and therefore the thread not informative anymore. Is posting a screenshot here actually the best method in this case or do you prefer another solution?)
So I played around with btrfs resizing and came up with the following inside of the debug mode based on https://unix.stackexchange.com/questions/424758/resize-btrfs-filesystem-to-the-minimum-size-in-a-single-step
mount /dev/sda2 /mnt/bt
free_size_original=$(btrfs filesystem usage -b /mnt/bt | grep unallocated | grep -Eo '[0-9]+')
mult_val=0.95
free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l)
while ! btrfs filesystem resize -${free_size} /mnt/bt
do
if [[ ${mult_val} -le 0 ]]
then
break
else
mult_val=$(${mult_val} - 0.05)
fi
free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l)
done
To bring it back to full size it only needs a:
btrfs filesystem resize max /mnt/bt
I guess the tricky part now is to allocate the correct partition sizes after the shrink and before the max.
@george1421 I tried to use fthe fog command within the debug mode but only got:
And the next enter sends me back to the command line.
Best,
Markus
Hello @george1421 ,
Thank you for answering me
When I move the Image Type to
Multiple Partition Image - Single Disk (Not resizable) - (2)
The imaging is starting and I am also able to successfully deploy the image to another machine…
I have the following partition setup:
sda 2 - 500 MB EFI
sda 3 - 44.5 GB btrfs
sda 1 - 5 GB swap
I just saw an error message appear in the (very fast) scrollthrough of the imaging process.
Populating /dev using udev: udevd[3160]: failed to execute '/lib/udev/${exec_prefix}/bin/udevadm' '${exec_prefix}/bin/udevadm trigger -s block -p ID_BTRFS_READY=0': No such file or directory.
Is there a way to have a look at the complete log?
It is scrolling very very fast :S
Hello FOG Team,
We are working a lot with the btrfs file system and I found this thread from 2015
https://forums.fogproject.org/topic/5670/btrfs-support/21
It seems that imaging a btrfs size with the resizable option is still not possible. (At least I still get an error saying:
Capture error Windows/Linux Partition Count Fail
)
However, I was wondering if there is some knowledge base from the last years that came up with a workaround.
I thought about something like shrinking the btrfs partition manually before imaging and expanding it with the help of postdownloadscripts on the client system.
Even though I am not sure how one would tackle this ^^
Any help is highly appreciated
Best,
Markus
Hello @george1421 ,
I looked into the error message and found an actual solution here: https://dnsmasq-discuss.thekelleys.org.narkive.com/3JlGMO6e/dhcp-proxy-problem
I needed to specify the dhcp-range for both subnets:
So instead of using:
dhcp-range=141.5.200.57,proxy
in the /etc/dnsmasq.d/ltsp.conf, I added the second subnet with the respective netmasks:
dhcp-range=141.5.200.255,proxy,255.255.240.0
dhcp-range=10.65.0.255,proxy,255.255.252.0
and everything seems to work now
Thank you so much for the help!
Hello @george1421 ,
The /var/log/syslog actually seems to show some information about the rejected request!
Log of the failing case:
Feb 3 10:02:01 fog-server2021 dnsmasq-dhcp[124691]: no address range available for DHCP request via 10.65.0.6
Feb 3 10:02:04 fog-server2021 dnsmasq-dhcp[124691]: message repeated 2 times: [ no address range available for DHCP request via 10.65.0.6]
Log of the working case:
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 available DHCP subnet: 141.5.200.57/255.255.240.0
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 vendor class: PXEClient:Arch:00000:UNDI:002001
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 user class: iPXE
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 PXE(ens160) 52:54:00:fb:96:27 proxy
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 tags: BIOS, ens160
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 bootfile name: undionly.kpxe
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 next server: 141.5.200.57
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 broadcast response
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size: 1 option: 53 message-type 2
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size: 4 option: 54 server-identifier 141.5.200.57
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size: 17 option: 97 client-machine-id 00:21:d0:93:2e:ac:07:9d:42:aa:2f:98:3c:ba...
Feb 3 09:53:52 fog-server2021 dnsmasq-dhcp[124691]: 3153480460 sent size: 50 option: 43 vendor-encap 06:01:03:08:07:80:00:01:8d:05:c8:39:09:0e...
So it seems that there is a problem with the provided (or actually not provided) DHCP address range.
Hello @george1421,
We checked the the DHCP relay and it seems like we did setup this correclty.
We also seem to receive the DISCOVER at the server, but somehow the proxyDHCP is refusing to answer with an offer.
I uploaded the tcpdump suggested in the link you sent me to OwnCloud for the working and not working case.
Let me know when you need more information and thanks a lot for looking at the case
Alright, I will provide you tomorrow with further information.
Another question:
Since the client and the FOG server are not in the same subnet, do you also need the tcpdump from the client PC during the time of the same PXE boot process?