Re: Getting rid of old, obsolete kernels

From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: 07/23/05 

Date: Sat, 23 Jul 2005 13:42:37 -0400

"Michael Heiming" <michael+USENET@www.heiming.de> wrote in message
news:bet9r2-oon.ln1@news.heiming.de...

> Don't use /boot since ages anymore, it's long since the 1023
> cylinder limit has been lifted, so it's obsolete and only really
> useful if you have multiple distro and want to share /boot.
> Initial reason was some brain-dead SCSI controller which didn't
> allow for enough partitions to setup via kickstart.

It also applied, as I remember, to quite a few old IDE controllers. The 1023
limit gets you 8 Gigabytes, and back when disks were smaller it didn't
matter as much. But I gave up on using separate /boot some time ago myself,
for my systems.

> Exactly this is the point I like about lilo, 'lilo -v' tells me
> at a glance if there's a problem, so I can correct it in a second
> while logged in comfortably through ssh anyway. Grub wouldn't
> tell me so the system might not reboot probably, so it's needed
> to login via terminal server, enter user/password, hard reset the
> box and get to the boot prompt to fix things. The "Lilo" method
> is just magnitudes faster.;)

I see your point, but it's just too darned easy in my experience to screw up
LILO and make the system unrecoverable without a boot disk. I've actually
had bad kernels unable to re-install the MBR. That is *BAD*........

>> ability to do "lilo -D kernel1" to override the default setting in
>> lilo.conf
>> and select my old kernel as default, then "lilo -R kernel2" to set the
>> new
>> kernel for one boot only, then reboot to have the new kernel boot the
>> next
>> time and the next time only. This is very, very helpful for installing
>> new
>> kernels on machines in data centers where the staff are only willing to
>> touch the reset button, not actually connect a keyboard and monitor even
>> if
>> their contract calls for it.
>
> Server should have a complete serial BIOS redirection, with
> additional cold reset and alike features. To allow 100% headless
> remote operation.

Oh, brother, don't get me going. OK, I'll get going anyway.

You need a remote serial concentrator to do this effectively. Remote serial
concentrators for a rack of 20 servers adds up to some cash, some rack
space, and some support issues, unless you buy enough to chain them together
and cross link them. That's roughly $1000/8 ports, plus the externally
accessible address space. There are few 16-port ones, but they're even more
expensive. And none of them supported encrypted access out of the box, so
you had to put some sort of reliable encrypted access to the network up
front to talk to the serial concentrator in an international data center.
Some of the higher end ones support SSH now, but most just support telnet.
Let's type the BIOS and root passwords to the machines in our remote data
centers, over an uncrypted telnet session! How wise!

Then you have to program all the BIOS's of all the computers. This is
expensive, up front, hands-on work, requiring keyboard/video in the first
place to reset it, and many BIOS's simply do this wrong or the motherboards
have nasty IRQ conflicts with other devices, such as add-on network devices.

Then there's the fact that with almost all commercial BIOS's, the default
does not support console redirection. Couple that with the fact that most
BIOS's revert to default if the system fails to successfully boot 3 times in
a row, and you have a solution that sounds good in theory, but when it fails
it fails *HARD* and will drive you nuts implementing robustly.

>
> Even if some older systems don't have that, it's pretty easy to
> configure lilo/(grub) so you can have a serial r/w connection
> starting from the lilo prompt, allowing to control the boot
> prompt remotely. Works nice even with 9600 baud.;)
>
> If you don't have a terminal server, just use some linux box,
> there are USB --> serial multiplexer for a few bucks that will
> make a nice terminal server.
>
> [..]
>
> --
> Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
> mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
> #bofh excuse 194: We only support a 1200 bps connection.