@kratkale Please update to the latest.

I cannot guarantee the 0 task will disappear, but I know there’s a bunch more fixes in place since 2571 (we’re at 5290 right now.)

FYI for anyone else running into this issue - I believe the problem was that I didn’t erase the /tftpboot images when I switched from http to https. I’m not really sure why that would matter, but when I did that, then re-ran the server reinstall and selected https, the images got but back in /tftpboot and my hosts didn’t see the mac error anymore.

@Priyankha We need a lot more details.

FOG Version

What bootfile is your boot server trying to send?

Is you server sending the right FOG server for option 66/67?

What OS are you trying to capture?

What does the error show or maybe a screen shot? (UEFI Boot looks different from Legacy boot from Mac from arm, etc…)

What type of machine are you trying to image?

What have you tried?

@JJ-Fullmer @edvandro This should be fixed in dev-branch as well, but I agree with JJ here, please upgrade to working-1.6.

@astrugatch Okay thanks and sorry there was that issue.

Can you pull and try installing again?

Thank you!

@Jeremy That capture is the answer we’ve been missing. Thank you — text from a terminal is exactly what I needed.

Read it with me:

13:58:46.427 and 13:58:46.457: two packets from 88:a2:9e:53:34:c0, 30 ms apart. That’s the Pi firmware’s DHCP: discover, then request. A clean, complete exchange in under a second (the offer and ack come back unicast, so the FOG server doesn’t see those, which is fine). 13:59:53.647: one packet. That’s during U-Boot’s phase. But your screen shows U-Boot broadcasting fifteen or more times across its retry cycles. Only one of them reached the network segment the FOG server is on, and that one wasn’t answered as far as U-Boot could tell.

So: the DHCP server is fine, the reservation is fine, ethaddr is correct (thanks for checking), and FOG’s side is proven. What’s broken is that almost every frame U-Boot sends is disappearing between the Pi and the rest of the LAN, while the firmware’s frames, seconds earlier on the same cable, all get through. That is not a FOG problem and not an OPNsense problem. It’s either the managed switch port treating U-Boot’s traffic differently (broadcast storm control, DHCP snooping rate limits, port security, or STP re-evaluating the port), or U-Boot’s Ethernet driver failing to put most of its packets on the wire. Both are real possibilities, and one test separates them, which is the one I asked for on the 4th and still haven’t seen:

Put a cheap unmanaged switch between the Pi and the wall. Wall cable into the little switch, Pi into the little switch. Power-cycle the Pi with the same tcpdump running on the FOG server.

If U-Boot’s DHCP now binds and you see its broadcasts arriving in the capture → the managed port is the problem. Give your colleagues the two captures side by side (with and without the little switch) and the port number; that’s everything they need. If it still fails and the capture still shows almost nothing from the Pi during U-Boot’s phase → it’s U-Boot’s driver on this board, and we look at which U-Boot build you’re running (version at the prompt, paste the first two lines).

One more piece for Monday, since it’s free: ask whoever runs OPNsense to look at its DHCP log for 88:a2:9e:53:34:c0 around 13:59:53 today. If OPNsense saw that one packet and sent an offer that never made it back, that’s the switch dropping traffic in both directions, and it’s another line of evidence for the port.

@maxcarpone I would ask you, if you’re daring/willing (it’s considered beta but uses the same pipeline with a lot more modern ui, I need people testing, and Fog_newb can likely attest the new ui look and feel though I think they ran into an issue and needed to get functional right away so the snapshotted back)

Upgrade to working-1.6.

I have a goal (along with @JJ-Fullmer ) to try to get working-1.6 to be master/stable branch by October.

1.6 has been “stagnant” since around 2017 and was in relatively stable grounds back then even.

With AI (as you undoubtly can see I’m using to help drive some things) it’s allowed us to get a lot more coding/refactoring and will hopefully present a much better experience of things on the UI side. Without testing I cannot fix UI bugs though.

AI can do some cool things, but it doesn’t know what “wrong/right” looks like, and JJ and I are only 2 people.

There are others on working-1.6 but more feedback is always good.

Thank you Tom, I got updated to Working-1.6beta.4105 and that issue is fixed. Not sure if it is just this particular install or not.

Some Issues I am noticing is Host registration is not showing up whether from the fog menu or the client. I can see it is trying but does not appear to be writing to sql.

36f170d3-0a3b-4de3-b327-4233bc53534b-image.png

Deployment: Getting invalid mac errors it seems on all devices. The task seems to be populating alright.

No viable macs to use

And I can’t add any hosts—whether via the web interface or by booting over the network—; ultimately, the new host doesn’t appear in the database…

Failed to query: Error: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect integer value: '' for column `fog`.`moduleStatusByHost`.`msHostID` at row 1 Error Message: Error Code: "22007", Error Message: ["22007",1366,"Incorrect integer value: '' for column `fog`.`moduleStatusByHost`.`msHostID` at row 1"], Debug: SQL: [629] INSERT INTO `moduleStatusByHost` (`msHostID`,`msModuleID`,`msState`) VALUES (:hostID_0,:moduleID_0,:state_0),(:hostID_1,:moduleID_1,:state_1),(:hostID_2,:moduleID_2,:state_2),(:hostID_3,:moduleID_3,:state_3),(:hostID_4,:moduleID_4,:state_4),(:hostID_5,:moduleID_5,:state_5),(:hostID_6,:moduleID_6,:state_6),(:hostID_7,:moduleID_7,:state_7),(:hostID_8,:moduleID_8,:state_8),(:hostID_9,:moduleID_9,:state_9),(:hostID_10,:moduleID_10,:state_10),(:hostID_11,:moduleID_11,:state_11),(:hostID_12,:moduleID_12,:state_12) ON DUPLICATE KEY UPDATE `msHostID`=VALUES(`msHostID`),`msModuleID`=VALUES(`msModuleID`),`msState`=VALUES(`msState`)

@Tom-Elliott thanks Tom - using the excellent fog-docker from 88fingerslukee - so will wait to hear his response

@Tom-Elliott I did update to version 1.6.2254 and the first multicast that worked was the first one I tried after the upgrade. This second one is now hanging like the one that prompted this thread.

Where in the logs can I find any clues?

What version of FOG are you running?

@rpycroft Please attempt to update to 2231.

@toschulz So I suspect the problem is due to a divergence of db schema between dev-branch/stable + working-1.6

If you can update yoru Mysql directly:

sudo mariadb -u root fog (if no root password of course - if you have a root password add -p

UPDATE schemaVersion SET vVersion=0;

Then refresh your screen, click the install/update, and hopefully the error will go away.

The way the schema is configured is it will attempt (idempotently) to rerun every single SQL query in the schema chain.

This should fix the problem you’re seeing.

I believe there’s a column on the login history piece being requested that may just simply be missing which would cause the issue with datatables.

I have figured out the issue. I was looking in the wrong place in BIOS for the secure boot setting which was on. Turning off secure boot fixed the process which runs perfectly now.

@Tom-Elliott Hello Tom yes I have installed the compatible Fog client from the Fog server on the reference machine, sys prepped and captured the image and now I am deploying.

@Strahd Have you been able to make progress?

@DiegoP I believe mdadm will still be allowed to work, but I think you’re supossed to use “mdraid=true” for a kernel argument. If this is not set, FOG won’t know to build the array. This would help explain why the disk couldn’t find a partition layout as well since it’s expecting to be part of an array (which then looks/acts as the disk you’re truly working with.

As for “partclone to partimage” I’m not sure I understand.

Fog moved FROM partimage -> partclone way back in the 1.0.0 days as partimage has been obsolete for quite some time now.