Posts made by Sebastian Roth

@george1421 said in Dell 7730 precision laptop deploy GPT error message:

Do we have empirical evidence that these disks are being swapped as being reported by the uefi bios?

See @jmason’s lsblk listings. From my point of view this is evidence enough. The disks are different size and do swap. As far as I got the postings it seems like the output was always taken on the same deploy system. One time 477 GB drive is last and the other time it’s first.

The Precision 7730 generation is pretty new, so the first thing I would check/watch for is firmware update availability.

Definitely a good point!!

It would be interesting to compare the FOS boot logs between the two states to see if there are any telling events.

Good one as well! @jmason Can you please schedule a debug deploy job. Boot that machine and run dmesg | grep -i nvm. Take a picture and reboot the machine. When you are bacl to the shell, again dmesg | grep -i nvm and take a picture. Do this maybe ten times to see if we see a difference there.

@jmason Hmmmm, the more I read the less I think we can do something about it. This is not something FOG or the Linux kernel is doing wrong. It’s more or less a combination of how the Dell UEFI firmware hands back the NVMe drive information to the Linux kernel. One boot it’s this way round and the next boot it might be the other way. When installing an OS on disk this is not much of an issue because you have partitions with UUIDs and labels on the disks and those can be used to identify which partition to mount for booting the OS. But in case of cloning we have a laptops with different physical disks (and identifiers) so there is no way we can use that information.

Possibly we could save the sector (or disk) size information in case of “Multiple Partition Image - All Disks (Not Resizable)” but then what happens if someone comes along with two identical size disks in their machines?

Hmmm, need more time to think about this. @george1421 @Wayne-Workman any ideas from your side?

Edit: By the way… I can imagine this being an issue when capturing the image as well. One time d1p* are from disk A and d2p* from disk B and next time it’s in reverse.

@jmason Thanks for testing. I’ll see what I can do for you. Guess I will take a bit of time to figure something out.

@jmason Yes, possibly (hopefully) this is something being more or less an issue of NVMe drives. Haha. Well, I’ll keep my head spinning on how we could possibly solve this as we have no influence on the order the Linux kernel enumerates your disks. We’d need to save disk identifier and store those with the image… I suppose.

@george1421 On the other hand I am wondering why we have not had other people reporting this in the past. What if you have a PC with two drives, one for OS and one for data. You only ever want to image the OS disk but could happen that you deploy to the data disk?! Just thinking out loud here.

@jmason I can’t give you a reference on this but it’s actually a likely cause (one that I have not though of before, grrrhhh) that disk enumeration can put your two disks in reverse order. This is known in Linux and usually circumnavigated through persistent block device naming.

Try deploying a couple of times in a row always using the debug mode and run lsblk before starting the task. See if it’s exactly how we imagine it to be (changing disk order).

@xburnerx00 Just got an idea. What size is that ZIP file? Possibly it’s “too big” for the server to handle in a certain amount of time and so it quits the connection. Have you tried a normal snapin (not pack) with let’s ay a one mega byte small executable to deploy to a client via snapin? See if that works.

@Gdelcimp Maybe I get this wrong but it sounds as if you start a normal group deploy instead of a group multicast deploy. I can imagine all of your computers doing single cast anyway. Do you see those 10-12 that start early go pretty much in sync? I mean do they all proceed in very much the same speed and on the same sector/byte count?

Make sure you use this icon (or it’s equivalent in the Basic Tasks) to start a multicast session:

If you are absolutely sure you created a multicast task then you might wanna take a look at the log file. Run tail -f /opt/fog/log/multicast.log in a command sehll on your FOG server before you schedule the session and then keep an eye on the log…

@jmason Well seems clear enough to me, is the source disk larger than the destination disk?

@Gdelcimp Have you ever tried to create a new group, add those hosts you want to image to that group and schedule a multicast deploy task for that group? Do you see the same thing happening when using a group multicast?

@xburnerx00 Hmm, the logs show some interesting things but from what I see I don’t thinks this will lead us to what is causing this.

First let’s try to tackle this from a different angle. Can you please create another snapin but use a simple one this time - not snapin pack. Just to see if that makes a difference. I kind of doubt it, but let’s see.

