@Tom-Elliott I just had a look trough the code and added debug statements. Looks like the $foglang array is being initialized with string values before language is being set (setlocale). Have you got an idea when language support fully worked? I mean it does work for many of the texts but it doesn’t for $foglang texts.

I am wondering if we should move the setlocale stuff from ProcessLogin to FOGPageManager. What do you think?

We need a bit more information to know where to start

What version of FOG are you using What version of the FOS kernels are you using What target hardware are you using (manufacturer and model)

If you manually register this target computer, then schedule a capture or deploy (doesn’t matter) but before you schedule the task check the debug check box then schedule the task. PXE boot the target computer and after a few enter key presses you will be dropped to a linux (FOS) command prompt. At the FOS command prompt key in lsblk then take a clear picture of the results and post them here.

@jcabuco scenario 2: is your network or at least that port setup for STP? If so, can you enable rapid or fast initialization of stp, sometimes called port fast or rstp?

@Sebastian-Roth said in Partclone Upload Stalling:

@jemerson93 Please test the newly compiled 4.15.2 kernels you find here: https://fogproject.org/kernels/new/

Let us know if those help in speeding up the process and still don’t have the other rcu_sched stall issue.

Hi Sebastian,

It may take me a couple of days to get a response back to you. As soon as I can, I’ll do another upload and update you.

@PITSKing said in New FOG install, now can't find old image files in FOG:

If I get it wrong and it fails, can I simply edit the Image Type after the Image is created?

Yes you can! Compression level does not play a role on deploy but Compression type does, gzip vs. Zstd…

Upgrading the Kernel fixed this issue. I am not sure what version he upgraded to but I can now image these new computers. Thank you for your help @george1421

@dooleyrd We need the FOG log from one of the host’s failed attempts before we can tell you anything. It’s normally at C:\fog.log Please don’t snip a tiny piece from this file, but give us a whole client iteration - or the whole file.

@fenix_team Check for Apache errors that are written during an attempt to see logs via the UI. Also check free space on your fog server.
Also, just as a general rule you can re-run the fog installer when you have issues, it’s pretty good at fixing them. As always, I recommend a snapshot/backup before making changes.

Sounds good. Thanks.
I’ll give it a whirl and let you know the outcome / results. Apprec’ 😉

spanning tree, spanning tree la la la la la (jingle bells)
I’m saying this from 2 months 😄
I’m glad to read you saying it ^^

@lacaca Again, please post a picture of the error. We can’t help you otherwise.

Thanks @Sebastian-Roth

We did a remote session. Turned out there was an old fog-client installed on all the machines and for some reason the hosts kept on downloading and trying to install the new fog-client version from the server consuming a lot of traffic on the VPN link. Possibly some security software was preventing the installation though.

@george1421 Ah, i see. I was doing it with rsync in a cron job at the moment. I’ll try out your suggestion. Thanks for the info. 🙂

@Sebastian-Roth Yep! That fixed it!

Thank you.

Andrei

@foguser said in Client doesn't boot from FOG:

When i bootet it again, it did not care again and just downloaded the citrix nbp-file.

This is why I need to see the pcap file, not a picture of it but the actual file so I can peek at its bits. I need to see who is telling what to load.

opened up all ports on the fog server, to make sure nothing is blocked, but i was again only seeing dhcp requests and discoveries. Not to my surprise because the client does, as mentioned above, never try to boot from there.

The fog server is not in the picture at the moment. Right now the actors are the pxe booting computer and what ever dhcp servers respond to the target computer. FOG comes into play as soon as the target computer asks for the boot file pointed to by dhcp option 67. Your focus needs to be capturing what dhcp server is telling the client. That will be in the pcap. I only care (read want to see) the dhcp packets that is why I recommended using the capture filter of port 67 and port 68

@krejci said in Intel RST RAID volumes - missing drives:

When boot in debug mode and cat /proc/mdstat - nothing, also lsblk and blkid shows nothing.

This is interesting. lsblk should show the individual drives even if it can’t see the raid. The intel rst “fake raid” (should be properly called hardware assisted software raid) adds an abstraction layer between the physical disks and the OS (FOS in this case) to create the virtual raid disk. If these were standard drives in UEFI mode and this was a dell computer I would say changed the disk mode from “raid-on” to ahci mode. But in this case you kind of need raid-on mode.

Is this a dell computer? Does it have a bios mode? It would be interesting to see if FOS can see the raid disks in BIOS mode.

@martial The fog-client mostly fails with Middleware::Response Invalid security token. From that I see in our code this can only happen if there is a security token set in the DB for this host (identified via MAC address but it’s always the same as you re-use the same adapter over and over).

Well let’s see if we can figure this out in the DB:

shell> mysql -u root -p Password: ... mysql> use fog; ... mysql> SELECT h.hostID,h.hostName,h.hostSecToken,m.hmMAC,m.hmPrimary,m.hmPending FROM hosts h JOIN hostMAC m ON h.hostID=m.hmHostID AND m.hmMAC LIKE '%aa:bb:cc:dd:ee:ff%'; ...

Use the USB nic adapter MAC address instead of aa:bb:cc:dd:ee:ff. See if you get any results.

@Sebastian-Roth This is exactly what it was. I feel a little embarrassed haha. Thank you for your help