Posts made by geardog

@sebastian-roth

Thanks for that. I’m using the linked tutorial in the correct context!

Fog 1.5.9 on Ubuntu 18 (sorry) spit back an error on systemctl restart dnsmasq “Bad dhcp-range at line 38” which was caused by including the <> around the IP. wow …

I’ve been poking around the links dealing with this, and I’m bleary-eyed.

Keeping ClearOS in control of dhcp, how do I address PXE bios & uefi boots? I did this fine with windows 66/67 direction, but the guides don’t quite align with what I’m doing, perhaps partly because ClearOS uses dnsmasq for this, and overwrites dhcp.conf with what it finds in dnsmasq configs.

First, am I correct in understanding that I could run dnsmasq on clear or fog box with the same effect?

Second, if I can run dnsmasq on fog leaving dhcp to ClearOS, what modification do I need to make to the outlined ltsp.conf file found at the following link work? I’m assuming the linked tutorial fails because it is with the expectation dhcp is on fog. Commenting the last line out lets the service start without errors, but I’m not getting boot files yet.
https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server,

@Sebastian-Roth

I’ve typically just restarted, but Fast start was enabled too.

A cold boot with fast-start disabled allowed a good capture.

Thanks so much.

Running FOG 1.5.6

Error(5): Could not map attribute 0x80 in inode 24291: Input/output error

This is a follow up to
https://forums.fogproject.org/topic/13334/mismatched-drive-sizes-in-win10-after-incomplete-capture-with-1-5-5

After correcting the FS size, I ran Windows DISM clean and chkdsk /f which completed succesfully; they gave no errors. I then captured a raw image of the box which completed succesfully.

Attempting to capture a resized image of this computer gave me this error

I ran chkdsk /f on the box, which completed clean before and after the imaging attempt.

Any thoughts on cause or resolution to the error?

Checking file system on
The type of the file system is NTFS.
Volume label is HP.

A disk check has been scheduled.
Windows will now check the disk.

Stage 1: Examining basic file system structure …
576000 file records processed.
File verification completed.
12848 large file records processed.
0 bad file records processed.

Stage 2: Examining file name linkage …
26147 reparse records processed.
657814 index entries processed.
Index verification completed.
0 unindexed files scanned.
0 unindexed files recovered to lost and found.
26147 reparse records processed.

Stage 3: Examining security descriptors …
Cleaning up 5 unused index entries from index $SII of file 0x9.
Cleaning up 5 unused index entries from index $SDH of file 0x9.
Cleaning up 5 unused security descriptors.
Security descriptor verification completed.
40908 data files processed.
CHKDSK is verifying Usn Journal…
36582096 USN bytes processed.
Usn Journal verification completed.

Windows has scanned the file system and found no problems.
No further action is required.

223223172 KB total disk space.
66502968 KB in 158976 files.
128652 KB in 40909 indexes.
0 KB in bad sectors.
698964 KB in use by the system.
65536 KB occupied by the log file.
155892588 KB available on disk.

  4096 bytes in each allocation unit.

55805793 total allocation units on disk.
38973147 allocation units available on disk.

Internal Info:
00 ca 08 00 d8 0c 03 00 63 aa 05 00 00 00 00 00 …c…
76 01 00 00 ad 64 00 00 00 00 00 00 00 00 00 00 v…d…

Windows has finished checking your disk.
Please wait while your computer restarts.

@Sebastian-Roth
Gparted fixed it with the “check” command, running what appeared to be the same commands I entered at terminal.

I’ll try to capture it again after I’m more confident the box is ok.

thanks guys

@Tom-Elliott
I double checked. It is MBR and system is on the small 500MB partition.

@Sebastian-Roth

note: -v gave no further info

What now?

@Sebastian-Roth

no apparent change

@Sebastian-Roth
ntfsfix processed, but the FS is still the same size. I guess now I try the previous command again to see if the bootsector error has been cleared to run the resize?

@Sebastian-Roth

The sector and cluster ratios seem appropriate for the partition size. Will the error cause issue?

Any guidance is appreciated. I can google some commands and pretend I know what I’m doing, but I’d rather not botch the box further.

@Sebastian-Roth

I obscured it, but, in file explorer, the 59.8GB is total size.

So using 1.5.5 I tried to capture a win10 box. It failed at 85% (as shown by the bar in fog’s “active tasks”), but rebooted to windows. Fine, but the windows machine still has a minimized OS/system partition.

incongruencies-
Win10 drive list shows OS partition as 60GB and throws errors as it being full.
Admin tools>comp management>storage>disk management- shows the partition as the expected ~180GB size

Any advice on how to un-hose this drive without borking it further? Hopefully someone better versed in this kind of thing might understand the discrepancy.

I have updated to fog 1.5.6, but still hope to salvage the workstation.

@Sebastian-Roth
No no, you’ve made clear that it is a lost cause trying to sort this out. If I had a clean capture and deploy on this version showing the system partition shrinking it would be different. Your comments made that clear. Thanks for the help.

@Sebastian-Roth
Good points.
I haven’t kept logs that would detail which version of fog I was on. It could be that the drive was initially that size when captured, but that is an odd number (37MB). This particular image has probably been deployed, updated, used, and recaptured meaning it has been passed through various versions of fog. This is surely asking for it, but I’ve yet to find a workstation backup method that gave me the fuzzies.

Just to be clear, as I’ve not fiddled with these files directly before, we are talking about image files from a host previously captured? Further, entering “:1” in this image file means that, upon deployment, it will inflate the first partition to it’s original (at time of capture) size?

I can’t seem to search the forums (404?) so I’m, just posting today’s fun.
edit: search works again, yet I’m not sure I want to delete the post

I tried to upgrade a deployed drive image from win10: 1803 to 1809 today. It told me my system partition was too small. Well it was quite small at 37MB. I’m guessing it was shrunk from the typical 100MB on capture and not inflated at deployment, but I can’t be sure. At any rate, the ensuing resize/raw FS/convert-to-NTFS fun landed me back at a redeployment of the same image that produces the small system partition.

Maybe I’ve missed the setting, or I’m using FOG in an A-typical way, but this could be an issue for quite a few.

If anyone has any thoughts on how to avoid/remedy the issue, I’d be happy to hear it.

@Zerpie
I know it doesn’t directly address your issue; forgive me.

Hardware raid cards are pretty darn cheap (used server pulls etc). Have you ever tried to rebuild one of those fakie raids? I’ve seen really poor results when it actually comes down to rebuilding a mirror, and the performance of general use is garbage.

I agree. Fog should tell you “these images won’t really be deleted, I’m just going to pretend… you’ll need to ssh in and clean up”

I revived this thread, because I’m seeing this issue. I see other threads saying it works, but I am on
FOG 1.5.4 kernel 4.18.3 and have to ssh to actually delete the files.

@george1421

I consider it resolved. Thanks for chiming in.

@george1421

I feel like a bit of a dummy. It works now, and I suspect I just needed to run the “chkdsk /f” from prompt instead of what I figure is the less thorough one from disk properties. For completeness I’ve included what didn’t work.

Nice thought, but the thread you note doesn’t hold my solution.
https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/43
Bit locker is off as evidenced by the encryption control commands.
manage-bde -off
manage-bde -status

“Way 1” from the FOG wiki made no change either.
https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

I believe command prompt “chkdsk /F” corrected the issue. I had previously just used disk check from disk properties, which doesn’t lock the drive. This was, however, in conjunction with a bios setting dealing with power saving that was causing hangs.