I've built countless Gentoo installations, and always used grub for the boot loader. Never had any problems until now. Grub just completely wouldn't work. Booting the system gave:



which according to searching says I don't have enough memory to use it. First I thought maybe it was the splashimage. Nope, disabled that. Then thought maybe it's the framebuffer settings. Nope not that either.

Emerged lilo, and just.....worked.

So, guess grub isn't all that good either. A bit like lilo sometimes, although lilo has always worked for me, whereas grub is lacking behind on one install

Incidently, it was a PIII 550 with 400MB of RAM and 10GB HDD, but this should have been far adequate for it to work.

hmm...I fail to see how one error means that grub is somehow worse than lilo

I imagine lilo could break just as easily.

I have exacly the same problem with grub...never could get it to work.
Since Mandriva 2007 spring change the bootloader to grub it just stop booting in this strange hardware configuration....urpmi lilo and puffff....work like a charm.

Mandriva was the only OS linux based that i experiment that booting was no problem until they replaced lilo by grub and i tried,Fedora which none of the versions from 3 to 6 was able to boot properly,suse from 10 it doesnt even could get it installed it hangs while loading installer,Debian based,well forget it i even tried Slackware which it installs but hangs at boot....so Mandriva was the only distro that worked just right out of the box with lilo....

This is a not so new AD77 Infinity board from DFI based on VIA KT400 with a scsi adaptec 19160 controler with a 18 GB SCSI HDD and 2 HDDs 120GB ATA on the raid controler plus a 120 GB ATA HDD as a primary master.Not very pretty this config but Mandriva really works fine in here.

Cheers.

There used to be a bug in grub related to ram. IIRC grub must have certain specific memory registers open in ram in order to work. If something else gloms onto those registers, grub will not load and you will get an error 1 message. This frequently was a problem with onboard graphics adapters that used some of the ram for graphics memory. The bios would frequently assign the registers needed by grub to the graphics adapter. I thought that bug was fixed but perhaps not. Lilo is not so fussy and will load into ram wherever there is space available.

waredevil, check out my post here re my adventure with grub:

http://mandrivausers.org/index.php?showtop...518&hl=grub

I feel your pain.

Yep,same pain tho.
I guess we must "ditch" grub for now.
I feel more confortable with lilo cause i have been using it since i start messing around with linux,Mandrake 8.0 was my first sucessfull linux install.
Not so familiar with grub but what i understand from what i have been reading about,is that grub is more flexible in some things than lilo....but hey....one thing i have learned using micro$hit products....if it works dont change it!!!!
Grub is still young and almost every distro is using it so,in a near future it could become much better and bug free(if such thing is possible).

Cheers....

All you geek types really have a problem don't you.

I couldn't program my way out of a paper bag yet I have been able to use grub without difficulty for over 4 years on 5 different hardware rebuilds of my computer, plus 3 rebuilds at least on each of two different friends computers plus 4 other peoples computers. But you guys can't handle it ???.

Come on now you must be joking, pulling our legs.

Cheers. John.

An example,have you installed grub in a machine with 2 Hdds on a Highpoint 378 on board raid controller and with a SCSI HDD over an adaptec 19160 controller?
If you didnt then you should and you will get an idea of what kind of trouble we are talking about....
For the record,i have been able to install pclinuxOS 2007 in a usb HDD with grub and it boots fine...the aside is that it wasnt installed on this computer,it doesnt even boot in here but boots fine im my lappy.
I am not saying that grub sucks....just it has a few glitches that need to be solved on some not very usual hardware configs....For most standard configs i dont doubt it works fine.

Cheers....

Funny you should mention that wardevil. The machine I've just installed on has a highpoint controller!

Looks like I started a flamewar with grub vs lilo here

I'm not dissing grub or lilo. A lot of people use grub and never have any problems and say why do people use lilo? Seen many a post here on this from regular members here. Lilo has worked everytime for me. I'm experienced enough to know that hardware can play a part as to whether lilo/grub will work or not.

