In <Pine.LNX.4.10.10007251900500.15559-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
JS> On Tue, 25 Jul 2000, Khimenko Victor wrote:
>> In <Pine.LNX.4.10.10007251640210.15492-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
>> JS> On Tue, 25 Jul 2000, Khimenko Victor wrote:
>>
>> >> For example our server do not have floppy drive at all. It does not have
>> >> kerboard or attached monitor as well.
>>
>> JS> How do you handle situations where you need to take it down to single-user
>> JS> mode, no network?
>>
>> Why you think it's ever needed ?
JS> You do all your system maintenance with the system online, serving users?!
Yes, of course. Why not ? And if I really want to close system there are no
need to go in single-user mode.
>> >> And it's quite possible that vendor's image will be unable to cope
>> >> with our Ethernet cards with 17,20 & 21 IRQ and will be unable to find
>> >> IDE with 22 IRQ so any drive attached to that IDE will be out of reach
>> >> for update program...
>>
>> JS> Can't Linux find your IDE adapter??
>>
>> Not if it's compiled without APIC support (in 2.2.x it's coupled with SMP
>> support, in 2.4.x it's separate option AFAIK).
JS> Assume it will be available in the bootdisk.
It WILL NOT. I can not boot DOS or Windows there (only specially tuned
version of Windows NT from Dell can work there) - why you think boot disk
from some manufacturer will be more compatible with different systems then
Windows ?
JS> If this is a problem, they could allow you to add "noapic" to the
JS> command line, or supply two kernel images. Not a huge problem.
It IS HUGE problem. There are millions of systems. There are A LOT OF
different ide chipsets (take look on kernel sources sometime!) with
different quirks and so on. Do you REALLY think HDD manufacturers will
spend A LOT OF energy, time (and money :-) to make sure boot disk is
compatible with all such systems ? Gosh.
>> >> > That way, they can't blame it on your anti-virus daemon, your NIC,
>> >> > the kernel version you're running, etc.
>> >>
>> >> Without my NIC I'll be unable to do ANYTHING with my system, sorry.
>>
>> JS> You're pretty much stuffed when your NIC firmware upgrade fails, then.
>>
>> Correct. But I have THREE NIC's there. So I can access system if ANY of them
>> fails (even more: if one NIC is fryed backup will be activated automagically).
JS> OK - supposing it's the system BIOS you just fried remotely?
There are no bullet-proof solution. Yes, in this case I'll get some
downtime. That's EMERGENCY case though. Firmware upgrade is NOT emergency.
>> JS> You have bigger problems than not getting a nice point&drool interface for
>> JS> low-level hardware modifications.
>>
>> Perhaps. Usually if one NIC is fryed I can shedure replacement procedure for
>> month or so later - I have more then enough time for that.
JS> IF it's a redundant component like that. Some aren't - the system BIOS,
JS> perhaps.
And now you want me to NOT upgrade redundant components at all (as well as
non-redundant components) ?? Thnx, but no, thnx.
>> P.S. NIC can be fried by static electricity, not only from cracker. That's
>> why this backup system was invented in first place.
JS> You don't seem to have any procedure in place for recovering if/when the
JS> upgrade fails. If you can't get the NICs online, or boot into Linux, what
JS> are you going to do?
"Boot to linux" ? Gosh. Who said I will SHUT DOWN linux first ? Of course I
want to perform the whole procedure without shutting linux down (and with
active users). This is NORMAL procedure for LOTS AND LOTS of "big" systems
out there. Just since it's "PC style" (or rather Microsoft style :-) : you
want to change settings - you need to reboot system does not mean it's NORMAL.
It's NOT normal. Quite an opposite: system SHOULD WORK. The less tasks need
reboot/shutdown the better.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:19 EST