Re: [opensuse] Very basic dd question
Stevens
03/01/17 9:17 AM >>>
On 03/01/2017 08:25 AM, Christopher Myers wrote:
In case it helps, these are notes that I have on resizing .img files created by dd:
<snip>
Shrink the partition down using gparted.
That's where the train comes off the tracks, as my gparted won't shrink a partition. Runs for a while, gives me an option for converting to FAT32 instead of FAT16, yada yada yada then BOOM! a box pops up saying I've found a gparted bug. So, no gparted shrink here. At least, not for a FAT16 partition. I haven't tried anything else because it's FAT16 I'm working with, so if it works with something else it matters not.
Now, if this solution were as simple as dd'ing the first 170MB of the image, that would be great because there is only about 150GB +/- of data but I suspect that all OSes put something at the end of a partition instead of just from the front forward so only copying the front will lose the back and render the image useless. Or do I have that wrong?
Later, and thanks. Fred
Hmm, I'm not really sure, but maybe others will have some input? I do know that the reason that you need to shrink the partition before shrinking the image is so that the data will all get consolidated at the beginning of the disk, otherwise you'll potentially have files throughout the partition that'd get chopped out. But I'm not sure of better ways to shrink the partition, especially on the image file. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 1 Mar 2017 09:40:19 -0600
Christopher Myers
I suspect that all OSes put something at the end of a partition instead of just from the front forward so only copying the front will lose the back and render the image useless. Or do I have that wrong?
I don't think that's the case for all filesystems. But it's easy enough to try anyway and no harm done if it doesn't work? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
That's where the train comes off the tracks, as my gparted won't shrink a partition. Runs for a while, gives me an option for converting to FAT32 instead of FAT16, yada yada yada then BOOM! a box pops up saying I've found a gparted bug. So, no gparted shrink here. At least, not for a FAT16 partition. I haven't tried anything else because it's FAT16 I'm working with, so if it works with something else it matters not. Now, if this solution were as simple as dd'ing the first 170MB of the image, that would be great because there is only about 150GB ± of data but I suspect that all OSes put something at the end of a partition instead of just from the front forward so only copying the front will lose the back and render the image useless. Or do I have that wrong? Once your dos based fat16 disk is defragmented you will only have data at the back of the disk, all the executable's data is moved to the front of the data area. The disk is in this order first partition table then mbr the FAT (File alocation tables) then directories and file names then last of all the actual file data, which the defragmenter loads the important executable files first. The outermost data is generally text and such like. If you had the old dos norton disk doctor utilities, I found them on some mirror about a year and a half ago, you could first defrag the disk and manually shrink the partition using norton diskedit via rewriting
On 01/03/2017 17:40, Christopher Myers wrote: the mbr and partition table. I used to do it all the time once when the world was young. If I remember where the mirror was I'll post it. Best regards Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-03-04 13:17, Dave Plater wrote:
On 01/03/2017 17:40, Christopher Myers wrote:
but I suspect that all OSes put something at the end of a partition instead of just from the front forward so only copying the front will lose the back and render the image useless. Or do I have that wrong? Once your dos based fat16 disk is defragmented you will only have data at the back of the disk, all the executable's data is moved to the front of the data area.
Some MsDos utilities do write things to the very last record. I remember a PCTools or Norton utility that saved a copy of the FAT and root directory to the end of the disk. It could help on some recovery ops. However, nothing really broke if these files were lost: just create them again as usual (typically done by autoexec or a halt script). The system itself saved nothing specifically to the end of the disk.
The disk is in this order first partition table then mbr the FAT (File alocation tables) then directories and file names then last of all the actual file data, which the defragmenter loads the important executable files first. The outermost data is generally text and such like. If you had the old dos norton disk doctor utilities, I found them on some mirror about a year and a half ago, you could first defrag the disk and manually shrink the partition using norton diskedit via rewriting the mbr and partition table. I used to do it all the time once when the world was young. If I remember where the mirror was I'll post it. Best regards Dave P
A good tool to shrink partitions was Partition Magic. There is a CD or DVD going around that has a surprising collection of recovery tools for msdos/win. Not very legal, though. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
participants (4)
-
Carlos E. R.
-
Christopher Myers
-
Dave Howorth
-
Dave Plater