Lilo bug apparently fixed in version 23.2

[mimosa]

I've been investigating the problem discussed in this thread:

http://www.salixos.org/forum/viewtopic. ... 361#p21361

and googling (that is, DuckDuckGoing) the error message made me think this might be a bug. Sure enough, a Lilo dev posted in an Archlinux thread to try out a patch, which is in the most recent version of Lilo. I upgraded Lilo from source and everything now works.

I don't know how often this bug has an effect, but maybe it would be worth considering upgrading Lilo in the repos to 23.2.

[Shador]

Strictly speaking I wouldn't call this a bug. Bugs are usually defined as regressions and there is no such regression as everything that booted in the past still boots with the affected lilo version. The problem is that some code in the linux kernel grew with more recent kernel versions, which conflicted with an assumption made by lilo regarding its size. You could possibly blame them for making that assumption in the first place. But bootloaders need to make such assumptions. They don't have all the abstraction an OS could offer. Their code is even unable to use many features of hardware like the MMU.

Other bootloaders make such assumptions too. For example a recent grub development version did not compile on my machine. That happened because my compiler was significantly worse at optimizing the size of the resulting code than the one used during test builds by some dev. As the space for bootloaders on BIOS (EFI improves that) is significantly limited, it wouldn't fit anymore into those size constraints. The solution was manually optimizing the code so my and other people's compilers perform better too.

In a highly constrained environment, which bootloaders run in, you have no choice but to make assumptions. If I give a talk about a big topic but am in a constrained environment where I only get 10 minutes, then I have to make assumptions too. For example regarding the previous knowledge of the audience.

[mimosa]

Well, not a bug perhaps, but a potential problem. It then seems relevant to consider how frequently it comes up - and maybe this one isn't common enough to merit special treatment. However, lilo is a small package and 23.2 seems to have fixed it.

I should make clear (in case it's not) that this wasn't caused by *running* the 3.2 kernel. I booted the machine with 2.6.x, upgraded the kernel packages, and ran lilo, still while running the standard Salix 13.37 kernel I had booted with.

For the record, to upgrade lilo, just download and unpack the source tarball, change to its directory, and as root, do make install. You need to blacklist it in the package manager. Actually, my log of slapt-get seems to show that's not necessary, because it doesn't realise anything has changed; but if there were ever an upgrade to 23.1.5 or something, the new /sbin/lilo might get zapped ...

[Shador]

I should make clear (in case it's not) that this wasn't caused by *running* the 3.2 kernel. I booted the machine with 2.6.x, upgraded the kernel packages, and ran lilo, still while running the standard Salix 13.37 kernel I had booted with.

The problem is not caused by the current kernel under whose supervision lilo runs. The problem is when the kernel version, which should be booted with lilo is too new. The version of lilo in 13.37 just can't cope with newer versions.

It then seems relevant to consider how frequently it comes up - and maybe this one isn't common enough to merit special treatment. However, lilo is a small package and 23.2 seems to have fixed it.

Lilo works fine with the kernel in 13.37 and actually older versions too. So why should we upgrade it? It just has the potential to introduce new bugs.
The only reason to upgrade it is for a newer kernel. But a newer kernel definitely won't come for 13.37, because there are much too many regressions it could introduce.

Actually I bet there a dozens of issues like this in 13.37 and they've existed in the past releases and will also exist in the future ones. Unless they're serious like security issues or completely unusable software, they are not usually fixed. Even more not for core system components with unclear, wide and often unexpected reach like kernel, bootloader or similar.
It's fine that it fixes your problem. But can you definitely tell, there's no way new problems are caused, which didn't exist previously?

Sorry, but this is stuff that is usually fixed with a completely new release. Where it's possible to test it for a longer period of time. More so, this makes it possible to revert to an older working release, which is not anymore possible if we break that one too.

[mimosa]

Your reasoning seems pretty convincing to me. You could also look at it in practical terms as follows: anyone who's upgrading the kernel is making a modification from the standard edition, and should expect to cope with the fallout. On the other hand, if you dual boot with a distro that has a newer kernel, you may be in trouble ... It's a hard balance to strike.

It also so happens that in this case, it's really easy to fix. I had to search quite a bit though. And what about users who are upgrading their kernel for essential hardware support? *I* deserve everything I get, because I was just doing it for the hell of it