• RE: Different bios files for different network cards

    @rodrigoantunes said in Different bios files for different network cards:

    wouldn’t it be a dhcp server functionality rather than fog

    FOG could do it with some programming, but its probably easier to do it on the dhcp server side. Its not super simple to do, but basically you would setup dhcp reservations or uniqueness based on the mac address of the target computer. When the dhcp server sees a known mac address then it sends out the alternate pxe boot loader. You would make the default pxe boot loader (like undionly.kpxe) be the default and then override it with reservation settings for the troubled computers. It can be done.

    I find its strange that the undi driver doesn’t work on some computers but does on others. The undi specification has been around for 30 years. Most firmware has had time to work out the bugs.

    posted in FOG Problems
  • RE: Problem Capturing right Host Primary Disk with INTEL VROC RAID1

    @Ceregon said in Problem Capturing right Host Primary Disk with INTEL VROC RAID1:

    Maybe i can work with groups of hosts to decide when this postinit script is used

    It is possible to access FOG system variables in a pre install script (where I would recommend you do any initialization needed for mdm arrays). So you could use like fog user field 1 or 2 (in the host definition) to contain something that indicates you need to init the mdm array. You might also be able to key it off of the target device name too. I have not looked that deep into it, but it should be possible at least on the surface.

    posted in General Problems
  • RE: capture image : bug at the end to rename tmp folder

    @collins91 I don’t have an answer for you, but I can connect what you see to how FOG works.

    With FOG, the FOS Engine (OS that gets loaded onto the target computer for capturing and deploying images) uses NFS to move disk information between the FOG server and target computer.

    On the fog server there are two NFS shares.

    1. /images that is shared as read only. That is where all of the captured image files end up. The read only attribute keeps the image files from being messed with (i.e. deleted) over the network once they are captured.
    2. /images/dev that is shared as read/write. That is where the files temporarily stored at while being captured.

    So now you have the basis of the design.
    At capture the FOS engine creates a temporary directory in /images/dev share as the mac name of the target computer for uniqueness.

    Once the NFS upload is completed. The FOS engine connects to the FOG server using the ftp protocol using the fogproject user account and instructs the OS to move the file pointer for the image from the temp location on /images/dev/<mac_name> to /images/<image_name>. Since only the file pointers are updated this “move” happens very fast.

    Then the target computer reboots.

    Now to tie this back into what you are seeing, the process seems to be failing on the ftp login and use of the mv command. Your condition kind of tells me the problem is a file permission issue where the (linux user) fogproject doesn’t have the proper permissions needed to execute the mv command.

    I would start there for trying to understand why its failed, for example lets say your dead link folder was created by root, and the fogproject user doesn’t have the rights to change a directory created by root. That would cause the process to fail as you outlined.

    posted in FOG Problems
  • RE: Providing installation media via pxe booting for UEFI systems.

    @mashina said in Providing installation media via pxe booting for UEFI systems.:

    Interestingly, the problem doesn’t occur when Ubuntu is already present, and then Windows is deployed. Anyway, that is not a big problem at this moment.

    But in this case the uefi firmware has already registered ubuntu as a bootable OS. So it just goes, oh hello I see you again on disk1. But if the entry doesn’t exist then it needs to be fixed up. You might be able to test this on a working system, go into the uefi firmware and delete the entry for ubuntu on the second disk, only leaving windows in the uefi boot manager. Upon reboot does it need to fix itself up again?

    Just be aware that FOG doesn’t touch the uefi firmware or boot manager. BUT you can do that with in a FOG post install script and using the linux uefi manager (not the actual name) app. You can add remove uefi boot manager entries at your need.

    Your suggestion works well for putting Linux on Disk1, but if the user needs to reinstall Windows, it’ll also go to /dev/nvme1n1, messing everything up

    True it will mess everything up. But also I took your inital post as you will load windows once and then could potentially reload ubuntu or the OS on the second drive multiple times. If you “had to” you could write a FOG preinstall script to ask what drive do you want to send the image too, but that gets a bit messy, but its possible.

    posted in General
  • RE: Surface Go 4 incompatible

    In the end I am maintaining a separate image, I was able to get management to let us buy a separate surface go 4 for maintaining the 4k disk image.
    I found that bhyve based VMs can be set to 4k blocks but it was cumbersome to get it to boot to fog to capture the image at the end. And when that image was deployed, it did not expand on the surface go.

    posted in Hardware Compatibility
  • RE: Surface Go 4 incompatible

    Some info from the debug session

    cat /images/4KDisk-Base-Dev/d1.original.fstypes
    /dev/vda3 ntfs
    
    [Fri Jan 26 root@fogclient ~]# cat /images/4KDisk-Base-Dev/d1.partitions
    label: gpt
    label-id: 9865AAFC-B984-4860-ACF5-4D6F2513747D
    device: /dev/vda
    unit: sectors
    first-lba: 6
    last-lba: 16777210
    sector-size: 4096
    
    /dev/vda1 : start=         256, size=       76800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=7C4743B5-7150-4672-B521-7B537528D7E7, name="EFI system partition", attrs="GUID:63"
    /dev/vda2 : start=       77056, size=        4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=F6216A84-0172-4445-B616-E36DFA20C731, name="Microsoft reserved partition", attrs="GUID:63"
    /dev/vda3 : start=       81152, size=    16501760, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=B6DA06DC-A5D0-434C-A6FE-494A1EFB515E, name="Basic data partition"
    /dev/vda4 : start=    16582912, size=      193792, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=7BB90563-4BB7-4281-98EA-3FF4BCF1FCA5, attrs="RequiredPartition GUID:63"
    
    [Fri Jan 26 root@fogclient ~]# cat /images/4KDisk-Base-Dev/d1.minimum.partitions
    label: gpt
    label-id: 9865AAFC-B984-4860-ACF5-4D6F2513747D
    device: /dev/vda
    unit: sectors
    first-lba: 6
    last-lba: 16777210
    sector-size: 4096
    
    /dev/vda1 : start=         256, size=       76800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=7C4743B5-7150-4672-B521-7B537528D7E7, name="EFI system partition", attrs="GUID:63"
    /dev/vda2 : start=       77056, size=        4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=F6216A84-0172-4445-B616-E36DFA20C731, name="Microsoft reserved partition", attrs="GUID:63"
    /dev/vda3 : start=       81152, size=    16501760, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=B6DA06DC-A5D0-434C-A6FE-494A1EFB515E, name="Basic data partition"
    /dev/vda4 : start=    16582912, size=      193792, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=7BB90563-4BB7-4281-98EA-3FF4BCF1FCA5, attrs="RequiredPartition GUID:63"
    
    [Fri Jan 26 root@fogclient ~]# cat /images/4KDisk-Base-Dev/d1.fixed_size_partitions
    1:2:4
    
    [Fri Jan 26 root@fogclient ~]# cat /images/4KDisk-Base-Dev/d1.
    d1.fixed_size_partitions  d1.minimum.partitions     d1.original.swapuuids     d1.shrunken.partitions
    d1.mbr                    d1.original.fstypes       d1.partitions
    
    
    [Fri Jan 26 root@fogclient ~]# cat /images/4KDisk-Base-Dev/d1.shrunken.partitions
    label: gpt
    label-id: 9865AAFC-B984-4860-ACF5-4D6F2513747D
    device: /dev/vda
    unit: sectors
    first-lba: 6
    last-lba: 16777210
    sector-size: 4096
    
    /dev/vda1 : start=         256, size=       76800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=7C4743B5-7150-4672-B521-7B537528D7E7, name="EFI system partition", attrs="GUID:63"
    /dev/vda2 : start=       77056, size=        4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=F6216A84-0172-4445-B616-E36DFA20C731, name="Microsoft reserved partition", attrs="GUID:63"
    /dev/vda3 : start=       81152, size=    16501760, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=B6DA06DC-A5D0-434C-A6FE-494A1EFB515E, name="Basic data partition"
    /dev/vda4 : start=    16582912, size=      193792, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=7BB90563-4BB7-4281-98EA-3FF4BCF1FCA5, attrs="RequiredPartition GUID:63"
    
    gdisk -l /dev/sda
    GPT fdisk (gdisk) version 1.0.8
    
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    
    Found valid GPT with protective MBR; using GPT.
    Disk /dev/sda: 31246336 sectors, 119.2 GiB
    Model: KLUDG4UHGC-B0E1
    Sector size (logical/physical): 4096/4096 bytes
    Disk identifier (GUID): 9865AAFC-B984-4860-ACF5-4D6F2513747D
    Partition table holds up to 128 entries
    Main partition table begins at sector 2 and ends at sector 5
    First usable sector is 6, last usable sector is 31246330
    Partitions will be aligned on 256-sector boundaries
    Total free space is 14469877 sectors (55.2 GiB)
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1             256           77055   300.0 MiB   EF00  EFI system partition
       2           77056           81151   16.0 MiB    0C01  Microsoft reserved ...
       3           81152        16582911   62.9 GiB    0700  Basic data partition
       4        16582912        16776703   757.0 MiB   2700
    

    It’s a 128 GB drive, the image was a 64 GB drive, I expected it to expand to 128 GB

    ntfsresize info on parts 4 and 3

     ntfsresize --info /dev/sda4
    ntfsresize v2022.10.3 (libntfs-3g)
    Device name        : /dev/sda4
    NTFS volume version: 3.1
    Cluster size       : 4096 bytes
    Current volume size: 793772032 bytes (794 MB)
    Current device size: 793772032 bytes (794 MB)
    Checking filesystem consistency ...
    100.00 percent completed
    Accounting clusters ...
    Space in use       : 14 MB (1.7%)
    Collecting resizing constraints ...
    You might resize at 13193216 bytes or 14 MB (freeing 780 MB).
    Please make a test run using both the -n and -s options before real resizing!
    
    [Fri Jan 26 root@fogclient ~]# ntfsresize --info /dev/sda3
    ntfsresize v2022.10.3 (libntfs-3g)
    Device name        : /dev/sda3
    NTFS volume version: 3.1
    Cluster size       : 4096 bytes
    Current volume size: 67591208960 bytes (67592 MB)
    Current device size: 67591208960 bytes (67592 MB)
    Checking filesystem consistency ...
    100.00 percent completed
    Accounting clusters ...
    Space in use       : 24382 MB (36.1%)
    Collecting resizing constraints ...
    You might resize at 24381546496 bytes or 24382 MB (freeing 43210 MB).
    Please make a test run using both the -n and -s options before real resizing!
    
    posted in Hardware Compatibility
  • RE: Problem Capturing right Host Primary Disk with INTEL VROC RAID1

    @Ceregon I’ve never messed with cloning a raid array. Anything can be done, but whether or not it’s going to work with built-in stuff is a different question.
    I imagine you have vroc/vmd enabled in the bios on the machine where you’re deploying already. I’ve never got to play with Vroc but I’m familiar with it, just wasn’t able to convince management to buy me the stuff to try it a few years back.
    My first guess is that /dev/md124 doesn’t exist because the raid volume doesn’t exist yet, but it sounds like you found that in a debug session on a host you’re trying to deploy too. So that’s probably out. But I just wonder if the VROC volume needs to be created beforehand to be deployed to, but I don’t have a full understanding of when that volume is made.

    My next guess would be that a RAID array is a multiple disk system, so the image needs to be captured in multiple disk mode e7c6e221-d546-4b02-9e5b-6668cb7bcca4-image.png
    Are you having different disk sizes for these RAID volumes? would capturing with multiple disk or dd be an option?
    In theory a RAID is a single volume, and you may be able to capture it correctly and it sounds like you’ve found others in the forum that have done that?

    Other possibility is the need for different VROC drivers in the bzImage kernel, but I feel like if that was the case, then you wouldn’t be able to see the disk at all when capturing.

    You could also capture in debug mode and mount the windows drive before starting the capture to see if you can read stuff?
    This is from part of a postdownload script that will mount the windows disk to the path /ntfs

    . /usr/share/fog/lib/funcs.sh
    mkdir -p /ntfs
    getHardDisk
    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"
    

    Also, hot tip, once you’re in debug mode, you can run passwd and set a root password for that debug session. Then run ifconfig to get the ip. Then you can ssh into your debug session with ssh root@ip then put in the password you set when prompted. Then you can copy and paste this stuff and it’s a lot easier to copy the output or take screenshots.

    Another possibilty could be using pre and post download scripts to fix the raid volume in the linux side, I found this information https://www.intel.com/content/dam/support/us/en/documents/memory-and-storage/linux-intel-vroc-userguide-333915.pdf but I didn’t dig into to that too much.

    posted in General Problems
  • RE: PXE Fog Subnet Problem?

    @pilgrimage This problem is connected to your other post: https://forums.fogproject.org/topic/17255/about-dhcp-and-pxe-problem?_=1707994213348

    Your issue is infrastructure and not a fog specific issue. DHCP works based on broadcast messages. These broadcast messages typically are not passed between subnets. On your subnet router there is a service that can be turned on to relay dhcp communications between subnets. I would also think this service is configured on your network because you have client computers on one subnet and servers on another.

    Since you are using dnsmasq to provide the pxe boot information since your dhcp server can’t be changed, you need to update this dhcp-helper / dhcp relay agent on your network router to include your dnsmasq server in the list of dhcp servers this service notifies of a dhcp request. Once that is done your dnsmasq server will hear the dhcp request from the remote subnet and respond with the pxe boot information.

    posted in FOG Problems
  • RE: FOG Project instead of CloneZilla Lite Server

    @Orfeous said in FOG Project instead of CloneZilla Lite Server:

    My goal here is to install Debian or Ubuntu on a PC to be run as a Server. I have a couple of NUCs that I want o deploy an image to via isolated network. Server and Client machines connected to the same switch. No router or such in play.

    You can do this on an isolated network completely or install 2 nics in your FOG server and have one connected to your imaging network and one to your business network for remote management on the fog server.

    You can also set this up on your business network without interfering with your business network communications. So it can work either way. In some instances you might need access to your business network for AD integration as your target computers boot during its first boot. I understand your goal is linux so AD is not required. But the point is either way FOG will work.

    I want this Server to run a DHCP server and broadcast ips to the client machines that will be netbooting via PXE.

    If you want to run on an isolated imaging network, just pick to include the FOG DHCP server and the installer script will install the dhcp server and configure it for you.

    I want to use those NUCs to boot via PXE and then automatically disk will be restored from image.

    If i get other PC vendors and models I want to use another image for those.

    No problem on multiple vendors. You just need to really be mindful of the firmware on the target computer bios or uefi modes because the target image is handled a little bit differently between the two firmware classes. FWIW you can not deploy a bios computer captured image to a uefi based computer. The same holds true in reverse.

    Is it possible to use my CloneZilla disk image that has already been saved?

    While Clonezilla and FOG both use partclone to capture the disk image, the images are stored and compressed differently on either platform. So you can not share the images between the two environments. You will need to capture with FOG if you want to deploy with FOG, or capture with Clonezilla if you want to deploy with clonezilla.

    Client NUCs uses NVme ssd and Windows 10 or 11 is located on the disk image.

    Now you introduced Windows 10 into the picture. No problem, but that also might mean needing AD during firstboot. You have to remember that the FOS engine (the OS that boots on the target computer) is linux based. So nvme drives have a different disk label that sata drives. But you can capture from a sata drive and deploy to an nvme drive, but that is not a common situation.

    Is this possible with FOG Project?

    Yes it is

    posted in General
  • RE: Providing installation media via pxe booting for UEFI systems.

    @mashina said in Providing installation media via pxe booting for UEFI systems.:

    I encounter a “Reset System” message and the machine reboots

    I can say I’ve never seen this before. When you see this message what is the default boot device? Is it the hard drive or PXE booting. Its not clear if its the UEFI firmware or iPXE/rEFInd (fog’s boot loader) that is throwing this error.

    This is only a guess, but I might think it the uefi firmware saying “hey something changed from the last boot” should I fix up the boot settings with the new information?

    It would be interesting to know if you reimaged the target computer again with the same FOG image would you also get that message, or do you only get the message when you change image formats (i.e. Windows was previously the boot image and now its ubuntu?)

    posted in General