Just as Tom said I’d also suggest creating a fresh one. Probably costs you less time and nerves. But if you are keen to give it a go I’d suggest doing this “by hand” instead of using FOG just in this particular case. While we use partclone in FOG I am sure there are other tools available that are good at retrying bad sectors over and over till data can be read. Here are some basic instructions from someone who tried it using clonezilla which in fact also uses partclone. But this way you can use special options as you like - options that we don’t use in FOG.

There are a couple of examples here in the forums. e.g.: [url]http://fogproject.org/forum/threads/boot-menu-iso-file-size.12442/[/url]

@astrugatch said in FOG 1.5.6 Officially Released:

Does this only happen on first install? I did an upgrade from 1.5.5 and didn’t see this question.

You are absolutely right. Seems like I have missed this important case altogether, arggghhhh!

The easiest route for you is editing /opt/fog/.fogsettings now. After running the 1.5.6 installer once you should have an “empty” hostname setting in there: hostname='' -> Just change the hostname to whatever you want it to be and re-run the installer.

Pushed a fix to dev-branch. Hope this is appropriate for the next releases.

Edit: More fixes pushed after testing this.

So I guess we can mark this solved for now!?

@cjenness In the FOG web GUI click on one of your hosts or groups, then click ‘Basic tasks’ on the left and ‘Advanced’ to show all the tasks available. Do you see “BootTask” here?

We might be able to help you make FOG run with you Lenovos but you’ll have to provide more information first.

What kind of Lenovo is it? Model number? or at least the exact name/number and model of the network card used in those machines?

And please provide more information about what is problem or error you see? We cannot help you if we don’t know what exactly is going wrong!

Which topic did you read? URL?

@astrugatch Sorry for my late reply. Just too many other things so I set this aside for a bit…

To be clear I’m mostly speaking about the web UI right now.

Ok fine. I will work on adding that to the installer in a way that more people might use it.

But the client would be important too.

What exactly to you mean? We do state of the art encryption between fog-client and FOG server ever since the current fog-client was released (compared to the old legacy client). Anything more we need here?

The way JAMF handles the migration is that it continues to use its internal CA and distributes the new cert to the machines on check in. It keeps track of those that have received the cert and compares that to its list of enrolled machines. When all machines have received the cert there is a UI element that goes from red to green letting you know that the server can now be switched to communicate via the external CA.

Yeah this is highly advanced certificate handling that I would love to add to FOG but probably won’t find the time to do so any time soon. We are on the very edge with way too little work force working on FOG.

I’d prioritize the mentioned database password security now. Follow up topic here: https://forums.fogproject.org/topic/13267/database-security

@d4rk3 Are you still seeing any of the issues after updating to the latest trunk?

@TCS_Taylor The PHP giving you the iPXE boot information is /var/www/fog/service/ipxe/boot.php. You can access it simply using your browser http://172.28.6.149/fog/service/ipxe/boot.php
This will show you the default iPXE menu for unregistered clients. If you want to see the code for a particular client you need to add it’s MAC address as GET parameter, e.g. http://172.28.6.149/fog/service/ipxe/boot.php?mac=00:0c:29:c6:61:5a

As far as I can see there is no MMC support compiled into the current FOG kernel. I guess you are the first one asking

See here: http://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/kernel/TomElliott.config.64

...
# CONFIG_MMC is not set
...

I guess Tom will happily add MMC support and compile a new kernel in the next few days…

@NTLINUX Yes right, fresh installs are not affected by this! Fresh installs on Ubuntu with 1.5.7 work perfectly fine.

We just fixed an issue with Multiple Partitions - Single Disk. Please update to the very latest and see if this helps!

Edit: As both upload and download in resizeable mode seam to fail with the same error you might want to modify your init.xz to see the actual error produced by sgdisk command. Edit usr/share/fog/lib/partition-funcs.sh (somewhere around line 645) and remove >/dev/null 2>&1 from the end of the sgdisk call(s). You should see real error message then. Hopefully we can figure things out then.

@zingaro I think you misinterpret the option. To quote Tom (see here

What ignore for imaging does is make sure that nic does not get used as the method for checkin and progress.

This option is for clients that actually have more than one MAC address. In this case things can fail if the client uses the wrong MAC/adapter in the imaging process. Checking the option will make this particular client to use the other (unchecked) MAC/adapter for imaging.

So back to the initial question: Imaging an unregistered client is only possible in the boot menu AFAIK.

Make sure you got the braces right! {$fog-ip} will not work IMO. But ${fog-ip} should.

Otherwise you could try using ipxe’s variable set, see here: http://ipxe.org/cfg

Maybe ${next-server} is working for you?!

@astrugatch Quazz is spot on with what he says.

Change the exit style for this machine (or general settings) from GRUB to EXIT…?

@Pikmin Which version of dnsmasq are you using? I am sure you’ve read the section “Compiling dnsmasq 2.76 if you need uefi support” in the wiki article you posted!?!

Maybe I am wrong but as far as I know FOG (1.2.0) does not add other repositories (like PPA)!

With saying this is not a FOG issue I don’t mean that we don’t want to help. It’s just that we know a lot about FOG but heaps less about the inner workings of ubuntu. Maybe you can get more help asking this (PHP package question) in a forum focusing on Ubuntu.

Looking through the output you posted I just found this: Impossibile allocare memoria
Maybe your disk is full?? What do you see running this command:

df -h

@lebrun78 Just be aware there is no way back to the 1.5.x version of FOG if you switched to working-1.6 now other than very messy manual manipulations in the database. We are working towards 1.6 and hope to have most users upgrade at some point. So I am not saying you shouldn’t. Just want to make sure you understand the consequences.

In the error.log it says:

...
Package dhcp-compat-12:4.3.3-8.P1.fc23.x86_64 is already installed, skipping.
...

According to this the package is only of temporary existence:

This package only exists to help transition dhcp users to the new
package split (dhcp -> dhcp & dhcrelay).
It will be removed after one distribution release cycle, please
do not reference it or depend on it in any way.

Seams like this was introduced in Fedora 22. I am wondering why we didn’t hit this earlier?! Does removing dhcp-compat before running the installer help?