On Wed, 2005-04-20 at 10:52 -0600, Guy Fraser wrote: [snip] Because I note a hint of willingness here, I'll respond again. > 1) If I spend the time to test GRUB on FC4t2, and discover the > same problems still exist, that I have seen before and can not > resolve the issue using the wonderful info documentation, are > you saying you would then consider LILO to be needed. That is not the nature of testing. Though if it were up to me, I personally would not rule out re-including lilo, you're leaving out a few important steps, here. If you discover the same problems still exist and you can't resolve them with the documentation you need to: a) Define what 'same problems' you are talking about. This may mean chipset information, mobo info, drive types (IDE, PATA, SATA, SCSI), drive arrangement (primary master, secondary slave, scsi id 0, etc.), and other pertinent information (software raid info with config files). You may not need to post this much detail to the list, but save it for a possible, future bugzilla entry. b) See if someone on the list can help. If the problem is solved with someone's help from the list, then it's probably a documentation bug and should be filed as such. c) Monitor any bugs you file (the default in Red Hat's bugzilla is to send you mail when it's updated) in particular for requests for more information or a request to check out a particular update on your specific setup. An all important goal here is assist developers in reproducing the problem on their own hardware if at all possible. And keep this feedback loop going, minus the 'grub sucks, lilo rules' rants. We know where you stand on that...no need to muddy up the bugzilla database with it. The point is, if you're going to help test grub, at least make an attempt to help developers fix it. If you instantly want Red Hat to abandon the idea of eliminating lilo as soon as you find a reproducible bug in grub, then that's not much help. Well, you can 'want' it, but don't give up on helping to fix grub in the meantime. > 2) One of the problems with the documentation may be that it > requires pinfo. If the documentation was put in HTML format > it would be *MUCH* easier to use. I have heard many people > who find pinfo very difficult to use, and prefer to avoid > info documentation all together. I don't care for it myself > but can use it, when necessary. +1 Don't even get me going on info files. It's just...twisted. > 3) What can you do about getting LILO reinstated if it can be > demonstrated that it will work in situations where GRUB will > not. See above. I will only see the justification for that if I start seeing specific bug numbers with specific controller model numbers and specific drive arrangements and a clear description of the technical problem. And even then, only if the problem can't be fixed in time before, say the next test release? Remember, though, you don't need to wait until then to test a fix, provided an updated boot.iso and *stage*img files are put out with the new grub embeded. Or maybe only the updated rpm in the rawhide is necessary -- I'm not sure how anaconda works regarding that. Either way, test, test, test ... and include any updates that show up in rawhide in that testing. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets