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:

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.

get imaged disk information for post download scripts

239

11.6k

17.1k

154.6k