Hi,
Would one of you guys would be kind enough to redirect this
e-mail to the right person ;-)
Playing with 2.6.7 on my laptop. I realised Lilo did not work
anymore. Look further, and the partition table was all screwed
up. Looked further, and I realised the kernel doesn't recognise the
geometry of my hard drive.
I did not try other 2.6.X kernel, on the other hand various
2.4.X kernel works on the box. Kernel are direct from kernel.org.
Below is the after/before. First is 2.6.7 (bogus), second is
2.4.23 (correct).
Thanks in advance...
Jean
-----------------------------------------------------------------
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 0000:00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1820-0x1827, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1828-0x182f, BIOS settings: hdc:DMA, hdd:pio
hda: IBM-DARA-206000, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: CD-224E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 9767520 sectors (5000 MB) w/418KiB Cache, CHS=10336/15/63, UDMA(33)
hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
-----------------------------------------------------------------
Disk /dev/hda: 15 heads, 63 sectors, 10336 cylinders
Units = cylinders of 945 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 1168 551848+ a0 IBM Thinkpad hibernation
Partition 1 does not end on cylinder boundary:
phys=(72, 239, 63) should be (72, 14, 63)
/dev/hda2 1169 6176 2366280 b Win95 FAT32
Partition 2 does not end on cylinder boundary:
phys=(385, 239, 63) should be (385, 14, 63)
/dev/hda3 * 6177 8352 1028160 83 Linux
Partition 3 does not end on cylinder boundary:
phys=(521, 239, 63) should be (521, 14, 63)
/dev/hda4 8353 10336 937440 5 Extended
Partition 4 does not end on cylinder boundary:
phys=(645, 239, 63) should be (645, 14, 63)
/dev/hda5 8353 8624 128488+ 82 Linux swap
/dev/hda6 8625 10336 808888+ 83 Linux
-----------------------------------------------------------------
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1820-0x1827, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1828-0x182f, BIOS settings: hdc:DMA, hdd:pio
hda: IBM-DARA-206000, ATA DISK drive
blk: queue c0278820, I/O limit 4095Mb (mask 0xffffffff)
hdc: CD-224E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 9767520 sectors (5001 MB) w/418KiB Cache, CHS=646/240/63, UDMA(33)
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
-----------------------------------------------------------------
Disk /dev/hda: 240 heads, 63 sectors, 646 cylinders
Units = cylinders of 15120 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 73 551848+ a0 IBM Thinkpad hibernation
/dev/hda2 74 386 2366280 b Win95 FAT32
/dev/hda3 * 387 522 1028160 83 Linux
/dev/hda4 523 646 937440 5 Extended
/dev/hda5 523 539 128488+ 82 Linux swap
/dev/hda6 540 646 808888+ 83 Linux
-----------------------------------------------------------------
On Wed, Jun 23, 2004 at 03:05:57PM -0700, Jean Tourrilhes wrote:
> Playing with 2.6.7 on my laptop. I realised Lilo did not work
> anymore. Look further, and the partition table was all screwed up.
Not so pessimistic.
Old situation:
> hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
New situation:
> hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
Nothing wrong with that partition table.
Maybe you get unhappy because of the fdisk output, but that only
shows that you have an old fdisk. Also there nothing wrong.
Ah - so the only wrong thing must be the fact that lilo stopped working.
I suppose things will improve if you give it the "linear" (or "lba32") flag.
What changed is that the kernel no longer attempts at guessing a geometry.
If such guessing is required, user space must do so itself.
Andries
On Thu, Jun 24, 2004 at 12:56:40AM +0200, Andries Brouwer wrote:
> On Wed, Jun 23, 2004 at 03:05:57PM -0700, Jean Tourrilhes wrote:
>
> > Playing with 2.6.7 on my laptop. I realised Lilo did not work
> > anymore. Look further, and the partition table was all screwed up.
>
> Not so pessimistic.
Sorry, I should have said "the partition table display".
> Old situation:
> > hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
> New situation:
> > hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
>
> Nothing wrong with that partition table.
Yep.
> Maybe you get unhappy because of the fdisk output, but that only
> shows that you have an old fdisk. Also there nothing wrong.
Ok.
> Ah - so the only wrong thing must be the fact that lilo stopped working.
> I suppose things will improve if you give it the "linear" (or "lba32") flag.
None of these helped. I guess I should update LILO as
well. I'll try to do that.
> What changed is that the kernel no longer attempts at guessing a geometry.
> If such guessing is required, user space must do so itself.
>
> Andries
Thanks very much for the quick answer, very helpful !
Jean
Having partition table troubles here with 2.6.7 on hdc: unknown partition table.
but not on hda.
Using 2.6.6 kernel, hdc is handled just fine, partitions are visible.
The boot drive is hda, drive hdc is for other optional mount points.
VP_IDE: IDE controller at PCI slot 0000:00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
hda: WDC AC26400B, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: QUANTUM FIREBALL CR8.4A, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2: I/O resource 0x3EE-0x3EE not free.
ide2: ports already in use, skipping probe
hda: max request size: 128KiB
hda: 12594960 sectors (6448 MB) w/512KiB Cache, CHS=13328/15/63
hda: hda1 hda2 hda3 < hda5 hda6 >
hdc: max request size: 128KiB
hdc: 16514064 sectors (8455 MB) w/418KiB Cache, CHS=16383/16/63
hdc: unknown partition table
--------
It's been said in this thread that the kernel no longer guesses a geometry;
it's also been said elsewhere that the kernel doesn't use CHS at all.
What do I put on the kernel parameter line to give a define geometry?
I've tried hdc=lba32, with no success.
On Fri, Jun 25, 2004 at 07:28:54PM -0700, [email protected] wrote:
> Having partition table troubles here with 2.6.7 on hdc: unknown partition table.
>
> Using 2.6.6 kernel, hdc is handled just fine, partitions are visible.
> The boot drive is hda, drive hdc is for other optional mount points.
>
> hdc: QUANTUM FIREBALL CR8.4A, ATA DISK drive
> ide1 at 0x170-0x177,0x376 on irq 15
> hdc: max request size: 128KiB
> hdc: 16514064 sectors (8455 MB) w/418KiB Cache, CHS=16383/16/63
> hdc: unknown partition table
>
> It's been said in this thread that the kernel no longer guesses a geometry;
> it's also been said elsewhere that the kernel doesn't use CHS at all.
> What do I put on the kernel parameter line to give a define geometry?
Well, I suppose whatever geometry you invent will make no difference at all.
Roughly speaking, Linux does not use any geometry.
Also, the geometry change you refer to is old, not something that happened
during 2.6.
Since reading the partition table is the very first thing that happens
on the disk, any kind of IDE problem will cause problems reading the pt
Check whether you can read that disk using dd.
Check that fdisk still can read the table on that disk.
Go back to 2.6.6 and check that the pt table is still OK.
Check what type it is, and that your 2.6.7 kernel still has
configured that type.
Using
fdisk v2.11u
displays the partition table for the drive that the kernel claims has an unknown
partition table. The bootable flag indicator is neither blank nor an *; instead it
was the ? character. Toggling the bootable flag in fdisk (bringing up the * ) and
writing the changed partition table allowed the booting kernel to then read
the partition table. This partition table has not been touched for many a kernel
version and has been identified by all the previous kernels, through 2.6.6.
Would the change that stopped the kernel from "guessing" the disk geometry have
brought out the sensitivity to whatever was not correct with the PT?
Quoting Andries Brouwer :
> Check whether you can read that disk using dd.
> Check that fdisk still can read the table on that disk.
> Go back to 2.6.6 and check that the pt table is still OK.
> Check what type it is, and that your 2.6.7 kernel still has
> configured that type.
>
On Sat, Jun 26, 2004 at 09:32:44AM -0700, [email protected] wrote:
> displays the partition table for the drive that the kernel claims has an unknown
> partition table. The bootable flag indicator is neither blank nor an *; instead it
> was the ? character. Toggling the bootable flag in fdisk (bringing up the * ) and
> writing the changed partition table allowed the booting kernel to then read
> the partition table. This partition table has not been touched for many a kernel
> version and has been identified by all the previous kernels, through 2.6.6.
> Would the change that stopped the kernel from "guessing" the disk geometry have
> brought out the sensitivity to whatever was not correct with the PT?
Ah, excellent. See - I have no memory.
No - I keep repeating: please stop this geometry nonsense.
This is something entirely different. Linux does automatic partition recognition.
That of course is bad, especially if there is no partition table at all, like on
certain ZIP drives and memory cards for digital cameras (that behave like
big floppies). In order to guess right more often the kernel now only believes
that something is a valid DOS-type partition table when there is a valid
bootable flag indicator (0 or 0x080).
You had garbage there (or at least an unusual value) - and the garbage was harmless,
but now causes the kernel to reject this table.
Remains the question: do you have any idea from where you got this unusual value?
Andries