@jeremyvdv Spanning tree enables the ports to wait for a period of time between link up/link down before the switch will pass the information to the machine in case there’s a link connected back to itself on the switch.

This up/down time can be around 27 seconds in normal Spanning tree mode. This would explain why during the automated portion the device cannot get a link or IP, but once at the terminal and restarting the networking it will pick it up.

If your network is using spanning tree, if you can do so, disable it, or if not it’s best to use one of the Fast/Rapid stp methodologies as their up/down time is much more significantly reduced.

@ty900000 I just pushed another update, though it may be a little while before the artifacts are ready for testing.

I’m fairly sure the issue here has to be the FIFO. I’ve also gotten rid of the “Maybe check the fog server to ensure disk space is good to go” by providing the available disk space. It also adds the exact command that partclone is trying to use so we can see what’s going on.

2060 is just the case statement, so I don’t think it’s failing because of the case. I think it’s failing because the FIFO was still open. To combat this, I’ve added a 5 second wait to let the disk settle and release the information for the FIFO so we can remove it to recreate it later on.

@TOXYKILLER Here’s what I find for one of your IP’s (if this is you then cool, but still a bit on the “whoa wait a minute” side)

Source: whois.arin.net
IP Address: 11.101.149.115
Name: DODIIS
Handle: NET-11-0-0-0-1
Registration Date: 1/19/84
Range: 11.0.0.0-11.255.255.255
Org: DoD Network Information Center
Org Handle: DNIC
Address: 3990 E. Broad Street
City: Columbus
State/Province: OH
Postal Code: 43218
Country: United States

What does this mean?

Well DoD own’s the IP Space in its entirety of 11.X.X.X (Including 11.101.X.X).

