get imaged disk information for post download scripts

[mrayzies]

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.

[george1421]

@mrayzies ?? Not sure what you are saying. The ‘osdiskpart=/dev/sda2;’ makes me think you are looking at one of my early tutorials where for Win7 /dev/sda2 was the “C:” drive.

Using FOG’s built in functions make the postinstall script a bit more robust.

#!/bin/bash
. /usr/share/fog/lib/funcs.sh
[[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/"
case $osid in
    5|6|7|9)
        clear
        [[ ! -d /ntfs ]] && mkdir -p /ntfs
        getHardDisk
        if [[ -z $hd ]]; then
            handleError "Could not find hdd to use"
        fi
        getPartitions $hd
        for part in $parts; do
            umount /ntfs >/dev/null 2>&1
            fsTypeSetting "$part"
            case $fstype in
                ntfs)
                    dots "Testing partition $part"
                    ntfs-3g -o force,rw $part /ntfs
                    ntfsstatus="$?"
                    if [[ ! $ntfsstatus -eq 0 ]]; then
                        echo "Skipped"
                        continue
                    fi
                    if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
                        echo "Not found"
                        umount /ntfs >/dev/null 2>&1
                        continue
                    fi
                    echo "Success"
                    break
                    ;;
                *)
                    echo " * Partition $part not NTFS filesystem"
                    ;;
            esac
        done
        if [[ ! $ntfsstatus -eq 0 ]]; then
            echo "Failed"
            debugPause
            handleError "Failed to mount $part ($0)\n    Args: $*"
        fi
        echo "Done"
        debugPause
        . ${postdownpath}fog.copydrivers
        # . ${postdownpath}fog.updateunattend
        umount /ntfs
        ;;
    *)
        echo "Non-Windows Deployment"
        debugPause
        return
        ;;
esac

ref: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

[mrayzies]

@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

[george1421]

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

funcs.sh

Undocumented feature…

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.

[mrayzies]

@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.

[Tom Elliott]

@mrayzies What do you mean it returns nothing?

It says:
“Could not find hdd to use”?

[george1421]

@mrayzies It has been in the system since the 1.2.0 trunk days. Does FOG image the computer correctly?

[mrayzies]

@Tom-Elliott – no output (see image)

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

[Tom Elliott]

funcs.sh has been in there since at least 0.30 days, though I’m sure it’s been there since much earlier. It just hadn’t been pushed into the repository until that point.

Reference:
First case of funcs.sh showing up.

[mrayzies]

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

[george1421]

@mrayzies Well when I run a pure debug console it doesn’t return a value either. I know it works because I’m using it on my production server. Let me see what I have in my dev environment. These are the same functions FOG uses to lay the image down on the target computer so they have to work.

[george1421]

@mrayzies Good to hear. If you look at my very first post you can see a ref link to the current versions of the post install scripts. You might get some ideas on how to update yours.