>On Sun, 10 Mar 2013 09:33:39 +0000
>tilmanbregler <tilmanbreg...@gmail.com> wrote:
>
> [snip]
>
> sudo fdisk -l
>
> Disk /dev/sda: 750.2 GB, 750156374016 bytes
> 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disk identifier: 0x05b005af
>
> Device Boot Start End Blocks Id System
> /dev/sda1 * 2048 206847 102400 7 HPFS/NTFS/exFAT
> /dev/sda3 206848 1465147391 732470272 5 Extended
> /dev/sda5 1024004096 1449783295 212889600 83 Linux
> /dev/sda6 1449785344 1465147391 7681024 82 Linux swap / Solaris
>
> Ideally, i'd like to create the ntfs partition starting at sector
> 206848. Any ideas how i can do that, or get back my windows partition,
> otherwise?
>
> Thanks in advance,
>
> Tilman
In short, what you wish to do is impossible, as such.
The "standard issue" PC partition table has only four slots for
partitions, called "physical partitions". In the case more partitions
are needed, the last partition gets subpartitioned. The subpartition
table is kept at the start of the fourth partition. These subpartitions
are called "virtual partitions".
So you are unable to make the NTFS partition start at 206848 presumably
because that is the first sector of where the virtual partition table is
being kept.
If you did at one point write a 5-partition table to the disk, with the
NTFS partition starting beyond sector 206848, with the content between
the end of /dev/sda1 and the start of NTFS partition being unaccounted
for, I am afraid that the start of your NTFS partition (and, by
extension, NTFS filesystem) has been nuked.
If, on the other hand, you did not write a 5-partition layout to the
disk, it is still possible for the resizing of the NTFS filesystem to
have hosed your Windows. This possibility has to do with bootloaders
and the way they find later stages. Because the Master Boot Record of
either the entire disk or just a partition is very, very small, the
very first stage of the bootloader also has to be very small which
translates into the bootloader being very dumb. This stupidity is
normaly worked around by having the first stage of the bootloader seek
a preprogrammed sector on the disk, loading the second stage of the
bootloader contained therein and passing control to it. What this means
is that once the first stage of the bootloader gets written into the
MBR, the file containing the second stage Must. Not. Be. Touched.
Otherwise, the first stage will not be able to find it. [See footnote
for aditional words of I-leaned-this-the-hard-way-just-like-you-now
wisdom.] It is entirely possible that during the resizing of the NTFS
the resizing program moved the second stage bootloader.
Footnote: In the case bootloader is single-stage, like LILO is, the
system operates in a similar way. Instead of searching for
the second stage bootloader, LILO is searching a specific
array of disk sectors for the Linux kernel. For this reason,
in every case that the kernel gets changed, LILO has to be
rewritten into the MBR so that the new kernel can be found.
Footnote.2: You know, it may be possible to get around this problem by
writing the contents of the new file into the old file.
((cat newfile > oldfile) instead of (cp newfile oldfile))
However, the contents would have to be of the same length
and you would have to rely on the filesystem to not move
the files around (I think ext3 does move files (reallocate
the sectors for the file) in this case but ext2 does not
move them; ext3 can be changed into ext2 by turning off the
journal).
--
You don't need an AI for a robot uprising.
Humans will do just fine.
--Skynet
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
