@dolf Finally got around to look into this. Here is a screenshot of what it looks like right now. Any comments on the text or style?

@george1421 said in rcu_sched stall OR kernel panic on PowerEdge R640:

We can also hold this “test” kernel in reserve in case this issue comes up again if you don’t want to release it as general availability.

Don’t get me wrong on this. I am more than happy to make this the default kernel for everyone. It comes at low cost. But I’d like to see this tested on several different machines (PC as well as notebooks and even servers if possible) before we make it the new default kernel.

@Wayne-Workman said in Installation stops during setting up fogproject password:

it seems generating passwords in fog has been an issue for a while… be it special characters that need handled or double vs single quotes to contain it…
Lately in my own projects, I opt for very long passwords made from upper & lower case letters and numbers randomly. I’m talking 32, or 64 characters long. Typically I look up the maximum length supported password, and generate one of that length, just letters and numbers.

Good point you have there. Early this year we started thinking about moving to better password policy in general. Not using an empty password for mysql, setting a random passphrase for the web UI login and such. As sort of a preperation I committed a change that moves away from the original openssl rand -base64 32 because I thought people wouldn’t even bother about trying to memorize a 32 length password (web UI login). But I got somehow sidetracked by too many other things and never finished what I initially thought about: Having different levels of complexity passwords instead of one fits all.

So we might discuss this now before we change things again.

For anyone interested, here is a working example of how to hide the Domain Password field.

1. Create a new empty file named /var/www/html/fog/lib/hooks/hideadhostdata.hook.php
2. Change ownership: chown apache:apache /var/www/html/fog/lib/hooks/hideadhostdata.hook.php (this is for CentOS, use chown www-data:www-data ... for Debian/Ubuntu)
3. Copy and paste the following code to that file and save it:

<?php
class hideadhostdata extends Hook {
    public $name = 'hideadhostdata';
    public $description = 'Hide some of the AD information in host edit view';
    public $author = 'SR';
    public $active = true;
    public function __construct()
    {
        parent::__construct();
        self::$HookManager
            ->register(
                'HOST_EDIT_AD', 
                array($this, 'hideADHostData')
            );
    }
    
    public function hideADHostData($arguments) {
        if ($_REQUEST['node'] == 'host' && $_REQUEST['sub'] == 'edit') {
            unset($arguments['data'][5],$arguments['template'][5]); // Domain Password
        }
    }
}
?>

@rockinhc Please click the “INSTALLATION SOURCE” button, take another picture of the settings and post here.

According to this website the boot option is not repo=... but inst.repo=nfs:[options:]server:/path!

@rogalskij Just want to add to George’s great instructions on testing that you might need to re-capture the image when using the 1.5.7 kernel/init because the used an older version of partclone with a different image format. Newer partclone can deploy older images but not the other way round.

@browlry I have not seen such a “crippled” partition layout before. No offense here, just saying that I am confused by this. Deploying the d1.mbr to an empty test VM disk and looking at it with gdisk I get a lot of warnings and so on:

Even if I let it correct things and re-write the partition table I still get the warnings when re-opening. This must be something very special from the MS world…

@Baessens Ohhhhhhhh no!!! Why haven’t I noticed this before??? Can’t believe it. The second picture of your initial post actually has the solution to this riddle in it already. Image is named UEFI01/09/20v2004 and as a forward slash is the directory separator on Linux systems it will fail to rename the uploaded image…

Simply use dashes (-) instead of the slash in both the image name and path and I am sure it will upload just fine.

We don’t get that very often and I actually thought we had some kind of regex check in the web UI to prevent from this but seems like I was wrong.

@rivybeast said in Deploy Image results in Invalid MAC Address:

dev/sdb on /images type ext4 (rw,relatime)

Ok, you moved your images to a secondary disk. That’s all fine but you simply missed one file we use to check. Run this command to recreate it: touch /images/.mntcheck

After that just do your deployments.

@Epsilon52 What kind of machine do you want to PXE boot? Is it set to legacy BIOS/CSM (undionly.kpxe is the right file here) or UEFI (you’d need to use ipxe.efi then)?

The other question I have for you is: Are the system (FOG server and the host machine) on the same subnet?

Turns out the install was corrupted with TFTP files in /srv/tftp (as for ARCH installs. Re-running the installer fixed it all up.

@rude26 Then try a manual download to find out what’s going on. On your FOG server run the following command and post output here:

curl -kOL https://github.com/FOGProject/fos/releases/latest/download/bzImage

@c4c Beside the guide George provided to conpile the FOS init I can suggest you try the build.sh script we provide within the FOS repo.

As well I ask you to pay close attention to the error messages. Make sure it’s always the exact same error or possibly a slightly different one. Just want to prevent you from going mad searching for a change in the inits.

@admiralshaw @LLamaPie This sounds very much like the issue someone reported just a few weeks ago. Happens when you have more than two network interfaces in your device. Can’t find the topic right now.

What do you think @JJ-Fullmer ? Would you remember where we discussed this?

@Bob-Henderson said:

on the plus side, was able to use FOG to image out 700 units in 3 hours today. Thanks, multicast and stacked switches!

Well that’s awesome!! See this, people out there using other cloning solutions. Anyone up for a race on this one?

Simply put, FOG is amazing (especially if you get multicast right).

If you access http://172.16.101.111/fog/service/ipxe/boot.php?mac=34:17:eb:a2:a9:86 from a browser in another client on your network, what do you see? Is it just those four lines you posted already? Don’t think so. Please post the full output you see in the browser.

@x23piracy I am sure I’ve read about PXE booting virtualbox in EFI mode not being possible but I can’t really find a clear statement. Only this forum post: https://forums.virtualbox.org/viewtopic.php?f=8&t=69954

Same issue on my machine (Debian 7.6). As Tom said, it’s got to do with services depending on others but being started too early. I am pretty sure the FOG init scripts (which call php scripts) fail because mysql is not coming up fast enough!

My fix is to remove all FOG init scripts from normal startup and call them in rc.local:

[CODE]# update-rc.d FOGMulticastManager remove

update-rc.d FOGScheduler remove

update-rc.d FOGImageReplicator remove

cat /etc/rc.local

sleep 5
service FOGMulticastManager start
service FOGScheduler start
service FOGImageReplicator start
[/CODE]

Not perfect but definitely working.

Maybe sort of a retry (x times) and wait loop could be implemented either in PHP or the init scripts…

@loosus456 said in FOG 1.5.0 RC 10:

But you can’t blame people for thinking that it’s dead when there is zero communication for over two months.

This is just not fair! Why would we still answer questions on the forums on a daily basis if this project would be dead?! Can’t believe you just said that. About the rest see Tom’s announcement…

Can you access the webinterface an check the hosts settings (Host Management -> edit host). See if there is any string (whitespaces??) in the “Host Kernel” field. Make sure this is completely empty. Then go to FOG Configuration -> FOG Settings -> TFTP Server. FOG_TFTP_PXE_KERNEL should be ‘bzImage’ and FOG_TFTP_PXE_KERNEL_32 should be ‘bzImage32’. I guess yours are empty?!