@ty900000 The problem with using 114, is it’s missing an argument. So the Segfault is double’d due to -c/-a0 and not likely due to either of the arguments, but rather the fact partclone is segfaulting as it cannot determine file size, as it is literally commented out of the code. This means, a raw (imager) image file will not be generated at all. (/images/<imagename>/d1p<#ofparttion_to_be_cloned_in_imager_format>.img will be missing comletely.)

In my case the partition number was 2, and in yours it appears the partition number is 3.

I have created a fork of the partclone repository and implemented what I would think should address the issue by reimplementing the filesize display capabilities. As @Sebastian-Roth learned, simply uncommenting the line allowed partclone to work properly (as far as we could tell).

Until we patch the issue on our side (either by using our forked copy of the repository or directly implementing it as a part of the build process), this is still going to be a problem. I think we have a way to fix it, just haven’t had time to implement and have you (or anybody else who’d be willing) to test it.

@lkisser in regards here it almost sounds like there could be 2 hard drives on the 3620? If so chances are the drive that is set to boot still has windows 7 installed, and the other drive actually has the windows 10 image on it. This is possible but again we’re left with too few details.

@Sebastian-Roth Yeah, this isn’t something readily available in the code.

@endia If you’re at least semi familiar with code, you might look into /var/www/fog/lib/fog/bootmenu.class.php

This isn’t currently coded for, but you might even be able to do what you want using a simple (relatively speaking) hook to alter the boot menu system.

There’s a template hook already created that should help get you started. By creating a hook, you aren’t altering the core code within FOG. Hooks are meant as a means to inject custom data specifically around what you’re requesting to happen.

The hook that’s setup is located in /var/www/fog/lib/hooks/bootitem.hook.php

Ultimately what you would do is make your changes and set the active flag to true. (it’s a variable named active)

@rogalskij while I understand the slowdown is problematic some of it seems bound to network speeds. For your tests are you only imaging a single machine, or multiples at the same time? Are they on a separated network or a congested one? No matter how fast an ssd disk you have, these things need to be thought of as well. What are the speeds of the performing network?

Please don’t take this as the only word. I just want to best understand the whole.

@george1421 Logging has not been removed, so you can easily see if an account is failing to login for some reason. (Not necessarily the why it isn’t logging in).

If it’s making it to the LDAP plugin to check authentication, the request will be logged if it fails for any reason.

As it’s not making it that far, I’m more inclined to think there’s an issue before this point (at which logging likely isn’t tracking).

@george1421 @fritoss007

I think this regex would work best:

(?=^.{3,40}$)^[\w][\w0-9]*[._-]?[\w0-9]*[._-]?[\w0-9]*[._-]?[\w0-9]*[@]?[\w0-9]*([.]?[\w0-9])+$

This isn’t perfect, but should be closer to what’s needed.

Essentially, it’s looking at the final [.]?[\w0-9] and grouping it allowing us to add as many as wanted.

Here’s a slightly better version, I think, as it will allow normal usernames or email addresses:

^(?:[\w\d][\w\d _\-]{3,40}|[\w\d.%+\-]+@[\w\d.\-]+\.[\w]{2,4})$

In the above, it will only limit 3-40 characters without email. With email, the sky’s the limit. However, as @george1421 stated, the user field is only 40 characters so it would fail if you had anything larger than the field could accept.

Master branch is on 1.5.9-RC2

To get specifically 1.5.8 you would run:

cd /root/fogproject
git checkout tag/1.5.8 -b master
cd bin
./installfog.sh -y

I would highly recommend not doing this in your main branch though.

Example:

git clone https://github.com/fogproject/fogproject /root/fog-1.5.8
cd /root/fog-1.5.8
git checkout tag/1.5.8 -b master
cd bin
./installfog.sh

This way your /root/fogproject folder can be updated easily.

Thank you,

Logging was configured to try to make things more easy to track.

I’ve just added the ability to select whether or not to actually write the information to disk.

They’re labelled appropriate as FOG Configuration Page -> FOG Settings -> Logging Settings.

Thank you,

I typically see this with permissions issues.

Please try running:

sudo chown -R fog:root /images && sudo chmod -R 777 /images

I suspect your capture will work a lot better after this is performed.

Due to the security controls of the fog client, I understand what you’re wanting and could probably code this relatively easily, however I think it would probably work better if you did an api script that ran on a schedule.

Essentially the request would be:

put <url>/fog/host

data:
{
[
‘hostIDs’: get <url>/fog/host/ids data: [{“pending”: 1}],
‘pending’: 0
]
}

Of course a bit more output may be needed, but the principal is the same and could be scripted from your fog server.

Simple.

You can not NFS share an NFS share.

What does this mean:

You have mounted the NFS Share to your FOG server. Then you’re trying to make that share be NFS shared from the FOG Server.

So you’re NFS sharing an NFS share. This is simply not allowed.

If you want the NFS share to work with minimal issue, you would need to setup a new Storage node, that just points to the relevant information for the NAS itself.

So, for example, you would create a new node within the group called:

NASNode
ipofnas
/volume1/images

etc…

There’s likely many posts with more direct implication of setting this kind of thing up.

https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

Essentially that will do what you’re looking for.

You do not install the fog software directly. You just need to configure the node to have FTP and NFS.

You will miss a few little details such as disk size and what not.

What version of FOG is installed?

Why not just rerun the installation script? This should recreate the missing dev folder and files as well as make sure they’re set to the proper permissions.

@Quazz is giving the right information, but If you’re using a fog version of 1.5.7 or earlier (I believe this was where we added fogproject as opposed to fog user) then the likely issue is here.

From what I can tell:

1.5.4 was missing the items for this accidentally.

Doing a compare from 1.5.4 to 1.5.9, I see that the config items have been added.

Maybe updating your instance will provide you with the missing items?

@george1421 I think the capture task could have a “allow bitlocker capture” or something similar, along the same lines as “Schedule as debug” task.

This could be interpretted as a kernel arg.

This would be extremely simple and require no Schema change at least.

Thanks for letting me think it through.

The only change is a minor GUI addition and a little change to the Init fsType script.

I don’t think we need to worry about bitlocker on a deploy task.

@george1421 the postinit could re source the funcs file at the end.

The “Unable to locate image store” message comes from not finding the image in the location it’s expected.

Meaning: The path you have set for the image is not the true path expected for the image.

Look at the host that’s giving this error, what image is associated. Look at that image, and find out the path it’s expected to exist at.

I have seen this with you setup in the past. I know you move images off and on from the datastore to a backup, and then put them back when needed. My guess is there’s a typo on the path that you restored.