The following might be lies, so take it with a grain of salt til someone more qualified comments:

When your scripts are running, they are running from the perspective of the client; however, the file system you see is not the actual file system on the disk of the client; it’s a temporary file system that comes from the PXE file/kernel you boot. So when you operate on “/etc/fstab”, you are making a change to the fstab of something that is running memory, and thus no changes persist. If you really want to operate on files on the host, you need to mount the disk device. This is not an entirely fool-proof way, but for my scripts, I mount /dev/sda to /mnt and then can operate on files within that and those changes end up in the host. So for your example, you’d need to do something like this in your script:

#!/bin/bash
mount -t ext4 /dev/sda1 /mnt
ORIGINAL=$(grep -v '#' /mnt/etc/fstab | grep swap | cut -d ' ' -f1 | cut -d '=' -f2)
....

/dev/sda has worked well enough for me, though I am sure there are situations in which it would fail.

Secondly, to the heart of your issue, I believe your analysis is correct in that the UUID issue isn’t something you should be fixing in postdownload scripts. UUID’s, if I understand correctly, are unique, based on the hardware ID of the device. To my understanding, FOG should be handing that during the imaging process (similarly to how it handles growing the file system).

Thanks for the reply Sebastian and sorry for the super long delay.

I am observing this behavior when using “ipxe.pxe” – I have not used any other one binary (not since I switched it to a production server a couple months ago).

Also, to clarify, the transfer rate is good once the transfer begins, it is only when it is “configuring net0” that it seems to be a slow link. However, I assume it is some hardware dependent issue as I just tried a random computer model and saw it was configuring at the expected 1Gb link speed.

So I guess the tl;dr is that this isn’t really a problem.

OK, it’s my fault for skimming code — getHardDisk does not print anything to stdout but saves the output to a variable. Checking that variable shows it does properly find the NVME drive.

I think this request can be closed then as I can use this library to access things, like the imaged drive and make my postimaging scripts much more robust.

Thanks @george1421 & @Tom-Elliott

@Tom-Elliott – no output (see image)

@george1421 – machine images properly; postdownload steps fail (due to hard-coded /dev/sda2)

@george1421 said in get imaged disk information for post download scripts:

@mrayzies said in get imaged disk information for post download scripts:

funcs.sh

Undocumented feature…

The best ones always are.

Actually one of the developers tuned up the script I wrote when the NVMe disks came on line. The NVMe naming convention is a bit different. The funcs.sh has always been in FOS, its just hasn’t been end user reachable.

Can you confirm when that was? I’m running 1.4.4, but when I source that library on a debug installation, getHardDisk returns nothing.

@george1421 – sorry, I’m a couple versions behind I guess; when did the shared library funcs.sh get introduced?

I don’t see anything on the forum for this library either:

• https://wiki.fogproject.org/wiki/index.php?title=Special%3ASearch&profile=default&search=funcs.sh&fulltext=Search
• https://wiki.fogproject.org/wiki/index.php?title=Special%3ASearch&profile=default&search=postdownload&fulltext=Search

If you need to image a particular device, you can use the “Host Primary Disk” argument to define something (e.g. “/dev/sdb”). However, if you specify nothing, FOS chooses a disk to image by some mechanism. In either case, the information of what disk FOG images (and what partitions it creates) are seemingly not available to post-imaging scripts; this leads to hard-coded values, e.g. osdiskpart=“/dev/sda2”;. The problem with this is that if the hard-coded value does not correspond to the imaged disk, post-imaging tasks fail (in the best case, everything errors out and in the worst case, data on a non-imaged disk gets mutated/overwritten). In my particular case, our image was setup with a typical SSD and worked well until we bought a laptop with an NVME drive, which enumerates as /dev/nvme0n1 .

If the disk information was shared/stored, post-imaging scripts could be rewritten intelligently to always run on the proper device, e.g. “mount $fog_disk_part_2 /mnt”.

This should work both for multiple disk systems, e.g. /dev/sda & /dev/sdb as well as with non-typical devices, e.g. /dev/nvme0n1.

