I can't use the lilo-22.5.5 ebuild. When starting up, all I see is "01 01 01 01 01 01 " etc. This is fully reproducable... I'm using a graphical (bitmap) bootmenu. All works fine with lilo-22.5.1, using a graphical boot with the same compileoptions, etc. Only the lilo-binary is different. The bootup also fails using lilo-22.5.5 with the boot-bmp.b from 22.5.1 Reproducible: Always Steps to Reproduce: 1. use a graphical bootmenu: bitmap = /boot/ins64e.bmp bmp-table = 12,18;3,7,20,4 bmp-colors = 14,11,;15,9,0 bmp-timer = 73,29;12,8,0 install = /boot/boot-bmp.b [...] 2. (add the rest of your lilo-setup to lilo.conf) 3. run lilo, and restart Actual Results: 01 01 01 01 10 10 10 10 01 01 10 01 10 01 01 01 01 (etcetera) Expected Results: graphical bootup. *) Compileflags are: "-mcpu=athlon-xp -O2 -pipe -fomit-frame-pointer -frerun-cse-after-loop -frerun-loop-opt -fexpensive-optimizations -ffast-math -msse -m3dnow -mmmx -mfpmath=sse,387" *) Using gcc-3.2.3-r1
Created attachment 14218 [details] my lilo configfile
Created attachment 14219 [details] Ignore this
Created attachment 14220 [details] Ignore this The configfile I use
Comment on attachment 14219 [details] Ignore this (resubmitted because an error occured in bugzilla during the first submission)
Comment on attachment 14220 [details] Ignore this (resubmitted because an error occured in bugzilla during the first submission)
I'm bumping this to Azarah as he seems to have had the most recent input into the ebuild. From the Changelog though: 03 Apr 2003; Martin Schlemmer <azarah@gentoo.org> lilo-22.5.1.ebuild : Set OPTS down to -O1 to fix a problem where lilo sometimes locked at boot. I realise that the comment refers to 22.5.1, but you might like to try rebuilding lilo with -O1 and less aggressive compile flags (perhaps just: -mcpu=athlon-xp -pipe) and see if that makes any difference. Additionally I haven't got a lilo configured box at the moment (grub shop here)
It seems the ebuild already forces the "-O1" flag, and nothing else, it seems to overwrite whatever value "OPT" has with "-O1": ---- src_compile() { [ -z "${CC}" ] && CC="gcc" emake CC="${CC}" OPT="-O1" \ ---- Or am I wrong? Based on this piece of code, I'd say the CFLAGS settings are actually totally ignored...
Having the same problems with 22.5.6 and I have just found out that both 22.5.5 and 22.5.6 don't make a "boot-bmp.b" nor a boot-txt.b nor a boot-menu.b. What the hell?!
It is a BARE SHAME(!!!) that noone actually follows this topic from the Gentoo team, but I already discussed this matter with the maintainer of lilo. It seems that some changes in the hd-detection causes lilo to see my DVD-rom as the first ("bios=0x80") drive, allthough it isn't a harddisk at all... People without harddisks as the first disk(s) (especially those with raid-arrays) should probably use: disk=/dev/my_actually_first_disc bios=0x80 (for me that is: disk=/dev/ataraid/disc0/disc bios=0x80 )
Kidion you've posted yourself a mess in here so please next time try to be a little neater. If you've managed to solve the problem as a configuration issue, than how should we fix this best? If you want a configuration file snip inserted than show us what you want it to look like and I'll be happy to accomodate you...
(If the bugzilla had worked properly, it wouldn't have gotten so messy. It just took a second and third submission to find out that the attachments were uploaded, but bugzilla only failed at the very last stage of the submission.) The problem is that I can't do without a working bootmenu. I just kept on editing package.mask every time I rsync'd. But I would have expected some more responsibility and cooperation from the maintainer of the lilo ebuild,but still no sign from him. Not even a "Sorry, I don't know". He did manage to submit a new (lilo-22.5.6) ebuild in the mean time, though. If someone chooses to upload/maintain an ebuild, he also should take responsibility when things fail for others with that ebuild. When you're actually one of the elite to submit new ebuild, you should at least to some level help people out on it. So excuse me when I just want to say thanks for nothing... I just hope this report may be of any use to people facing the same problems. It can be set to "resolved" now...
Lets start in the cool and collected way: I am fairly swamped currently, so this is the first time I am getting to this bug - sorry. Glad you got it working ... do you think we should add that to the example lilo.conf (/etc/lilo.conf.example), and if so do you mind submitting a patch ? Thanks. Then, the first time I read this, it was when comming home after another long day, so I was fairly tired. I thus did not take the comments in here very good, and wrote the message below. Now, yes, this is not normally how I would react, and it is not the way we should do things either. I decided to leave it be and sleep it over, and then decide if I should post it or not. I currently do not think making that official is a good idea, but I do not want to 'not post' it either ... thus: 1) If it makes you understand what many of the Gentoo devs (and I guess many others that contribute to OO (Open Source) have_to_face/are_feeling, great. 2) If it does offend, sorry, please disregard. Thanks. ------------------------------------------------- Ok, I do not know who you refer to as the maintainer, but I guess before phosphan went all balistic on 22.5.6, it was considered as me and Chip. Now, if you do refer to me: 1) I am sorry if Gentoo do not have sponsors like RH/MDK/whoever to enable me to work full time on Gentoo, but rather have to try and get to all my bugs when ever I do get home after my 12-18 hour job currently. 2) I am sorry that my mail was (and is currently again) down for some stretches, and that I lost a lot of it at some stage, so did not get all my bugzilla stuff. 3) I am sorry that I get so little time when I am home and do not just want to hit the sack, that I have about 2300 unread bugzilla mails, and about 2800 -core/-dev mails. 4) I am sorry that I have to try and tread through about 350-500 bugs that am assigned to me, I am CC'd in, or part of the group (gnome, release,xfree,mozilla,etc), and thus with my very little spare time currenly after the bussiness rocketed, cannot get to all. 5) And lastly, I am sorry that I make this public scene after getting home again today after another 13hour day at work, and then tried to sort through some of my latest bugs to see if I can make head way and not just pull out all my hair with the older more tricky stuff that have been around for a bit, and then getting to this, over reacting because just one more person are not prepared to understand that what we are doing here (and many others in the OO world), is out of passion/whatever without any compensation, but just have to make demands and act as if I (we?) are an employee that need to slave for that user without even a "thanks that except for the latest version, it has worked really ok for me". Anyhow, everybody who in this time did mail me directly, did get a reply when my mail was up. And once again sorry for this 'scene', as I will prob regret it in the morning.
I do regret some things I've said, it's really upsetting when a very serious bug isn't looked into, I would have liked to undo some things said... But getting a member of the gentoo-team elite and/or submitting an ebuild includes some responsibilities (as is stated in the dev. docs) and I would recommend you to use message filters & folders to seperate urgent emails form less urgent. I think it's foolish to release new ebuilds while you are unable to read your bugzilla emails that may concern the current/new ebuilds. You are entitled to disagree Anyway, this bug is one in lilo 22.5.[56] and the last couple of days I've worked closely with John Coffman (maint. of lilo) to fix the problem for future lilo-releases. I'm pleased to announce that he lilo-22.5.7-beta3 already contains a fix for anyone with a promise/highpoint raid-controller like me. (Of course we'll have to wait for the stable release for an ebuild). However adding a line to lilo.conf.example does seem to me like a good idea, I would propose the following: --- # if you're having problems booting from a hardware raid-array # or have a unusual setup, try this: #disk=/dev/ataraid/disc0/disc bios=0x80 # see this as the first BIOS disk #disk=/dev/sda bios=0x81 # see this as the second BIOS disk #disk=/dev/hda bios=0x82 # see this as the third BIOS disk --- By the way: the boot-*.b files are no longer needed from lilo-22.5.5 (according to the maintainer), you may want to adapt src_install (again) accordingly. The boot-*.b files are now linked into the lilo-binary.
> But getting a member of the gentoo-team elite and/or submitting an ebuild > includes some responsibilities (as is stated in the dev. docs) and I would > recommend you to use message filters & folders to seperate urgent emails > form less urgent. I think it's foolish to release new ebuilds while you are > unable to read your bugzilla emails that may concern the current/new ebuilds. > You are entitled to disagree > And I do, as it was not me adding 22.5.6 :P Like I said, I haven't been able to get to anything lately, and thus the backlog and not getting to this sooner. If you need to shout at anybody for not looking at outstanding bugs when doing a new ebuild, shout at Phosphan 8) > Anyway, this bug is one in lilo 22.5.[56] and the last couple of days I've > worked closely with John Coffman (maint. of lilo) to fix the problem for > future lilo-releases. I'm pleased to announce that he lilo-22.5.7-beta3 > already contains a fix for anyone with a promise/highpoint raid-controller > like me. (Of course we'll have to wait for the stable release for an ebuild). > Ok, great to know, thanks. > However adding a line to lilo.conf.example does seem to me like a good idea, > I would propose the following: > --- > > # if you're having problems booting from a hardware raid-array > # or have a unusual setup, try this: > #disk=/dev/ataraid/disc0/disc bios=0x80 # see this as the first BIOS disk > #disk=/dev/sda bios=0x81 # see this as the second BIOS disk > #disk=/dev/hda bios=0x82 # see this as the third BIOS disk > > --- > Yes, I would like that as well, as we might get this issue in the future again with new BIOS/controller .... > By the way: the boot-*.b files are no longer needed from lilo-22.5.5 > (according to the maintainer), you may want to adapt src_install (again) > accordingly. The boot-*.b files are now linked into the lilo-binary. > Ah, ok, missed that. I wondered why he commented time in 22.5.5 ... You still just specify boot-bmp.b/boot-text.b/whatever in lilo.conf though ?
> Ah, ok, missed that. I wondered why he commented time in 22.5.5 ... > You still just specify boot-bmp.b/boot-text.b/whatever in lilo.conf > though ? > Yep, or just "text", "menu", etc. Anyhow, will commit a new version with new example in a bit.
