RE: lilo.conf
Ok, lets answer these in order:
True. I missed that on debian-devel. I have been pointed to the message.
I apologize.
No, /etc/lilo.conf.old does NOT have a backup. It has a copy of a
configuration I was using months ago. More than likely I'd made a copy of
my configuration for some reason under that name, although I don't remember
doing it. I do recognize the configuration in that file as being an old
one, however. Does yours not overwrite a .old file if it finds one? Why
was a backup necessary in the first place? I wasn't asked if I wanted my
configuration overwritten. Why didn't it auto-run the debconf front-end,
for that matter, which would have at least been an indication that, hey,
you'd better save that file!
Assuming that everyone uses kernel-package is stupid. Plain and simple.
Not bothering to look at the running configuration to make SURE is even
worse. If you're going to throw the "you're running unstable" shill at me,
I'm going to throw right back at you the fact that people running unstable
are likely to compile their own kernels. And horrors, they might actually
download a tarball and do it that way. Why would I want a deb of my kernel?
I'm not going to run it anywhere else, so what good is portability?
Certainly I do. That's why I run unstable. But unstable doesn't mean that
the maintainer makes a deliberate attempt to lunch your box. "Sorry for the
data loss?" (quote from postinst) You KNEW this was going to do this.
As for filing bug reports, I note that several people already have on these
issues. Should I add another? Would it have helped?
You haven't MADE a request for my lilo.conf. Here it is:
boot=/dev/hda
root=/dev/hda3
install=/boot/boot.b
map=/boot/map
vga=normal
lba32
# restricted
password="password"
default="linux"
read-only
# delay=20
prompt
timeout=100
image=/boot/vmlinuz
label=linux
image=/boot/vmlinuz.old
label=linux.old
image=/boot/vmlinuz.safe
label=linux.safe
image=/boot/vmlinuz.test11
label=linux.test11
image=/boot/vmlinuz.test12
label=linux.test12
image=/boot/vmlinuz.prerel
label=linux.prerel
I'm not planning on being a developer. I *am* planning on keeping my boxen
running.
-----
Marc Wilson
mwilson@moonkingdom.net
mwilson@cts.com
http://www.moonkingdom.net/mwilson
-----Original Message-----
From: Russell Coker [mailto:russell@coker.com.au]
Sent: Friday, January 05, 2001 8:50 PM
To: Marc Wilson; debian-user@lists.debian.org
Subject: Re: lilo.conf
On Saturday 06 January 2001 15:12, Marc Wilson wrote:
> Why the hell are you doing anything at ALL? You're not the maintainer,
The previous maintainer of lilo invited me to take over.
> your preinst/postinst is screwed, you trash a working configuration with
> unwarranted assumptions on your own part and don't even save a backup of
> the original configuration. I had SIX working kernel images defined in my
/etc/lilo.conf.old has a backup.
> configuration, all in /boot. Now I have NONE, because you removed their
> configurations, and replaced them with configurations pointing to the root
> of the filesystem where, needless to say, there are no kernel images.
If you had symbolic links installed (as all kernel packages produced by the
kernel-package package will have) then it will work.
> You removed my PASSWORD definitions. So much for security, eh? You
> removed my 'lba32' setting. And you didn't even mention that you were
> going to do it before it happened. You, sir, are a menace.
Do you have any understanding of what the word "unstable" means?
If you install a package from unstable then you face a risk that it won't
work correctly. The proceedure that you should follow is to file a bug
report describing how it didn't work as you expected. If you are unable to
file bug reports and have a risk of things not working as designed then you
should stick to potato.
Also you have ignored my request for a copy of your lilo.conf.
NB I expect passwords to be removed before people upload their lilo.conf
files - I didn't mention this before because it's stating the obvious, but
it
seems that some things which are obvious to the rest of us aren't obvious to
you.
> Your comments in postinst are insulting and intentionally inflammatory.
> I'd hope that you can at least make the claim that English isn't your
first
> language, because if it is, you've really got problems.
Actually those parts weren't written by me, they were written by someone who
(from their email address) appears to be Hungarian. I have already started
correcting the writing.
> Whyinhell are you making NMU's on critical system files when you don't
know
> what you're doing?
I had put pre-release versions online and informed everyone on debian-devel
of what I was doing. Anyone who was interested was free to test them and
comment. I also announced the pre-release versions on the ReiserFS list
(the
new version solves the ReiserFS problems).
I knew that this had potential to cause trouble. This is why I requested
testers and input from debian-devel several times.
NB You don't have to be a Debian developer to subscribe to debian-devel.
If
you run the unstable distribution then you should probably be subscribed.
Now if you have any positive suggestions then I would like to hear them.
Suggesting that we keep an old lilo that can't correctly handle software
RAID
or ReiserFS isn't an option. Suggesting that I don't maintain lilo is not
an
option because the only other person who has expressed interest is the
person
who wrote the debconf text you greatly object to.
If you wish to become a Debian developer and want to take over lilo then
this
could be an option. However I don't think it would be a good first package
so you would be better off maintaining something else first. Let me know if
you'd like to persue this option.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Reply to: