|
|
Subject: Re: Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_GETGEO semantics) - msg#00064
List: gnu.parted.bugs
On Tue, 6 Jul 2004, Szakacsits Szabolcs wrote:
> On Mon, 5 Jul 2004, Bartlomiej Zolnierkiewicz wrote:
> > On Monday 05 of July 2004 23:08, Andries Brouwer wrote:
[...]
> Are you really not aware of the seriousness of the issue? Didn't you read
> the bugzilla URL's sent? LWN, Eweeks, O'Reilly, OSNews, Slashdot, Amazon
> and many others discussed this 2.6 kernel problem already. Only kernel
> developers aren't aware of it? :-o
>
> > > Also "the old situation" is badly defined. The returned value differs
> > > for 2.0, 2.2, 2.4, 2.6.
>
> 2.4 was slightly broken. 2.6 is much more broken than 2.4 from the
> number of partition table corruptions point of view.
Neither 2.6 nor 2.4 are broken. It was well known all the time that
HDIO_GETGEO returns CHS values that are close to useless: all partitioning
tools spend lots of time on partition table guesswork. I really don't see a
point in blaming 2.6 here.
Nevertheless we have the fact that parted and kernel 2.6 don't work well
together. Now what? To get out of this people have to get either a changed
parted or a changed kernel.
And IMO it's far better to fix parted than to reintroduce an obscure piece
of code into the kernel.
Steffen
Was this page helpful?
Thread at a glance:
Previous Message by Date:
click to view message preview
Re: Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_GETGEO semantics)
On Tue, Jul 06, 2004 at 02:17:47AM +0200, Szakacsits Szabolcs wrote:
...
We agree about most of the facts, and I am too lazy to quarrel anyway.
Such a waste of time. But we draw different conclusions.
We discover that the present combination of 2.6 and parted is
unfortunate. Because of bugs in parted. OK - so lets fix them.
There is nothing especially difficult there.
You prefer a larger change to the kernel above a smaller change
to parted, where the change to parted fixes parted, and the change
to the kernel makes the kernel buggier. I do not.
You say that other utilities are affected. Maybe, yes.
So let us look at them. In the time spent writing all these
letters we probably could have fixed a few.
Andries
Next Message by Date:
click to view message preview
Re: Parted hates my partition table, can't update to Fedora Core
On Jul 3, 2004, at 5:23 AM, Andrew Clausen wrote:
On Sat, Jul 03, 2004 at 10:18:52PM +1000, Andrew Clausen wrote:
The problem seems to be that partitions 6 and 7 aren't inside the
extended partition. I can't think of any painless way to fix this.
Perhaps delete partitions 4, 5, 6 and 7 and recover them with gpart?
P.S. How did you end up with this weird partition table?
Disk Druid under RedHat 7.3. This machine is a Dell, and _must_ have
the weird, goofy partition in there to boot. The first time I booted
the older (7.3) install tools, I had to do a lot of dancing to make
sure there was always a type 222 partition around for the next boot.
That's why the NetBSD partition starts at 64260; there used to be
another copy of the 222 partition there.
I'm attaching the output of NetBSD's fdisk program, mainly as there are
a lot more extended partitions that aren't showing up. However it looks
like you're right, that some of the partitions are off the end of the
intermediate extended partition.
I might also just try adjusting the length of the outer extended
partition.
Take care,
Bill
Disk: /dev/wd0d
NetBSD disklabel disk geometry:
cylinders: 16383 heads: 16 sectors/track: 63 (1008 sectors/cylinder)
BIOS disk geometry:
cylinders: 1023 heads: 255 sectors/track: 63 (16065 sectors/cylinder)
Partition table:
0: sysid 169 (NetBSD)
start 64260, size 14008680 (6840 MB), flag 0x0
beg: cylinder 4, head 0, sector 1
end: cylinder 875, head 254, sector 63
1: sysid 12 (Primary DOS with 32 bit FAT - LBA)
start 14072940, size 13020682 (6357 MB), flag 0x0
beg: cylinder 876, head 0, sector 1
end: cylinder 1022, head 254, sector 63
2: sysid 131 (Linux native)
start 27093622, size 12288000 (6000 MB), flag 0x0
beg: cylinder 1022, head 254, sector 63
end: cylinder 1022, head 254, sector 63
3: sysid 5 (Extended partition)
start 39381622, size 266798 (130 MB), flag 0x0
beg: cylinder 1022, head 254, sector 63
end: cylinder 1022, head 254, sector 63
Extended partition table:
0: sysid 130 (Linux swap or Prime or Solaris)
start 39381685, size 266735 (130 MB), flag 0x0
beg: cylinder 1023, head 101, sector 8
end: cylinder 1023, head 254, sector 63
1: sysid 5 (Extended partition)
start 39648482, size 64198 (31 MB), flag 0x0
beg: cylinder 1023, head 0, sector 63
end: cylinder 1023, head 254, sector 63
Extended partition table:
0: sysid 222 (unknown)
start 39648483, size 64197 (31 MB), flag 0x0
beg: cylinder 1023, head 1, sector 1
end: cylinder 1023, head 254, sector 63
1: sysid 5 (Extended partition)
start 39712742, size 417628 (203 MB), flag 0x0
beg: cylinder 1023, head 0, sector 63
end: cylinder 1023, head 254, sector 63
Extended partition table:
0: sysid 131 (Linux native)
start 39712743, size 417627 (203 MB), flag
0x0
beg: cylinder 1023, head 1, sector 1
end: cylinder 1023, head 254, sector 63
1: <UNUSED>
2: <UNUSED>
3: <UNUSED>
2: <UNUSED>
3: <UNUSED>
2: <UNUSED>
3: <UNUSED>
PGP.sig
Description: This is a digitally signed message part
_______________________________________________
Bug-parted mailing list
Bug-parted@xxxxxxx
http://lists.gnu.org/mailman/listinfo/bug-parted
Previous Message by Thread:
click to view message preview
Re: Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_GETGEO semantics)
On Wed, 7 Jul 2004, Roman Zippel wrote:
> At this point we either complete the job and remove this ioctl or we
> restore the 2.4 behaviour (maybe with a deprecated warning).
Well, yes. Perhaps a competent guy/gal could even fix most of the broken
2.4 cases during the same time, e.g. by using EDD, if possible and make
sense. But somehow I doubt anybody would take this nasty retore&fix
challange and actually it's even possible.
I also say, things might rely on the 2.6 behavior now, thus they might be
broken by the restoration. They should be investigated to prevent
deserving another brown paper bag.
Andries says, it's not a kernel issue because he is going on vacation soon
(that's why he's off-topic all the time, wanting to adjust only the easy
user space quickly).
Szaka
Next Message by Thread:
click to view message preview
Re: Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_GETGEO semantics)
On Mon, 5 Jul 2004, Bartlomiej Zolnierkiewicz wrote:
> On Monday 05 of July 2004 14:14, Szakacsits Szabolcs wrote:
>
> > - nobody could point out any _technical_ benefit why the new
> > HDIO_GETGEO code is better than the old one (the _way_ Andries wanted to
>
> Andries pointed it many times but you seem to completely ignore it
Hmmm. I'm recovering people's partition tables in my spare time,
voluntarily, free of charge when they got trashed due to Andries' and
Andrew's bugs over the last two years (gpart, testdisk and parted's
rescue mode don't always work),
http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#troubleshoot
I reported them several bugs, hints, reasons, potential reasons, guesses,
user feature request both privately and publicly.
I do know very well Andries' arguments, I've learnt them the hard way.
Actually I responded them several times, even in this thread.
> I also pointed out that IDE driver _doesn't_ need BIOS geometry et all.
Thanks but I thought it was off-topic and think the same now, too. It was
explained several times.
However none of you who responded seems to understand, still, what I want
to say.
You can't fix, for example, parted 1.6.11 and all earlier versions when
one does a 2.4 -> 2.6 kernel upgrade. If a user uses an old enough tool on
the new kernels then it can trash its partition table whatever the OS it
is (not only the geometry but the layout in sectors, too).
Also, sometimes [even very popular] distros ship one or two old tools, no
need for kernel upgrade. Whenever a user use the shipped old tool on 2.6
it can trash the partition table, being during install or later.
You, Bartlomiej Zolnierkiewicz, Andries Brouwer and Steffen Winterfeldt
say don't care about those people. OK, at least now it's documented
and this thread can be pointed out as a reference in the future.
Since there is nothing I could do more if maintainers aren't willing to
fix their more destructive 2.6 kernel code, the case is closed from my
part by this email.
Thanks,
Szaka
|
|