@pdit Well, not knowing your setup in all details makes it hard to guess about the reasons.

Do you have different versions of FOG running on those two different servers?

@Tom-Elliott @george1421 Yes adding more room shouldn’t hurt. But could you please tell me where you see an error happening which leads you to think that there is a space issue within FOS? I can’t see it.

Edit: Never mind, I just saw the other topic. Building new inits with 256 MB size right now. Will take roughly four hours to complete. Will update the official binaries on the web server soon.
I wonder why I didn’t get (or notice) those errors when doing the tests on my VM?!

About the UUID issue, let’s first gather some more information before we decide what to do. @Junkhacker Would be great to get the two command outputs, thanks!

Please let us the UUID things here so we don’t loose the focus in this topic! @george1421 Did you figure out why you got different results than @Junkhacker when trying to deploy “old” images with partclone 0.3.12?

@tandersb Can you please post a picture of the error.

@michaeloberg said in Smartinstaller Client not joining computers to Domain after imaging:

Logon failure: unknown username or bad password, code =  1326

The error is pretty clear. Username and/or password don’t match the credentials needed to join the machine to the domain.

We had some rumor about special characters in the password causing an issue with domain join but were never able to nail that down. See here: https://forums.fogproject.org/topic/12407/active-direcory-join-fail-bad-password-1-5-4/7 and https://forums.fogproject.org/topic/11692/active-directory-join-failing

As well you might want to read through this topic: https://forums.fogproject.org/topic/11137/ad-join-works-with-legacy-client-fails-with-new-client

Follow up here: https://forums.fogproject.org/topic/13218/smartinstaller-client-not-joining-computers-to-domain-after-imaging

@processor Please download the latest init files (32 bit and 64 bit) and put those in /var/www/html/fog/service/ipxe/ (rename the originals for the time being).

@dambron Yeah, Quazz is totally right. We have updated the init files and I totally forgot to ask you to try out the most current ones (32 bit and 64 bit). Hope this will fix the issue for you.

@Junkhacker Thanks for the picture. @Quazz Is exactly right about this commit having removed some of the UUID stuff as I noticed that we created an unnecessary file with UUID information that we have available in sfdisk output already. Therefore I went ahead and removed all the extra UUID stuff.

Can you please do me a favor and do a debug capture on your master client. When you get to the shell run blkid -po udev /dev/sda | grep "PART_TABLE_UUID" as well as sfdisk -d /dev/sda | grep "label-id" and post outputs here.

Great you guys have figured this out!!

@Rebelman I am ob the road and can’t post a long answer right now. Looking at the boot.php output you posted I already see that there seems to be an issue with the iPXE code generated. I will have a closer look when I get home tonight.

@michaeloberg Please post the contents of the log file from the client (either in C:\fog.log or C:\Program Files (x86)\FOG\fog.log).

@G-M Allow me another question. Have you run the database maintenance commands yet? Find those in our wiki…

@dambron Ok, that all seems fine so far. I still can make heads or tails of this. Can you please do the debug capture again and step through till you see the message Processing Hard Disk: /dev/sda and then take a picture again.

As well please post the contents of /images/<IMAGENAME>/d1.original.fstypes here.

@pdit said in dhcp issue:

Realtek RTL8111GN

Searching the web for this NIC I find many people having all sorts of issues with this!
https://www.unixblogger.com/the-pain-of-an-realtek-rtl8111rtl8168-ethernet-card/
https://ubuntuforums.org/showthread.php?t=1793279
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1007236

So you are right. It seams model specific. Not sure when I will find the time to build a kernel with a modified driver version. Not sure if we want to maintain a different driver version anyway.

@dambron Ah well, why go to bed if digging through the script code is just so much fun… Please schedule another debug capture task. When you get to the shell run the command fog to start the capture as usual but in debug mode you need to manually step through pressing ENTER for every action. When you see the line Saving original partition table..... take a picture of the screen and post that picture here.

@dambron Ok, thanks. Looking good so far. I will take a look at the scripts tomorrow and see what I can find.

@Rebelman One last thing I forgot earlier. Please open this URL in your browser and post the full output here: http://10.254.1.20/fog/service/ipxe/boot.php?menuAccess=1

@Rebelman Great you took those videos. Well done!! It’s way easier to follow than reading text and trying to wind my head around what is being said.

So first thing I noticed is that in the text output where it asks you to press a key to get to the menu I see ESC on the UEFI machine and Escape on the legacy machine. I still can’t make sense of this difference and so allow me to ask if those two clients surely booted from the exact same FOG server? Looking at the text output I should be able to see if they both boot from the same IP but the text is too blurry on the UEFI boot video that I just can’t say for sure it’s the exact same IP they boot from. Just want to make sure it is.

Second we see that both systems seem to boot from a hidden menu. But the option is not set in the web UI or the database as we checked. Did you ever intend to hide the FOG menu? Do you remember since when it is like that (need to hit ESC and enter password to get the menu)?

Just to make sure we are not hunting down the wrong track here, can you please grab a copy of the file /var/www/html/fog/lib/fog/bootmenu.class.php, upload it to a file sharing platform and post a link here.

Ok, watching the videos over and over I have a feeling that the difference between legacy and UEFI is that loading the kernel/init (FOS) after selecting Full Registration from the menu simply fails on UEFI and because of that you are thrown back to the menu (which is black and white due to a minor issue we have in the code - should fix that but it’s not causing an issue for you here). So the big question is, why does loading the kernel/init actually fail on this UEFI machine??? It really shouldn’t as this is working for so many other people on UEFI machines. Do you have other UEFI models around? Can you please test if you have the same behavior with all UEFI machines?! Also check if there is a firmware upgrade for this particular machine model you see the issue with.

I have to say again that this would not have been possible without you taking the videos. There are small bits of information I can get out of such a video that we would not be able to get to by me just asking questions and you explaining what is going on.

I’m wondering if I should just do a reinstall on my server and start fresh

Maybe this might help in the hidden menu issue but it most probably won’t change anything for the UEFI booting issue. I am still in hope that we can figure out the hidden menu thing without you re-installing the server.

@dambron You need to hit ENTER twice to get to the shell and only then run the command below mentioned.

@dambron In this case where you only have one single partition we seem to have an issue in the capture scripts. It shouldn’t mark it as fixed partition. I think we have another user who reported this last week but I have not had the time to further debug this.

I was hoping that George might be right about it not properly detecting this as a NTFS partition but as the image on the server is around 16 GB it’s not likely to be captured as raw.

Please do me a favor, schedule another capture task on your master but this time tick debug option. Start it up and when you get to the shell run blkid -po udev /dev/sda1, take a picture and post here.