Copy Sectors 5-7 from HDD
-
@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 -
@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 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.
-
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_7
in the image you’re deploying. and if it’s there, to write it. -
@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.
-
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.
-
@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.
-
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.
-
@kai any news? Topic is interesting
-
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.