FOG restore only one partition
-
That isn’t your concern though, that’s mine. Just noting it’s a problem and I don’t know why it’s even happening.
-
@Tom-Elliott i can make other tests if you want
-
I found out why the d1.mbr/d1.grub.mbr file wasn’t being created.
Yes, it’s kind of an important bit. Please update and re-upload the windows 7 guy (as well as your windows xp if you feel up to it.)
I know i’m asking a lot, but I really think we have all the kinks fixed now. (hopefully).
Again, my only worry on the Win 7 is in the case of resizable we do place our own generalized BCD file. I think this can cause issues, but it can be fixed. I don’t remove the original bcd, rather I move it to a BCD.bak
-
@Tom-Elliott said:
I found out why the d1.mbr/d1.grub.mbr file wasn’t being created.
Yes, it’s kind of an important bit. Please update and re-upload the windows 7 guy (as well as your windows xp if you feel up to it.)
I will test on Monday. Do i have to capture again before ?
I will test for the windows 7 machine and windows XP machineI know i’m asking a lot, but I really think we have all the kinks fixed now. (hopefully).
No problem for me. If i want it works …
-
-
@Tom-Elliott Hello
Test Windows 7
- Update fog to 4959 / 6609
- Restore machine with ghost image
- The machine works fine and show 3 partitions
- Delete old image with files on fog web interface
- Create new image
default: Windows 7 Single Disk - Resizable Everything
- Basic task
- Capture
Messages before partclone
Clearing part (/dev/sda2) …Reg file not found
Clearing part (/dev/sda3) …Reg file not foundFiles in image directory
d1.fixed_size_partitions d1.mbr d1.minimum.partitions d1.original.fstypes d1.original.swapuuids d1p1.img d1p2.img d1p3.img d1.partitions
d1.mbr is present
After capture, windows start without problem !!!
- Basic task
- Deploy
After deploy task, the machine stay on “Booting…”
I dont know it it’s usefull :
sfdisk -d /dev/sda label: dos label-id: 0x2bd2c32a device: /dev/sda unit: sectors /dev/sda1 : start= 63, size= 80262, type=de /dev/sda2 : start= 80325, size= 1536000, type=7, bootable /dev/sda3 : start= 1616325, size= 975156736, type=7
blkid -po udev /dev/sda1 ID_FS_SEC_TYPE=msdos ID_FS_LABEL=DellUtility ID_FS_LABEL_ENC=DellUtility ID_FS_UUID=5450-4444 ID_FS_UUID_ENC=5450-4444 ID_FS_VERSION=FAT16 ID_FS_TYPE=vfat ID_FS_USAGE=filesystem ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_UUID=2bd2c32a-01 ID_PART_ENTRY_TYPE=0xde ID_PART_ENTRY_NUMBER=1 ID_PART_ENTRY_OFFSET=63 ID_PART_ENTRY_SIZE=80262 ID_PART_ENTRY_DISK=8:0
blkid -po udev /dev/sda2 ID_FS_LABEL=RECOVERY ID_FS_LABEL_ENC=RECOVERY ID_FS_UUID=B2FA97C8FA97876F ID_FS_UUID_ENC=B2FA97C8FA97876F ID_FS_TYPE=ntfs ID_FS_USAGE=filesystem ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_UUID=2bd2c32a-02 ID_PART_ENTRY_TYPE=0x7 ID_PART_ENTRY_FLAGS=0x80 ID_PART_ENTRY_NUMBER=2 ID_PART_ENTRY_OFFSET=80325 ID_PART_ENTRY_SIZE=1536000 ID_PART_ENTRY_DISK=8:0
blkid -po udev /dev/sda3 ID_FS_LABEL=OS ID_FS_LABEL_ENC=OS ID_FS_UUID=A2B89AD7B89AA975 ID_FS_UUID_ENC=A2B89AD7B89AA975 ID_FS_TYPE=ntfs ID_FS_USAGE=filesystem ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_UUID=2bd2c32a-03 ID_PART_ENTRY_TYPE=0x7 ID_PART_ENTRY_NUMBER=3 ID_PART_ENTRY_OFFSET=1616325 ID_PART_ENTRY_SIZE=975156736 ID_PART_ENTRY_DISK=8:0
-
After reading through most of your posts again I noticed that I probably missed a very important detail. You have two different systems, one WinXP and one Win7 but both having three partitions! I somehow got confused by the different sector counts but same number of partitions…
@plegrand said:
…
Clearing part (/dev/sda2) …Reg file not found
…Is this definitely a Windows 7 installation you are trying this on? Then it most probably won’t boot because of this!! On Win7 we need to be able modify the registry because it would hang on booting otherwise!
Can you please restore your Win7 image from ghost again. Then schedule a debug upload task and run the following commands (sda3 is your OS system partition, right?):
mkdir -p /ntfs ntfs-3g -o force,ro /dev/sda3 /ntfs find /ntfs -type f -iname "SYSTEM" ... umount /ntfs reboot
On a normal system you should see
/ntfs/Windows/System32/config/SYSTEM
printed from the find command. If you don’t get any output from that you can tryfind /ntfs -iname "SYSTEM*"
to see if there is any backup file of the registry. Maybe ghost is doing some kind of magic?? -
@Sebastian-Roth I’m of the mind this is the BCD issue I was describing earlier.
I’m going to try making a post download script to revert the BCD.
-
Can you try using this script in your /images/postdownloadscripts/revertbcd
#!/bin/bash [[ $osid != [5-7] ]] && return getHardDisk getPartitions $hd for part in $parts; do fsTypeSetting "$part" [[ $fstype != ntfs ]] && continue dots "Mounting Partition" if [[ ! -d /bcdstore ]]; then mkdir -p /bcdstore >/dev/null 2>&1 case $? in 0) ;; *) echo "Failed" debugPause echo " * Could not create mount location" return ;; esac fi ntfs-3g -o force,rw $part /bcdstore >/tmp/ntfs-mount-output 2>&1 case $? in 0) echo "Done" ;; *) echo "Failed" debugPause echo " * Could not mount $part to /bcdstore" continue ;; esac if [[ ! -f /bcd/Boot/BCD.bak ]]; then umount /bcdstore >/dev/null 2>&1 continue fi dots "Restoring original BCD" mv /bcdstore/Boot/BCD{.bak,} >/dev/null 2>&1 case $? in 0) ;; *) echo "Failed" debugPause umount /bcdstore >/dev/null 2>&1 echo " * Could not revert BCD File" continue ;; esac echo "Done" debugPause umount /bcdstore >/dev/null 2>&1 done
Change the file to allow the script to run as a script
chmod +x /images/postdownloadscripts/revertbcd
And add to the /images/postdownloadscripts/fog.download
. ${postdownpath}revertbcd
-
@Sebastian-Roth said:
After reading through most of your posts again I noticed that I probably missed a very important detail. You have two different systems, one WinXP and one Win7 but both having three partitions! I somehow got confused by the different sector counts but same number of partitions…
Yes as you said i made tests with 2 machines but each time i precise in my post wich machine i use
At this time i’m testing on a WIndows 7 machine
I made what you ask me to do and i come back -
@Tom-Elliott Hello
you mean /images/postdownloadscripts/fog.download => /images/postdownloadscripts/fog.postdownload ??
I’m actually deploying image ghost on this machine -
@Tom-Elliott Hello
then i added the script into/home/images/postdownloadscripts/revertbcd
then
chmod +x /home/images/postdownloadscripts/revertbcd
and
add to the /home/images/postdownloadscripts/fog.postdownload . ${postdownpath}revertbcd
ls -al /home/images/postdownloadscripts/ total 16 drwxrwxrwx 2 root root 4096 mars 7 13:59 . drwxrwxrwx 7 root root 4096 mars 7 10:24 .. -rwxrwxrwx 1 root root 260 mars 7 13:59 fog.postdownload -rwxr-xr-x 1 root root 1279 mars 7 13:52 revertbcd
cat /home/images/postdownloadscripts/fog.postdownload #!/bin/sh ## This file serves as a starting point to call your custom postimaging scripts. ## <SCRIPTNAME> should be changed to the script you're planning to use. ## Syntax of post download scripts are #. ${postdownpath}<SCRIPTNAME> . ${postdownpath}revertbcd
but same problem
-
@Sebastian-Roth said:
mkdir -p /ntfs ntfs-3g -o force,ro /dev/sda3 /ntfs find /ntfs -type f -iname "SYSTEM"
find /ntfs -type f -iname “SYSTEM”
/ntfs/Windows/System32/config/RegBack/SYSTEM
/ntfs/Windows/System32/config/system -
@plegrand My intuition was right… This is one thing I hate about windows. It does not care much about case-sensitivity in filenames and paths! Someone or some tool made a backup of the original reg-file called ‘SYSTEM’ but named the new file ‘system’. Windows seams to not care and still boots. But FOG/linux cares about it. We have the path for this defined as ‘/ntfs/Windows/System32/config/SYSTEM’ and therefore our scripts won’t find ‘…/config/system’!
I am not sure what to do about it. I don’t think we should change our scripts as this has never happened before and I guess this is very rarely the case. But it’s kind of easy for you to fix. After restoring the Win7 image via ghost please boot in debug upload again and run:
mkdir -p /ntfs ntfs-3g -o force,rw /dev/sda3 /ntfs mv /ntfs/Windows/System32/config/system /ntfs/Windows/System32/config/SYSTEM.moved mv /ntfs/Windows/System32/config/SYSTEM.moved /ntfs/Windows/System32/config/SYSTEM umount /ntfs
I guess you can rename the file directly from ‘system’ to ‘SYSTEM’ but I have seen cases (probably on VFAT filesystems) where this fails - therefore I suggest two renames. After that you can start the upload via command
fog
… -
@Sebastian-Roth Hello
then after restoring ghost image i launch debug capture task and thenmkdir -p /ntfs ntfs-3g -o force,rw /dev/sda3 /ntfs find /ntfs -type f -iname "SYSTEM" /ntfs/Windows/System32/config/RegBack/SYSTEM /ntfs/Windows/System32/config/system mv /ntfs/Windows/System32/config/system /ntfs/Windows/System32/config/SYSTEM.moved mv /ntfs/Windows/System32/config/SYSTEM.moved /ntfs/Windows/System32/config/SYSTEM find /ntfs -type f -iname "SYSTEM" /ntfs/Windows/System32/config/RegBack/SYSTEM /ntfs/Windows/System32/config/SYSTEM umount /ntfs/
fog to launch capture task
reboot
After capture windows 7 works fine.Deploy task
Same problem : stuck on “booting …”I keep the Tom’s script (revertbcd) may be i should remove it ?
-
@Sebastian-Roth May be i could give you access to this machine if it’s usefull ?
-
Definitely was useful to get access to the machine. That particular partition layout turned out to be not very easy to handle and FOG stumbled! Those DELL partitions are quite an issue. But I think Tom and I have fixed it all. @plegrand Please upgrade to the very latest version. Then re-upload and try deploy again! Please test both of your machines to see if this is really the same issue.
-
@Sebastian-Roth Hello
do i have to keep the “revertbcd” script ? -
@plegrand Please try without it first!
-
@Sebastian-Roth argh …
for this test i let it …