Jump to content

Grub not always so good


Recommended Posts

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.

Link to comment
Share on other sites

  • Replies 32
  • Created
  • Last Reply

Top Posters In This Topic

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!) ;)

Link to comment
Share on other sites

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'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.

Link to comment
Share on other sites

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.

Then how do you explain this:

 

https://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.

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.
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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?? :D

Link to comment
Share on other sites

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..... :lol2:

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

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.

Link to comment
Share on other sites

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.

 

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.

Link to comment
Share on other sites

And if grub wants to claim it can boot linux
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.
Link to comment
Share on other sites

I can see both sides to this, but if Grub is not at fault, why does lilo not have the same problem?
Because LILO works differently, obviously. That's like asking why a square peg doesn't fit in a triangular hole :P
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...