Re: 2.0.32, XNvidia, Vtk
Hi,
Please do not blame Herbert for this, since I am responsible
for the kernel-image scripts.
>>"Arto" == Arto Astala <astala@tnso13.tele.nokia.fi> writes:
Arto> I upgraded to a new snapshot of hamm (1997-12-13) and dselect
Arto> naturally marked for upgrade everything I had. I also noticed
Arto> the new kernel 2.0.32 and installed it.
Oooooh.
Arto> Now, this is what I believe what happened.
Arto> When configuring kernel it asks if I want to make boot disk. I
Arto> did want. Then it asks something like "Hmm. You seem to have new
Arto> superformat, want to use it?" and I felt I'm taking risks
Arto> already and I don't want to answer yes to anything this
Arto> dubious. Then it tried to create floppy with old format (and
Arto> with non-existing device as well?) but didn't succeed. There was
Arto> no obvious way to back up to "Hmmm. ..." or otherwise correct
Arto> the situation. ( Later I found a note to the effect that use
Arto> superformat since it obsoletes the older one and is better and
Arto> removes some /fev/fd* entries. I think that *if* superformat is
Arto> safe to use it should be the default. It probably should be the
Arto> default anyway, since the alternative does not work. Why give
Arto> user possibility to give wrong answer when script can detect the
Arto> right one.
The reason that the script asks about using superformat stems
from the days when superformat was newly introduced; and it had
problems. If that has indeed changed, I shall make the script not
ask.
Actually, embarrasingly enough, niether seems to work for me:
__> fdformat /dev/fd0
get geometry parameters: Operation not supported by device
__> superformat /dev/fd0 hd
old capacity=12500
Measuring drive 0's raw capacity
Fatal error while measuring raw capacity
0: 40
1: 04
2: 00
3: 00
4: 00
5: 01
6: 08
__>
I think I may well remove this option of formatting the
floppy. It has aways given me problems.
Arto> I also think that configuration should notice that
Arto> boot disk was not created and e.g. not run lilo or at least ask
Arto> about it. )
What do you want the process to do on errors? abort? It does
tell the installer how to manually create a boot disk. I did not
think aborting the install because of a failure of the boot disk
creation was necessary.
And it does ask you if you want to run lilo.
The process does stop, and inform you about failure to write a
boot floppy. You have to hit return to proceed. It warns about not
being able to reboot the system.
At this point, unless lilo is run, the system is
unbootable. Not running lilo is wrong, IMHO.
Arto> Then configuring kernel asks if I want to use old lilo.config of
Arto> let him create a new one. Silly me, I thought that lilo 20 might
Arto> need something new, let there be new config. A new config there
Arto> was, lilo was run, and the system was unbootable. (Well, maybe I
Arto> fumbled with it a bit afterwards.)
What was the error? was the new lilo.conf incorrect? in what
way?
Arto> ( Aside from possible lilo version problem, since upgrade from
Arto> 19 to 20 was unpacked but not configured at this time, there are
Arto> some other problems.
Hmm ;-(.
Arto> First, I think that the default should be
Arto> to append lines to existing lilo.config since that presumably
Arto> worked in the last boot.
The lilo file created is simple, but it should allow the
system to be upgraded; provided, of course, that lilo is available
;-(. Appending to an existing file is fraught with complications, and
is unlikely to create a valid lilo.conf. If one has a valid
lilo.conf, the dafault is to use it.
Arto> If lilo 20 is installed then no symlinks should be used or
Arto> changed.
Why?
Arto> Maybe that should be the case anyway, since the real
Arto> lilo.config may reside in some other place in multi boot
Arto> machines?
On my multiboot machine, it does not. If people are changing
the Debian conventions, I think they should be capable of dealing
with the consequences.
Arto> Then running lilo should be optional.
It is.
Arto> If no links have been broken then not running lilo does not
Arto> break anything, only new kernel is not yet used.
Links are not broken, they are updated.
Arto> The generated lilo.config file was broken, since my partition,
Arto> /dev/hda5, was a logical one, and lilo gave error for that. Is
Arto> there a way of detecting the partition type? )
I do not know. Anybody?
Arto> That was it. Although the consequences were not so nice, it was
Arto> mostly my mistake, but I would recommend that you do not upgrade
Arto> kernel and lilo without booting in between.
I wholeheartedly agree.
Arto> A couple questions about it all:
Arto> Is it necessary or even possible to coordinate upgrades of
Arto> kernel and bootloader so that their upgrades are not
Arto> interleaved?
This should be a question for the Deity list.
Arto> Is it possible to safely generate bootloader config file or
Arto> would it be better to show message "Will mail more info to you,
Arto> read it before booting" and pause to make sure that user reads
Arto> it. (and mail the info)
The genrated config file was as safe as I could make it. Any
enhancements shall be gratefully accepted. I'll think about extended
partition types and all. (I think the solution is not to blow away a
hand crafted lilo.conf).
Mailing the info should not be required; just look into
/usr/doc/lilo and read the manual there.
I think I'll remove the option of formatting the floppy and
put dire warnings all over the place.
manoj
--
"And we heard him exclaim As he started to roam: `I'm a hologram,
kids, please don't try this at home!'" Bob Violence Howie Chaykin's
little animated 3-dimensional darling, Bob Violence
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: