Re: Requesting to take over maintenance of lilo

[Joshua Hudson]

So I updated the bug report, and have requested maintenance of lilo
from Joachim. In any case, I'll be on vacation next week.

If Joachim says he wants lilo upstream I'd be glad to let him have it,
but I don't think he does.

Re: Requesting to take over maintenance of lilo

[Paul Wise]

On Sat, 2019-12-21 at 08:42 -0800, Joshua Hudson wrote:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861053

I think it would be appropriate to add some more information to this
bug to make it easier to understand and take action on.

These bits of information would help:

The output of both these two commands:

sudo /usr/sbin/grub-mkconfig -o /root/grub.cfg
sudo sh -x /usr/sbin/grub-mkconfig -o /root/grub.cfg

The generated grub config file.

> I have less resources than Joachim Wiedorn , but it looks like
> maintaining lilo is very little work. The upstream source (same
> person) had its last release in 2015.

Since Joachim is also the upstream maintainer of lilo, it would be a
good idea for someone to take over maintaining it upstream too if it is
to continue being available for use in Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Requesting to take over maintenance of lilo

[Bernd Zeimetz]

Hi,

> I knocked out the sanity check preventing it from being installed on
> my RAID array. If I did it for distribution I'd have it actually check
> if the RAID array is RAID 1 (as no other will function).

can you explain why this is necessary? Do you have a raid over the whole
device (like /dev/sda + /dev/sdb)?


If so, I'd assume you can talk grub into doing what you need by
modifying /etc/grub.d/10_linux

Does that help?


Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Requesting to take over maintenance of lilo

[Joshua Hudson]

>> I have some hardware that update-grub just doesn't understand
>
> Please report a bug about it if you haven't done that yet.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861053

>> a locally modified lilo that has support for it.
>
>Is the modification likely to be break lilo for other folks or is it
>suitable for distribution in the Debian package?

I knocked out the sanity check preventing it from being installed on
my RAID array. If I did it for distribution I'd have it actually check
if the RAID array is RAID 1 (as no other will function).

I have less resources than Joachim Wiedorn , but it looks like
maintaining lilo is very little work. The upstream source (same
person) had its last release in 2015.

On 12/21/19, Paul Wise  wrote:
> On Sat, Dec 21, 2019 at 5:21 AM Joshua Hudson wrote:
>
>> Basically, the existing package maintainer doesn't want to maintain
>> lilo anymore, says "will disappear by end of 2020"
>
> You might want to read through the thread about this if you haven't yet:
>
> https://lists.debian.org/msgid-search/2019193422.2852b...@jupiter.home
>
>> I have some hardware that update-grub just doesn't understand
>
> Please report a bug about it if you haven't done that yet.
>
>> a locally modified lilo that has support for it.
>
> Is the modification likely to be break lilo for other folks or is it
> suitable for distribution in the Debian package?
>
>> I want to take over lilo maitenance so that apt-get update integration
>> continues to work.
>
> Please contact the current lilo maintainer about this and also read
> through these documents:
>
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package
> https://mentors.debian.net/intro-maintainers
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Re: Requesting to take over maintenance of lilo

[Paul Wise]

On Sat, Dec 21, 2019 at 5:21 AM Joshua Hudson wrote:

> Basically, the existing package maintainer doesn't want to maintain
> lilo anymore, says "will disappear by end of 2020"

You might want to read through the thread about this if you haven't yet:

https://lists.debian.org/msgid-search/2019193422.2852b...@jupiter.home

> I have some hardware that update-grub just doesn't understand

Please report a bug about it if you haven't done that yet.

> a locally modified lilo that has support for it.

Is the modification likely to be break lilo for other folks or is it
suitable for distribution in the Debian package?

> I want to take over lilo maitenance so that apt-get update integration
> continues to work.

Please contact the current lilo maintainer about this and also read
through these documents:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package
https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Requesting to take over maintenance of lilo

[Joshua Hudson]

Basically, the existing package maintainer doesn't want to maintain
lilo anymore, says "will disappear by end of 2020"

But I have some hardware that update-grub just doesn't understand and
a locally modified lilo that has support for it. Multiple attempts at
fixing update-grub have resulted in merge-disaster every single update
to the grub package and it's just not worth trying that anymore.

I want to take over lilo maitenance so that apt-get update integration
continues to work.

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 upstream development

[Tollef Fog Heen]

]] Bjørn Mork 

| Joachim Wiedorn  writes:
| 
| > After the long silence about the popular bootloader LILO the development
| > was started again.
| >
| > The new Homepage can be found here:
| > http://lilo.alioth.debian.org/
| >
| > For the development of the bootloader I have started an Alioth project
| > with Git repository and Mailinglist:
| > http://alioth.debian.org/projects/lilo/
| 
| Nice.  And thus I learned about bug #573736

