Re: lilo removal in squeeze (or, "please test grub2")

[Ferenc Wagner]

Daniel Baumann  writes:

> On 05/24/2010 11:29 AM, Ferenc Wagner wrote:
>
>> You may want to try extlinux, it works much like LILO in this respect.
>> It lacks a convenient configuration system, but that of grub-legacy
>> would be easy to adapt, and I actually plan to work on this.
>
> sometime ago i've added extliux-install and update-extlinux. if fits my
> setups well, however, any other/better ideas how to improve it are very
> welcome, see #573042 for more information.

Heh, yes, that's me again. :)  I got distracted, but didn't give up work
on this.  Now I'm nosing around the current Grub2 method for ideas.
Meanwhile, the unconditional destroying of extlinux.conf on update gave
me the grief again. :-/
-- 
Cheers,
Feri.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3wlyt1a@tac.ki.iif.hu

Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

[Vincent Danjean]

On 07/06/2010 17:37, Stephen Powell wrote:
 But for a kernel install or reconfigure, it is the responsibility of the
 kernel maintainer scripts to invoke the bootloader.  See also, for example,
 linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
 on line 38.  This really is an open and shut case, if only I can the kernel
 people to actually look at it!  Please look at it!

If I recall correctly, kernel maintainers have introduced
/etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
bootloader in their script.
Can't lilo provide a script here ?

  Regards,
Vincent

-- 
Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble
Téléphone:  +33 4 76 61 20 11ENSIMAG - antenne de Montbonnot
Fax:+33 4 76 61 20 99ZIRST 51, avenue Jean Kuntzmann
Email: vincent.danj...@imag.fr   38330 Montbonnot Saint Martin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c0e2c0e.2060...@free.fr

Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

[Ben Hutchings]

On Tue, 2010-06-08 at 13:39 +0200, Vincent Danjean wrote:
 On 07/06/2010 17:37, Stephen Powell wrote:
  But for a kernel install or reconfigure, it is the responsibility of the
  kernel maintainer scripts to invoke the bootloader.  See also, for example,
  linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
  on line 38.  This really is an open and shut case, if only I can the 
  kernel
  people to actually look at it!  Please look at it!
 
 If I recall correctly, kernel maintainers have introduced
 /etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
 bootloader in their script.
 Can't lilo provide a script here ?

It could, but that should be redundant in squeeze since update-initramfs
already runs lilo.

This appears to be a problem in lenny, where by default neither the
kernel postinst nor the initramfs builder runs lilo.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

[Peter Palfrader]

On Tue, 08 Jun 2010, Ben Hutchings wrote:

 On Tue, 2010-06-08 at 13:39 +0200, Vincent Danjean wrote:
  On 07/06/2010 17:37, Stephen Powell wrote:
   But for a kernel install or reconfigure, it is the responsibility of the
   kernel maintainer scripts to invoke the bootloader.  See also, for 
   example,
   linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the 
   bootloader
   on line 38.  This really is an open and shut case, if only I can the 
   kernel
   people to actually look at it!  Please look at it!
  
  If I recall correctly, kernel maintainers have introduced
  /etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
  bootloader in their script.
  Can't lilo provide a script here ?
 
 It could, but that should be redundant in squeeze since update-initramfs
 already runs lilo.

Not every kernel package needs an initrd.

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100608120012.gu14...@anguilla.noreply.org

Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

[Ben Hutchings]

On Tue, 2010-06-08 at 14:00 +0200, Peter Palfrader wrote:
 On Tue, 08 Jun 2010, Ben Hutchings wrote:
 
  On Tue, 2010-06-08 at 13:39 +0200, Vincent Danjean wrote:
   On 07/06/2010 17:37, Stephen Powell wrote:
But for a kernel install or reconfigure, it is the responsibility of the
kernel maintainer scripts to invoke the bootloader.  See also, for 
example,
linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the 
bootloader
on line 38.  This really is an open and shut case, if only I can the 
kernel
people to actually look at it!  Please look at it!
   
   If I recall correctly, kernel maintainers have introduced
   /etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
   bootloader in their script.
   Can't lilo provide a script here ?
  
  It could, but that should be redundant in squeeze since update-initramfs
  already runs lilo.
 
 Not every kernel package needs an initrd.

But those that don't, invoke lilo (or other bootloader) directly.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

[Stephen Powell]

On Tue, 08 Jun 2010 07:39:58 -0400 (EDT), Vincent Danjean wrote:
 On 07/06/2010 17:37, Stephen Powell wrote:
 But for a kernel install or reconfigure, it is the responsibility of the
 kernel maintainer scripts to invoke the bootloader.  See also, for example,
 linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
 on line 38.  This really is an open and shut case, if only I can the kernel
 people to actually look at it!  Please look at it!
 
 If I recall correctly, kernel maintainers have introduced
 /etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
 bootloader in their script.
 Can't lilo provide a script here ?

   do_bootloader = yes

in /etc/kernel-img.conf means run the historic boot loader for this platform.
For the i386 platform (and amd64) the historic boot loader is lilo.  For
the s390 platform, that boot loader is zipl.  The kernel maintainer scripts
for the s390 platform still specify zipl as the boot loader

   my $loader= zipl; # lilo, silo, quik, palo, vmelilo, nettrom, 
arcboot, or delo

so that

   do_bootloader = yes

in /etc/kernel-img.conf will work.  The kernel maintainer scripts for i386 and 
amd64
for Lenny and beyond specify a null string.  That is inconsistent.  It should 
specify

   my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, 
arcboot, or delo

for consistency between platforms.  For non-historic boot loaders, the method 
used is to set

   do_bootloader = no

in /etc/kernel-img.conf and supply a hook script of some kind, if needed.  For 
example,
grub version 1 in Lenny invokes it's hook scripts via

   do_bootloader = no
   postinst_hook = update-grub
   postrm_hook   = update-grub

in /etc/kernel-img.conf.  Grub version 2 does not need a hook script; so it 
simply sets

   do_bootloader = no

in /etc/kernel-img.conf.  In Squeeze and later, there is an alternate method 
for running
hook scripts (so that more than one hook script can be invoked).  Simply 
install the
script in /etc/kernel/preinst.d, /etc/kernel/prerm.d, /etc/kernel/postinst.d, or
/etc/kernel/postrm.d.  But even in Squeeze/Sid, the historic boot loader can 
still be run
by setting

   do_bootloader = yes

in /etc/kernel-img.conf.  That still works for zipl on the s390 platform.  But 
it's
been broken since Lenny on the i386 and amd64 platforms for lilo.

initramfs-tools also examines this variable and runs the historic boot loader
when

   update-initramfs -u

is invoked.  That still works, even on the i386 and amd64 platforms, provided 
that

   do_bootloader = yes

is specified in /etc/kernel-img.conf.  But

   update-initramfs -c

does not invoke the boot loader.  Running the historic boot loader during 
installation,
reconfiguration, or upgrade of a kernel is still the responsibility of the 
kernel
maintainer scripts.  And it cannot do so unless my $loader is set to the name 
of
the historic boot loader.  On s390, that variable is set properly.  On i386 and 
amd64,
it is not.

The kernel maintainer scripts provided by kernel image packages created by 
make-kpkg
on Squeeze and later are another story.  They no longer do *any* 
post-installation
actions unless user-provided hook scripts cause it to happen.  But the 
maintainer
scripts for official stock Debian kernel images still support these historic
post-installation activities.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1661542040.41185.1276004599156.javamail.r...@md01.wow.synacor.com

new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

[Stephen Powell]

On Mon, 07 Jun 2010 03:22:46 -0400 (EDT), sean finney wrote:
 On Mon, Jun 07, 2010 at 01:44:05AM +0400, William Pitcock wrote:
 Have fun.  When you have a release that actually has merit, it can be
 reconsidered for inclusion in Debian.
 
 In the meantime, the original plan continues.
 
 actually, i don't think you have any say about what software can and
 can not be in debian, that is the sole privilege of ftp-master.  your
 options are (a) to claim you still want to maintain the package and
 continue to do so, or (b) ask for its removal by ftp-master.  given your
 comments here i think if you were to claim (a) there would be a decent
 case for someone to take to the tech-ctte.
 
 ftp-master, if they're aware of this argument, may just say why not
 orphan it instead?.  but regardless, if someone else is interested they 
 can just follow that removal with a new upload using their name as
 Maintainer, and then again it's up to ftp-master to accept or deny it.
 given that there may be an active upstream and maintainer, and the
 software is otherwise DFSG-compatible, i don't see why they would deny
 such a new upload.
 
 of course, it would be a lot nicer if you could just hand over the reins
 of the current package to those who have been asking for them, to avoid
 some un-needed overhead...


 sean

Perhaps I can offer a solution here.  Since William obviously doesn't wish
to maintain this package any longer, I am willing to take over his
responsibilities as a Debian package maintainer for lilo under two
conditions:  (1) The kernel team fixes bug number 505609, and (2) Debian
ceases its attempts to remove lilo from the distribution.  What do you
say, William?  Do you have any objections?  Does anyone else have any
objections?  If so, speak now, or forever hold your peace.

Keep in mind that I have never been a Debian package maintainer before.
This will be my first package.  Please be patient with me as I learn the
ropes, so to speak.

As for whether or not lilo continues to be offered as an alternate boot
loader by the Debian installer, that is entirely up to them.  I would
think that the path of least resistance would be to maintain the status
quo, but if they want to remove lilo from the Debian installer menu
that's their call, as far as I am concerned.  I just don't want to see
lilo removed from the distribution.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1196418916.5745.1275918400688.javamail.r...@md01.wow.synacor.com

Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

[Holger Levsen]

reassign 505609 initramfs-tools
thanks

Hi Stephen,

thanks for stepping up maintaining lilo in Debian! I hope you'll manage this 
well.

On Montag, 7. Juni 2010, Stephen Powell wrote:
 Perhaps I can offer a solution here.  Since William obviously doesn't wish
 to maintain this package any longer, I am willing to take over his
 responsibilities as a Debian package maintainer for lilo under two
 conditions:  (1) The kernel team fixes bug number 505609, and (2) Debian
 ceases its attempts to remove lilo from the distribution.

There is no attempt from Debian. The current lilo maintainer thought this 
was the best option for lilo as he was going to orphan it and also because 
there was no upstream. If you step up to maintain lilo (and the codebase is 
and stays acceptable) and maintain lilo in Debian, removing lilo is moot.

 Keep in mind that I have never been a Debian package maintainer before.

The Debian New Maintainers Guide (ie at 
http://www.debian.org/doc/maint-guide/) shall be your friend, as well as 
lintian and debian-ment...@lists.debian.org as well as #debian-mentors on 
IRC.

Have fun! :-)

 As for whether or not lilo continues to be offered as an alternate boot
 loader by the Debian installer, that is entirely up to them.  

Fair enough. 


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

[Stephen Powell]

On Mon, 07 Jun 2010 10:33:52 -0400 (EDT), Holger Levsen wrote:
 
 Hi Stephen,

 thanks for stepping up maintaining lilo in Debian! I hope you'll manage this 
 well.

Um, thanks; but I don't understand the reassignment of bug number 505609 to
package initramfs-tools.  If you read my previous posts to the bug log, it
is clear that this problem started with a change to the maintainer scripts
between Etch and Lenny.  Please read my posts again carefully.  Then consider
whether this is really a bug in initramfs-tools or a bug in the kernel 
maintainer
scripts.  initramfs-tools only gets involved when

   update-initramfs -u

is issued.  And it *does* invoke the boot loader under these conditions, if
do_bootloader = yes is present in /etc/kernel-img.conf and lilo is installed.
But for a kernel install or reconfigure, it is the responsibility of the
kernel maintainer scripts to invoke the bootloader.  See also, for example,
linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
on line 38.  This really is an open and shut case, if only I can the kernel
people to actually look at it!  Please look at it!




-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/120369280.10411.1275925077969.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze (or, please test grub2)

[Russell Coker]

On Wed, 26 May 2010, Stephen Powell zlinux...@wowway.com wrote:
 You're missing the point.  The main selling point to management
 is that Linux is free.  If they have to buy new backup software
 in order to accommodate Linux' backup requirements, that will
 kill it on the spot.  Whatever boot loader I use must not
 require new backup software or impose special backup requirements.

One of the advantages of Linux is that you are not forced to do things the way 
that the distribution vendor packages it.

You can take the last lilo package that gets uploaded, build it and put it in 
your own apt repository, and then support it for your own users.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201006052230.21682.russ...@coker.com.au

Re: lilo removal in squeeze (or, please test grub2)

[Josip Rodin]

On Tue, May 25, 2010 at 11:08:21AM +0100, Chris Carr wrote:
 On 25/05/2010 10:00, Harald Braumann wrote:
 On Sat, May 22, 2010 at 10:39:52PM -0500, William Pitcock wrote:
 (4) Users need to test grub2 now.

 I've been using grub2 for quite some time now on several different
 systems with mixed success.
 [snip]
 Because of this, coupled with the many open bugs and the lack of
 documentation, I'm not sure if grub2 is ready to be released to the
 unsuspecting public.

 Just to add my 2p, I have had significant, foreseeable, nonunique  
 problems with grub2 on several machines (#495433, #508405, #518835 are  
 merely the ones I reported). I would agree with Harald's assessment that  
 grub2 is not ready.

 It appears from this thread that the maintainer status of grub2 is  
 little better than that of lilo. It is therefore difficult to understand  
 an argument in favour of removing lilo on the basis of a lack of  
 maintainer(s), as that would also apply to grub2.

If it wasn't obvious from the grub-pc bug list already, I have to echo this
sentiment, sadly. So far, grub2 package has been pretty much all trouble on
both non-trivial configurations I've tried - #548648, #557425. I've also
tried converting a system where I have LILO booting / off an LVM volume of
a very large device, but that simply wasn't supported at all, upstream.
(Some googling just now leads me to believe that this might possibly be fixed
nowadays, but that still doesn't make it release-quality software.)

So all this lilo needs to die now, everyone quickly get grub2 talk does
look a fair bit premature. Cynics might say amateurish or worse, YMMV.
grub2 won't magically get better if we just throw more users at it.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100531135638.ga8...@orion.carnet.hr

Re: lilo removal in squeeze (or, please test grub2)

[Marc Haber]

On Mon, 31 May 2010 15:56:38 +0200, Josip Rodin j...@entuzijast.net
wrote:
So all this lilo needs to die now, everyone quickly get grub2 talk does
look a fair bit premature. Cynics might say amateurish or worse, YMMV.
grub2 won't magically get better if we just throw more users at it.

I fully agree. The grub situation is as with KDE: Old version
abandoned, new version not finished.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oj6rx-0006hs...@swivel.zugschlus.de

Re: lilo removal in squeeze (or, please test grub2)

[Alexey Salmin]

On Mon, May 31, 2010 at 10:25 PM, Marc Haber
mh+debian-de...@zugschlus.de wrote:
 I fully agree. The grub situation is as with KDE: Old version
 abandoned, new version not finished.

Not exactly. I was testing KDE4 since 3.97 and it was quite
interesting and amusing. Not many people like to test bootloader on
themself, though.

/* also grub2 works pretty well for me but nevertheless I've no idea
why we need to remove good old stable lilo */

Alexey


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktim3xsh7lcbbtvkkxlxmi5hfaw9cwz7l05-qv...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

[Stefano Zacchiroli]

On Sat, May 29, 2010 at 04:51:09PM +0200, Marc Haber wrote:
 Right, but also note that there's an open RFH on grub2 #248397
 (retitled/refreshed recently, despite the low bug number).
 
 As long as there are tested-and-ready-to-apply[1] patches rotting away
 in the BTS without any comments, I don't get the feeling that this
 kind of help is really wanted.

YMMV, to me it would seem an even more acute indication of the fact that
maintainer is so unavailable that he hasn't even found the time to apply
tested-and-ready-to-apply patches; I believe both yours and mine
interpretation make sense.  Anyhow, now Colin is on the matter, let's
leave him some time to breathe, and I'm confident the patches you
mention will get through.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'?? ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu ?? tous ceux que j'aime


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

[Stanislav Maslovski]

On Sat, May 29, 2010 at 04:43:32PM -0400, Stephen Powell wrote:
 On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote:
  Stephen Powell wrote:
  On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
  After some discussion about lilo on #debian-devel in IRC, it has pretty
  much been determined that kernel sizes have crossed the line past where
  lilo can reliably determine the payload size.
 
 
  We're speaking about #505609 I assume?
 
 I hope not.  Strictly speaking, 505609 is not a lilo bug.  The key is
 that he was still able to boot his old kernel that had been de-installed.
 That's a sure sign that lilo's map installer did not get run during the
 kernel upgrade process.

[skipped]

 If there's a bug here, it's somewhere else in the kernel installation
 process, not in lilo itself.  If this so-called bug in lilo is what
 prompted the decision to drop lilo, then the decision was based on bad data.
 lilo, at least in this case, is working as designed.  The problem is that
 the lilo map installer did not get run during the kernel installation
 process.  I've helped a number of people on debian-user with problems
 like this, and in every case so far running lilo at the command line
 fixed the problem.

I guess your analysis was based on the follow-up by Tomas Pospisek?
Christian Hammers from the same bug thread also stated that the
problem disappeared after executing lilo from the command line.

If that is really the case, then I would advise William to simply
orphan lilo, if for some reason he does not want to work on it
anymore. Removing, IMO, is not justified in this case.

BTW, Stephen, you could also post your analysis on the BTS.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100530081726.ga31...@kaiba.homelan

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Fri, 28 May 2010 16:44:11 -0400 (EDT), Peter Samuelson wrote:
 Stephen Powell wrote:
 It *does* recognize lilo and has special logic to patch lilo after
 the restore so that the machine will boot.
 
 So can this software be fooled into thinking it is dealing with lilo?
 Would it be sufficient to rename /boot/extlinux/extlinux.sys to
 /boot/maps or something?

I wasn't going to post to this thread on debian-devel anymore, since
it is evident that they really don't want to hear about it.  But for
the sake of answering a specific question I will respond.

I'm afraid that won't work.  In the first place, renaming
/boot/extlinux/extlinux.sys to something else would interfere with
the correct operation of extlinux.  Second, this is the second stage
loader for extlinux.  It does not use a map file, as lilo does.
Third, the boot sector for extlinux has a different signature
than the lilo boot sector.  And there are probably more reasons
as well.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/254055006.148047.1275142053121.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Marc Haber]

On Sun, 23 May 2010 16:26:48 +0200, Stefano Zacchiroli
z...@debian.org wrote:
On Sun, May 23, 2010 at 02:08:59PM +0200, Marc Haber wrote:
 This also means that the grub2 maintainers (both Debian and Upstream)
 need to work on the regressions that exist in regard to moving from
 lilo or grub legacy to grub2. There are too many bug reports in the
 BTS which are completely unaddressed.

Right, but also note that there's an open RFH on grub2 #248397
(retitled/refreshed recently, despite the low bug number).

As long as there are tested-and-ready-to-apply[1] patches rotting away
in the BTS without any comments, I don't get the feeling that this
kind of help is really wanted.

Greetings
Marc

[1] at least they were at the time they were posted
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oinnv-0004kv...@swivel.zugschlus.de

Re: Re (2): lilo removal in squeeze (or, please test grub2)

[Marc Haber]

On Tue, 25 May 2010 11:42:34 -0400 (EDT), Stephen Powell
zlinux...@wowway.com wrote:
You're missing the point.  The main selling point to management
is that Linux is free.  If they have to buy new backup software
in order to accommodate Linux' backup requirements, that will
kill it on the spot.  Whatever boot loader I use must not
require new backup software or impose special backup requirements.

From what I guess, your backup scheme is highly hardware dependent
since lilo uses block lists in the MBR to find its later stages on
disk. So your restored system will only boot if you restore to a disk
with the exactly same geometry.

I would change the restore process to manually reinstall the boot
loader after the backup software finished with its restore job anyway,
or you might be surprised with an unbootable restored system if you
had to restore to different hardware.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oinnw-0004kv...@swivel.zugschlus.de

Re: lilo removal in squeeze (or, please test grub2)

[Andreas Barth]

* Stephen Powell (zlinux...@wowway.com) [100523 21:21]:
 On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
  After some discussion about lilo on #debian-devel in IRC, it has pretty
  much been determined that kernel sizes have crossed the line past where
  lilo can reliably determine the payload size.

We're speaking about #505609 I assume?


I'm not sure this bug requires an removal of lilo (see below), however
I think this means we should strongly discourage usage of lilo.


  (1) The release notes need to be updated to reflect that lilo is no
  longer a bootloader option;

The release notes should be updated in case we keep lilo that we
recommend to move to another boot loader now.


  (2) The debian-installer team needs to remove the lilo-installer udeb;

