Posts made by geardog

It sounds like your VM handler doesn’t know how to boot off PXE. I had to fiddle with VBox some to find the right NIC settings, but I was able to PXE boot VBox eventually. If your physical boxes can do it, FOG would seem to be up and functional.

I’ve captured most of the boxes around the house, but a couple of them don’t appear to resize. FOG tells me I’m capturing 232GB images.

During capture the bar says it is basically done at 122GB.

Image lists show it at 232GB

The folder shows something like 42GB

I’ve run cleanup, chkdsk, & defrags. These boxes aren’t encrypted.

Any tips to get these to behave/report properly?

@george1421

Tried disabling Spanning tree with no effect.

It turned out to be a bios/UEFI setting “option rom launch policies.” New to me. In my defense, this box’s bios is pretty massive and clumsy to navigate through, but works now!
I feel stupid, but my issue appears resolved! Thank you very much George. I might not have ever stumbled through those screens again if it weren’t for you.

As an aside, the MAC address cloning is a little odd as fog find and tries to get an IP on the wrong NIC first, before it gives up and tries the next NIC.

@george1421
I hadn’t considered a MAC mismatch. This box has two NICs (one to control some equipment). They BOTH have the same MAC address… So maybe the box is trying to configure the first NIC that is only connected to a machine. Of course no IP will be given. Should I spoof a MAC for the “internet NIC” and enter taht in the host record? Will this method confuse FOG?

Details on this NIC say it supports pre-boot, but also speaks of available option ROMs. I’m not familiar with much of what I find in this document. Clueless here.

https://www.intel.com/content/dam/www/public/us/en/documents/faqs/ethernet-controller-i210-i211-faq.pdf

I might just swap out the NIC, but I don’t honestly know if it will make a bit of difference.

So this is an HP workstation with an I210-T1 NIC I’m trying to image. It is UEFI, and I don’t make it to the FOG boot menu. Instead I get this:

I added vendor codes to the DHCP / windows AD setup ages back, and all that is foggy. I can say that other UEFI boxes image ok.

Any advice on how to get PXE up on this one?

@Sebastian-Roth

lspci -nn showed the drive to be in raid mode

using a tutorial on bcdedit via cmd for safemode boot I was able to change the setting without reinstalling windows

now the machine is imaged

resolved and thankyou

coming back to this with a fresh mind and some new info helped

@george1421
Back at it. One of the other hats I wear got in the way.

I’m on FOG 1.5.4 \ kernel 4.18.3

As requested…

Any hope of getting this NVMe to show up?

also … on pxe boot this comes up … significant?

This error occurs when trying to catalog a PE1950. I find it a little odd, as I have cataloged and deployed to another PE1950. I have, however, upgraded FOG since then. I’m running fog from a PE2950, on ver 1.5.4 and using the latest kernel (images from 4.18.3).

I found similar topics, but cringe a little at modifying the boot image. Any other thoughts?

https://forums.fogproject.org/topic/915/where-do-i-place-firmware-so-fog-can-use-it-during-imaging?loggedin=true

https://github.com/FOGProject/fos/issues/11

Just drop firmware file in /lib/firmware/ ?

@sebastian-roth

I just happen to be harvesting 1TB drives from workstations for server use. The 250GB drives I picked up for $10 each are adequate for the floor computers.

Thank you for the firm point at cause.

@george1421
I had a handful of the target drive model. I used the same drives I attempted to use as a deploy target to start over. I reinstalled windows on one of the handful of 512 sector drive, and managed to capture and deploy flawlessly to the same box (a Dell Inspiron 3650).

I then started over trying to capture/deploy the OEM drive/install to help debug the issue. I still can’t deploy an image of the OEM successfully. All of this has been on the same box.

The error came in when capturing a 4k sector drive and deploying it to a 512 sector drive. This failed in the same way repeatably. This scenario is what I’ve documented here in various ways. The last pictures are of the originating 4k 1TB OEM dell install drive, next the error on deploying the capture of that drive (that was listed as a successful capture), and finally a debug deploy showing the resulting partition info on the intended 250GB 512 target drive.

In case there is desire to sort out what was going on I ran through the attempted capture/deploy of the original disks. Hoping I’m giving the info asked for.

This is the disk I captured.

This is the error I got deploying was:
“no image files found that would match the partitions to be restored”

This is the debug info I got of the target of failed deployment.

Update:
The box itself clearly hasn’t been the issue. I’ve done a fresh install of Win10. It captured and deployed successfully to the same target drives. The computer handles 4k and 512 drives fine.

With the hopes of clearing any confusion, I used diskpart to clean the 250GB drive that was mis-sized with the protected GPT partition mess. It was then 238GB unallocated, which I tried to deploy the 65GB image to again, with the same results.

I’ve not adjusted anything. This machine is how Dell shipped it. It is a box with UEFI. “Windows tried to fix gpt but nearly fails…” doesn’t make much sense to me, as all of this is outside of windows. The only time windows has any play is when it is booting the original working drive, at which point it works fine. I attached the intended target drive (after deployment failure) to a running windows box to see that mis-sized 1TB protected gpt partition business. As I haven’t successfully cloned the drive, I’m not keen on fixpart’ing it. Maybe tomorrow I’ll call it quits, and just install fresh on another drive, leaving this odd issue to experimentation.

I can boot from fog either uefi or legacy, but native is surely uefi. I get the same squashed image results.

EDIT: Ah, you’re curious about output of fixparts on the target drive, I suppose. I’ll try it tomorrow.

@george1421
You have it correct. Compressed, it adds up to 65GB. It is an OEM layout that probably has a recovery partition, that I’d hope to never deal with really. For “siplicity” I hoped to just grab and go dealing with the extra data.

@Sebastian-Roth
That is a good thought! I’ve never run into compatibility issues on this topic. The original is 4k, and the target that got mis-sized is 512.

Edit:

As an update to this peculiar behavior, I see that fog has written the target drive for deployment to be a 1TB drive, but it is a 250GB. Connecting the mis-sized drive to a windows box and opening a storage management window, I see that it is GPT protected and it is 1TB (the size of the drive that was captured coincidentally). If I open diskpart, it shows as the expected 232GB. Cleaning the disk with diskpart returns it to expected values in windows’ storage management viewport.

@george1421

I took two shots of ls -la results. The first pic is where the image is shown as being 0.0GB in image listings. The second picture is a re-capture to again show 65GB in the image listing. As soon as I try to deploy this 65GB image it fails and goes to 0.0GB.

The bios only shows AHCI. No other option exists.