Thanks for bringing this to our attention.

| $ git clone https://alioth.debian.org/anonscm/git/lilo/lilo.git
| Initialized empty Git repository in /usr/local/src/git/lilo/.git/
| error: server certificate verification failed. CAfile: 
/etc/ssl/certs/ca-certificates.crt while accessing 
https://alioth.debian.org/anonscm/git/lilo/lilo.git/info/refs
| 
| fatal: HTTP request failed
| 
| Maybe someone could fix the certificate chain sorting on alioth?

I've fixed it now, sorry for the long delay.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87sk2h9gww@qurzaw.linpro.no

Re: New LILO upstream version 23.0

[Joachim Wiedorn]

Hello,

the first version of the new LILO is released as version 23.0.
The most patches (especially from Debian/OpenSuse/Fedora packages)
are included, which fixes some problems.

The links can be found in the mail below.

Have a nice day,
Joachim (Germany)




Joachim Wiedorn  wrote on 2010-06-19 11:51:

> Hello,
> 
> 
> After the long silence about the popular bootloader LILO the development
> was started again.
> 
> The new Homepage can be found here:
> http://lilo.alioth.debian.org/
> 
> For the development of the bootloader I have started an Alioth project
> with Git repository and Mailinglist:
> http://alioth.debian.org/projects/lilo/
> 
> The next version is in work: LILO 23.0 
> 
> 
> Have a nice day,
> 
> Joachim (Germany)



signature.asc
Description: PGP signature

Re: New LILO upstream development

[Patryk Cisek]

On Sat, Jun 19, 2010 at 12:39:53PM +0200, Bjørn Mork wrote:
> Maybe someone could fix the certificate chain sorting on alioth?
In the meantime you can either:
$ GIT_SSL_NO_VERIFY=1 git clone
https://alioth.debian.org/anonscm/git/lilo/lilo.git

or:
$ git clone git://git.debian.org/lilo/lilo.git

-- 
Patryk Cisek


-- 
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/20100619125706.ga2...@prezu.one.pl

Re: New LILO upstream development

[Bjørn Mork]

Joachim Wiedorn  writes:

> After the long silence about the popular bootloader LILO the development
> was started again.
>
> The new Homepage can be found here:
> http://lilo.alioth.debian.org/
>
> For the development of the bootloader I have started an Alioth project
> with Git repository and Mailinglist:
> http://alioth.debian.org/projects/lilo/

Nice.  And thus I learned about bug #573736

$ git clone https://alioth.debian.org/anonscm/git/lilo/lilo.git
Initialized empty Git repository in /usr/local/src/git/lilo/.git/
error: server certificate verification failed. CAfile: 
/etc/ssl/certs/ca-certificates.crt while accessing 
https://alioth.debian.org/anonscm/git/lilo/lilo.git/info/refs

fatal: HTTP request failed

Maybe someone could fix the certificate chain sorting on alioth?



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/87bpb7e26e@nemi.mork.no

New LILO upstream development

[Joachim Wiedorn]

Hello,


After the long silence about the popular bootloader LILO the development
was started again.

The new Homepage can be found here:
http://lilo.alioth.debian.org/

For the development of the bootloader I have started an Alioth project
with Git repository and Mailinglist:
http://alioth.debian.org/projects/lilo/

The next version is in work: LILO 23.0 


Have a nice day,

Joachim (Germany)


signature.asc
Description: PGP signature

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

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)

[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 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)

[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)

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

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: Re (2): lilo removal in squeeze / new lilo upstream

[sean finney]

hi,

this should all be prefaced with the disclaimer that i'm not actually
using lilo at the moment, but i thought i'd throw in something due to
some of the comments/posturing that i've been seeing here.

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
~ 


signature.asc
Description: Digital signature

Re: Re (2): lilo removal in squeeze / new lilo upstream

[Stephen Powell]

On: Sun, 06 Jun 2010 17:44:05 -0400 (EDT), William Pitcock wrote:
> "Joachim Wiedorn"  wrote:
>> I see that more people than thought still want to have or need LiLO.
>> Now I have decided to start and reanimate the upstream development.
>> Everyone is invited to join in this development.  I'm working on LiLO
>> version 23.  Shortly with more informations ...
> 
> Have fun.  When you have a release that actually has merit, it can be
> reconsidered for inclusion in Debian.

What is your definition of "merit", William?  And why does
the current release not have it?
> 
> In the meantime, the original plan continues.

The original plan was based on false assumptions.  Why would you
continue with a plan based on false assumptions?  We now have a
release of lilo with (a) an active upstream maintainer, and (b) no
release critical bugs.  If you simply don't want to be a Debian
package maintainer for lilo anymore, why not ask for volunteers to
take over for you?

