Bugzilla Bug 38685 says lilo "fixed already in 22.5.8" however the glibc233.patch used to fix the problem is incorrect. The problem occurs because gcc 3.x cannot find the a.out.h header file which includes the page.h header file which defines PAGE_SIZE. gcc 3.x cannot find a.out.h unless the file name is prefixed with the linux/ directory. I am inlcuding the correct patch. But it still begs the question, why can gcc 2.95 find the include file without the linux/ prefix, and gcc 3.x cannot? Looks like a gcc bug to me.
Created attachment 24393 [details, diff] corrected patch
For me 22.5.8 compiles fine using the glibc 233 patch, but I am on glibc 2.3.2? But afterwards I can not start lilo. It gives: ---cut--- root@syl maik(0) # lilo Fatal: cache_add: LILO internal error ---cut--- I contacted johninsd@san.rr.com and he told me: ---cut--- This is due to a change in the kernel headers which LILO includes. The compile error occurs for all versions of LILO up to & including the current, which is 22.5.8. Apparently, newer kernels no longer define this symbol. "#define PAGE_SIZE 4096" may be added to "common.h" to create a definition of this symbol. ---cut--- I cheated portage to accept a correspondingly modified 2.22.6-r2 not including the glibc233-patch, but fankly speaking, I am not happy with cheating portage, as I hardly understand very small parts of how it works :(.
> 22.5.8 compiles fine using the glibc 233 patch, but I am on glibc 2.3.2? glibc 2.3.2 vs glibc 2.3.3 is irrelevant. > But afterwards I can not start lilo. It gives: LILO internal error That's not surprising. As I already said, the patch is incorrect, and I provided a corrected patch. > I contacted johninsd@san.rr.com and he told me: >> Apparently, newer kernels no longer define this symbol. That is false. The PAGE_SIZE symbol is where it's always been, in asm/page.h, in kernels 2.4.22, 2.4.24, and 2.6.1. asm/page.h is included by linux/a.out.h, and gcc 3.x fails to find linux/a.out.h because in lilo boot.c, the #inlcude does not specify <linux/a.out.h>, it only has the file name <a.out.h> > "#define PAGE_SIZE 4096" may be added to "common.h" And yet another incorrect attempt at fixing the problem. > I am not happy with cheating portage Replace the incorrect patch with the one I provided, and it works fine. But the question still remains: Why does GCC 3.x FAIL to find a.out.h without the linux/ prefix? This would appear to be a glibc or gcc porting bug, since it finds the a.out.h header file without the linux/ prefix when using glibc 2.2.5 and gcc 2.95. But in any case, there is no harm in applying my patch. Since you have already contacted the lilo maintainer, I suggest you forward the patch to him.
I send the patch to the lilo maintainer and exchanged lilo-glibc233.patch on my system, too. However, after remerging lilo-22.5.8-r1: root@syl maik(0) # lilo -v5 LILO version 22.5.8, Copyright (C) 1992-1998 Werner Almesberger Development beyond version 21 Copyright (C) 1999-2003 John Coffman Released 10-Oct-2003 and compiled at 12:27:48 on Jan 26 2004 raid_setup: dev=0008 rdev=0300 raid_setup returns offset = 00000000 ndisk = 0 BIOS VolumeID Device Reading boot sector from /dev/hda geo_get: device 0300, all=1 pf_hard_disk_scan: (58,0) /dev/vg00/lv00 Caching device /dev/vg00/lv00 (0x3A00) pf_hard_disk_scan: (33,0) /dev/ide/host0/bus1/target0/lun0/disc Fatal: cache_add: LILO internal error I add FEATURES="noclean" and saw that the linux/ prefix was add in line with your patch. root@syl maik(1) # emerge info Portage 2.0.49-r20 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r9, 2.4.20-xfs-r3) ================================================================= System uname: 2.4.20-xfs-r3 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.4.3.10p1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1 /share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/tex/gen eric/config/ /usr/share/texmf/tex/platex/config/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache noclean sandbox" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror http:/ /gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib acl acpi alsa apm arts avi berkdb bonobo cdr crypt cscope cup s curl dga dierctfb doc dvb dvd dvdr emacs encode esd ethereal fastcgi foomaticd b gb gd gdbm ggi gif gnome gphoto2 gpm gps gstreamer gtk gtk2 gtkhtml guile imap imlib innodb jack java joystick jpeg kde ladcca lcms ldap libg++ libwww lirc ma d matroska mbox mcal mikmod motif mozilla mpeg mysql naspda ncurses nls oggvorbi s opengl oss pam pdflib perl png python qt quicktime readline samba scanner sdl slang slp snmp socks5 spell ssl svga sysl tcltk tcpd tetex tiff truetype usb vid eos wmf x86 xml2 xmms xosd xv zlib" I can only use the cheated lilo-2.5.6-r2 :(
> Fatal: cache_add: LILO internal error cache_add is in device.c, and it appears to be sanity checking device name vs. number. Apparently the new version of lilo cannot cope with your hardware setup, which would be a problem for the lilo maintainer. > Caching device /dev/vg00/lv00 (0x3A00) On my setup, lilo does not cache any device like that. I would guess your problem is a hardware/raid/lvm vs. lilo issue, unrelated to my patch.
Since your problem is a different bug, I suggest you create a new bug report with details of the difference between the lilo version which works vs. the one which fails. Perhaps the new lilo version is not tested well enough to be marked stable.
You are going to get the same issue with 2.6 headers, so rather then something like: +#ifndef PAGE_SIZE +#define PAGE_SIZE 4096 +#endif in "common.h" as suggested by the maintainer.
> You are going to get the same issue with 2.6 headers, so > +#ifndef PAGE_SIZE > +#define PAGE_SIZE 4096 > +#endif > in "common.h" as suggested by the maintainer. Look at the 2.6.1 headers. PAGE_SIZE is defined in <asm/page.h> just like 2.4.22. You and the maintiner are suggesting a duplicate, redundant defintion. Both wrong.
Actually the problem is newer glibc's a.out.h do not include asm/page.h anymore. So your issue is really just cosmetic of nature. I thing the more important issue is why the author do not want to use the linux a.out.h, but rather the one distributed with glibc ...
> newer glibc's a.out.h do not include asm/page.h > why the author do not want to use the linux a.out.h, > but rather the one distributed with glibc It is a mistake. Since lilo runs before the kernel, how can it make use of glibc? And thus why should lilo prefer an inlucde from glibc instead of the more appropriate one from the kernel? Perhaps this can be closed as a gcc bug, but I believe my patch should replace the existing one, to fix up lilo.
Since LILO 22.6 the patch is no longer needed, and I believe it all worked in 22.5.8-r2 and up. This bug seems old and stale, so I'm closing.
