Posts made by EspenU

@Tom-Elliott
I have no idea how to read regular expressions, but the way I understand your post is that from 1.4.0 it will be possible to use image path names that include - and . again? If so, that’s great! Thank you very much :-).

Server

• FOG Version: .1.3.3
• OS: Ubuntu 16.04 LTS

Client

• Service Version: N/A
• OS: N/A

Description

In previous versions of FOG it was possible to use image path names with “-” or “.”. This does not seem to be possible any more. The question is, why is this no longer possible, and is there a work around?

Only using underscore in an image path makes a long image name hard to read (at least for me as I hate using underscore).

I’ve tried to find if this has been mentioned or asked about previously (which it probably has), but I’m just not able to find it.
This is of course not a critical issue, just nice to have.

@Tom-Elliott said in 1.3.0 installer does not handle class B IP's correctly with DHCP:

@EspenU right but the ip and subnet are determined by what’s defined on the nic when you run the installer. While you can change these things I think your seeing class c subnet is because that’s what the nic was set for.

Dammit you right. The first installation was probably run before a static IP was set on the server. That explains a lot.
Thanks for your help. Sorry to have bugged you with such a silly mistake.

@Tom-Elliott said in Boot issues with UEFI32 & x86_64 CPU:

And pictures might go a lot further than trying to describe it, either pictures or a short video would go a long way for us to better see the issue and hopefully figure out a solution.

I’m going to move this post into FOG Problems as this, from what I can tell, is NOT a bug at least where fog is concerned. Of course, please provide a browser output of what’s being presented as well.

I think you could do this with:

http://fogserver/fog/service/ipxe/boot.php?arch=x86_64&platform=efi

I’ll try to compile some more information during the week so it’s easier to see.
However, since it’s possible to work around the issue by changing the default kernel it might be just as good to use that as a “solution” and close the issue.
This strange combination of 32-bit and 64-bit hardware is probably not very common, and for those edge cases it should be fine just to force the 32-bit kernel.

Thanks for your help :-).

@Tom-Elliott said in Boot issues with UEFI32 & x86_64 CPU:

Location is:

FOG Configuration Page->FOG Settings->TFTP Server-> FOG_TFTP_PXE_KERNEL FOG_PXE_BOOT_IMAGE

Just change bzImage and init.xz to bzImage32 and init_32.xz respectively.

I’ll try that. Thanks.

@Tom-Elliott Right, sorry about that.
What happens when it “does not go very well” is what I described further up in my post.
It just jumps back to a non-graphical version of the FOG boot menu. No errors or messages of any kind as far as I can see.

@george1421 I can try that later today to see what happens. Although it will not work as a production solution since I will be imaging around 100 of these per year…

@Tom-Elliott Ah, yes I see your point that there might be situations where you would want it to load a 64-bit kernel even if you’ve loaded a 32-bit ipxe.efi.
In my situation that does not work. The PC cannot handle a 64-bit environment, even though the CPU is 64-bit… So the arch check done in default.ipxe is “correct”, but it just will not work for this PC…
Hmmm… Then I might have to live with having a modified default.ipxe, since other PC’s seem to work fine with it as well.

If you’re still confused, I can try to explain it again from scratch, I’m just having a hard time finding the right way to describe it…

@Tom-Elliott The server IP is 172.16.200.251. The DHCP subnet section does not directly set the range, it only says in which subnet the range is located. At least that’s how I understand the config file, I’m no expert.
The range is specified further down in the same subnet section, so that’s where you would have to make sure that there is no conflict with the server IP.

Server

• FOG Version: 1.3.0 RC23
• OS: Ubuntu 16.04 x64 server

Client

• Service Version: N/A
• OS: N/A

Description

When installing FOG and setting the IP for example to be 172.16.200.251, then it sets the wrong subnet.
Class B subnet should be 255.255.0.0, but it’s set to 255.255.255.0 in the “.fogsettings” file.
If the “.fogsettings” file is corrected, then the installer writes wrong values to “dhcpd.conf”.

In my example, the DHCP range was set to 172.16.38.10 - 172.16.38.254.
In “dhcpd.conf” the “subnet” section was set to:

subnet 172.16.0.10 netmask 255.255.0.0{

This causes the DHCP server fail a syntax check on the config file. The correct line should read:

subnet 172.16.0.0 netmask 255.255.0.0{

Server

• FOG Version: 1.3.0 RC23
• OS: Ubuntu 16.04 x64 server

Client

• Service Version: N/A
• OS: N/A

Description

I’m working on a touch screen panel PC that is giving me a LOT of headaches (not only FOG related).
Although it’s using an x86_64 CPU, the rest of the PC is 32-bit. So it needs to boot a 32-bit kernel.
It boots to the FOG menu fine, so far so good.
But if I try quick registration from there, it loads a couple of files, and then jumps back to a non-graphical version of the menu.
Other PC’s can do quick registration without any issues.

Eventually I managed to figure out what goes wrong.
The DHCP request from the PC sets the correct arch and loads i386-efi/ipxe.efi.
In the “default.ipxe” file the first line sets the arch again. But it checks what arch the CPU is. Since the CPU arch is x86_64, the system assumes from there on out that it’s a 64-bit system and loads 64-bit files.
This of course does not go very well and it fails.

My temporary solution has been to modify the first line of “default.ipxe” to only read “set arch i386”.
So… Can this check be improved to check the running kernel arch instead of the CPU arch?