Copy Sectors 5-7 from HDD
- FOG Version: 1.3.5
- OS: Debian 9
- Service Version: ?
- OS: Win7 x64
When capturing an image I need to make sure that sectors 5,6 and 7 of the HDD/SSD are stored, because the so-called “Wächterkarte” from Dr. Kaiser GmbH stores its configuration in those sectors. I also need to make sure that the sectors are recreated while deploying.
There has been an option somewhere™ which sounded like it was the one I need, but I can’t find it any more.
What might work? I can recapture the image.
(if the sectors are not there I have to configure every PC manually which is some pita, as the f**** Smarttech-Beamers are not intelligent enough to display 640x480/BIOS)
First I feel I should clarify, “Sectors 5-7” is always going to be in regards to the disk. I’m not aware of any system that refer’s to “Sectors” on a “partition” basis. Sector 5-7 will remain Sector 5-7 irrespective of the partition those sectors may reside in.
@kai any news? Topic is interesting
Well, we’re only going on what we’re told. It might be sectors 5-7 of the boot partition, or the recovery partition, or of the entire disk. Maybe the software replaces the MBR. Who knows.
I posted those below commands so he could manually test this first - and see if it would even work or not. My bet is doing so would make the system not boot.
@Tom-Elliott The way I understand this is their copy protection software writes specific values in sectors 5-7 on the disk. If those sectors are not there or damaged then the copy protected software will think the license is invalid. So if we set aside the legality of what the OP is doing (I assume he is properly licensed). When you image something with single disk resizable, there is a potential on an image resize the contents that were in sectors 5-7 may be skewed a bit by the image being resized.
Now in reality these are the very first sectors on the disk and the likelihood of them being shifted about is very small (and actually I’m a bit surprised that the master boot record doesn’t occupy those locations on the disk right now.
The way imaging happens is block for block. As long as there’s data on a sector, and those blocks are used, it will be copied. Is there a reason for this request, or is this more just information gathering trying to make sure if you make an image of this device the elements you need will be copied.
@Wayne-Workman You could use a postinit script function of FOG, a little bash shell programming and your script to capture those sectors before image capture too. That way the process would be fully automated.
Assuming a 512 byte sector size, this is the dd command to read sectors 5 through 7 to a file from disk 1.
dd if=/dev/sda of=/images/someImage/sectors5_7 skip=5 count=3 bs=512
To write that file back to those sectors:
dd if=/images/someImage/sectors5_7 of=/dev/sda skip=5 count=3 bs=512
You would need to capture these sectors manually - then you would need to write a postdownloadscript to check for this file
sectors5_7in the image you’re deploying. and if it’s there, to write it.
@george1421 if he’s only got a 100Mbit connection, zstd might actually be faster on the upload too, since the bandwidth will be the major bottleneck, not cpu utilization.
@kai yes raw mode has compression before its uploaded to the fog server. You just can’t shrink or expand the volume. As for compression if you are using fog 1.3.5 you can use zstd compression which will take longer to upload, but you will get a somewhat smaller file on the FOG server and quicker decompression speeds over the fog standard gzip compression.
In your case I would take an image and see if you can use raw disk format to get what you need.
@george1421 regarding the locations: I tend to not thinking in files here, because the card relies on the sectors 5 to 7 being present (and outside of a filesystem) and filled with the expected data, otherwise it asks to be installed.
Raw capture/deploy might be an option - but does this come with compression? Otherwise I might get stuck as I can only use 100 MBit/s-switchports here
I think for this I would use the raw disk capture/deploy option. With locating specific sectors, any type of resizing may potentially change these file locations.