[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: parted-1.4.11 seemed to cause Invalid Media Type
From: |
Andrew Clausen |
Subject: |
Re: parted-1.4.11 seemed to cause Invalid Media Type |
Date: |
Mon, 18 Jun 2001 09:30:13 +1000 |
User-agent: |
Mutt/1.2.5i |
Hi, it looks like my mail never made it to the list.
On Thu, Jun 07, 2001 at 10:28:43PM +0100, Simon Dalley wrote:
> I have had a slight disaster when resizing a couple of FAT32 partitions.
>
> I have a hard disk which _had_ a 779121KB (according to Linux fdisk)
> FAT32 partition on hda1 (cylinders 1-97). This was C: under my Windows
> 95 OSR2.
>
> It also had a D: drive, cyls 98-163, a logical partition of
> 530113KB which was also FAT32, on hda5.
>
> I also had an E: drive (FAT16) on hda6.
>
> hda7 - hda12 are GNU/Linux ext2 and swap partitions.
>
> The extended partition is hda2 which contains the D: and E: drives
> and all logical Linux partitions.
>
> Since I was getting tight on space on C: but had plenty spare on D:, I
> thought I would use parted to shrink D: (and hence the start of the
> extended partition) so that I could expand primary partition C:.
>
> The sequence of parted commands was something like
> resize 5 840 1278.610
> resize 2 839.333 6181.259
> (previous start of 2 was a smidgeon (=far less than a cylinder) less
> that previous start of 5, end was unchanged from previous value)
> (This resulted in 2 occupying 831.489 - 6181.259, starting about a full
> cylinder less than I expected - clue?)
The problem is, the first resize puts the start of partition 5 on
head 0, not head 1. So, Parted has to start the extended partition
on the previous cylinder.
Perhaps the solution is to always make Parted attempt to start partition
5 on head 1? I'm not sure how other software likes this...
(I should try it out!)
> resize 1 0.031 831.489
> (previous values for 1 were 0.031 to same value as prev. start of 2).
Right.
> The overall result was as below:
> /-------------
> (parted) print
> Warning: Unable to align partition properly. This probably means that
> another partitioning tool generated an
> incorrect partition table, because it didn't have the correct BIOS
> geometry. It is safe to ignore,but ignoring
> may cause (fixable) problems with some boot loaders.
> Ignore Cancel ? i
Did you get this message before?
> Disk geometry for /dev/hda: 0.000-19470.937 megabytes
> Disk label type: msdos
> Minor Start End Type Filesystem Flags
> 1 0.031 831.489 primary FAT
> 2 831.489 6181.259 extended
> 5 839.333 1278.610 logical FAT
> 6 1278.642 1404.118 logical FAT
> 7 1404.150 1670.822 logical ext2
> 8 1670.854 1804.174 logical linux-swap
> 9 1804.206 2023.813 logical ext2
> 10 2023.845 4016.250 logical ext2
> 11 4016.281 5098.754 logical ext2
> 12 5098.786 6181.259 logical
> 3 6181.260 6196.948 primary ext2 boot
> 4 6196.948 19469.399 primary ext2
> (parted) check 1
> (parted) check 2
> Error: Could not detect file system.
> (parted) check 5
> (parted) check 6
> (parted)
Looks fine.
> ---------------/
>
> I then rebooted to w95 and observed that both my C: and D: drives
> functioned beautifully with their new sizes.
>
> I then repeated the operation on my backup disk and used dd to back up
> /dev/hda1 and /dev/hda5 to identical partitions on the new disk.
>
> Imagine my dismay to then discover that my _E:_ drive (/dev/hda6)
> could no longer be
> read by windows. It gave something like "there has been a device failure
> on this disk". Booting from a w95 floppy gave no problems with dir
> command on C: and D:, but dir on E: gave
> Invalid media type error
> Abort, Retry, Fail ?
That is very weird. Before I continue: DO NOT RUN SCANDISK. It will
destroy the file system.
This usually indicates that Windows is looking in the wrong place for
the File Allocation Tables. Snipped from my docs on FAT:
"The cluster_size and fat_length fields are ignored by Microsoft's
implementation of FAT12 and FAT16, but NOT FAT32. That is, they are written
outcorrectly, but NOT READ IN. (Note: if FAT32 file system is configured to
have less than 65520 clusters, then Windows assumes it's FAT16)
Since these values don't usually change unless you resize a filesystem, this
causes no problems. However, if you want to resize the filesystem, you have to
calculate these values to what Microsoft calculates them to, from the size of
the filesystem. It took me 2 months to figure this out (I want to KILL
somebody...)"
(note: the Media Type is stored in both the boot sector, and the start of
each file allocation table. This is a basic sanity check by Windows, to
check if the file system is sane, with it's parameters
So, it looks like it's computing the offset of the FATs to something
different now. This might be because Parted wrote out different CHS
geometry for that partition. (Remember that previous error message)
I didn't realise this type of problem was possible! I should experiment
with it more, and update the docs/warning message...
Anyway, I would have suggested using parted to set all of your FAT
partitions to "LBA"...
(parted) set [PARTITION] lba on
I think that would have fixed it (because Windows will use the LBA
values for the partition, rather than the CHS ones)
> Rebooting under Linux, I was able to mount and access this partition
> with no problems at all, thank goodness.
>
> For what it's worth, the output of Linux fdisk is shown below:
> /---------------
> centaur:~ # fdisk /dev/hda
>
> The number of cylinders for this disk is set to 2482.
> There is nothing wrong with that, but this is larger than 1024,
> and could in certain setups cause problems with:
> 1) software that runs at boot time (e.g., LILO)
> 2) booting and partitioning software from other OSs
> (e.g., DOS FDISK, OS/2 FDISK)
>
> Command (m for help): p
>
> Disk /dev/hda: 255 heads, 63 sectors, 2482 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/hda1 1 106 851413+ b Win95 FAT32
> /dev/hda2 107 788 5478165 5 Extended
> /dev/hda3 * 789 790 16065 83 Linux
> /dev/hda4 791 2482 13590990 83 Linux
> /dev/hda5 108 163 449820 b Win95 FAT32
> /dev/hda6 164 179 128488+ 6 FAT16
> /dev/hda7 180 213 273073 83 Linux
> /dev/hda8 214 230 136520+ 82 Linux swap
> /dev/hda9 231 258 224878 83 Linux
> /dev/hda10 259 512 2040223 83 Linux
> /dev/hda11 513 650 1108453 83 Linux
> /dev/hda12 651 788 1108453 83 Linux
>
> Command (m for help): q
>
> -----------/
> I then tarred all files off E: (hda6) to a tarfile on hda12.
>
> Rebooting in full windows95, I ran w95 FDISK in a DOS box. This showed
> one DOS partition, one extended partition and 2 non-DOS partition in the
> primary entries. The extended partition displayed as _empty_ in spite of
> windows being able to see D: just fine.
>
> Then tried (in the dos box) doing format e:. Appeared to run fine - gave
> nice new empty filesystem.
>
> Rebooted in linux, ran fdisk. Alas, most of the extended partitions were
> gone altogether:
Ouch!
> /-----
> Warning: invalid flag 0x0000 of partition table 6 will be corrected by
> w(rite)
> Command (m for help): p
>
> Disk /dev/hda: 255 heads, 63 sectors, 2482 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/hda1 1 106 851413+ b Win95 FAT32
> /dev/hda2 107 788 5478165 5 Extended
> /dev/hda3 * 789 790 16065 83 Linux
> /dev/hda4 791 2482 13590990 83 Linux
> /dev/hda5 108 163 449820 b Win95 FAT32
> ------/
> Parted gave:
> /---------
> (parted) print
> Error: Invalid partition table on /dev/hda - wrong signature 0
> Ignore Cancel ? i
> Disk geometry for /dev/hda: 0.000-19470.937 megabytes
> Disk label type: msdos
> Minor Start End Type Filesystem Flags
> 1 0.031 831.489 primary FAT
> 2 831.489 6181.259 extended
> 5 839.333 1278.610 logical FAT
> 3 6181.260 6196.948 primary ext2 boot
> 4 6196.948 19469.399 primary ext2
> (parted)
> ----------/
> It is definitely a bug that /dev/hda6 (my E:) became inaccessible
> under W95 after adjusting the boundary between C: and D: with parted,
> wouldn't you think?
Well, it's a bug somewhere ;-) (The whole design of msdos partition
tables is broken to begin with, not to mention the BIOS)
We just need better warning messages.
I'm pretty sure all the problems are due to your Linux and BIOS
CHS geometries not matching, AND Windows using CHS.
(It's only a problem when both conditions are true)
The docs do tell you to make sure they match, just there's no
automatic way we can verify with parted. (msw: maybe that
virtual machine job...?)
BTW: have you tried using gpart to recover the other partitions?
I should add that support into parted...
(Note to everyone: I now have time to start cleaning up 1.5.x. I'll
do that when pretzelgod sends me device_linux.c that I stupidly
forgot to copy...)
> I am useing Suse 6.2 distribution.
>
> If there is any more info that I can provide, please let me know.
>
> Maybe documentation could be improved too? It was not clear about the
> order things should be done in where moving extended partitions was
> concerned.
>
> Backups are, indeed, a Good Thing. All the best for Parted, the GPL,
> and Free Software.
Thanks for the report!
Andrew Clausen (who has been stuck on exams, sorry for taking so long)