This should indeed happen - if someone activly requires lilo, then
doing it by hand should be ok-ish.



 I am not a Debian package maintainer or a Debian developer.  I am just an
 ordinary system administrator.  So I'm sure that my opinion will not count
 for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
 grub-pc use sectors on the hard disk outside of the master boot record
 (cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head 0,
 sector 2 and possibly subsequent sectors on cylinder 0 head 0.  This breaks
 the design of the backup software that my employer uses.  This backup software
 backs up the master boot record and all partitions; but since the extra
 sectors used by grub-legacy and grub-pc are outside the master boot record
 and are not part of any partition, they don't get backed up.  Consequently,
 if we have a hard drive failure and restore from a backup, we have an
 unbootable machine.  Lilo uses only the master boot record.  A lilo-booted
 machine can be backed up and restored with our existing backup software
 just fine.  Given these requirements, I wouldn't use grub-pc even if it
 were bug free and well documented.  (But neither is the case!)

Would it be possible to move (perhaps optionally) the extra grub sectors
into an (perhaps dummy) partition (this question is for the
grub2-people)? Would that be ok for you?


 As for the claims that kernels are too big now, I find that hard to
 believe, especially now that we have the large-memory option available.
 The standard stock Debian kernel image file that I use for Squeeze,
 vmlinuz-2.6.32-3-686, is currently 2234080 bytes.  Are you trying to tell
 me that there's no room for a 2M kernel below the start of the EBDA?
 
 I am able to load *both* the kernel *and* the initial RAM filesystem
 below the EBDA (i.e. the large-memory option is not used) if I use
 MODULES=dep instead of MODULES=most in the initial RAM filesystem
 under Lenny.  I'll bet I can do it with Squeeze too.

This sounds like we should add an wrapper around lilo that warns that
lilo is deprecated and warns if the images are too large.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100529184041.gk13...@mails.so.argh.org

Re: Re (2): lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Sat, 29 May 2010 10:51:10 -0400 (EDT), Marc Haber wrote:
 On Tue, 25 May 2010 11:42:34 -0400 (EDT), Stephen Powell wrote:
 
 You're missing the point.  The main selling point to management
 is that Linux is free.  If they have to buy new backup software
 in order to accommodate Linux' backup requirements, that will
 kill it on the spot.  Whatever boot loader I use must not
 require new backup software or impose special backup requirements.
 
 From what I guess, your backup scheme is highly hardware dependent
 since lilo uses block lists in the MBR to find its later stages on
 disk.

Strictly speaking, the MBR points to the partition boot sector,
the partition boot sector points to the second stage loader,
the second stage loader points to the map file (/boot/map) and
the map file points to the kernel image blocks and the initial RAM
file system image blocks.  But yes, this is location-dependent
information.

 So your restored system will only boot if you restore to a disk
 with the exactly same geometry.

Not if the restore software understands the format of the boot loader
files and knows how to patch them.  Fortunately it does.  But only
for lilo.  And only under certain conditions.

 I would change the restore process to manually reinstall the boot
 loader after the backup software finished with its restore job anyway,
 or you might be surprised with an unbootable restored system if you
 had to restore to different hardware.

That is not an option.  When the restore completes it automatically
reboots the machine.  Besides, the restore software runs under DOS,
not under Linux.  The boot loader installation program won't run under
DOS.  If patching the boot loader files was not
successful, the machine won't boot.  Manual intervention is necessary
(i.e. boot from a rescue CD, chroot into the root file system, mount
the /boot partition, and re-run the boot loader installation program).

The only way around this problem (other than using smarter software)
is to create an image (sector by sector) backup and do an image restore.
That works with any boot loader.  But that has two major drawbacks.
(1) The technician has to remember to do it that way, and (2) it
prevents restoring individual files.  You either restore the whole
server or nothing.

As I've stated in other posts, we are aware of the deficiencies of
our backup software and are looking at alternatives.  But right now,
this is what we're stuck with.  Thanks for the suggestions, though.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/225990742.152441.1275162416466.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote:
 Stephen Powell wrote:
 On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
 After some discussion about lilo on #debian-devel in IRC, it has pretty
 much been determined that kernel sizes have crossed the line past where
 lilo can reliably determine the payload size.


 We're speaking about #505609 I assume?

I hope not.  Strictly speaking, 505609 is not a lilo bug.  The key is
that he was still able to boot his old kernel that had been de-installed.
That's a sure sign that lilo's map installer did not get run during the
kernel upgrade process.  It used to be that if

   do_bootloader = yes

was specified in /etc/kernel-img.conf that installing a new kernel would
cause lilo to be run.  That is no longer the case.  update-initramfs -u ... 
will cause lilo to be run if this option is set; but update-initramfs -c ...
(or mkinitramfs ...) which is what is run during installation of a new kernel,
will not.  I have created my own hook script to fix that problem on my system.
Strangely, though, do_bootloader = yes in /etc/kernel-img.conf still
causes zipl to be run during kernel installation on the s390 platform.
Something must have changed in the kernel maintainer script or in
update-initramfs that causes the lilo map installer to not be run anymore
under conditions that used to cause it to be run.

Look carefully at the console log.  There is no output from the map installer
until he manually runs lilo.  He apparently thinks that running lilo from
the command line simply lists the installed kernels.  No.  Running lilo
from the command line is what fixed the problem.

If there's a bug here, it's somewhere else in the kernel installation
process, not in lilo itself.  If this so-called bug in lilo is what
prompted the decision to drop lilo, then the decision was based on bad data.
lilo, at least in this case, is working as designed.  The problem is that
the lilo map installer did not get run during the kernel installation
process.  I've helped a number of people on debian-user with problems
like this, and in every case so far running lilo at the command line
fixed the problem.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/267435255.153128.1275165812236.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Tue, 25 May 2010 13:12:27 -0400 (EDT), Stephen Powell wrote:
 Boyd Stephen Smith Jr. wrote:
 No software is entirely without cost ...
 volunteers work on whatever they like ... 
 your specific requirements may differ from their goals ... 
 volunteers are rarely concerned with market share ... 
 
 All excellent points, Boyd.  Fortunately in this case, extlinux appears
 to be a viable solution.  I'll soon know ...

Unfortunately, logical backups of a Linux machine using the extlinux
boot loader do not work with our backup/restore software.  The master boot
record and partition boot sector are restored correctly, but
/boot/extlinux/extlinux.sys will probably not be restored to the exact
same sectors from which it was backed up, and the restore software has no
special logic to remedy that situation.  Therefore, after restore, the
machine will not boot.  It *does* recognize lilo and has special logic
to patch lilo after the restore so that the machine will boot.

The problem can be circumvented by taking an image backup
instead of a logical backup, but that gets into special backup
requirements.  Until we get newer backup software I must either use
lilo or ask for special backup procedures for my Linux servers.
I choose the former.  Logical (file by file) backups have many advantages,
one of which is to avoid giving the Windows advocates an excuse to oppose
further deployment of Linux servers. 

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1739612780.129666.1275057918173.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Josselin Mouette]

Le vendredi 28 mai 2010 à 10:45 -0400, Stephen Powell a écrit :
 Unfortunately, logical backups of a Linux machine using the extlinux
 boot loader do not work with our backup/restore software.  The master boot
 record and partition boot sector are restored correctly, but
 /boot/extlinux/extlinux.sys will probably not be restored to the exact
 same sectors from which it was backed up, and the restore software has no
 special logic to remedy that situation.  Therefore, after restore, the
 machine will not boot.  It *does* recognize lilo and has special logic
 to patch lilo after the restore so that the machine will boot.

We have understood that your backup software is broken. It’s not the
only one. There’s nothing we can do to fix broken, proprietary backup
software.

If you want to become the new upstream for lilo because you need to cope
with broken backup software, please go ahead; I’m sure the effort will
be welcome. If not, I think you have made your point by now.

As a personal advice, I would recommend you to stop bothering with that
broken backup software, it doesn’t seem good for your health. Set up a
CIFS share on a backed-up Windows server, copy your data there using one
of the numerous solutions in Debian, and get done with it. Or just state
that you can’t backup modern Linux servers with it, and let them
struggle with Windows servers if they really decide to use this instead.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `- as a signed contact.”  -- Jörg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1275063080.4783.14.ca...@meh

Re: lilo removal in squeeze (or, please test grub2)

[Peter Samuelson]

[Stephen Powell]
 It *does* recognize lilo and has special logic to patch lilo after
 the restore so that the machine will boot.

So can this software be fooled into thinking it is dealing with lilo?
Would it be sufficient to rename /boot/extlinux/extlinux.sys to
/boot/maps or something?
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100528204411.ge18...@p12n.org

Re: lilo removal in squeeze (or, please test grub2)

[Martin Buck]

In gmane.linux.debian.devel.general Stephen Powell zlinux...@wowway.com wrote:
 But like lilo it stays out of unallocated (and therefore not backed up)
 sectors.  The boot block of extlinux is installed in the boot sector
 of a partition, and the second stage loader occupies a file within the
 partition.  It does not use the master boot record.  It relies on a
 master boot record program to chain load it from the partition boot
 sector.  (I use the mbr package for that.)

BTW, you can install grub exactly the same way. I usually do this because
I absolutely don't like the idea to install something as important as a
boot loader into unallocated sectors. Just do grub-install /dev/sda1
and Grub will adapt its installation procedure accordingly. It's a pity
that this isn't documented more prominently...

Martin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/htl90g$hu...@dough.gmane.org

Re: lilo removal in squeeze (or, please test grub2)

[Ferenc Wagner]

Samuel Thibault sthiba...@debian.org writes:

 Paul Vojta, le Thu 27 May 2010 00:47:14 +, a écrit :
 In article enjn8-64s...@gated-at.bofh.it,
 Ferenc Wagner  wf...@niif.hu wrote:

 Sorry, I don't trust in the future of LILO myself.  If there's anything
 which only LILO can do, I recommend you start complaining on the
 Syslinux and the Grub mailing lists.  I suppose it will be heard.
 
 Does either grub2 or syslinux allow for single-key booting?

 It is available in the experimental branch of grub2.

To quote upstream:

hpa: It's trivial to add support for it (just another MENU directive)

So if you really need it, it'll be in the next version.
And I assume that's why you asked, right? :)
-- 
Cheers,
Feri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vda9tnrx@tac.ki.iif.hu

Re: lilo removal in squeeze (or, please test grub2)

[Colin Watson]

On Mon, May 24, 2010 at 07:10:37PM +0200, Stefano Zacchiroli wrote:
 On Mon, May 24, 2010 at 06:13:13PM +0200, Jordi Mallach wrote:
  Colin added himself to the Uploaders field when I requested him to do so,
  as he's been in charge of Ubuntu's switch to GRUB2 for Ubuntu and after
  the disappearance of Felix and Robert, he's the Debian person with more
  experience to do uploads of the package. He did know he wouldn't be able
  to track upstream as Felix and Robert were (ie, uploading several
  snapshots every two weeks or so).
  
  I can try to work with Vladimir and Colin to get things shaped out a
  little, but honestly I don't think I'd be in a position to do this before
  the 22th of June, when exams finish.
 
 In the meantime, it would be terribly useful if some of you can inform
 us of whether you think things can get in shape for Squeeze or not,
 considering the currently available manpower.  If not, we probably ought
 to be more communicative on the fact we really need help on grub2
 (e.g. Colin can blog about that *g*).

I think grub2 is in a slightly less awful state than it looks just from
its RC bug count.  Boot loaders do tend to attract RC bugs - if it
doesn't boot in some corner case, people understandably crank the
severity up rather high even if it doesn't indicate that it's broken for
most people.

That said, this is a reason and not an excuse.  I've certainly been
neglecting the bug list - Robert and Felix were doing a much better job
of keeping up with it than I seem to have managed.

I'm in the process of preparing a new upstream snapshot now, and have
spent most of the day trying to tidy things up a bit.  I've downgraded a
couple of RC bugs as corner-case and unreproducible, and closed several
more since they were already fixed in the current package.  Of the rest,
they mostly fall into a few main categories with the odd outlier:

 * upgrade-from-grub-legacy problems
 * an assortment of problems with complex block devices (LVM/RAID)
 * unstable device naming in grub-pc/install_devices

I haven't tackled the first yet, but they're hopefully fairly tractable;
that code is just a little unrefined as yet.  Fixing the LVM/RAID cases
is very likely a matter of sitting down with a sequence of test installs
in a VM, which I'm going to attack over the next couple of days.  The
last is nearly done, but I want to fix some known problems in it first
and will probably upload a snapshot without it to start with in order to
make it easier to bisect any new bugs.

In short: my apologies that it's ended up in such a state.  However, I
think I will have time to at least deal with the RC bugs, and hopefully
a number more (including e.g. the btrfs probing bug).  I wouldn't
complain about help though!

(CCs welcome on replies if you want to get my attention a bit faster.)

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100527160709.gy12...@riva.ucam.org

Re: lilo removal in squeeze (or, please test grub2)

[Praveen A]

2010/5/26 Joachim Wiedorn ad_deb...@joonet.de:
 Harald Braumann ha...@unheit.net wrote on Tue, 25 May 2010:

 On simple standard system -- one disk, one kernel in /boot, no fancy
 stuff -- it works quite well.

 This is enough to use grub2 for new installing of Debian.

 On other systems it often breaks miserably. Updates leave my system
 unbootable every other time. One major problem are incompatible
 versions of the boot loader installed in the MBR and grub.cfg.

not strictly a grub2 issue, but os-prober creates unbootable menu's
when you have dual boot systems with same /boot.

Even during a new installation if the system already have another
GNU/Linux it will create unbootable entries for that. See #580736

Earlier with grub I remember these are correctly configured. Plus
without a single configuration file, it is much more difficult to get
it to work as you like.

Praveen
-- 
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
GPLv2 I know my rights; I want my phone call!
DRM What use is a phone call, if you are unable to speak?
(as seen on /.)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktiki7z6_yww2eyduexw6vofd55aldmcu-2kdq...@mail.gmail.com

extlinux (was: Re: lilo removal in squeeze (or, please test grub2))

[Bjørn Mork]

Daniel Baumann dan...@debian.org writes:

 as of current git, you can now use EXTLINUX_UPDATE=false in
 /etc/default/extlinux to prevent having update-extlinux do anything.

That's the single feature I misseded.  Thanks.

Although it would be even better if it was possible to include some
fixed part in it, while keeping most of it auto updated.  I tested the
extlinux package after reading about it yesterday, and the missing
feature that immediately hit me was the ability to use a serial console.
This is of course as easy as with sys-/pxe-/mem-linux: just add 
serial 0 9600 0 or something similar to the config file.  But running
update-extlinux would remove it on every kernel upgrade. Anyway, I
understand that this issue is now solved.

It has puzzled me for a while that grub2 has been chosen over extlinux
as the default x86 bootloader, but didn't know until this discussion
came up that extlinux now was packaged separately from syslinux, with
the nice helper scripts. I guess we all know syslinux and pxelinux very
well from Linux installation procedures over the last 15 years (for
syslinux at least), and HPA has been an active upstream maintainer all
this time AFAIK.  This makes me very confident in extlinux.  While grub2
has already bitten me too much to be considered at all on the important
boxes...

Just comparing http://git.kernel.org/?p=boot/syslinux/syslinux.git with
http://bzr.savannah.gnu.org/r/grub/trunk/grub/ should IMHO give more
than enough information to choose extlinux over grub2

Thanks a lot for packaging extlinux!



Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4qrjbk2.fsf...@nemi.mork.no

Re: extlinux (was: Re: lilo removal in squeeze (or, please test grub2))

[Samuel Thibault]

Bjørn Mork, le Wed 26 May 2010 10:45:49 +0200, a écrit :
 Just comparing http://git.kernel.org/?p=boot/syslinux/syslinux.git with
 http://bzr.savannah.gnu.org/r/grub/trunk/grub/ should IMHO give more
 than enough information to choose extlinux over grub2

I don't understand what you mean here.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100526085116.gw5...@const.bordeaux.inria.fr

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Wed, 26 May 2010 00:23:04 -0400 (EDT), Daniel Baumann wrote:
 On 05/26/2010 03:36 AM, Stephen Powell wrote:
 ...
 That works for now; but if a package upgrade for extlinux is ever
 downloaded, I'm afraid that new versions of the hook scripts will
 be copied into these directories which are marked executable, and
 my hand-made configuration file will get wiped out.
 ...

 as of current git, you can now use EXTLINUX_UPDATE=false in
 /etc/default/extlinux to prevent having update-extlinux do anything.

That's good to know, thanks.  I'm looking forward to that feature
migrating into squeeze.

 Second, it is important that any script run as a hook script not
 produce any output at all to standard output.  I found that out the
 hard way when I was writing my own hook scripts for use with lilo.
 That's because they run under debconf, which has redirected standard
 output for its own purposes.  Thus, anything written to standard
 output is (1) never seen by the user and (2) has a good chance of
 messing up debconf, which is examining the output.  The invocation
 of update-extlinux should have a redirection on it to redirect
 output to standard error.  For example,
 
update-extlinux 2
 
 none of the hooks is doing this (initramfs-tools, grub, etc), might
 needs further convincing.

It is a little-known requirement, and often you can get away with it,
but not always.  I'm going from memory here, but I believe that
debconf redirects standard output, then calls the maintainer script
for the kernel, which calls the run-parts utility, which then calls
the hook script.  If the standard output produced by the hook script
matches something that debconf is looking for it can mess things up.

Sometimes the
failure will occur for one type of call, such as a purge, but not
for another type of call, such as a configure or a remove.  Manoj
Srivastava, author and Debian package maintainer of the kernel-package
package, mentions it in the man page for kernel-img.conf, and
I have personally been burned by it with one of my own hook scripts
that I wrote for use with lilo.  The hook script failed with a
non-zero return code, which caused the kernel installation process
to fail.  I could not figure out for the life of me what was wrong.
The script ran fine when invoked stand-alone, but not as a hook script.
Redirecting lilo output to standard error solved the problem.
It ran perfectly after that.  But even if the stuff written to
standard output does not mess up debconf, the user still won't
see it.  The safe (and informative) thing to do is for all hook
scripts to write all output to standard error.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/375009335.66290.1274880285294.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Paul Vojta]

In article enjn8-64s...@gated-at.bofh.it,
Ferenc Wagner  wf...@niif.hu wrote:

Sorry, I don't trust in the future of LILO myself.  If there's anything
which only LILO can do, I recommend you start complaining on the
Syslinux and the Grub mailing lists.  I suppose it will be heard.

Does either grub2 or syslinux allow for single-key booting?

(For example, if in lilo.conf I have the command single-key near the
beginning of the file, alias=w in the stanza for Windows, and no labels
begin with w or W, then at boot time the single key w will cause lilo to
start booting Windows.)

--Paul Vojta, vo...@math.berkeley.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/htkfei$3r...@news.eternal-september.org

Re: lilo removal in squeeze (or, please test grub2)

[Samuel Thibault]

Paul Vojta, le Thu 27 May 2010 00:47:14 +, a écrit :
 In article enjn8-64s...@gated-at.bofh.it,
 Ferenc Wagner  wf...@niif.hu wrote:
 
 Sorry, I don't trust in the future of LILO myself.  If there's anything
 which only LILO can do, I recommend you start complaining on the
 Syslinux and the Grub mailing lists.  I suppose it will be heard.
 
 Does either grub2 or syslinux allow for single-key booting?

It is available in the experimental branch of grub2.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100527013126.gr4...@const.famille.thibault.fr

Re: lilo removal in squeeze (or, please test grub2)

[Harald Braumann]

Hi,

On Sat, May 22, 2010 at 10:39:52PM -0500, William Pitcock wrote:
 (4) Users need to test grub2 now.

I've been using grub2 for quite some time now on several different
systems with mixed success.

On simple standard system -- one disk, one kernel in /boot, no fancy
stuff -- it works quite well.

On other systems it often breaks miserably. Updates leave my system
unbootable every other time. One major problem are incompatible
versions of the boot loader installed in the MBR and grub.cfg.

Currently, automatic installation of grub in the MBR is a no-go for me,
because of #554790 but I can't prevent grub from automatically
updating grub.cfg which leads to incompatible versions, hence an
unbootable system. 

On some systems the generated grub.cfg is useless for me. On each
update I have to check for changes and incorporate them in my own
hand-edited version.

It is my belief, that the whole automagic configuration system as it
is now is far to complex and convoluted. It is too inflexible to
support any requirements by the user the developers haven't thought
about and in this case you have to work actively against the system to
get what you want. See #578576. I'm not sure if this can be fixed or
if the whole system has to be rethought. Currently I'd tend to the
latter.

And because of the tight dependency between the loader and grub.cfg
and zero-tolerance of the loader to unknown parameters in grub.cfg, it
is far too fragile and very easily leads to an unbootable system.

Because of this, coupled with the many open bugs and the lack of
documentation, I'm not sure if grub2 is ready to be released to the
unsuspecting public.

Cheers,
harry



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100525090027.ga30...@sbs288.lan

Re: lilo removal in squeeze (or, please test grub2)

[Chris Carr]

On 25/05/2010 10:00, Harald Braumann wrote:

Hi,

On Sat, May 22, 2010 at 10:39:52PM -0500, William Pitcock wrote:

(4) Users need to test grub2 now.


I've been using grub2 for quite some time now on several different
systems with mixed success.

[snip]

Because of this, coupled with the many open bugs and the lack of
documentation, I'm not sure if grub2 is ready to be released to the
unsuspecting public.


Just to add my 2p, I have had significant, foreseeable, nonunique 
problems with grub2 on several machines (#495433, #508405, #518835 are 
merely the ones I reported). I would agree with Harald's assessment that 
grub2 is not ready.


It appears from this thread that the maintainer status of grub2 is 
little better than that of lilo. It is therefore difficult to understand 
an argument in favour of removing lilo on the basis of a lack of 
maintainer(s), as that would also apply to grub2.


Given the importance of a reliable boot loader and the severity and 
urgency of any significant bugs in one, it is no surprise that volunteer 
maintainers are hard to find. Would it be sensible to consider creating 
a boot loader team to maintain one or more boot loaders, instead of 
waiting for individuals to step up?


CC


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bfba195.4050...@gmail.com

Re: lilo removal in squeeze (or, please test grub2)

[Steffen Möller]

Hello,

On 05/23/2010 03:44 PM, Julien BLACHE wrote:
 Darren Salt li...@youmustbejoking.demon.co.uk wrote:

 Hi,
   
 Working fine here on i386, whether booting a stock kernel (testing with
 2.6.33 from experimental) or a custom kernel. I've not checked a stock kernel
 on amd64 for some time now, but I've seen no problems with my custom kernels
 (which are all initrd-free).
 
 No problems to report on amd64 either, with or without an initrd.
   
this Grub thingy is something really tough to explain to migrators.
The worst is that while the boot prompt works, one loses the console
all too easily and does not get it back. And google says one should
edit files here and there to keep the gfxpayload.

Yes, I did all that. But I did not want to do that. And then I lost it
again at some later update.

Since the console is the entry to most newbies, whatever you do,
make it as easy as possible. If that is not possible, then please
leave LILO in.

Thanks

Steffen (who accepted to have lost his Console, no ALT-F1 any more)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bfbb8bd.8050...@gmx.de

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

Ferenc Wagner wrote:
 Stephen Powell zlinux...@wowway.com writes:

 Both grub-legacy and grub-pc use sectors on the hard disk outside of
 the master boot record and outside of a partition ...

 You may want to try extlinux, it works much like LILO in this respect.

Well, I tried extlinux last night, and I am hopeful that this is going
to be a solution, at least for me.  extlinux seems to combine the best
parts of grub-pc and lilo.  Like grub-pc, extlinux understands the file
system, and can read the configuration file, kernel, and the initial
RAM file system image from the file system without needing a list of
specific blocks to read.  Thus, the boot loader does not need to be re-run
every time a kernel is installed or updated or an initial RAM file system
image is installed or updated.  The number of file systems it supports
is limited, but that's OK.  A separate /boot partition of the file system
type supported by the boot loader is acceptable.

But like lilo it stays out of unallocated (and therefore not backed up)
sectors.  The boot block of extlinux is installed in the boot sector
of a partition, and the second stage loader occupies a file within the
partition.  It does not use the master boot record.  It relies on a
master boot record program to chain load it from the partition boot
sector.  (I use the mbr package for that.)  It *does* support the
specification of an initial text video mode (vga option), though this
is not specifically documented.

Speaking of documentation, that seems to be its main weakness.
Documentation is sketchy and spread out over a number of different files.
I would have had a hard time configuring it if it weren't for
correct guesses based on my knowledge of how lilo is configured, which
newer users won't have.  It installs hook scripts that I don't want
(and that have bugs).  But after manual configuration and tweaking,
it works just fine.  Now, if it passes the backup / low-level-format /
restore test, I'll be good to go.  Stay tuned ...

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1078928757.35141.1274793733671.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Tue, 25 May 2010 07:08:20 -0400 (EDT), Mihamina Rakotomandimby wrote:
 William Pitcock neno...@dereferenced.org wrote:
 This bug *can* be fixed, but not without a significant rewrite of the
 way that lilo's stage2 loader code works.  Given that there is no
 active upstream and that the Debian lilo package carries many patches
 for bug fixes that are alleviated by standardizing on grub2, this
 seems like the best option for Debian.
 
 Agreed: dead (and buggy) softwares must be out of the distribution.
 Whatever happens. If LILO regains upstream coders, its return to the
 distribution is quite easy.

By that standard, grub-pc should be removed from the distribution.
It may have upstream support, but based on other posts I've seen, it
effectively has no maintainer.  Which is worse, a package with
effectively no upstream support or a package with effectively no
maintainer?  And grub-pc is buggier than lilo.

I understand the need to remove packages with no upstream support.
But asking users to test a package with umpteen known release-critical
bugs, most of which have apparently been fixed upstream, but have
not been fixed in Debian because there is no maintainer to download
a new upstream version, is not a reasonable request in my humble
opinion.  Get a maintainer for it, fix the known bugs, and *then*
ask the users to test it.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1927842586.35924.1274795074336.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[David Weinehall]

On Tue, May 25, 2010 at 09:22:13AM -0400, Stephen Powell wrote:

[snip]

 Speaking of documentation, that seems to be its main weakness.
 Documentation is sketchy and spread out over a number of different files.
 I would have had a hard time configuring it if it weren't for
 correct guesses based on my knowledge of how lilo is configured, which
 newer users won't have.  It installs hook scripts that I don't want
 (and that have bugs).  But after manual configuration and tweaking,
 it works just fine.  Now, if it passes the backup / low-level-format /
 restore test, I'll be good to go.  Stay tuned ...

Perhaps you, with the experienced gained from your adventures with
extlinux, could help write some documentation?


Kind regards: David Weinehall
-- 
 /) David Weinehall t...@debian.org /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100525143916.gh24...@test5.acc.umu.se

Re: lilo removal in squeeze (or, please test grub2)

[Ferenc Wagner]

Stephen Powell zlinux...@wowway.com writes:

 Ferenc Wagner wrote:

 Stephen Powell zlinux...@wowway.com writes:

 Both grub-legacy and grub-pc use sectors on the hard disk outside of
 the master boot record and outside of a partition ...

 You may want to try extlinux, it works much like LILO in this respect.

 It does not use the master boot record.  It relies on a master boot
 record program to chain load it from the partition boot sector.  (I
 use the mbr package for that.)

The extlinux package itself also contains an mbr.bin, which you can use
(it's strong point is probably EBIOS support).

 Speaking of documentation, that seems to be its main weakness.
 Documentation is sketchy and spread out over a number of different files.

/usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly
comprehensive according to my standards, at least as far as the core is
concerned.  What did you miss?  Some modules may be less well documented.

 It installs hook scripts that I don't want (and that have bugs).

I hope we can fix them soon (they are Debian specific additions).
-- 
Cheers,
Feri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874ohwt3td@tac.ki.iif.hu

Re: Re (2): lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
 Stephen Powell wrote:
 (3) The need for special backup requirements will be 
 used by the opponents of Linux at my place of employment 
 to oppose further deployments of Linux, ...
 
 What about the carrot approach?  Find an even better 
 backup method, compatible with Grub 2 and appealing 
 to your management for its efficiency.

You're missing the point.  The main selling point to management
is that Linux is free.  If they have to buy new backup software
in order to accommodate Linux' backup requirements, that will
kill it on the spot.  Whatever boot loader I use must not
require new backup software or impose special backup requirements.
And its not just money.  As a rule, people like what they know.
The backup people are Windows people, and they'd love an
excuse to complain to management about the backup requirements
of my Linux servers.  grub-legacy and grub-pc are non-starters
for me for that reason.  Until now, only lilo, as far as I knew,
met all my requirements.  It now appears that extlinux may also
work.  I'll soon know.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/351821928.39974.1274802154546.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze (or, please test grub2)

[Mark]

On Tue, May 25, 2010 at 8:42 AM, Stephen Powell zlinux...@wowway.comwrote:

 On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
  Stephen Powell wrote:
  (3) The need for special backup requirements will be
  used by the opponents of Linux at my place of employment
  to oppose further deployments of Linux, ...
 
  What about the carrot approach?  Find an even better
  backup method, compatible with Grub 2 and appealing
  to your management for its efficiency.

 You're missing the point.  The main selling point to management
 is that Linux is free.  If they have to buy new backup software
 in order to accommodate Linux' backup requirements, that will
 kill it on the spot.  Whatever boot loader I use must not
 require new backup software or impose special backup requirements.
 And its not just money.  As a rule, people like what they know.
 The backup people are Windows people, and they'd love an
 excuse to complain to management about the backup requirements
 of my Linux servers.  grub-legacy and grub-pc are non-starters
 for me for that reason.  Until now, only lilo, as far as I knew,
 met all my requirements.  It now appears that extlinux may also
 work.  I'll soon know.


Clonezilla is free, and when using the saveparts option to save an image
of one partition and not the full hard drive, it includes the MBR and
associated data.  You can then drop that partition image onto a new/blank
disk, that does not have anything in the MBR, and once Clonezilla restores
the image to the new partition, will put the MBR in place and the machine
boots on its own the next time, with no extra work (I just did this last
week with a new hard drive).  This has been my experience with using
Clonezilla and Lenny, at least.  So it may help in your case.

Mark

Re: Re (2): lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Tue, 25 May 2010 11:51:11 -0400 (EDT), Mark mamar...@gmail.com
 On Tue, May 25, 2010 at 8:42 AM, Stephen Powell zlinux...@wowway.comwrote:
 On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
 Stephen Powell wrote:
 (3) The need for special backup requirements will be
 used by the opponents of Linux at my place of employment
 to oppose further deployments of Linux, ...

 What about the carrot approach?  Find an even better
 backup method, compatible with Grub 2 and appealing
 to your management for its efficiency.

 You're missing the point.  The main selling point to management
 is that Linux is free.  ...

 Clonezilla is free, and when using the saveparts option to save an image
 of one partition and not the full hard drive, it includes the MBR and
 associated data.  You can then drop that partition image onto a new/blank
 disk, that does not have anything in the MBR, and once Clonezilla restores
 the image to the new partition, will put the MBR in place and the machine
 boots on its own the next time, with no extra work (I just did this last
 week with a new hard drive).  This has been my experience with using
 Clonezilla and Lenny, at least.  So it may help in your case.

Perhaps so.  But it's not what the backup people know.  They're very
comfortable with the backup software that they know and love for
backing up their Windows servers, which was purchased with Windows servers
in mind.  Do you think they're going to redo their whole backup architecture
just for a few Linux servers?  If I want to play in their sandbox, I have
to play by their rules.  That's the political reality.  At our shop, Linux
has a small beachhead on a vast continent controlled by Windows.  Over time,
the role of Linux may expand to the point where Linux is actually thought
about and planned for when decisions are made.  But that day is not today.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/479605722.42620.1274806845480.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Tue, 25 May 2010 12:03:17 -0400 (EDT), Boyd Stephen Smith Jr. wrote:
 Stephen Powell wrote:
 
 You're missing the point.  The main selling point to management
 is that Linux is free.
 
 No software is entirely without cost.  Free Software is no exception.  There 
 are usually no up-front licening fees, sure.  However, volunteers work on 
 whatever they like, and if no one volunteers to maintain and support your 
 software you may have to pay for that.
 
 Even with volunteers providing maintenance and support, your specific 
 requirements may differ from their goals and that will require effort to 
 resolve.
 ...
 Also, volunteers are rarely concerned with market share, losing your 
 management as users is not necessarily a concern to them.  If it is a concern 
 for you, you may have to put forward some additional effort to address your 
 management's issues.

All excellent points, Boyd.  Fortunately in this case, extlinux appears
to be a viable solution.  I'll soon know.  The guy I need to see about
setting a test server to test the backup and restore scenario
has been off work with a sick child for the past couple of days, but when
he gets back I'll try to prove that it is 100% compatible with our
backup software.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1557806589.43087.1274807547943.javamail.r...@md01.wow.synacor.com

Re (3): lilo removal in squeeze (or, please test grub2)

[peasthope]

From:   Stephen Powell zlinux...@wowway.com
Date:   Tue, 25 May 2010 11:42:34 -0400 (EDT)
 The backup people are Windows people, and they'd love an
 excuse to complain to management about the backup requirements
 of my Linux servers.

Implies that you don't have responsibility for 
backing the Linux systems.  Too bad; or maybe 
you'd rather not have the extra chore.

Regards,... Peter E.

-- 
Carnot is waiting for a disk replacement; Web pages may not work.
Google pathology workshop.
In ETHNO click here - Desktops.OpenDoc http://carnot.pathology.ubc.ca/.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/171056505.51375.497...@cantor.invalid

Re: lilo removal in squeeze (or, please test grub2)

[Joachim Wiedorn]

Harald Braumann ha...@unheit.net wrote on Tue, 25 May 2010:
 
 On simple standard system -- one disk, one kernel in /boot, no fancy
 stuff -- it works quite well.

This is enough to use grub2 for new installing of Debian.

 On other systems it often breaks miserably. Updates leave my system
 unbootable every other time. One major problem are incompatible
 versions of the boot loader installed in the MBR and grub.cfg.
 
 Currently, automatic installation of grub in the MBR is a no-go for me,
 because of #554790 but I can't prevent grub from automatically
 updating grub.cfg which leads to incompatible versions, hence an
 unbootable system. 

And these problems say, we still need an alternative - I would say: LiLO.

William Pitcock neno...@dereferenced.org wrote on Sat, 22 May 2010:
 
 After some discussion about lilo on #debian-devel in IRC, it has pretty
 much been determined that kernel sizes have crossed the line past where
 lilo can reliably determine the payload size.

But not all kernels are to large - especially the custom kernels - and
LiLO can be used for this special situation. Until which size of kernel 
is LiLO usable?

My suggestion / recommendation is now:

  a) using grub2 as default boot manager for new installations (d-i)
 and for updating grub.

  b) provide LiLO in squeeze as alternative for grub2. The
 limitations must be said while installing the lilo package.
 I think it must not be a proposal in d-i.

Because I still use LiLO for all my systems, I could support the
maintaining of LiLO. Would this a way for you, William?

Fondest regards,
 Joachim Wiedorn



signature.asc
Description: PGP signature

Re: Re (2): lilo removal in squeeze (or, please test grub2)

[owens]

 Original Message 
From: zlinux...@wowway.com
To: debian-devel@lists.debian.org, debian-u...@lists.debian.org,
debian-b...@lists.debian.org
Subject: Re: Re (2): lilo removal in squeeze (or, please test
grub2)
Date: Tue, 25 May 2010 13:00:45 -0400 (EDT)

On Tue, 25 May 2010 11:51:11 -0400 (EDT), Mark mamar...@gmail.com
 On Tue, May 25, 2010 at 8:42 AM, Stephen Powell
zlinux...@wowway.comwrote:
 On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
 Stephen Powell wrote:
 (3) The need for special backup requirements will be
 used by the opponents of Linux at my place of employment
 to oppose further deployments of Linux, ...

 What about the carrot approach?  Find an even better
 backup method, compatible with Grub 2 and appealing
 to your management for its efficiency.

 You're missing the point.  The main selling point to management
 is that Linux is free.  ...

 Clonezilla is free, and when using the saveparts option to save
an image
 of one partition and not the full hard drive, it includes the MBR
and
 associated data.  You can then drop that partition image onto a
new/blank
 disk, that does not have anything in the MBR, and once Clonezilla
restores
 the image to the new partition, will put the MBR in place and the
machine
 boots on its own the next time, with no extra work (I just did
this last
 week with a new hard drive).  This has been my experience with
using
 Clonezilla and Lenny, at least.  So it may help in your case.

Perhaps so.  But it's not what the backup people know.  They're very
comfortable with the backup software that they know and love for
backing up their Windows servers, which was purchased with Windows
servers
in mind.  Do you think they're going to redo their whole backup
architecture
just for a few Linux servers?  If I want to play in their sandbox, I
have
to play by their rules.  That's the political reality.  At our shop,
Linux
has a small beachhead on a vast continent controlled by Windows. 
Over time,
the role of Linux may expand to the point where Linux is actually
thought
about and planned for when decisions are made.  But that day is not
today.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


+1
I have been where Steven is and agree with his approach.
Larry
-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive: http://lists.debian.org/479605722.42620.1274806845480.JavaM
ail.r...@md01.wow.synacor.com





--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/380-220105225234210...@netptc.net

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Tue, 25 May 2010 11:10:38 -0400 (EDT), Ferenc Wagner wrote:
 Stephen Powell wrote:
 ... I installed the mbr package ...
 
 The extlinux package itself also contains an mbr.bin, which you can use
 (it's strong point is probably EBIOS support).

So it does.  Well, I've now installed extlinux' version
of mbr.bin to the master boot record and purged the mbr package.
extlinux' built-in version of a master boot record boot loader works great.

 Speaking of documentation, that seems to be its main weakness.
 Documentation is sketchy and spread out over a number of different files.
 
 /usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly
 comprehensive according to my standards, at least as far as the core is
 concerned.  What did you miss?  Some modules may be less well documented.

Yes, I found those two files.  Reference documentation for each specific
boot loader option is there, but what is lacking is tutorial-type stuff.
For example, there is a global options section at the beginning that applies
to all bootable images, and there are options which are specific to each
boot image.  I guessed at that mainly based on how /etc/lilo.conf works,
but I'm not sure it was directly stated anywhere.  It may be hinted at
in the description of some individual configuration option but not explained
up front.  Also, there's no example configuration file.  There are little
pieces of configuration files but no complete typical configuration file.
A picture is worth a thousand words.

 It installs hook scripts that I don't want (and that have bugs).
 
 I hope we can fix them soon (they are Debian specific additions).

Remember, I'm used to using lilo.  And based on analogies with lilo,
I built a /boot/extlinux/extlinux.conf file that looks like this:

-

DEFAULT Linux
APPEND root=/dev/sda2 ro vga=779
TIMEOUT 50
PROMPT 1
LABEL Linux
KERNEL ../vmlinuz
INITRD ../initrd.img
LABEL LinuxOLD
KERNEL ../vmlinuz.old
INITRD ../initrd.img.old

-

The kernel and initial RAM disk images are specified via the
traditional symlinks.  As long as the symlinks are maintained
properly, my config file never needs updating, just like lilo's.
Consequently, I really don't want the extlinux hook scripts to
execute at all when I install or remove a kernel.  I solved that
temporarily by issuing

   chmod -x /etc/kernel/postinst.d/extlinux
   chmod -x /etc/kernel/postrm.d/extlinux

That works for now; but if a package upgrade for extlinux is ever
downloaded, I'm afraid that new versions of the hook scripts will
be copied into these directories which are marked executable, and
my hand-made configuration file will get wiped out.  I would suggest
testing the existence of some flag file.  If the flag file exists,
then invoking update-extlinux should be bypassed.  Thus, if the user
doesn't want his hand-made /boot/extlinux/extlinux.conf file to be
tampered with, he can create that flag file via touch and the hook
script will not run update-extlinux.  Strictly speaking, this is
an enhancement request.

Second, it is important that any script run as a hook script not
produce any output at all to standard output.  I found that out the
hard way when I was writing my own hook scripts for use with lilo.
That's because they run under debconf, which has redirected standard
output for its own purposes.  Thus, anything written to standard
output is (1) never seen by the user and (2) has a good chance of
messing up debconf, which is examining the output.  The invocation
of update-extlinux should have a redirection on it to redirect
output to standard error.  For example,

   update-extlinux 2

This is a bona-fide bug.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/630546796.56099.1274837814099.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Daniel Baumann]

On 05/26/2010 03:36 AM, Stephen Powell wrote:
 That works for now; but if a package upgrade for extlinux is ever
 downloaded, I'm afraid that new versions of the hook scripts will
 be copied into these directories which are marked executable, and
 my hand-made configuration file will get wiped out.  I would suggest
 testing the existence of some flag file.  If the flag file exists,
 then invoking update-extlinux should be bypassed.  Thus, if the user
 doesn't want his hand-made /boot/extlinux/extlinux.conf file to be
 tampered with, he can create that flag file via touch and the hook
 script will not run update-extlinux.  Strictly speaking, this is
 an enhancement request.

as of current git, you can now use EXTLINUX_UPDATE=false in
/etc/default/extlinux to prevent having update-extlinux do anything.

 Second, it is important that any script run as a hook script not
 produce any output at all to standard output.  I found that out the
 hard way when I was writing my own hook scripts for use with lilo.
 That's because they run under debconf, which has redirected standard
 output for its own purposes.  Thus, anything written to standard
 output is (1) never seen by the user and (2) has a good chance of
 messing up debconf, which is examining the output.  The invocation
 of update-extlinux should have a redirection on it to redirect
 output to standard error.  For example,
 
update-extlinux 2

none of the hooks is doing this (initramfs-tools, grub, etc), might
needs further convincing.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  daniel.baum...@panthera-systems.net
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bfca228.5000...@debian.org

Re: lilo removal in squeeze (or, please test grub2)

[Christian PERRIER]

Quoting Stanislav Maslovski (stanislav.maslov...@gmail.com):

  Nobody cares if you are opposed to it.  Unless you are offering to become
  lilo upstream, it's going away.
 
 That is why I love reading d-dev. Some debian developers are so good
 at argumentation!

Everybody has time constraints and I think the answer you're quoting
is pretty much well summarizing the point: yes, lilo is useful to some
people.yes, nobody stepped up to maintain it enough for being kept
in the archive, even among those peopleyes, keeping lilo in the
archive is a burden for some *other* people (security team, D-I
team).

So, the conclusion is easy to drive: if some people are interested in
keeping the lilo package alive, then their only chance is to step up,
keep the package maintenance alive by taking it over (I'm sure nobody
will complain).

This is not much argumentation needed here...:-)

And, yes, I agree that the same could be said about grub2, indeed..:)




signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

[Philipp Kern]

On 2010-05-24, Florian Zagler florianzag...@web.de wrote:
 Don't drop lilo in squeeze but mark it orphaned. Leave it in Squeeze and 
 schedule the removal for Squeeze+1.

Orphaned packages in a release are a pain if nobody steps up to fix RC bugs
suddenly popping up in stable.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhvka69.ml7.tr...@kelgar.0x539.de

Re: lilo removal in squeeze (or, please test grub2)

[Ferenc Wagner]

Kurt Roeckx k...@roeckx.be writes:

 On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote:
 William Pitcock neno...@dereferenced.org (22/05/2010):
 This means that users should *test grub2 extensively* before Squeeze
 is released so that any issues can be resolved now.
 
 There should also be some folks fixing the discovered issues.

 grub2 currently seems to be having 18 RC bugs, plus a whole bunch
 of merged bugs, while lilo only has 1 RC bug.  

I chatted about this with the grub upstream a couple of days ago.
According to Vladimir, most of those bugs are already fixed, but there's
nobody around to do a new upload.  Both grub maintainers (Felix Zielke
and Robert Millan) unexpectedly disappeared some time ago.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w791w0v@tac.ki.iif.hu

Re: lilo removal in squeeze (or, please test grub2)

[Ferenc Wagner]

Stephen Powell zlinux...@wowway.com writes:

 Both grub-legacy and grub-pc use sectors on the hard disk outside of
 the master boot record [...] This breaks the design of the backup
 software that my employer uses.  This backup software backs up the
 master boot record and all partitions; but since the extra sectors
 used by grub-legacy and grub-pc are outside the master boot record and
 are not part of any partition, they don't get backed up.
 Consequently, if we have a hard drive failure and restore from a
 backup, we have an unbootable machine.  Lilo uses only the master boot
 record.  A lilo-booted machine can be backed up and restored with our
 existing backup software just fine.

You may want to try extlinux, it works much like LILO in this respect.
It lacks a convenient configuration system, but that of grub-legacy
would be easy to adapt, and I actually plan to work on this.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3wl1wbv@tac.ki.iif.hu

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Mon, 24 May 2010 05:36:32 -0400 (EDT), Ferenc Wagner wrote:
 Kurt Roeckx k...@roeckx.be wrote:
 On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote:
 William Pitcock neno...@dereferenced.org (22/05/2010):
 This means that users should *test grub2 extensively* before Squeeze
 is released so that any issues can be resolved now.
 
 There should also be some folks fixing the discovered issues.

 grub2 currently seems to be having 18 RC bugs, plus a whole bunch
 of merged bugs, while lilo only has 1 RC bug.  
 
 I chatted about this with the grub upstream a couple of days ago.
 According to Vladimir, most of those bugs are already fixed, but there's
 nobody around to do a new upload.  Both grub maintainers (Felix Zielke
 and Robert Millan) unexpectedly disappeared some time ago.

What about Jordi Mallach and Colin Watson?  The package page for grub-pc

   http://packages.debian.org/squeeze/grub-pc

lists them as maintainers too.  Have they disappeared as well?  Or are
they no longer maintainers for this package?  In which case their names
should be removed from the web page.

Somehow I feel a dip in motivation.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1054400013.5379.1274709588267.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Thijs Kinkhorst]

On moandei 24 Maaie 2010, Christian PERRIER wrote:
 yes, keeping lilo in the
 archive is a burden for some other people (security team,

I would like to correct the suggestion that the security team would oppose 
keeping lilo in squeeze. There is currently no such objection, and in the past 
the security team has only voiced objections or asked for removal of packages 
with a security risk that is deemed significantly larger than average, for 
example based on past experience. That is not the case for lilo. The security 
team should not be used as an argument pro/contra lilo.



Cheers,
Thijs


signature.asc
Description: This is a digitally signed message part.

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote:
 Stephen Powell zlinux...@wowway.com writes:

 Both grub-legacy and grub-pc use sectors on the hard disk outside of
 the master boot record [...] This breaks the design of the backup
 software that my employer uses.  This backup software backs up the
 master boot record and all partitions; but since the extra sectors
 used by grub-legacy and grub-pc are outside the master boot record and
 are not part of any partition, they don't get backed up.
 Consequently, if we have a hard drive failure and restore from a
 backup, we have an unbootable machine.  Lilo uses only the master boot
 record.  A lilo-booted machine can be backed up and restored with our
 existing backup software just fine.

 You may want to try extlinux, it works much like LILO in this respect.
 It lacks a convenient configuration system, but that of grub-legacy
 would be easy to adapt, and I actually plan to work on this.

Thanks for the tip.  That may be an option.  I looked at the documentation
online, and there does not appear to be an option equivalent to lilo's
vga option, though, which I use a lot, especially since svgatextmode
has already been pulled from squeeze.  As of right now, if lilo was
pulled from the distribution, I think I'd be inclined to build my own
lilo package from source before switching to any other bootloader.
To the best of my knowledge, it is the *only* bootloader which supports
setting an initial text video mode *and* does not use any sectors outside
the master boot record and outside of a partition.  If I'm wrong about
that, someone please correct me.

As for a convenient configuration system, editing a plain text
file is plenty good enough for me.  Your time is yours
to use as you see fit; but if you have the requisite skills to become
the equivalent of lilo upstream, I think there's a lot of people
who would rather that you do that, myself included.  I'd do it myself
if I had the necessary skills and knowledge.  But I don't.

Thanks again for the tip.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1012155825.7010.1274712448896.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Jordi Mallach]

[Please Cc: replies, I'm not subscribed to debian-devel ]

Stephen Powell wrote:
 What about Jordi Mallach and Colin Watson?  The package page for grub-pc
 lists them as maintainers too.  Have they disappeared as well?  Or are
 they no longer maintainers for this package?  In which case their names
 should be removed from the web page.

The main reason for being listed as an Uploader for GRUB was helping out
with PowerPC support; a task which isn't critical for squeeze nor I can
really keep doing as my G4 box is dead.

Colin added himself to the Uploaders field when I requested him to do so,
as he's been in charge of Ubuntu's switch to GRUB2 for Ubuntu and after
the disappearance of Felix and Robert, he's the Debian person with more
experience to do uploads of the package. He did know he wouldn't be able
to track upstream as Felix and Robert were (ie, uploading several
snapshots every two weeks or so).

I can try to work with Vladimir and Colin to get things shaped out a
little, but honestly I don't think I'd be in a position to do this before
the 22th of June, when exams finish.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

[Stefano Zacchiroli]

On Mon, May 24, 2010 at 06:13:13PM +0200, Jordi Mallach wrote:
 Colin added himself to the Uploaders field when I requested him to do so,
 as he's been in charge of Ubuntu's switch to GRUB2 for Ubuntu and after
 the disappearance of Felix and Robert, he's the Debian person with more
 experience to do uploads of the package. He did know he wouldn't be able
 to track upstream as Felix and Robert were (ie, uploading several
 snapshots every two weeks or so).
 
 I can try to work with Vladimir and Colin to get things shaped out a
 little, but honestly I don't think I'd be in a position to do this before
 the 22th of June, when exams finish.

In the meantime, it would be terribly useful if some of you can inform
us of whether you think things can get in shape for Squeeze or not,
considering the currently available manpower.  If not, we probably ought
to be more communicative on the fact we really need help on grub2
(e.g. Colin can blog about that *g*).

Many thanks for your feedback!
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

[Edward Allcutt]

On Mon, 24 May 2010, Stephen Powell wrote:

To the best of my knowledge, it is the *only* bootloader which supports
setting an initial text video mode *and* does not use any sectors outside
the master boot record and outside of a partition.  If I'm wrong about
that, someone please correct me.


grub2 supports loading its core.img from a dedicated partition instead
of embedding it in the first cylinder. This does require switching to
the GPT partitioning scheme which may or may not be acceptable to you.

--
Edward Allcutt


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1005241244200.1...@emallcut-x.pc.teamgleim.com

Re: lilo removal in squeeze (or, please test grub2)

[Ferenc Wagner]

Stephen Powell zlinux...@wowway.com writes:

 On Mon, 24 May 2010 05:36:32 -0400 (EDT), Ferenc Wagner wrote:
 Kurt Roeckx k...@roeckx.be wrote:
 On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote:
 William Pitcock neno...@dereferenced.org (22/05/2010):
 This means that users should *test grub2 extensively* before Squeeze
 is released so that any issues can be resolved now.
 
 There should also be some folks fixing the discovered issues.

 grub2 currently seems to be having 18 RC bugs, plus a whole bunch
 of merged bugs, while lilo only has 1 RC bug.  
 
 I chatted about this with the grub upstream a couple of days ago.
 According to Vladimir, most of those bugs are already fixed, but there's
 nobody around to do a new upload.  Both grub maintainers (Felix Zielke
 and Robert Millan) unexpectedly disappeared some time ago.

 What about Jordi Mallach and Colin Watson?

I really don't know, I just echoed what I heard on the #grub IRC
channel.  I saw articles from Colin Watson recently, so he's around, but
I don't know how he feels about Grub maintenance.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6f9z0il@tac.ki.iif.hu

Re: lilo removal in squeeze (or, please test grub2)

[Ferenc Wagner]

Stephen Powell zlinux...@wowway.com writes:

 On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote:

 Stephen Powell zlinux...@wowway.com writes:

 Both grub-legacy and grub-pc use sectors on the hard disk outside of
 the master boot record [...]

 You may want to try extlinux, it works much like LILO in this respect.

 Thanks for the tip.  That may be an option.  I looked at the documentation
 online, and there does not appear to be an option equivalent to lilo's
 vga option, though, which I use a lot, especially since svgatextmode
 has already been pulled from squeeze.

I'm not sure what you're after, I haven't used LILO for ages.  But
typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a
80x60 console.  The other variants use the same code.

 It lacks a convenient configuration system, but that of grub-legacy
 would be easy to adapt, and I actually plan to work on this.

 if you have the requisite skills to become the equivalent of lilo
 upstream, I think there's a lot of people who would rather that you do
 that, myself included.

Sorry, I don't trust in the future of LILO myself.  If there's anything
which only LILO can do, I recommend you start complaining on the
Syslinux and the Grub mailing lists.  I suppose it will be heard.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87typxyzbk@tac.ki.iif.hu

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Mon, 24 May 2010 13:01:30 -0400 (EDT), Edward Allcutt wrote:
 On Mon, 24 May 2010, Stephen Powell wrote:
 To the best of my knowledge, lilo is the *only* bootloader which supports
 setting an initial text video mode *and* does not use any sectors outside
 the master boot record and outside of a partition.  If I'm wrong about
 that, someone please correct me.
 
 grub2 supports loading its core.img from a dedicated partition instead
 of embedding it in the first cylinder. This does require switching to
 the GPT partitioning scheme which may or may not be acceptable to you.

No, the backup software assumes the traditional MS-DOS hard disk partitioning
scheme.  One can get around this by requiring an image backup, but that
has three substantial drawbacks: (1) The entire disk, including free space
and extended partition free space, must be backed up.  This takes a lot
more time.  (2) A restore can only be done to a disk of the exact same
size as the one backed up.  Often, a larger disk must be used because the
model that failed is no longer available on the market.  (3) The need
for special backup requirements will be used by the opponents of Linux at
my place of employment to oppose further deployments of Linux, which I wish
to avoid at all costs.  But thanks for the info anyway.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1081731293.13454.1274723918397.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Daniel Baumann]

On 05/24/2010 11:29 AM, Ferenc Wagner wrote:
 You may want to try extlinux, it works much like LILO in this respect.
 It lacks a convenient configuration system, but that of grub-legacy
 would be easy to adapt, and I actually plan to work on this.

sometime ago i've added extliux-install and update-extlinux. if fits my
setups well, however, any other/better ideas how to improve it are very
welcome, see #573042 for more information.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  daniel.baum...@panthera-systems.net
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bfac975.1070...@debian.org

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Mon, 24 May 2010 13:38:55 -0400 (EDT), Ferenc Wagner wrote:
 Stephen Powell zlinux...@wowway.com writes:
 On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote:
 Stephen Powell zlinux...@wowway.com writes:
 Both grub-legacy and grub-pc use sectors on the hard disk outside of
 the master boot record [...]

 You may want to try extlinux, it works much like LILO in this respect.

 Thanks for the tip.  That may be an option.  I looked at the documentation
 online, and there does not appear to be an option equivalent to lilo's
 vga option, though, which I use a lot, especially since svgatextmode
 has already been pulled from squeeze.
 
 I'm not sure what you're after, I haven't used LILO for ages.  But
 typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a
 80x60 console.  The other variants use the same code.

Interesting.  At one point, the kernel itself had de-supported the
vga boot option, relying on the boot loader to set the video mode
before transferring control to the kernel.  And now you're saying
it's back.  Hmm.  According to Documentation/svga.txt in the kernel
source tree:

   This small document describes the Video Mode Selection feature which
   allows the use of various special video modes supported by the video BIOS.
   Due to usage of the BIOS, the selection is limited to boot time (before
   the kernel decompression starts) and works only on 80X86 machines.

Note the wording before the kernel decompression starts.  That to me
implies done by the bootloader, because the bootloader decompresses
the kernel (if it is compressed) before transferring control to it,
does it not?

The vga option is a separate option in lilo.  You can't include it in
the append variable without lilo generating an error.  You've got my
curiosity up now.  I'll have to try this.  I do have a spare computer
with which to test.  I'm going to have to try installing Squeeze using
extlinux as the boot loader.  (No doubt I'll have to change bootloaders
after installation, as the Debian Installer won't offer that option.)
Then I'll see if I can pass it the vga option and have it work.  And
if that works, then I'll try the backup, nuke, and restore scenario.
And if that works, then I may have a viable alternative to lilo.
I'll let you know how it goes.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/158609809.14709.1274725819037.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Ferenc Wagner]

Stephen Powell zlinux...@wowway.com writes:

 On Mon, 24 May 2010 13:38:55 -0400 (EDT), Ferenc Wagner wrote:
 Stephen Powell zlinux...@wowway.com writes:
 On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote:
 Stephen Powell zlinux...@wowway.com writes:
 Both grub-legacy and grub-pc use sectors on the hard disk outside of
 the master boot record [...]

 You may want to try extlinux, it works much like LILO in this respect.

 Thanks for the tip.  That may be an option.  I looked at the documentation
 online, and there does not appear to be an option equivalent to lilo's
 vga option, though, which I use a lot, especially since svgatextmode
 has already been pulled from squeeze.
 
 I'm not sure what you're after, I haven't used LILO for ages.  But
 typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a
 80x60 console.  The other variants use the same code.

 Interesting.  At one point, the kernel itself had de-supported the
 vga boot option, relying on the boot loader to set the video mode
 before transferring control to the kernel.  And now you're saying
 it's back.  Hmm.  According to Documentation/svga.txt in the kernel
 source tree:

This small document describes the Video Mode Selection feature which
allows the use of various special video modes supported by the video BIOS.
Due to usage of the BIOS, the selection is limited to boot time (before
the kernel decompression starts) and works only on 80X86 machines.

 Note the wording before the kernel decompression starts.  That to me
 implies done by the bootloader, because the bootloader decompresses
 the kernel (if it is compressed) before transferring control to it,
 does it not?

It does not, the kernel is sort of a self-decompressing binary.
However, the vga= parameter is indeed parsed by the bootloader and
passed to the kernel by a special protocol.  It's then used before the
kernel parses its command line.

 I'm going to have to try installing Squeeze using extlinux as the boot
 loader.  (No doubt I'll have to change bootloaders after installation,
 as the Debian Installer won't offer that option.)

Yes, you'll have to back out of Grub installation, start a shell, chroot
into /target, and install exlinux.  Take care to have /boot on an ext2
partition.
-- 
Good luck!
Feri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iq6dytpl@tac.ki.iif.hu

Re: lilo removal in squeeze (or, please test grub2)

[Josselin Mouette]

Le dimanche 23 mai 2010 à 20:48 -0400, Stephen Powell a écrit : 
 I do understand why a Debian package maintainer does not wish to become
 upstream.  And I hope that someone who is both willing and able to do
 so steps up to the plate.  But withdrawing it from the distribution seems
 like overkill to me, especially since you want to withdraw it from Squeeze
 and not Squeeze+1.  Lilo, as it exists today, works just fine for my
 purposes.  And apparently it works just fine for a lot of other people too.

Debian stable releases are not here to serve as a repository for
orphaned packages. We are supposed to keep them in shape for the
lifetime of the release.

 The Lord bless you, William.

May His noodly appendage touch you.

Ramen,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


signature.asc
Description: This is a digitally signed message part

Re: lilo removal in squeeze (or, please test grub2)

[Josselin Mouette]

Le lundi 24 mai 2010 à 20:46 +0200, Daniel Baumann a écrit : 
 On 05/24/2010 11:29 AM, Ferenc Wagner wrote:
  You may want to try extlinux, it works much like LILO in this respect.
  It lacks a convenient configuration system, but that of grub-legacy
  would be easy to adapt, and I actually plan to work on this.
 
 sometime ago i've added extliux-install and update-extlinux. if fits my
 setups well, however, any other/better ideas how to improve it are very
 welcome, see #573042 for more information.

Could this also be eventually added as an alternative to grub2 in the
installer?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


signature.asc
Description: This is a digitally signed message part

Re: lilo removal in squeeze (or, please test grub2)

[Ferenc Wagner]

Daniel Baumann dan...@debian.org writes:

 On 05/24/2010 11:29 AM, Ferenc Wagner wrote:

 You may want to try extlinux, it works much like LILO in this respect.
 It lacks a convenient configuration system, but that of grub-legacy
 would be easy to adapt, and I actually plan to work on this.

 sometime ago i've added extliux-install and update-extlinux. if fits my
 setups well, however, any other/better ideas how to improve it are very
 welcome, see #573042 for more information.

Heh, yes, that's me again. :)  I got distracted, but didn't give up work
on this.  Now I'm nosing around the current Grub2 method for ideas.
Meanwhile, the unconditional destroying of extlinux.conf on update gave
me the grief again. :-/
-- 
Cheers,
Feri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3wlyt1a@tac.ki.iif.hu

Re: lilo removal in squeeze (or, please test grub2)

[Daniel Baumann]

On 05/24/2010 10:07 PM, Josselin Mouette wrote:
 Could this also be eventually added as an alternative to grub2 in the
 installer?

i've talked with otavio about this already a year ago, as i'm much in
favour[0] of extlinux over grub2 anyway, but i didn't got arround to
finally push it. if anyone has time before debconf/debcamp, that would
be great. otherwise, i hope to have a look together with otavio at
debconf/debcamp (if he accepts my bribes with chocolate :).

[0]
http://blog.daniel-baumann.ch/2009/11/30#20091130_extlinux-as-alternative-bootloader

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  daniel.baum...@panthera-systems.net
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bfadee4.5080...@debian.org

Re: lilo removal in squeeze (or, please test grub2)

[Darren Salt]

I demand that Ferenc Wagner may or may not have written...

[snip]
 You may want to try extlinux, it works much like LILO in this respect. It
 lacks a convenient configuration system, but that of grub-legacy would be
 easy to adapt, and I actually plan to work on this.

Given an upload of a 4.00 RC to unstable or experimental (for the ext4
support), I'd have a look...

-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + At least 4000 million too many people. POPULATION LEVEL IS UNSUSTAINABLE.

I'd like to, but my bathroom tiles need grouting.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51220d2c30%li...@youmustbejoking.demon.co.uk

Re: lilo removal in squeeze (or, please test grub2)

[Cyril Brulebois]

(Dropping -release, which isn't a discussion list.)

William Pitcock neno...@dereferenced.org (22/05/2010):
 Given that there is no active upstream and that the Debian lilo
 package carries many patches for bug fixes that are alleviated by
 standardizing on grub2, this seems like the best option for Debian.

Speaking of upstream and bug fixing, what about that?
  http://bugs.debian.org/src:grub2

 This means that users should *test grub2 extensively* before Squeeze
 is released so that any issues can be resolved now.

There should also be some folks fixing the discovered issues.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

[Kurt Roeckx]

On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote:
 William Pitcock neno...@dereferenced.org (22/05/2010):
  This means that users should *test grub2 extensively* before Squeeze
  is released so that any issues can be resolved now.
 
 There should also be some folks fixing the discovered issues.

grub2 currently seems to be having 18 RC bugs, plus a whole bunch
of merged bugs, while lilo only has 1 RC bug.  

I think the difference is that lilo will probably not work
for a lot of people while grub2 does work for a lot of people.
And I understand that Debian's lilo maintainer basicly doesn't want
to become upstream and rewrite everything when there is an
alternative.

But I agree that a call for extensive testing would be better if
number of RC bugs would be a lot lower.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100523114251.ga3...@roeckx.be

Re: lilo removal in squeeze (or, please test grub2)

[Darren Salt]

I demand that William Pitcock may or may not have written...

 After some discussion about lilo on #debian-devel in IRC, it has pretty
 much been determined that kernel sizes have crossed the line past where
 lilo can reliably determine the payload size.

Working fine here on i386, whether booting a stock kernel (testing with
2.6.33 from experimental) or a custom kernel. I've not checked a stock kernel
on amd64 for some time now, but I've seen no problems with my custom kernels
(which are all initrd-free).

[snip]
 This means that users should *test grub2 extensively* before Squeeze is
 released so that any issues can be resolved now.

Well... I recall an issue with the default boot menu item no. being left
untouched and, consequently, becoming out of sync with menu content as
kernels were added or removed, although that may just be grub1.

Still, it was enough of a reason to stick with lilo.

(However, I recall extlinux being mentioned when this last came up...)

 As for removal, the following things need to be done:

 (1) The release notes need to be updated to reflect that lilo is no
 longer a bootloader option;
 (2) The debian-installer team needs to remove the lilo-installer udeb;
 (3) The ftpmasters need to remove lilo from unstable (which will be done
 using the appropriate bug filing once the above steps are made);

Alternatively, document its limitations and bugs, and let it stay.

 (4) Users need to test grub2 now.

Need? I see no need...

[snip]
-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + I say leave it for squeeze+∞ :-)

Drive must be A: or B:, 0:1


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/512157417c%li...@youmustbejoking.demon.co.uk

Re: lilo removal in squeeze (or, please test grub2)

[Julien BLACHE]

Darren Salt li...@youmustbejoking.demon.co.uk wrote:

Hi,

 Working fine here on i386, whether booting a stock kernel (testing with
 2.6.33 from experimental) or a custom kernel. I've not checked a stock kernel
 on amd64 for some time now, but I've seen no problems with my custom kernels
 (which are all initrd-free).

No problems to report on amd64 either, with or without an initrd.

JB.

-- 
 Julien BLACHE - Debian  GNU/Linux Developer - jbla...@debian.org 
 
 Public key available on http://www.jblache.org - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871vd268d2@sonic.technologeek.org

Re: lilo removal in squeeze (or, please test grub2)

[Marc Haber]

On Sat, 22 May 2010 22:39:52 -0500, William Pitcock
neno...@dereferenced.org wrote:
This means that users should *test grub2 extensively* before Squeeze is
released so that any issues can be resolved now.

This also means that the grub2 maintainers (both Debian and Upstream)
need to work on the regressions that exist in regard to moving from
lilo or grub legacy to grub2. There are too many bug reports in the
BTS which are completely unaddressed.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1og9zh-0003pu...@swivel.zugschlus.de

Re: lilo removal in squeeze (or, please test grub2)

[Stefano Zacchiroli]

On Sun, May 23, 2010 at 02:08:59PM +0200, Marc Haber wrote:
 This also means that the grub2 maintainers (both Debian and Upstream)
 need to work on the regressions that exist in regard to moving from
 lilo or grub legacy to grub2. There are too many bug reports in the
 BTS which are completely unaddressed.

Right, but also note that there's an open RFH on grub2 #248397
(retitled/refreshed recently, despite the low bug number).

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

[Darren Salt]

I demand that Julien BLACHE may or may not have written...

 Darren Salt li...@youmustbejoking.demon.co.uk wrote:
 Working fine here on i386, whether booting a stock kernel (testing with
 2.6.33 from experimental) or a custom kernel. I've not checked a stock
 kernel on amd64 for some time now, but I've seen no problems with my
 custom kernels (which are all initrd-free).

 No problems to report on amd64 either, with or without an initrd.

You removed too much context; I'm assuming that you were testing lilo...

-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.

Beauty is only skin deep, but ugly goes clear to the bone.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/512165675c%li...@youmustbejoking.demon.co.uk

Re: lilo removal in squeeze (or, please test grub2)

[Julien BLACHE]

Darren Salt li...@youmustbejoking.demon.co.uk wrote:

Hi,

 Working fine here on i386, whether booting a stock kernel (testing with
 2.6.33 from experimental) or a custom kernel. I've not checked a stock
 kernel on amd64 for some time now, but I've seen no problems with my
 custom kernels (which are all initrd-free).

 No problems to report on amd64 either, with or without an initrd.

Yes indeed.

JB.

-- 
 Julien BLACHE - Debian  GNU/Linux Developer - jbla...@debian.org 
 
 Public key available on http://www.jblache.org - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wruu4ouq@sonic.technologeek.org

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
 
 After some discussion about lilo on #debian-devel in IRC, it has pretty
 much been determined that kernel sizes have crossed the line past where
 lilo can reliably determine the payload size.
 
 This bug *can* be fixed, but not without a significant rewrite of the
 way that lilo's stage2 loader code works.  Given that there is no active
 upstream and that the Debian lilo package carries many patches for bug
 fixes that are alleviated by standardizing on grub2, this seems like the
 best option for Debian.
 
 This means that users should *test grub2 extensively* before Squeeze is
 released so that any issues can be resolved now.
 
 As for removal, the following things need to be done:
 
 (1) The release notes need to be updated to reflect that lilo is no
 longer a bootloader option;
 (2) The debian-installer team needs to remove the lilo-installer udeb;
 (3) The ftpmasters need to remove lilo from unstable (which will be done
 using the appropriate bug filing once the above steps are made);
 (4) Users need to test grub2 now.

First of all, forgive me for cross-posting, which is generally a no-no.
But if you can cross-post, I can cross-reply.

Second, unless you reply to debian-user, to which I am subscribed, please
CC me.  I am not subscribed to any of the other lists.

I am not a Debian package maintainer or a Debian developer.  I am just an
ordinary system administrator.  So I'm sure that my opinion will not count
for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
grub-pc use sectors on the hard disk outside of the master boot record
(cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head 0,
sector 2 and possibly subsequent sectors on cylinder 0 head 0.  This breaks
the design of the backup software that my employer uses.  This backup software
backs up the master boot record and all partitions; but since the extra
sectors used by grub-legacy and grub-pc are outside the master boot record
and are not part of any partition, they don't get backed up.  Consequently,
if we have a hard drive failure and restore from a backup, we have an
unbootable machine.  Lilo uses only the master boot record.  A lilo-booted
machine can be backed up and restored with our existing backup software
just fine.  Given these requirements, I wouldn't use grub-pc even if it
were bug free and well documented.  (But neither is the case!)

As for the claims that kernels are too big now, I find that hard to
believe, especially now that we have the large-memory option available.
The standard stock Debian kernel image file that I use for Squeeze,
vmlinuz-2.6.32-3-686, is currently 2234080 bytes.  Are you trying to tell
me that there's no room for a 2M kernel below the start of the EBDA?

I am able to load *both* the kernel *and* the initial RAM filesystem
below the EBDA (i.e. the large-memory option is not used) if I use
MODULES=dep instead of MODULES=most in the initial RAM filesystem
under Lenny.  I'll bet I can do it with Squeeze too.

I realize that lilo doesn't work for everyone, and I'm not suggesting
that it be the default bootloader; but to get rid of it entirely is
unacceptable.  As far as I know, it's the only bootloader that meets
all of my requirements, and I will not voluntarily give it up.

No doubt you will tell me that I am welcome to maintain it myself.
Unfortunately, I do not have the requisite skills to do so.  All I
can do is to appeal in the name of reason that it not be dropped.

Also, please excuse my ignorance, but what exactly is this
payload size to which you refer?  Is that the same thing as the
size of the kernel?  Or is it something else?

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/698259750.358730.1274641482395.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[William Pitcock]

Hi,

- Stephen Powell zlinux...@wowway.com wrote:

 (blah blah blah blah)

Nobody cares if you are opposed to it.  Unless you are offering to become
lilo upstream, it's going away.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2152114.3751274645490011.javamail.r...@ifrit.dereferenced.org

Re: lilo removal in squeeze (or, please test grub2)

[Stanislav Maslovski]

On Mon, May 24, 2010 at 12:11:30AM +0400, William Pitcock wrote:
 Hi,
 
 - Stephen Powell zlinux...@wowway.com wrote:
 
  (blah blah blah blah)
 
 Nobody cares if you are opposed to it.  Unless you are offering to become
 lilo upstream, it's going away.

That is why I love reading d-dev. Some debian developers are so good
at argumentation!

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100523215431.ga6...@kaiba.homelan

Re: lilo removal in squeeze (or, please test grub2)

[Stephen Powell]

On Sun, 23 May 2010 16:11:30 -0400 (EDT), William Pitcock wrote:
 Stephen Powell zlinux...@wowway.com wrote:
 (blah blah blah blah)

 Nobody cares if you are opposed to it.  Unless you are offering to become
 lilo upstream, it's going away.
 
 William

I do understand why a Debian package maintainer does not wish to become
upstream.  And I hope that someone who is both willing and able to do
so steps up to the plate.  But withdrawing it from the distribution seems
like overkill to me, especially since you want to withdraw it from Squeeze
and not Squeeze+1.  Lilo, as it exists today, works just fine for my
purposes.  And apparently it works just fine for a lot of other people too.

The Lord bless you, William.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1170680188.363342.1274662130640.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

[Don Armstrong]

On Sun, 23 May 2010, Stephen Powell wrote:
 But withdrawing it from the distribution seems like overkill to me,
 especially since you want to withdraw it from Squeeze and not
 Squeeze+1. Lilo, as it exists today, works just fine for my
 purposes.

If the maintainer doesn't wish to maintain it for another stable
release cycle, and no one steps up to the plate to handle it, it
should be removed.

It's not like the removal of the package from the next release will
cause your working version to be removed, after all... and you can
presumably install manually later if you actually want it.


Don Armstrong

-- 
He was wrong. Nature abhors dimensional abnormalities, and seals them
neatly away so that they don't upset people. Nature, in fact, abhors a
lot of things, including vacuums, ships called the Marie Celeste, and
the chuck keys for electric drills.
 -- Terry Pratchet _Pyramids_ p166

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100524030219.gk4...@teltox.donarmstrong.com

Re: lilo removal in squeeze (or, please test grub2)

[Florian Zagler]

On Monday, 24. May 2010, Stephen Powell wrote:
 I do understand why a Debian package maintainer does not wish to become
 upstream.  And I hope that someone who is both willing and able to do
 so steps up to the plate.  But withdrawing it from the distribution seems
 like overkill to me, especially since you want to withdraw it from Squeeze
 and not Squeeze+1.  Lilo, as it exists today, works just fine for my
 purposes.  And apparently it works just fine for a lot of other people too.

I think the best solution for all should be:
Don't drop lilo in squeeze but mark it orphaned. Leave it in Squeeze and 
schedule the removal for Squeeze+1. It may be unuseful for most users if the 
kernels are too large but if someone uses a (smaller) custom kernel lilo can 
be an alternative and in special cases sometimes the only way to go ...

This gives us all more time to test grub2 and other bootloaders and maybe 
someone finds a solution for Stephens backup problem (which is a good reason 
not to drop lilo now)

Florian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201005240518.27435...@alix.athome

lilo removal in squeeze (or, please test grub2)

[William Pitcock]

Hi,

After some discussion about lilo on #debian-devel in IRC, it has pretty
much been determined that kernel sizes have crossed the line past where
lilo can reliably determine the payload size.

This bug *can* be fixed, but not without a significant rewrite of the
way that lilo's stage2 loader code works.  Given that there is no active
upstream and that the Debian lilo package carries many patches for bug
fixes that are alleviated by standardizing on grub2, this seems like the
best option for Debian.

This means that users should *test grub2 extensively* before Squeeze is
released so that any issues can be resolved now.

As for removal, the following things need to be done:

(1) The release notes need to be updated to reflect that lilo is no
longer a bootloader option;
(2) The debian-installer team needs to remove the lilo-installer udeb;
(3) The ftpmasters need to remove lilo from unstable (which will be done
using the appropriate bug filing once the above steps are made);
(4) Users need to test grub2 now.

William


signature.asc
Description: This is a digitally signed message part