Posts made by Fog_Newb

@Sebastian-Roth

I don’t want to be that guy but…

Any updates?

@Sebastian-Roth

No worries I didn’t expect the fix to be available when I updated. I was just testing/wondering about .size files and why they were missing and or not being created automatically. I didn’t know they were only created in all disk mode and thought maybe something else was wrong. Thanks for clearing that up.

@Sebastian-Roth

Wow. After creating the .size files I captured an image from each NVMe drive to their corresponding existing image. the .size files are now gone. Did I need to change the owner of the .size files to root?

Anyways so I updated FOG dev build to the latest as of today 1.5.9.29 captured an image from the NVMe. The .size files weren’t created. Maybe this is indicative of another problem?

@Sebastian-Roth
Thanks

Some of the images were initially captured on the 1.5.9 RC candidates 11 - 16 from the dev branch. One new image was captured on 1.5.9 final dev branch, (just a couple days ago), neither image directory had the .size files.

I have created d1.size and d2.size files inside the directories of the 2 NVMe based images using the values from the blockdev --getsize64 output

@Sebastian-Roth

Thanks. I checked the images directory and the only file in it was .mntcheck then the directories containing the images and postdownloadscripts directory as well as a dev directory none of them contained a d1.size or d2.size file.

@Sebastian-Roth

The other NVMe is 1TB. Is there a way to specify the target NVMe by size? I can’t find that setting.

@Sebastian-Roth

Hello,

I am running “the latest stable version: 1.5.9”

Yes I want to back up or deploy to a certain 256GB NVMe drive. I set the host primary disk to /dev/nvme0n1 and it was working. I would schedule a capture and reboot manually and it would back up the correct drive. Early this morning I set a task to capture and the FOG client rebooted the PC. I noticed it was capturing from the wrong drive but no settings were changed. So i went in an set a task for a capture and manually rebooted and it captured from the correct drive.

lsblk showed nvme0n1 was the 256GB drive

It is too bad there is not a way when you boot PXE from a client you can’t choose the drive.

After reading up I found NVMe drive are initialized at different times during the boot process.

This causes issues when trying to capture or deploy to the right drive. Perhaps FOG could add something to choose the drive when deploying and capturing.

/dev/nvme0n1 is my OS drive I like to capture on regular intervals. Sometimes it is seen as /dev/nvme1n1 which causes a problem.

Feedback?

@george1421

I figured it out. /dev/nvme1n1

I wasn’t sure how Linux named NVMe’s.

I’ve added a 2nd NVMe drive to my PC. Now when I capture an image it captures from the wrong NVMe drive.

I am not sure what to put for the Host Primary Disk setting. How can I find out?

@Sebastian-Roth

Cool an even newer version is out now. Gonna try 2.19

@Sebastian-Roth

I don’t know. The Win 10 UEFI image on the FOG server at work and a completely different Win 10 UEFI image on my home FOG server both deployed and worked fine the day before. Nobody else has access to either FOG server and the only change made was the update from RC2.15 to 1.5.9-RC2.17

@Sebastian-Roth

Sorry I am not explaining this well.

I was able to resolve the situation by creating a new UEFI image from a legacy image and capturing it. The original UEFI based image that got corrupted is not working.

@Sebastian-Roth

The Windows 10 EFI image is just the legacy image converted to EFI

Since the Legacy image was still working fine I deployed the legacy image, converted it to EFI then re-captured it replacing the broken Win 10 EFI image

@Sebastian-Roth

Yes that update was installed on both images.

The odd thing is it only affected the EFI image(s) not Legacy one and the same behavior on 2 different fog servers and 2 different images that deployed fine prior to the FOG upgrade.

But yeah who knows. It was easy to sort it just seemed related to the upgrade at the time.

I updated my home server and a server at work. Today at work, I noticed a once working Win10 UEFI image would not longer boot to the desktop properly… even deploying it to the same workstation it was captured from.

The image was captured a couple of days prior on 1.5.9-RC2.15 and had been deployed a few times without any problems. The problem only happened after going to 1.5.9-RC2.17.

This was easy to resolve since we have the same exact image in legacy, I deployed the legacy image then converted it to UEFI and re-captured it as the broken UEFI image. … tested working.

I just figured oh… the image got corrupted due to… something else. I was too burnt to look into it any further.

I got home and tried to deploy a completely different Win10 UEFI image that also was captured and deployed on 1.5.9-RC2.15 and since updating to 1.5.9-RC2.17 the same exact weird behavior. The desktop never completely loads. Task manager never opens… etc etc.

The image is close to stock so it is easy to recreate. I’m wondering if anyone else experienced this.

@gadams

From the latest pics in the post… The Fog server…
Seems hard drive related for sure. Problems mounting the file system and other issues related to the file system.

@george1421

I can confirm those mixed kernel versions work fine. We also have dc7800’s they can make it to the FOG menu but they can’t register, deploy or capture with the newer kernels.

When I first encountered DC7800 problems I rolled the kernel way back to one even older than 4.15.2 and I would get an error message saying kernel was too old at some point during the DC7800 registration process.
4.15.2 was the first kernel I came to where it didn’t throw the kernel was too old error.

With 4.15.2 I have been able to image, capture, etc etc all different kinds of laptops and workstations via legacy and UEFI PXE boot without any problems.

Once the DC7800’s are gone I will go to the latest kernel. I hate those things.

I am thinking there is some corruption with the captured image maybe even a bad sector on the FOG servers hard drive?. Just a guess but definitely not the kernel.

what is up (PTM) @gadams

Has the default setting for snmysqluser been changed to ‘fogmaster’?