I started using grub because everyone was saying how superior grub was, etc, etc, etc. I started to like it because of the splashscreens and being able to edit the file without reloading the boot sector like you have to do with lilo. You can edit the boot line when you start the machine, making testing parameters easy.

Perhaps grub is better for newer hardware, and perhaps lilo is much better for older hardware. Or even specific hardware old or new, you have to use one or the other based on your experience/problems.

I'm still using both, and I believe both grub and lilo have a place in this world. If there was only grub, I'd have a BIG problem trying to boot my machine. Thank god we have a choice in this world to ensure a resolution to my problem.

You're obviously lucky with hardware and don't have anything that causes issue with grub. I use grub and gentoo. Gentoo you install and build everything manually, so I know I can handle grub easily. I'd say easily without problem, but hardware is out of my or even anyones control.

As I said in my first post, I've never had problems with grub until now. The Error 1 it seems is a bug (from pmpatricks post) or cannot allocate memory where lilo doesn't care. 400MB on a system should be plenty enough to work fine, and an Error 1 that I searched says not enough memory. Somehow my machine doesn't fit that scenario.

As I said in my post, that grub breaks sometimes just like lilo. Grub, like lilo has it's own niggles, and therefore isn't the big thing everyone makes it out to be. Everyone says grub is so superior, which yes for some of the features it is. But it seems to have a bug that requires specific memory addresses, instead of just using whatever memory it needs without being so specific. That affects it's so-called superiority a little methinks.

Anyway, I use both, as I've continually said here. It's a bit like the gnome versus kde thing. Some hate gnome, some hate kde. I use both, like I do with grub/lilo.

People should be able to realise the benefits of both options, than be narrow-minded, because I realise the benefits between using gnome versus kde, or in this case, grub versus lilo - instead of pushing myself down one path without considering the use or benefits of another boot loader or desktop environment or whatever else.

This all sounds to me like a bug in a specific version/build of grub. Nothing dramatic imho.

Me also thinks it's a bug. Is that grub vanilla, or is it "beautified" with a gfx patch? (bit silly to ask since it's a new Gentoo installation and grub should normally be from clean source, but...)

I use grub on my Debian laptop mainly because it was the default and it's fine. But I use lilo for everything else mainly because I started with lilo and it's really easy for me to understand and use. And writing lilo.conf for Gentoo is ridiculously simple. Unfortunately though for some reason Mandriva doesn't like me using lilo in Gentoo. It fails to boot completely. So I have to add Gentoo to Mandriva's lilo and then boot into Mandriva every time I build a new kernel in Gentoo. It's sort of a pain. Oh well!

grub v lilo's also a bit of a religious flamewar. I've used both successfully for extended periods of time, and most errors or criticism for either that I see, were caused by the user, not the bootloader.

in reality, both suck in different ways because of their design.

Once GRUB2 is released, I think we'll see a lot of these issues solved. GRUB2 is a redesign, and shares nothing with it's previous version.

http://www.gnu.org/software/grub/grub-2.en.html

I discovered that Grub sometimes gets mixed up in a mixed environment with both ide and sata/scsi devices. When I installed Fedora on my laptop, it would not boot because it wanted to call my hard drive boot partition sda2 instead of hda2. It did the same on my brother's machine, with Mandirva rather than Fedora, but an edit of Grub fixed the problem. (On my brothers, it tried to boot hdb1, where the drive was on sda1.) In both cases the fix was to check that the file named the correct devices. So it is a good policy to look at the file, whether lilo or grub, before completing the install.

I have used both lilo and Grub with 4 or more operating systems. I have also experienced problems with both.

That sums up my experience as well. Other than that, I can't really get excited about bootloaders. If it boots my OS, I'm happy; if not, I have to fool around with it until it does. I'm probably a little better at fooling around with lilo since I've used it longer but grub is pretty easy to hack once you get the hang of it.

Grub might actually be a little better from that perspective. If lilo won't work, you're done. An emergency disk can get you into the system. But if Grub loads its screen and the launch won't work, then you can perform edits and still get in. (if you can figure out what is wrong!)

That's not grub, it's the kernel. As of 2.6.21 or 20, i cant remember, the kernel moved to the new libATA subsystem, which has all devices, sata and IDE named sdXX. If the installer spat out a bad grub.conf, you can hardly blame grub anyway, that's an installer bug, not grub. One of the criticims of grub, and things fixed in grub2, is it's naming. it uses it's own naming, different to the kernel, and this tends to cause confusion.

Then how do you explain this:

http://mandrivausers.org/index.php?showtop...518&hl=grub

That's with a stock mandriva 2007.1 kernel. And that problem apparently exists on all debian based distros and suse as well. This is a bug in grub IMHO. You get inconsistent naming by grub in some mixed environments when the linux kernel is loaded as compared to when it is not. Apparently, the linux kernel prevents grub from properly communicating with the system bios when the kernel is loaded resulting in the inconsistent behavior. Now you can blame that on the kernel if you want but to my mind, if the grub devs want to claim grub is a linux bootloader, grub should be able to work with the linux kernel.

GRUB dev's don't claim it's a Linux bootloader, they simply claim it's a bootloader. GRUB Wiki. And really, the kernel should start being consistent and not keep changing how it names devices.

My point is that I don't think it's solely a problem with kernel changing naming conventions since mdv2007.1 and the earlier versions of ubuntu I linked to used the standard libata with the usual hdx,sdx naming conventions and all those distros report the same aberrant behavior in some mixed environments. As I eluded to above, I believe it must be a problem with at least some linux kernels that used standard hdx,sdx naming, blocking grub from properly communicating with the system bios when grub is installing with the kernel loaded. There may be very good reasons for this behavior in the kernel related to security, stability, whatever. I really don't know, but I don't think it's realistic to expect the kernel devs to rewrite the kernel so the current version of grub works more consistently. The onus should be on grub to adapt to the current characteristics of the linux kernel, just like everybody else. Hopefully, grub 2.0 will clean this up.

What is realistic is expecting kernel devs to stick to a standard, and not constantly change conventions, causing everyone downstream from them to have to rewrite their code just to be compatible with the kernels latest "features". This is an MS mentality: "We changed conventions to be 'better', but we broke backwards compatibility, so you'll have to fix your shit, even though we were the ones who broke it, technically."

I think iphitus, having been a kernel patch-set maintainer for some time, has more experience with this than I.

Unless you specifically know what code in the kernel is causing the problem for grub, and it is not the naming convention, it is impossible to intelligently discuss whether the kernel changes causing the problem are worth the aggravation caused to other developers. As I previously stated, there may be very good reasons for those kernel changes and those changes may significantly improve the kernel.
I can appreciate the aggravation you have with the moving target the 2.6 kernel has become. However, if you want to use the linux kernel, that's the development model you're stuck with. And if grub wants to claim it can boot linux, their devs should deal with it as well as I'm confident they are.

I can see both sides to this, but if Grub is not at fault, why does lilo not have the same problem? Something is different. At any rate, none of it is unsolvable; and it makes it fun, doesn't it??

Luckily lilo isn't suffering the bugs.

What I find funny is that when I read this and say that you have a problem with grub, that it's a bug. And yet, when something doesn't work with lilo in the same manner, people say that lilo is crap with some hardware. I'd say it was a bug for that particular hardware!

And I'm not flaming, it's a perfectly valid response to those who say lilo is crap because it doesn't work on their hardware, and yet grub does. I use grub mostly, but I used to use lilo when it was the default in Mandriva. Incidently, if you did a software raid install on Mandriva 2007.0 and prior versions you could only use lilo, grub wouldn't work or install at all. Or maybe that was another bug.....

Well, lilo and grub both have their strenghts, weaknesses and bugs. I simply find grub a bit easier to configure than lilo. That's all. But I wouldn't whine if I am suddenly forced to use lilo again.

Such major changes should be made in a 2.7 cycle. NOT a "stable" cycle of 2.6

I understand that the development of the kernel is a different process than it used to be, and that 2.6 isnt really a "stable" cycle as it once was. But it's becoming clear that it isnt feasible. Since adopting this new style, stability has gone *way* downhill. This is acknowledged quite globally by developers such as Greg KH[1], Dave Jones[2], and others.

To try and remedy this, the y (2.6.x.y) release was created, and is currently maintained by Greg KH. It's become a great way of distributing security fixes quickly, though it still fails to cover many bugs that exist upon each release and is more of a band-aid than a solution. Adrian Bunk is *still* distributing the 2.6.16 kernel, now up to 2.6.16.52 [3], including many bug fixes and security fixes. This is a pretty solid kernel, and worked well on my laptop, excepting a resume from sleep bug that was fixed in later kernels.

Distributions now need to include ridiculous amounts of patches, far far more than they ever needed to. This has inherent faults (see [1][2] again), many patches arent as well tested, and induce problems for others. What do the distros do? they're damned if they do include them, damned if they dont. This LWN subscriber article[4] describes the situation for some distributors well

Take a look at this subscriber article from LWN which explains the situation of many distros quite well. [4]

A 2.7 cycle would make more sense. Such changes as, libata, tickless kernel and hrtimers, overdue new suspend system, new scheduler, sem2mutex, and other major changes could have been developed far more agressively and in a better environment. This doesnt prevent them from being merged back to 2.6, as backports have historically been common, with many things being backported to 2.4. Along with an accellerated 2.7 cycle compared to previous odd numbered cycles, this is one possible solution.

Maybe it's not an ideal solution, but changes do need to be made, and I'd rather criticise constructively and offer some sort of alternative, then just badmouth.

I could rant for ages on the kernel, there's a host of other issues with the current development style. It works, but I think the talent of the kernel developers could be used better, and the kernel could work far better.

James

[1] http://www.kroah.com/log/linux/enterprise_kernel_future.html
[2] http://kernelslacker.livejournal.com/82610.html
[3] http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.52
[4] http://lwn.net/SubscriberLink/239036/76e19bbb9ff0acd8/ - Subscriber only article, though lwn allow and encourage subscribers to post links to non-subscribers. LWN is an awesome resource, it offers a great summary of the weeks news in Linux, as well as many good articles. It's not expensive, and is a worthwhile investment if you spend plenty of time reading up on RSS feeds, checking news sites, or are a developer of a project.

I have the same sentiment as you arctic. I use what works for me. I'll use grub where I can, or if it tends to default to lilo, like Mandriva used to do. If grub doesn't work, I use lilo, and vice-versa. I feel it's a much better approach to things.

It all comes down to choose what's best for you and your preferences, but you should still consider the latter if your preference fails.

Hey, it works fine on my system! There is a large difference between a bug (who ever caused it) and claiming to have a feature where one doesn't exist. In this case, it is most definitely a bug.

Because LILO works differently, obviously. That's like asking why a square peg doesn't fit in a triangular hole

Yes, but if the kernel were all the fault then it seems both would have similar errors. At any rate, it is not a show stopper, but it is annoying.

It may seem that way, but it's not necessarily true. Think of it this way: You have to trains, running from NYC to Sometown, NJ, both taking different routes (I realize this sounds like a 5th grade math problem, but bear with me). If Train A's route is under construction, or is otherwise obstructed, Train B would still reach it's destination on-time, but Train A may not. They are still doing the same thing, still have the same destination, but because they get there by different routes, one is effected by a change and the other is not. I hope that makes sense...

However, both are using the same route (kernel), therefore, perhaps it should work?