-- 
  .''`. 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/1545549194.342558.1275871054568.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze / new lilo upstream

[William Pitcock]

Hi,

- "Joachim Wiedorn"  wrote:

> Russell Coker  wrote on 2010-06-05 22:30:
> 
> > On Wed, 26 May 2010, 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.
> > 
> > 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.
>  
> I see that more people than thought still want to have or need LiLO.
> Now 
> I have decided to start and reanimate the upstream development.
> Everyone
> is invited to join in this development. I'm working on LiLO version
> 23.
> 
> Shortly with more informations ...

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.

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/28336861.3901275860645697.javamail.r...@ifrit.dereferenced.org

Re: Re (2): lilo removal in squeeze / new lilo upstream

[Stephen Powell]

On Sun, 06 Jun 2010 09:39:59 -0400 (EDT), Joachim Wiedorn wrote:
>  
> I see that more people than thought still want to have or need LiLO. Now 
> I have decided to start and reanimate the upstream development. Everyone
> is invited to join in this development. I'm working on LiLO version 23.
> 
> Shortly with more informations ...
> 
> Fondest regards,
>  Joachim Wiedorn

That's great news, Joachim!  If it weren't for my complete ignorance of
x86 assembly language, I might have been tempted to try it myself.
But perhaps I may be able to help out in some way.  We lilo users
are very grateful to you for your willingness to take over.

By the way, did anyone ever find out what happened to John Coffman?

-- 
  .''`. 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/1978551454.33.1275845120737.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze / new lilo upstream

[Joachim Wiedorn]

Russell Coker  wrote on 2010-06-05 22:30:

> On Wed, 26 May 2010, 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.
> 
> 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.
 
I see that more people than thought still want to have or need LiLO. Now 
I have decided to start and reanimate the upstream development. Everyone
is invited to join in this development. I'm working on LiLO version 23.

Shortly with more informations ...

Fondest regards,
 Joachim Wiedorn



signature.asc
Description: PGP signature

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

[Russell Coker]

On Wed, 26 May 2010, 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.

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")

[Alexey Salmin]

On Mon, May 31, 2010 at 10:25 PM, Marc Haber
 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")

[Marc Haber]

On Mon, 31 May 2010 15:56:38 +0200, Josip Rodin 
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")

[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: [SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel

[Frans Pop]

reopen 505609 
reassign 505609 linux-2.6
affects 505609 lilo
thanks

Stephen Powell wrote:
> The real question is, "Why didn't the map installer get run during
> the kernel upgrade?"
[...]
> So is this a bug in the kernel maintainer scripts?  Or is it a feature?
> I don't know.  I'll leave that up to the kernel maintainers to decide.

Reopening and reassigning to the kernel team.


-- 
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/201005302059.16911.elen...@planet.nl

[SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel

[Stephen Powell]

This is not a lilo bug.  The problem is that lilo's map installer
did not get run during the kernel upgrade process.  The fact that
the user was able to boot his old de-installed kernel is proof of
this.  The /boot/map file still pointed to the blocks in the file
system which formerly contained the old kernel and its initial RAM
file system image.  And since, fortunately, those blocks had not yet
been reused, the data was still there.  Modules which were
loaded from the initial RAM file system image loaded OK.  But once
the switch was made from the initial RAM file system to the
permanent root file system, further module loads could not be done,
since the modules had been erased.  When the user manually ran lilo's
map installer at the command line, the problem disappeared.

The real question is, "Why didn't the map installer get run during
the kernel upgrade?"  There is not sufficient data in the bug log
to determine the answer to that question, but I have observed that
"do_bootloader = yes" in /etc/kernel-img.conf no longer causes
lilo to be run when a new kernel is installed.  I believe that this
change in behavior was caused by changes to the kernel maintainer
scripts made around the time of the switch to grub version 1 as
the default boot loader.  "do_bootloader = yes" in /etc/kernel-img.conf
still causes zipl to be run on the s390 port, a port that neither
version of grub supports.  "do_bootloader = yes" should still be
specified in /etc/kernel-img.conf, however, so that "update-initramfs -u"
will cause lilo's map installer to be run when an initial RAM file
system is updated (but not when it is initially created).

So is this a bug in the kernel maintainer scripts?  Or is it a feature?
I don't know.  I'll leave that up to the kernel maintainers to decide.
A full discussion of how to make sure that lilo's map installer gets
run during the installation of a new kernel, taking into account all
types of kernels (official stock Debian kernels, custom kernels created
by make-kpkg, custom kernels created by "make deb-pkg", etc., is beyond
the scope of this bug log.  Interested readers may wish to look at my
web page on kernel building, particularly step 10, for further
information.  http://www.wowway.com/~zlinuxman/Kernel.htm  The instructions
for "customizing the Lenny environment" will work in Squeeze or Sid also,
provided that you use only official stock Debian kernels.  If you use
custom kernels in Squeeze or later, you *must* use hook scripts to ensure
that any post-installation activities, such as the creation of an initial
RAM file system, updating symlinks, or running a boot loader, take place.

-- 
  .''`. 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/2000712474.159302.1275230137351.javamail.r...@md01.wow.synacor.com

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")

[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")

[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: 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")

[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")

[Marc Haber]

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

[Marc Haber]

On Sun, 23 May 2010 16:26:48 +0200, Stefano Zacchiroli
 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: 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")

[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")

[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")

[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")

[Praveen A]

2010/5/26 Joachim Wiedorn :
> Harald Braumann  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
-- 
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
 I know my rights; I want my phone call!
 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

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")

[Ferenc Wagner]

Samuel Thibault  writes:

> Paul Vojta, le Thu 27 May 2010 00:47:14 +, a écrit :
>> In article ,
>> Ferenc Wagner   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")

[Martin Buck]

In gmane.linux.debian.devel.general Stephen Powell  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")

[Samuel Thibault]

Paul Vojta, le Thu 27 May 2010 00:47:14 +, a écrit :
> In article ,
> Ferenc Wagner   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")

[Paul Vojta]

In article ,
Ferenc Wagner   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")

[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: 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

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

[Bjørn Mork]

Daniel Baumann  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: 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")

[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: 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 
>>> On Tue, May 25, 2010 at 8:42 AM, Stephen Powell
>wrote:
>>>> 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")

[Joachim Wiedorn]

Harald Braumann  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  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 (3): lilo removal in squeeze (or, "please test grub2")

[peasthope]

From:   Stephen Powell 
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: 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: Re (2): lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Tue, 25 May 2010 11:51:11 -0400 (EDT), Mark 
> On Tue, May 25, 2010 at 8:42 AM, Stephen Powell wrote:
>> 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")

[Mark]

On Tue, May 25, 2010 at 8:42 AM, Stephen Powell wrote:

> 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 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: lilo removal in squeeze (or, "please test grub2")

[Ferenc Wagner]

Stephen Powell  writes:

> Ferenc Wagner wrote:
>
>> Stephen Powell  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: 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  /) 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")

[Stephen Powell]

On Tue, 25 May 2010 07:08:20 -0400 (EDT), Mihamina Rakotomandimby wrote:
> William Pitcock  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")

[Stephen Powell]

Ferenc Wagner wrote:
> Stephen Powell  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")

[Steffen Möller]

Hello,

On 05/23/2010 03:44 PM, Julien BLACHE wrote:
> Darren Salt  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")

[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")

[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")

[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")

[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")

[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-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")

[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")

[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")

[Ferenc Wagner]

Stephen Powell  writes:

> On Mon, 24 May 2010 13:38:55 -0400 (EDT), Ferenc Wagner wrote:
>> Stephen Powell  writes:
>>> On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote:
>>>> Stephen Powell  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")

[Stephen Powell]

On Mon, 24 May 2010 13:38:55 -0400 (EDT), Ferenc Wagner wrote:
> Stephen Powell  writes:
>> On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote:
>>> Stephen Powell  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")

[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: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")

[Ferenc Wagner]

Stephen Powell  writes:

> On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote:
>
>> Stephen Powell  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")

[Ferenc Wagner]

Stephen Powell  writes:

> On Mon, 24 May 2010 05:36:32 -0400 (EDT), Ferenc Wagner wrote:
>> Kurt Roeckx  wrote:
>>> On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote:
>>>> William Pitcock  (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")

[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")

[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")

[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")

[Stephen Powell]

On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote:
> Stephen Powell  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")

[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:36:32 -0400 (EDT), Ferenc Wagner wrote:
> Kurt Roeckx  wrote:
>> On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote:
>>> William Pitcock  (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")

[Ferenc Wagner]

Stephen Powell  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")

[Ferenc Wagner]

Kurt Roeckx  writes:

> On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote:
>> William Pitcock  (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")

[Philipp Kern]

On 2010-05-24, Florian Zagler  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")

[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")

[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

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")

[Stephen Powell]

On Sun, 23 May 2010 16:11:30 -0400 (EDT), William Pitcock wrote:
> "Stephen Powell"  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")

[Stanislav Maslovski]

On Mon, May 24, 2010 at 12:11:30AM +0400, William Pitcock wrote:
> Hi,
> 
> - "Stephen Powell"  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")

[William Pitcock]

Hi,

- "Stephen Powell"  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")

[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")

[Julien BLACHE]

Darren Salt  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 -  
 
 Public key available on  - 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")

[Darren Salt]

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

> Darren Salt  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")

[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")

[Marc Haber]

On Sat, 22 May 2010 22:39:52 -0500, William Pitcock
 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")

[Julien BLACHE]

Darren Salt  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 -  
 
 Public key available on  - 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")

[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