@dholtz-docbox

For this image, what do you have defined for “Image Type” and “Partition”? Perhaps you have something misconfigured here which is why the UUID of the SWAP space is not set properly?

I’d guess that you should have “Multiple Partition Image - Single Disk (Not Resizable) - (2)” and “Everything - (1)” respectively.

The following might be lies, so take it with a grain of salt til someone more qualified comments:

When your scripts are running, they are running from the perspective of the client; however, the file system you see is not the actual file system on the disk of the client; it’s a temporary file system that comes from the PXE file/kernel you boot. So when you operate on “/etc/fstab”, you are making a change to the fstab of something that is running memory, and thus no changes persist. If you really want to operate on files on the host, you need to mount the disk device. This is not an entirely fool-proof way, but for my scripts, I mount /dev/sda to /mnt and then can operate on files within that and those changes end up in the host. So for your example, you’d need to do something like this in your script:

#!/bin/bash
mount -t ext4 /dev/sda1 /mnt
ORIGINAL=$(grep -v '#' /mnt/etc/fstab | grep swap | cut -d ' ' -f1 | cut -d '=' -f2)
....

/dev/sda has worked well enough for me, though I am sure there are situations in which it would fail.

Secondly, to the heart of your issue, I believe your analysis is correct in that the UUID issue isn’t something you should be fixing in postdownload scripts. UUID’s, if I understand correctly, are unique, based on the hardware ID of the device. To my understanding, FOG should be handing that during the imaging process (similarly to how it handles growing the file system).

@Wayne-Workman said in Splitting up FOG pieces:

@mrayzies said in Splitting up FOG pieces:

I verified I was able to complete all steps listed in the “testing” section (https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP) and still see the error.
Any other ideas?

The main server will first try to make a web query to the storage node. If the node were an actual storage node setup by the fog installer, it would respond. Since its not a full storage node, the web query fails, and the web server is supposed to fall back to FTP.

when testing, test from cli of the web server, use the same credentials you put in the storage management area for the node. Did you set the ftp users home directory to where the images are?

My new server is failing the FTP commands. But so is my old server.

What I believe is happening is my customization is coming back to bite me – I am pretty confident that I hardcoded some values into the old install that hijacked what would have been requests to the storage nodes and re-wrote them to use the local FOG server; so the client would make an FTP request to the FOG server, it would work fine, and then it would try and mount the remote server anyway – and I had added all the necessary permissions to make that work.

So I can either straighten out my install to be more standard or go through that headache again. In either case, I’d consider this “resolved” and not spend anymore time on it. Thanks for the help.

Debug output, like @george1421 mentioned, should help you diagnose the problem. Debug deploys can help you get it, but you can also cheat it by waiting for input:

#!/bin/sh
set -x

. ${postdownpath}update_swap_uuid.sh

read -n1 -r -p "[$(date)] press any key to continue"

Off hand, I’m guessing it’s probably that “${postdownpath}” doesn’t end in a trailing slash, so your client is trying to execute something like /images/postdownloadscriptsupdate_swap_uuid.sh which likely doesn’t exist.

@Wayne-Workman said in Splitting up FOG pieces:

@mrayzies said in Splitting up FOG pieces:

However, I am unable to schedule any deploy tasks as the webUI returns: “Type: 8, File: /var/www/fog/lib/fog/fogbase.class.php, Line: 793, Message: Undefined index: value, Host: 10.52.2.31, Username: fog”.

That’s an FTP issue. Look in the wiki for Troubleshoot FTP.

I verified I was able to complete all steps listed in the “testing” section (https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP) and still see the error.

Any other ideas?

Regarding the silent installer – you had me install it once, then change settings and re-run it; is it supported to change the settings beforehand and then run it?

Lastly, regarding the non-standard setup, that’s good information about the progress of FOG and I’m glad to see it’s doing well. I’ll consider moving to the supported setup, but I won’t waste time trying to debug my non-standard setup.