Posts made by Enrico

I confirm it is solved.

Notice:
timeout is -1, so it boot the first os if no esc key is pressed.

@tom-elliott Ok, I confirm it is working. Thanks!

@sebastian-roth
My osx/windows environment does not use grub! I paused the original script and I can assure that saveGRUB creates d1.mbr and sgdisk overwrites it then.

d1.mbr  d1.original.uuids  d1p1.img  d1p2.img  d1p3.img  d1p4.img  d1.partitions

However, my grub environment (linux/windows) does not create d1.grub.mbr, but touches d1.has_grub.

d1.has_grub  d1.mbr  d1p1.img  d1p3.img  d1.partitions

    [[ -n $sgdisk && $hasGRUB -eq 1 ]] && mbr="$imagePath/d${disk_number}.grub.mbr" || mbr="$imagePath/d${disk_number}.mbr"

In grub/MBR environment (linux/windows) $sgdisk is null -> d1.mbr
In no grub/GPT environment (osx/windows) $hasGRUB is 0 -> d1.mbr

@sebastian-roth I totally agree! This is the reason why I don’t like to submit a patch…
I’m going to bore you with a few other details to help clarifying the issue.

The problem begins in the capture phase in savePartitionTablesAndBootLoaders():

        1)
            dots "Saving Partition Tables (GPT)"
            saveGRUB "$disk" "$disk_number" "$imagePath" "true"
            sgdisk -b "$imagePath/d${disk_number}.mbr" $disk >/dev/null 2>&1

the sgdisk command overwrites the just created saveGRUB file ($imagePath/d${disk_number}.mbr).

In the deploy phase, restorePartitionTablesAndBootLoaders():

        restoreGRUB "$disk" "$disk_number" "$imagePath" "true"
        sgdisk -gl $tmpMBR $disk >/dev/null 2>&1

restoreGRUB is restoring the sgdisk’s file
One more thing: restoreGRUB is using dd on first sectors and does not restore the backup GPT that is at the end of disk.
So, when sgdisk is called to restore data, it says CRC mismatch between the main partition table (restored by restoreGRUB) and the backup one (not restored): error 2.
I think saveGRUB() and restoreGRUB() are saving and restoring MBR in effect: I can’t see the hasGRUB() usefullness in GPT

So, my last proposal (for today) is to forgot previous patches and comment out:

