osdir.com
mailing list archive

Subject: Re: Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_GETGEO semantics) - msg#00064

List: gnu.parted.bugs

Date: Prev Next Index Thread: Prev Next Index
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?
Yes No
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
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by