partition table corruption?

Hi Ingo,

It might clarify things if you could identify:

o the last version of 2.5 that worked for you,
o the version of 2.4 that works for you,
o the version of lilo that you are using for all of this.

Back in May, I experienced some similar problem and discussed
it with John Coffman, the lilo maintainer, whom I am cc'ing.

I'll just quote two parts of an email that he sent me during
our discussion. It's a little more relevant to your message if I quote them out of order:

| The head/sector mismatch check (fn 8h/fn 48h) has actually been in LILO
| since last year (22.0), and the (kernel/bios) check since 22.2.  It has
| only been seriously visible since the introduction of the 2.4.18 kernel.
| The IDE disk drivers are now reporting actual IDE disk geometry, rather
| than the mapped BIOS geometry, which was reported by all previous kernels.
| This change in the results returned by the IOCTL used to get the disk
| geometry has been extremely annoying.  It also leads to complaints about
| the format of the partition table.

Earlier in that seem email, he indicated that he was
thinking about giving precedence to the BIOS geometry in future versions of lilo (this was 22.3, and I believe the current version is now 22.3.1):

| Actually, on serious reflection on the issue, there is no choice:  the
| value returned by (int 13h/fn 8h) should be used, if it is available.  This
| is the value used by the conversion routine (linear/lba32 -> geometric) in
| the boot loader (read.S).  Currently, the kernel value is given precedence;
| I am seriously reviewing this issue.

I just wonder if this is the problem that you are experiencing
rather than anything that was new in 2.5.29.

Adam J. Richter     __     ______________   575 Oroville Road
[email protected]     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America

"Free Software For The Rest Of Us."

How did he think DOS does disk access during dos fdisk time before?
As far as I can see lilo is relying on the BIOS during the "dot printing phase" anyway so this should have been this way since day one of lilo. *Not* the other way around.

Yes.

folks, please keep in mind that this is a system that i just dont reconfigure at whim. It's a proven, known system i use for testing and nothing else. Suddenly it stopped working somewhere between 2.5.20 and 2.5.30. No lilo upgrade, no nothing, 2 years old binaries:

[mingo@a mingo]$ ls -l /sbin/lilo
-rwxr-xr-x 1 root root 59324 Aug 23 2000 /sbin/lilo

Ingo

Uz.ytkownik Ingo Molnar napisa?:

Yes sure. It is simply a very old bug in lilo, which the kernel worked around and did fight against in a diallectic way.

just tested 2.5.29-vanilla, it works, without and with linear. 2.5.30-vanilla is broken without linear, works with linear.

i dont mind who's at fault, but generally we just dont break working systems, no matter how good the reason. Somehow communicate with the lilo folks to handle this in a smooth way. Being able to boot trumps purity, no matter what.

Ingo

Excellent, precisely as expected.

[Yes, I don't know why an entire thread blossomed up around something very well understood. Many wrong statements were made, but I am too lazy to go and refute them all.

Concerning what happened: Long ago, the kernel did some more or less silly things to get a geometry - for example, asking the BIOS and the disk; but that did not produce the desired results and someone added (in 1.3.61) some code to override the geometry found this way by something guessed from the partition table, in the good old tradition: is there a bug in a user space program? fix it in the kernel. That is the [PTBL] you see in kernel boot messages. Now that this kernel fix has been removed in a small cleanup operation, lilo will have to be fixed, or people will have to invoke lilo with linear, or so.

The full truth is more complicated, but this is the full truth in your case.]

Andries

Its not a bug in lilo. Its a bug in the new kernel. Breaking backward compatibility arbitarily is bad. The kernel needs to know geometry anyway for the folks who have force ide translation

1. Requiring the kernel to read the partition table information is a BUG.

2. Falling back on the values which are used by the application afterwards is a BUG. (BIOS IRQ after all)

3. Not detecting LBA disk access is required by checking Cylinder value to emulate BIOS behaviour is a BUG.

4. Asking the kernel to kindly avoid 100% partition table scanning and
*guessing* some *heuristic* values which fail frequently enough is a BUG. (Take a look at the jumps and hops in the function in question if you don't think it is guessing. I recommend the switch in esp.)

5. Relying on the kernel for the translation "trick" himself (if anything) is a BUG.

6. It's after all no more inconvenient then renaming well for example the USB host controller module.

7. It is *not* breaking backward compatibility. After the lilo configuration fix the old kernel boots fine as well.

Not reading confusing lilo docs which should better say what to do is a BUG.

BTW.> Silly RH beta fdisk did tell me bogous things about the geometry of disks I did install under plain RH 7.3...

BTW.> And finally what about dd if=/dev/hda of=/dev/hdb?

We read it anyway to read the partitions for the block layer.

Breaking code is not a bug

So why did you take it out ?

Thank you for reminding me why I've given up on the 2.5 kernel ever working. Fortunately free software is self correcting so the tree can be forked into something workable

I say it n-th time already dd if=/dev/hda of=/dev/hdb should give a prefect sector by sector disk clone.

The bugs should be fixed in lilo and not worked around in the kernel. We have the goal (and in fact obligation for scalability issues) to move partition scanning out of the kernel space.

Did you ever bother looking the the function in question?

Did you ever look at the missordered code in lilo I cited here?

Did you ever think about what to do about the recurring complains from people about disk order differences between BIOS and Linux?

Or the whole GET_GEO_BIG confusion ioctl()?

Please compare it with the proper formulas provided at www.phoenix.com in excellent white papers. (Which can't be linked to directly, since they check the refferrer.)

It did contain 'heuristics" which stopped to annoy people just becouse
many have developed the immediate reflex of always adding the linear
parameter during lilo configuration already a very very long time ago
becouse anything else doesn't make much sense and disks have passed the 512MB or even 4G barrier quite a time ago.

	
	[email protected]>	<[email protected]>
	 <[email protected]>
	<[email protected]> 
	<[email protected]>

Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6)
Date: 08 Aug 2002 20:34:07 +0100
Message-Id: <[email protected]>
Mime-Version: 1.0

The specific case of the hack for EZdisk I have no issue with the general problem I do

Partition handling doesn't show up in any scalability benchmarks. Show me an IBM 8 way with partition reading showing up in lockmeter

Yes

Did you ever think that it

So fix the heuristics to the official algorithm. Thats a good thing to do and test in a development kernel tree.

And btw lots of people still use < 512Mb and < 4G disks. No doubt you'd prefer your kernel only ran on a pentiumII or higher

Alan

Hi,

I have lots of pseudo-diskless hosts. Whereever I didn't want to spend money for a boot PROM, I've grabbed out disks of ~30M, and things worked fine. If things don't, I also have a Busybox on those disks which can be booted instead of the network. They're clients, routers, blah...

Thunder

.-../../-./..-/-..- .-./..-/.-.././.../.-.-.-

Uz.ytkownik Thunder from the hill napisa?:

They still work becouse then lilo doesn't get confused.

They still work.