restorePartitionTablesAndBootLoaders() {
...
    if [[ $table_type == GPT ]]; then
        dots "Restoring Partition Tables (GPT)"
#        restoreGRUB "$disk" "$disk_number" "$imagePath" "true"
        sgdisk -gl $tmpMBR $disk >/dev/null 2>&1

and

savePartitionTablesAndBootLoaders() {
...
    case $hasgpt in
        0)
            strdots="Saving Partition Tables (MBR)"
...
            dots "$strdots"
#            saveGRUB "$disk" "$disk_number" "$imagePath"
            sfdisk -d $disk 2>/dev/null > $sfdiskfilename

I tested capture/deploy of my windows/linux (MBR) and osx/windows (GPT) with no issues.

@tom-elliott Thanks for your attention on my tickets!
The most cryptic one (count= issue) is not solved by sgdisk -z before dd but after. I’m going to add some infos.
Thanks again for FOG: I’ve been using it by 6-7 years. I can multicast deploy a 20 dual boot pc classroom in 30 minutes!

Sorry for the misunderstanding! I’m not a developer. Thanks for pointing out my mistake. I’m going to edit the first snippets removing

sgdisk -z $disk

(my single patch)
I reported one solution but I’m not sure that it has no side effects because I’m not familiar with the code.
Do you think I had to push a request on git? I’m not familiar but I can learn.
About https://forums.fogproject.org/topic/10998/problem-of-deployment-of-an-old-image ticket:
I don’t think it is related. My image is captured using the same 1.4.4 as the one in the deploy phase.
In my case, the problem is like https://github.com/ceph/ceph-ansible/issues/759
My bootloader seems hybrid MBR and I don’t understand why $count parameter of dd is 40 (MBR is first 512 bytes, I think).
I debugged deeper and I see FOG makes an

    dots "Erasing current MBR/GPT Tables";
    sgdisk -Z $disk >/dev/null;

then

dd if=$tmpMBR of=$disk bs=512 count=$count >/dev/null 2>&1

with $count=40.
If I fire an gdisk -l $disk
the output says

MBR: hybrid
...
GPT: damaged

Firing by hand instead

dd if=$tmpMBR of=$disk bs=512 count=1

gdisk -l $disk outputs:

MBR: hybrid
...
GPT: not present

then I can send sgdisk -gl $tmpMBR $disk >/dev/null 2>&1 without errors.
So, a better patch could be setting $count=1 before dd?

     [[ $count -eq 8 ]] && count=1
# patch?
    [[ $count -eq 40 ]] && count=1
    dd if=$tmpMBR of=$disk bs=512 count=$count >/dev/null 2>&1

It is beyond my FOG code knowdlege.
Let me know.
Thanks!

Those settings fit more situations, I think (but I can’t assure that) but you can tune them.

scanfor selects where it is going to search for boot loaders. In my case, “internal” does not find bootcamp boot loader, so I add “hdbios”.

scandelay 5 is needed because the default 0 is too quick to permit the bootcamp become available.

timeout 5 is needed because the default -1 goes straightforward to boot the default loader and does not show the two os options. So, this one is needed if you have a multiboot system only.

Because, in my mind, in a multiboot environment (osx + windows), if I select osx (for example) it could not fit the windows os or reverse. I selected “99” os type to image a windows+linux for years, but let me know if it is better to choose an other option.
Thanks for fog!

To boot Mac with OSx and windows bootcamp, you have to select REFIND_EFI in Exit to Hard Drive Type(EFI) menu of FOG PXE Boot Menu Configuration.
Then modify /var/www/html/fog/service/ipxe/refind.conf parameters:

timeout 5
scanfor internal,hdbios,external,biosexternal
scan_delay 5

Hope this helps someone!

Hi,
try setting this parameter in /var/www/html/fog/service/ipxe/refind.conf:

# Delay for the specified number of seconds before scanning disks.
# This can help some users who find that some of their disks
# (usually external or optical discs) aren't detected initially,
# but are detected after pressing Esc.
# The default is 0.
#
scan_delay 5

and, if you need, this:

# Timeout in seconds for the main menu screen. Setting the timeout to 0
# disables automatic booting (i.e., no timeout). Setting it to -1 causes
# an immediate boot to the default OS *UNLESS* a keypress is in the buffer
# when rEFInd launches, in which case that keypress is interpreted as a
# shortcut key. If no matching shortcut is found, rEFInd displays its
# menu with no timeout.
#
timeout 5

I’m using fog 1.4.4 to deploy osx + windows bootcamp and catched some bug (and solution). I’m going to open one ticket each one.
Second one.
If you create an image with os type 99 “Other OS”, it can’t be restored because of:

No source file passed (writeImage)
Args passed:   /dev/sda1

Digging, I found that there is no “99” case entry in restorePartition(). I modified it in:

                4|8|50|51|99)
                    imgpart="$imagePath/d${disk_number}p${part_number}.img*"
                    ;;

And it works.

I’m using fog 1.4.4 to deploy osx + windows bootcamp and catched some bug (and solution). I’m going to open one ticket each one.
First one.
Restoring the image the bahavior was like https://forums.fogproject.org/topic/9272/error-trying-to-restore-gpt-partition-tables. It is a gpt issue, not Osx one.

I went on deploy debug and, it executes in restorePartitionTablesAndBootLoaders() (edited):

        restoreGRUB "$disk" "$disk_number" "$imagePath" "true"
        sgdisk -gl $tmpMBR $disk >/dev/null 2>&1
        sgdiskexit="$?"

