Uz.ytkownik Ingo Molnar napisa?:
> On Thu, 8 Aug 2002, Marcin Dalecki wrote:
>
>
>>>>LILO without "linear" or "lba32" is inherently broken: it will talk CHS
>>>>at boot time to the BIOS and hence needs a geometry and install time,
>>>>and nobody knows the geometry required. So, if LILO doesnt break, this
>>>>is pure coincidence.
>>>
>>>
>>>well, lilo without linear worked for like years on this box ...
>>
>>You have to take in to account that by creating a new kernel image
>>you are storing it sometimes after a long long time at perhaps maybe
>>another block group far away. This is becouse ext2 suddenly may feel
>>like doing so...And surprisingly you have to teach lilo about the new
>>far away sectors becouse basic C/H/S addressing can't reach them
>>anylonger. Been there seen that frequently enough.
>
>
> this particular testbox has seen *thousands* of development kernels of all
> sizes, and i often have filled up the complete /boot partition. It is very
> unlikely that this harmless (and not too big) 2.5.29 kernel would have
> been the first one to trigger a 'wrong' CHS combination. Especially since
> 2.4 kernels with exactly the *same* bzImage (and same lilo) work just
> fine.
Well well having a look at lilo-s inwards I can the the following:
if (ioctl(fd,HDIO_GETGEO,&hdprm) < 0)
die("geo_query_dev HDIO_GETGEO (dev 0x%04x): %s",device,
strerror(errno));
geo->heads = hdprm.heads;
geo->cylinders = hdprm.cylinders;
geo->sectors = hdprm.sectors;
geo->start = hdprm.start;
if ((geo->device = bios_device(geo, device)) < 0)
geo->device = 0x80 + (MINOR(device) >> 6) +
(MAJOR(device) == MAJOR_HD ? 0 :
last_dev(MAJOR_HD,64));
If you look at the boot messages from a kernel:
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 78140160 sectors, CHS=77520/16/63, UDMA(33)
hda: hda1 hda4
You can actually see the CHS info field.
Would you care to maybe compare them between 2.4 and 2.5 on the
system in question?
If they are not different, well, taking a look at the bios_device()
in lilo you can actually see that it doesn't know *anything* about
EZ disk or similar partition table tricks and therelike - this can be
definitively considered a bug *there*.
On Thu, 8 Aug 2002, Marcin Dalecki wrote:
> If you look at the boot messages from a kernel:
>
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hda: 78140160 sectors, CHS=77520/16/63, UDMA(33)
> hda: hda1 hda4
>
> You can actually see the CHS info field.
okay, here are the 2.4.18(-ish) and 2.5.30 CHS fields:
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 8418816 sectors (4310 MB) w/80KiB Cache, CHS=524/255/63, UDMA(33)
hdc: 40132503 sectors (20548 MB) w/1900KiB Cache, CHS=39813/16/63, UDMA(33)
hdb: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache
hda: QUANTUM FIREBALL SE4.3A, DISK drive
hdb: RICOH CD-R/RW MP7083A, ATAPI CD/DVD-ROM drive
hdc: QUANTUM FIREBALLP LM20.5, DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 8418816 sectors w/80KiB Cache, CHS=14848/9/63, UDMA(33)
hda: hda1 hda2 < hda5 hda6 >
hdc: 40132503 sectors w/1900KiB Cache, CHS=39813/16/63, UDMA(33)
hdc: hdc1
hdb: Disabling (U)DMA for RICOH CD-R/RW MP7083A
hdb: DMA disabled
hdb: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache
i have the bootlogs of this system back to 2.5.25 only, which also shows
the wrong(?) CHS:
Linux version 2.5.25 (mingo@mars) (gcc version 2.96 20000731 (Red Hat Linux 7.2
2.96-101.9)) #3 SMP Tue Jul 9 21:12:18 CEST 2002
hda: QUANTUM FIREBALL SE4.3A, DISK drive
hdb: RICOH CD-R/RW MP7083A, ATAPI CD/DVD-ROM drive
hdc: QUANTUM FIREBALLP LM20.5, DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 8418816 sectors w/80KiB Cache, CHS=14848/9/63
hda: [PTBL] [524/255/63] hda1 hda2 < hda5 hda6 >
hdc: 40132503 sectors w/1900KiB Cache, CHS=39813/16/63
hdc: hdc1
Ingo