As well please try following the log files while the client is trying to pull the snapin, just to see if you get any messages in the logs while this is happening. For that have your client ready and use the command to watch the log files on your FOG server: tail -f /var/log/httpd/error_log /var/log/php-fpm/*.log (now hit ENTER a couple of times so you see when new lines of logging come in and schedule a snapin task for the client - check the client logs as well so you know when it happens)

@martial First let me give you a more general answer to your request. FOG came to life when every machine still had an internal ethernet adapter - I know this sounds a bit like dinosaurs roaring but hey - so the MAC address was used as unique identifier of machines.Over the years more and more devices without ethernet came out and we had a first go at switching to a different unique identifier that would be machine specific but not (only) using its MAC address. You can find discussions on this topic in the forums. The end of the story as of now is that we were running into major issues with the other unique identifier and decided to stay with the MAC address for now. It’s a huge change within FOG and we don’t seem to have enough time to go ahead with this change - development, testing, user support… It’s all a big story.

Ok, enough of that, back to the point. Re-using the same ethernet adapter (MAC address) is essentially breaking FOGs logic of identifying machines. I am not sure but I think most people using FOG this way don’t use the fog-client and therefore don’t run into the same issue as you are. Imaging usually works just fine.

I am not saying that AD join is impossible but I have not looked into it myself to have a solution for you at hand. There might be other tools around that can be used to make Windows join a Domain on first boot or something like that.

now I have problems with the security token and repeated mac address

You might also want to take a look at the database entries to see why you seem to have duplicate MAC entries in there. As well please share the full client log so we can have a look. Possibly it’s something else causing the problem.

@jmason How did you schedule the task? Just go to the host’s settings in the web UI, click Basic Tasks, deploy and just before you create the task, tick the checkbox for debug. This way it very similar to a non-debug deploy but the difference is that you have to start manually (by running the very simple command fog - should work if you schedule the task as described!) and you are asked to step through the whole process instead of it going without interaction. Give it a try.

If you have scheduled the task as described already, then I am wondering if you do PXE boot the laptop or USB boot?!

@Taspharel Have you searched the forums for “rcu_sched” yet?

@totoro Sounds like you have a rough DHCP server somewhere in your network! Read about this topic on the web and try to find it.

Yes it’s true, but the message is the same,

I am fairly sure the IP address is also different!!! Next time post your own picture!

@xburnerx00 Thanks for posting the log file picture. The line about hostname can be ignored. But there are a couple of important lines like “Error dispatching request to”. This is a real issue. It’s strange you seem to be able to use the web UI! On first sight of this errors I’d have expected the PHP-FPM process to be dead. But it’s probably not.

What kind of Linux OS do you have? Please see if you have any kind of /var/log/php*-fpm.log and post contents or picture of that here.

Also, I do not know if it’s relevant but I have a red circle with a white ‘!’ on the host management list in the web gui saying “No such device or address”.

Not related and not an issue. Just means that FOG is not able to contact that client via port 445 (Windows stuff). This online check was added in FOG long time ago and is often failing because of Windows firewall or other means of port blocks.

@jmason What I meant was that you cannot actually tell FOG you have a multi OS setup on your machine. Still doesn’t mean that FOG cannot handle it. In many cases it works pretty well. Even more nowadays when you really have a true UEFI install with GPT, EFI boot partition and no need for MBR loaders.

I have not though of it this way but possibly you could make it two different images. But I would not want to go that route cause you would have to task your machines twice then.

@totoro Do I get this right? Did you re-use the picture from this post here https://forums.fogproject.org/post/116007 ??

Please take a picture of the actual error on the screen of your client and post here. We can’t help you if you don’t give us the exact details. Most instructions on debugging and assumptions on the actual error are based on the information you give. If it’s just “looks like this” we might be way off!

@jmason You seem to get into the details of FOG fairly quickly! Well done. It’s great to see people reading the docs and forums and making their way. Let’s see, where shall I start.

PartImage - switches on its own to Partclone Gzip after I attempt to deploy a captured image.

Partclone Gzip is definitely the better choice. I know we still had an issue in FOG 1.5.5 which made it default to Partimage on a fresh install. You don’t really want that legacy stuff. Use Partclone Gzip oder Zstd.

but there is no OS Dropdown selection item for a multisetup

Absolutely right and I’d really like to add that at some point in the future. But it makes things a lot more complex and therefore we have not added it yet. In very many cases one or the other OS choice is working for multisetup but sometimes needs a bit of adjustment. That said, it’s still possible that FOG is not able to handle your setup (combination of boot loaders, partition layouts and all that) yet but if we find out what’s wrong I am happy to add a fix!

So during the deploy PXE boot with Linux(50) selected as the OS, I receive: …

Let’s try to tackle this. Please schedule another debug deploy task. Start up the client and fire up fog when you get to the shell. Step through and when you are back to the console after the error please type sgdisk -gl /images/DELL7730_Win10_Centos7/d2.mbr /dev/nvme1n1 (most probably returns an error as well. Please take a picture or copy&paste the error message if you are connected via SSH to the client)

When selecting Windows as the OS for the image it appears to get further…

That’s kind of interesting. While I have not had the time to actually look through the scripts to figure out the difference I find it funny that it proceeds but later on seems to have restored the partitions but is failing to actually push out the contents of the image files to those partitions. This part might be harder to debug so I’d stick to OS=Linux (50) for now. Let’s see how far we get.

OS=Linux (50) should handle Linux legacy BIOS (MBR) boot loaders a bit better by the way. You say you think it’s true UEFI. So maybe this stuff is not much relevant at all. Well, let’s see what you get from the debug session mentioned above.

@xburnerx00 While I am not exactly sure what’s going wrong I might suggest you have a look at the apache and php log files (see my signature) to hopefully get a better idea of why it returns a HTTP 503 error.

You can also try to open that exact same URL in your normal browser to see if it leads to the same error.