FS#23540 - [kernel26] [lilo] Setup length exceeds 31 maximum

Attached to Project: Arch Linux
Opened by Miroslaw Czachor (forest76) - Thursday, 31 March 2011, 18:23 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 10 April 2011, 06:26 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Tobias Powalowski (tpowa)
Eric Belanger (Snowman)
Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
After upgrade kernel26 to 2.6.38.2-1 end execute
lilo (version 23.1-2) command I got this error
----------------------------------------------------
Fatal: Setup length exceeds 31 maximum; kernel setup will overwrite boot loader
----------------------------------------------------
When I increase verbose level to maximum I got information
that vmlinuz26 has 33 sectors, so is bigger then maximum.
But filesize vmlinuz26 is even smaller on 2.6.38.2-1 kernel
then on previous version which works with no problem.


Steps to reproduce:
Upgrade to 2.6.38.2-1 on lilo boot manager nad type `lilo`


Greetings,
Miroslaw

This task depends upon

Closed by  Tobias Powalowski (tpowa)
Sunday, 10 April 2011, 06:26 GMT
Reason for closing:  Fixed
Additional comments about closing:  23.2-1
Comment by Marcin Karpezo (sirmacik) - Thursday, 07 April 2011, 08:54 GMT
I'm suffering from this error too. For now I've switched to grub2), but it'd be great to have lilo back. Is there any way that we or I can help You with fixing it or provide some more information? May be important that I'm using lzma compression of the initrd image. I'm going to try it with other compression algorithms and without, then post the results.

Regards, Marcin
Comment by Thomas Bächler (brain0) - Thursday, 07 April 2011, 09:02 GMT
The xz decompressor seems to make the setup length exceed what lilo expects. This is a limitation in lilo - maybe someone has a fix for it, I didn't check. We could switch back to lzma compression (which seemed to work) or consider finally dropping lilo support entirely (personally, I would have done that years ago).
Comment by Marcin Karpezo (sirmacik) - Thursday, 07 April 2011, 09:10 GMT
Generally lilo still seems to be working fine, if it is about xz compression support then I'll report this on their mailing list. Hopefully they'll implement it as lilo still is considered as an active project (in opposite to grub1 witch is working for me quite well). Grub2 still seems to have a long way to go before it becomes usable (it has frequent tendency to hung up during bootup on my laptop).
Comment by Thomas Bächler (brain0) - Thursday, 07 April 2011, 09:18 GMT
If lilo is an active project, it should be possible to quickly find out if this problem is fixable.
Comment by Marcin Karpezo (sirmacik) - Thursday, 07 April 2011, 09:20 GMT
As You can see here, it is: https://alioth.debian.org/scm/browser.php?group_id=100507 I've sent them this "future request". Lets see how it goes. (;
Comment by Marcin Karpezo (sirmacik) - Friday, 08 April 2011, 09:21 GMT
Joachim - lilo developer, has promised to look into lilo and kernel source and generate appropriate patch.
Comment by Marcin Karpezo (sirmacik) - Saturday, 09 April 2011, 11:25 GMT
Yeah, current git tree seems to have the problem fixed. https://alioth.debian.org/scm/browser.php?group_id=100507
In the meantime I've pushed working lilo-git package to AUR http://aur.archlinux.org/packages.php?ID=48094 (new build from testing repository still gives me the same error).
Comment by Tobias Powalowski (tpowa) - Saturday, 09 April 2011, 20:52 GMT
testing lilo should work now, please confirm.
Comment by Marcin Karpezo (sirmacik) - Saturday, 09 April 2011, 21:26 GMT
I've tried and it gave me the same old error. There was a new release today. It should work as the current git tree works.
Comment by Tobias Powalowski (tpowa) - Saturday, 09 April 2011, 21:38 GMT
ok 23.2 should fix this now finally, please confirm.
Comment by Marcin Karpezo (sirmacik) - Saturday, 09 April 2011, 22:39 GMT
It works great, thanks!

Loading...