That looks amazing!
I think linking as much of the UI to the wiki would benefit everyone, even the technical writers. This is a great start. I think when linking a page to the Wiki, that wiki page becomes somewhat more “canonical”, and it shows users where to start, which is sometimes a challenge with Wikis (in comparison to other forms of documentation like an old-school manual).
Hi @Junkhacker,
You don’t have to convince me. I get that now.
However, I have read many Fog Forum posts and Fog Wiki pages, and have not come across any such ‘encouragement’. That’s why I suggested that it be made clear in the UI – it would be a form of self-documentation.
I just saw this on Amazon Web Services, in a table header. It’s similar to what I envisaged next to the dropdown:
Hi Sebastian,
Would you help us write the texts and find a good way to place them in the web UI so people definitely see them but don’t get annoyed?
Although I am a developer, I’m not great with UX design. But I would think that some kind of info icon 
next to the drop-down list with a popup saying something like “Read about the image types here: [insert wiki link]” would suffice. It would draw the attention of anyone who is confused about the options, but is unobtrusive enough not to annoy anyone else.
I’ve seen this somewhere, and wanted to make a screenshot, but can’t find it, so I made a mockup: 
This could be used in all kinds of places in the UI. You could even color it red, green or yellow depending on the importance or level of danger. These are just suggestions, and I’m not trying to do your job for you. If you want a pull request for this, I’ll need to figure out where the source code is, first. I’m not acquainted with your source code at all.
The system restore actually worked. It seems that /dev/sda5 (the recovery partition) was still intact, and the “HP recovery” simply formatted /dev/sda3 and rebuilt the entire OS. I think the reason it failed before was because /dev/sda3 was not properly sized to fill the partition, which is what I fixed by rewriting the boot sector with testdisk.
I won’t waste you time with this anymore, and I’ll make sure to take backups with Clonezilla and/or the Single disk (not resizable) option in FOG.
Thanks for the quick feedback! 
It’s always a pleasure to be on this forum.
@Sebastian-Roth said in NTFS partitions corrupt after capturing resizable image:
Why do you choose resizable if you intend to make a backup copy of this laptop? This backup is supposed to go back to the same machine with the same disk and there shouldn’t be a need to use resizable image type for that reason!
Because it’s the default option, and when in doubt, default options are usually safe. In this case it’s not. I understand why this was a bad choice. Lesson learnt.
The non-resizable images type don’t take up more space for storing the image on your FOG server either.
Good to know!
May I suggest that there shoud be some help text or a link to the wiki in the GUI that warns users about the pros and cons of different types of images?
Did you disable Windows 10 fast boot and properly shutdown before you started the capture?
I always shut down from the command line before capturing. Is that sufficient? As far as I understand that disables fast boot for the next boot. That would be the same as “method 2” in the link you referred to, but a tad less hackish.
There is no way we can prevent users from all different kinds of situations. We try to make FOG with as much care as we can bit it’s like a swiss knife and if someone uses it the wrong way no one will blame the factory or engineers for having created a dangerous tool, right?!
This is true!! But maybe the default option should be the safe(-r) one?
Can you boot using a Windows 10 DVD and get into a CMD shell there and run
chkdskcommand? What output do you get from that? We need a picture!
Yes (Win10 flash drive made with Rufus, actually). This is how I ran chkdsk. I took a few pictures, but it reported so many errors that most of them got lost off-screen. It also unlinked a lot of files and threw them in lost+found.
Just before going home today (GMT+2 here), I tried something else. I restored again, from the Clonezilla backup I have, ran testdisk on /dev/sda3 (C:) and copied the backup bootsector over the normal bootsector. Then I rebooted into recovery and used the HP factory reset option instead of Windows’ “reset PC” option. It seemed to work, but it was still running when I left. I’ll post again tomorrow with results!
Here is the output of ntfsresize --info /dev/sda3 right after restoring the Clonezilla backup:
Hi there,
It’s a few years since I used FOG, but I’m back.
In short:
New HP 15-ra0xx laptop, that came with Win10 and MS Office pre-installed and activated. I decided it would be a good idea to back up the entire laptop using FOG before I make any changes. It failed, and now I have an brand new unbootable laptop, and the system recovery options won’t work, either.
In more detail:
This is an expensive issue for me… please help!
Epilogue
My previous experience with FOG also resulted in corrupted HDDs when capturing. It seems that FOG just isn’t careful enough with the source disk. You may recall this: https://forums.fogproject.org/topic/8059/pc-unbootable-after-capture-fails
See this example: https://forums.fogproject.org/uploads/files/1468447170744-gparted_details_bad.htm
Thank you for looking at this issue! I will try out the new code and report back.
I updated FOG to RC15. Now the FOG clients do update themselves to 0.11.5, but only if I re-deploy the host (using the same image, not a new one).
@Sebastian-Roth said in PC unbootable after capture fails:
To find out what exactly caused this we need the exact error message from when it happens (resize…?)!
See this message, as well as @Tom-Elliott’s reply on it.
The take-home message is still: GParted stops before destroying the disk. FOG should do the same.
Thank you. I’ll check the logs when I’m on site on Monday.
I saw some chatter on the forums about the fog client not updating,so I ask: In order to get the FOG client that contains the fix you mentioned, will it be sufficient to update the FOG server to trunk at this stage?
I have about 215 computers, running the same Windows 7 Enterprise based image. They are being used by hundreds of students on a daily basis. However, about half of the hosts have no login history in the FOG database. Only 6 hosts report a login in the past 24 hours. The others show login times of more than a month ago (when they were running an older image, with the legacy FOG client).
Do you have advice on how I could debug this?
Sorry for the vague question. I’ll gladly provide more details, if I know what to look for.
Windows 7 Enterprise. I don’t know what is special about this image. The problem started after installing a bunch of large software packages on the master image. Fragmentation was less than 1%.
It fails when trying to resize the partition, as described in previous posts. When doing the same thing with CloneZilla, it works. The fixed-size option in FOG also works, because it doesn’t try to resize the partition. As far as I can see, resizing the partition is not necessary for capturing images with partclone, even when restoring to a smaller drive. You might as well remove that step from the capturing process, which will speed things up significantly.
So now I just capture it into a temporary image using the “fixed size” option, and then move the files manually to an image which is configured as “resizable”.
mint mint # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 232.9G 0 disk
├─sda1 8:1 0 100M 0 part
└─sda2 8:2 0 232.8G 0 part
sdb 8:16 1 7.5G 0 disk /cdrom
├─sdb1 8:17 1 1.6G 0 part
└─sdb2 8:18 1 2.3M 0 part
sr0 11:0 1 1024M 0 rom
loop0 7:0 0 1.5G 1 loop /rofs
mint mint # fdisk -l
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x95d3684b
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 488396799 488189952 232.8G 7 HPFS/NTFS/exFAT
mint mint # lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 6 Series/C200 Series Chipset Family KT Controller (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4)
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b4)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4)
00:1f.0 ISA bridge: Intel Corporation Q67 Express Chipset Family LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
I omitted the RAM drives and /dev/sdb, since I was booting from a LinuxMint USB drive.
I’m still experiencing this problem. Running trunk these days. However, I have found another workaround to upload resizable images:
d1.fixed_size_partitionsd1.minimum.partitionsd1p2.imggzip -l d1p2.imgd1.original.fstypesd1.original.swapuuidsIt works. Therefore it seems that resizing the partition before and after capturing with partclone.ntfs is not necessary, even for resizable images.
In @Joe-Schmitt’s second last message, the plan was to require no modification to setupcomplete.cmd. But the wiki still says I have to modify it. Which instructions should I follow?
Thanks. Makes sense. Will fix my stuff.
@Joe-Schmitt Will do!
Any idea why it would work for the old PCs but not the new ones? It find it strange.
Ooh… Didn’t know that. My setupcomplete.cmd only deletes the unattend.xml file. I have nothing that touches the FOG Client in any way. Looks like I’ll have to change the image, then? I just installed the FOG Client without any further configuration, and it works for all PCs which were added to the FOG db last year.