in restoreGRUB():

    dd if=$tmpMBR of=$disk bs=512 count=$count >/dev/null 2>&1

and the execution of “sgdisk -gl $tmpMBR $disk >/dev/null 2>&1” fails with error code 2:

Caution! After loading partitions, the CRC doesn't checkout!
Warning! Main partition table CRC mismatch! Loaded backup partition table instead of main partition table!

Warning! One o more CRCs don't match! You should repair the disk!

Invalid partition data!
Information: Loading backup partiton table; will override earlier problems!
The operation has completed successfully.

And reboots.

I modified restorePartitionTablesAndBootLoaders():

        restoreGRUB "$disk" "$disk_number" "$imagePath" "true"
        sgdisk -z $disk
        sgdisk -gl $tmpMBR $disk >/dev/null 2>&1
        sgdiskexit="$?"

and it works.

Hi,
The last svn and git (4586) versions does not include auto increment ov FOG_QUICKREG_SYS_NUMBER in Registration.class.php.
So, when you quick register second host, it cannot because the name exists and it delete the previous one too (why?).
Resolved adding:
129,130d128
< //increment quickreg system number
< $this->FOGCore->setSetting(FOG_QUICKREG_SYS_NUMBER,$autoRegSysNumber + 1);
to Registration.class.php.

Hope this helps
bye
Enrico

Hi, I falled into the same issue.
I found a mismatch in servicemodule-active.php, db and snapin exe.
The snapin exe asks for the “snapin” module.
The “module” db table has “snapinclient” short name.
The servicemodule-active.php script check the “snapin” module.
I workarounded (< is mine) the script (awful) because I don’t want to change the db or the snapin exe.

13,15d12
< if (($_REQUEST[‘moduleid’]==“snapin”)) {$_REQUEST[‘moduleid’]=“snapinclient”;}
<
29c26
< ‘snapinclient’ => $FOGCore->getSetting(‘FOG_SERVICE_SNAPIN_ENABLED’),

          'snapin' => $FOGCore->getSetting('FOG_SERVICE_SNAPIN_ENABLED'),

(works)

[quote=“ictadmin, post: 34293, member: 1004”]Hi Tom,

For us the multicast task never starts, it’s as if the computers are waiting for another computer to join - or for something to kick the session off.

How can I check if the FOGMulitcastManager is running please?

Thanks,

IA[/quote]
This is the log file: /opt/fog/log/multicast.log
the process is:
ps aux|grep FOGMulticastManager
root 1716 0.0 2.0 333900 20888 ? S 12:31 0:00 /usr/bin/php -q /opt/fog/service/FOGMulticastManager/FOGMulticastManager

I create the task, then I boot the 2 group members and the task starts (I can see the udpcast process and the log entry:
cat /images/test1/test1|/usr/local/sbin/udp-sender --min-receivers 2 --portbase 57050 --interface eth0 --full-duplex --ttl 32 --nokbd;

the hosts start partclone “starting to restore image…” and hang (I don’t see any traffic).
Sending a multicast task on a single host works…
Thanks for your help

I have the same issue:
when the clients are set to multicast individually, the job completes just fine, when they are part of a group job they don’t even begin, they just sit at the blue screen as if they are waiting for another computer to join the group, have left them for an hour in this state and nothing I’m afraid
and so I subscribe (up?) the thread to get notifications… Wrong?

subscribe

Ok, thanks, In fedora20 is default. I understand you don’t include this support, but an exception on the log file could be a good idea.
I spent a few hours to identify the trouble and some other people could do too. Sorry if I miss any documentation about it.

Sorry, I attach the fedora 20 output:
[B]em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet x.x.x.x netmask 255.255.255.224 broadcast x.x.x.y[/B]
As you can see, there is not a ‘:’ but the source code search for it:
exec(“/sbin/ifconfig | grep ‘[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}’|[B] cut -d’:’ -f 2[/B] | cut -d’ ’ -f1”, $arR, $retVal);
so the outuput is null…
Ciao
Enrico