Posts made by abos_systemax

Server

• FOG Version: RC 36
• OS: Windows 7

Description

Hello,

I’m seeing this strange issue where Windows diskpart reports that the partition is 236GB, but Windows itself thinks that the partition is only 80GB. I am unable to shrink/extent the partition, because both the utilities think they are right.

This poses an issue, because Windows thinks that it runs out of free space…

I think this issue came from restoring a single partition only with ‘Single Disk, Not resizeable’ selected in FOG; on a bigger partition then the source image.

How can I fix this (if it is at all possible)

@Wayne-Workman Problem is: our customers build their images and we have to work with it… Ill still try to figure things out; but this thread can be closed. Apparently it’s not a FOG issue, it’s a hardware (or software) related issue; which doesn’t fall into Fog’s domain…

Thanks for the support anyway; you did point me in the right direction: at least now I know what the problem is.

@Wayne-Workman I tried, but Windows is unable to launch.
I am wiping the disk now to ensure that the EFI partition is removed before the image is applied

But alas, it is still unable to find the OS disk

@abos_systemax

Meh, too bad… if I only restore partitions 2,3, and 4, I receive a Windows needs to be repared error because the Win10 EFI Boot manager still thinks it boots Windows 10…

The FOG screen displays a message about formatting and settingup the new MBR/GPT… but it doesnt seem to do that; is that correct?

@Wayne-Workman can I just use the MBR that is created on the image?

@Quazz There are options to capture only certain partitions; is there a method to SKIP certain partitions?
I am able to capture SDA2,SDA3 and SDA4 with no problem

@Quazz
After that, I receive an I/O error:4 from fatclone.c

message: Fatclone.c: I/O error:4

@Quazz

The output from Fdisk is as below:

Disk label type: gpt

Device | Start | End |Sectors |Size | Type
/dev/sda1 | 2048 | 206847 | 204800 | 100M | EFI System
/dev/sda2 | 206848 | 468991 | 262144 | 128M | Microsoft Reserved
/dev/sda3 | 468992 | 168353297 | 167884306 | 80.1G | Microsoft Basic data
/dev/sda4 | 467146752 | 500117503 | 32970572 | 15.7G | Microsoft Basic data

the Partclone fails on Sda1

@george1421

This concerns a Lenovo M900 Desktop (ThinkCentre) - Type 10FLS4BD00
The Windows 7 image can boot successfully, but the FS is NTFS, not FAT.
I performed a chkdisk /F, but that did not resolve anything

Server

• FOG Version: RC36
• OS: Windows 7

Description

We are experiencing an issue when trying to capture an image with FOG.
The error message we receive is:
Fatclone.c: Filesystem isn’t in valid state. May be it is not cleanly mounted?

I’ve tried a Multi Parition - Non resize option in the image, and single disk resizable… but both present me with this issue.

I’ve upgraded to RC36 to see if the issue was resolved, but to no avail.

The issue only appears on known hosts apparently. We have no issues on hosts that fog doesn’t know somehow.
I’m still trying to investigate why the arch isn’t parsed correctly on this device… will post as soon as I find an answer

@Tom-Elliott I will get back to you on that, Now that i Have a workaround I first need to finish the current job before I can test any further

edit
== Yes, it changes both accordingly

@abos_systemax

This is my DHCP config:

option space PXE;
option PXE.mtftp-ip    code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16; # RFC4578

authoritative;
allow unknown-clients;
option broadcast-address 192.168.71.255;
option subnet-mask 255.255.252.0;
option routers 192.168.68.1;
ddns-update-style none;
option domain-name "local";
option domain-name-servers 192.168.68.11, 8.8.8.8;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;

# LAN
subnet 192.168.68.0 netmask 255.255.252.0 {
	max-lease-time 14400;
	default-lease-time 14400;
	allow unknown-clients;
	next-server 192.168.68.13;
	range 192.168.68.30 192.168.71.200;
	}

class "pxeclient" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";

    if substring (option vendor-class-identifier, 15, 5) = "00000" {
        # BIOS client 
        filename "undionly.kpxe";
    }
    elsif substring (option vendor-class-identifier, 15, 5) = "00006" {
        # EFI client 32 bit
        filename   "ipxe32.efi";
    }
    else {
        # default to EFI 64 bit
        filename   "ipxe.efi";
    }
   }

The config states the following:

Chip: undionly
filename: undionly.kpxe
buildarch: i386
platform: pcbios

@Tom-Elliott I don’t know why it boots to bz32… it does apparently…
I assumed that it used bzImage for UEFI because UEFI doesn’t really support x32?

however, I retrieved the boot command from the boot.php and forced the boot.php to present it to this machine with bzImage instead of bzImage32 and now it apparently seems to work…

Somehow it doesn’t give it’s archtype correctly?

===

If I drop to Shelland check the buildarch, then it displays i386.
Could this be my DHCP server that is confused?

@Tom-Elliott the device displays the INFOrmational; when in Legacy (and booting bzImage32), but displays the 0x7f048283 when in UEFI
If i force the bzImage on legacy then … =it works=

@Tom-Elliott

as a matter of debugging, I tried booting to UEFI…
Then I receive the iPXE error 0x7f048283, which is - funnily enough - the same error I had yesterday on a Lenovo M700 which wás able to boot on Legacy

I can also confirm that other brands of Linux are able too boot.

@Tom-Elliott There isn’t a firmware update available for these machines either. It’s on 1.22 and Lenovo’s latest release is 1.22

@Tom-Elliott setting it to 0 gives me the blinking cursor, 1 as well
bumping it up to Debug and log level 7, logs until PCI device initialisation before the RCU informationals appear and I then receive a task dump for CPU 0

bumping it back down to level 4 doesn’t show less messages, so apparently Log level 7 is the same as log level 4 with Kernel_debug?

btw there is a small typo in the helptext for loglevel (the instead of they)

@Tom-Elliott
ok, so as soon as I disable Hyper-treading (which makes ipxe monstrously slow btw), I still receive the Informational error, but immediatly after that I receive an rcu_sched kthread starved for xxxxxx jiffies! (where xxxx is a number)
_RCU_GP_WAIT_FQS(3) -> state=0x1 (and the following message is state=0x0)