[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Filesystem completely hosed

On Son, Mär 09, 2003 at 11:54:21 +0100, Alfred M. Szmidt wrote:
>    The current version of gnumach advertises itself as 1.2 (version in
>    changelog.Debian.gz: 20020421-1). Except for the announcenment I
>    haven't seen 1.3 anywhere.
> That's because there exists an small typo in the version string in GNU
> Mach 1.3.x.  If you look at ftp.gnu.org you will see the 1.3 tarball
> there (and if you look at the version string in that tarball you will
> notice that it says 1.2.x :).

Oh, I see. In the meantime I've discovered another possible reason for
the hassle. I removed the old GNU/Hurd partition with GNU parted and
re-created it. Parted said, I had an "unusual" partition table which
might cause probs with some boot loaders. In fact, the physical location
of the partitions doesn't conform with the partition numbers. 

The output
of fdisk -l /dev/hdc is as follows:

Disk /dev/hdc: 20.4 GB, 20496236544 bytes
16 heads, 63 sectors/track, 39714 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hdc1   *     35382     39446   2048287+  83  Linux
/dev/hdc2         39446     39701    128520   82  Linux swap
/dev/hdc3            16      7953   4000185   83  Linux
/dev/hdc4          7953     35382  13823932+   f  Win95 Ext'd (LBA)
/dev/hdc5          7953     15890   4000153+  83  Linux
/dev/hdc6         15890     30473   7349706   83  Linux
/dev/hdc7         30474     35381   2473600+  83  Linux

Partition table entries are not in disk order

Linux doesn't seem to care about this, so I never bothered correcting
it. But could it be that this gives either gnumach or hurd a headache?

I reinstalled a minimal GNU/Hurd system with gnu-latest.tar.gz. Now,
fschk fails and says it was unable to determine if the partition was
mounted and that the physical size of the device does not conform with
the partition table entry. Under GNU/Linux, though, I see no such

What would be the easiest way to correct this - if it is indeed the
reason for the failure? I was thinking about backing up hdc1, removing
the swap partition (hdc2) and then enlarging the extended partition to
re-create the removed partitions there (i.e. the former hdc1 and hdc2).
But AFAIK parted is unable to resize (enlarge) extended partitions,
isn't it? Is there another tool that does this safely?



Reply to: