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.
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
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
>> 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
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://lis
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-g
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 wo
]] 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 h
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
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.
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
>
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
t; /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) t
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/
; 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
ced
> /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
ne 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.
Ca
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.
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
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 remov
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
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
ntages 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.
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 o
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 vend
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
emself, 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.debi
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.
ad 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
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&
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 cont
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 o
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,
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
t; 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
* 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
> &
e 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 r
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
>> lil
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 wit
[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 som
oot/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
>
re, 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 newe
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. Update
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 "dis
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
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
> partiti
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 a
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 syslinu
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 w
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 her
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
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 purpo
e 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
>
>
>
> 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
t; 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 bee
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 b
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-fro
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 p
gt; 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. Unti
xcuse 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 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 extlin
; 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
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 th
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 ex
, 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?
ould 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 woul
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 wel
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 up
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
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 wo
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
bution 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 repo
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
>>
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
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 extli
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 m
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 wa
hould *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 who
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.
gr
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
> experien
[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 na
d 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
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 pas
gt;>> 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.
>
&
ce 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
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
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 Ke
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 argument
t; 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 sq
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 wi
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 understa
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.
Tha
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 "unsubsc
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 *
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).
>
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 | n
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
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
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 probl
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
1 - 100 of 332 matches
Mail list logo
