[Sussex] GRUB mystery

[Steve Dobson]

Nico

On Sun, Feb 18, 2007 at 09:10:47AM +0000, Nico Kadel-Garcia wrote:
> On 2/18/07, Steve Dobson <steve at dobson.org> wrote:
> >As I know you've installed Linux many times before I won't give details
> >full details, but here how I've done it in the past.
> >
> >1). On your install machine (P3 for you) make sure that the disk is
> >   configured as Master on the primary IDE bus.  This is where it is
> >   going to be when you plug it in the kiosk server, so that is where
> >   it MUST be when installing.
> 
> What? That's not so. I'd done several installations with disks in weird
> locations and transferring them around to others. It can be an adventure to
> do so, because /etc/fstab needs to be set up appropriately, and because the
> grub needs to be set appropriately. It's easier if grub thinks that hd0 is
> the drive with grub on it, and it's consistent between machines. But grub is
> *extremely* flexible, and can be configured to deal with all sorts of
> nuttiness.

Agreed, grub is very powerful and if you are a SysAdmin god then you can do
things other ways.  With all due respect to Gavin that isn't him.  He is a
very capable user, so having the disk as hd0 is the EASIEST way to do this,
not the ONLY way.

> 2). Install as normal except deselect all options in the Task Select
> >   phase.  You are going to be moving the disk so you probably haven't
> >   got the same graphical hardware on the P3 as you have on the kiosk.
> >   This means that you have to be comfortable with the CLI.  You could
> >   pick one of the server options if you want, but I find it easier
> >   to just apt-get install the software I need later.
> 
> That's a very common way to do it. Unfortunately, a lot of GUI installers
> have options that the text based instlalers don't. (Many text based
> installers aren't command line: they're ncurses based, with very simple
> clickable or "move with the Tab key" interfaces. I'm curious what Debian
> actually does these days.)

The new "graphical" Debian installer which comes with etch is basicly the
same as the text (ncurses) one.

> It's also possible to use the graphical installation, and simply ignore its
> presence or even set /etc/inittab to boot in run level 3, to avoid the
> graphical interface until you have a chance to reconfigure it on the
> insalled machine. I've used that technique as well.

For me run levels were a good idea that never got used properly.  Every
flavour of *nix used them differently, so I never play with run levels.
I want my *nix skills to be as platform independent as possible.  I would
love there to be only one packaging system, but one can only dream.

> 4). Are you running the kiosk headless or are you going to plug in a
> >   screen & keyboard (possibly via a KVM)?  If running headless then
> >   it is worth configuring for serial console.  You need a null modem
> >   cable but that's a lot cheaper than using a KVM if you don't already
> >   have one.  I'll not give details here (it will double the size of
> >   this post), but just say if that's what you want and I provide
> >   details, there is only about three files to edit.  But it if you're
> >   going to go serial console you should test it before moving the disk
> >   when you have got a keyboard and screen connected and working.
> 
> 
> Amen. Also remember that most motherboards will revert to their default
> settings after 3 failed reboots, so if you expect the serial console to
> always be available for BIOS resetting, make sure to password it for a
> kiosk, but be prepared to lose that serial console for BIOS settings if some
> idiot starts plugging and unplugging it, or you have a boot problem. This
> wouldn't be so bad except that most BIOS's have a default setting of "If the
> keyboard doesn't seem happy, you have to type F1 to continue". This sucks
> but hard on a system without a keyboard. I know at least one company sells
> little Ps/2 plug-in widgets to satisfy this demand on keyboardless servers.

I never never configured a BIOS to go serial, to be honest I don't do as
little with the BIOS as possible.  About all I do do here is disable error
on no keyboard.

The configuration I was talking about is to set grub & the kernel to use
a serial port as console, and I don't see how any BIOS resets will effect
this.

> >5). Consider configuring a static IP address (edit
> >/etc/network/interfaces,
> >   "man 5 interfaces" for more information).  If you're running DHCP,
> >   which most people are then when you move the disk and boot it on the
> >   kiosk server it will be using different network hardware and therefore
> >   your DHCP server (probably your ADSL router) will see it as a new
> >   computer and give it a new IP address.
> 
> That makes complete sense. What I prefer to do is to register the MAC
> addresses of individual hardware in the DHCP server: this way, the hostname
> is associated with the motherboard or Ethernet port, and remains consistent.

That only works while you're DHCP server is running.  If it dies then you're
servers are going to come up all over the shop.  It also doesn't work if 
the motherboard or NIC dies and you replace.  If you configure the disk
then that disk will always boot to that IP address.

In many ways this is horse for course.  If the server (disk) is not going to
be mobile then I'd set it on the disk.  If you are going to move the system
then the DHCP server is the better way.  My golden rule for SysAdmin is:

   A configuration setting should be done in the lowest number of places
   possible.  ONE being only one that will not cause to some pain later on.

> 6). You may as well install the SSH server so you can remotely log in
> >   to your server.  If you've configured for a static IP this maybe
> >   your easiest way in after a booting on the kiosk server.
> >
> >     # apt-get install openssh-server
> >
> >6). Shutdown, poweroff and then reboot where the disk is to double check
> >   everything works as expected.  Nothing worse than moving to the new
> >   hardware, booting and then finding you've forgotten something and
> >having
> >   to move the disk back again.  And I would recommending plugging the
> >   install system (P3) back together until the kiosk server is up and
> >working.
> 
> Amen. Actually testing systems before expecting them to work elsewhere is
> priceless advice.

And I have it at no cost. :-)

> And if you expect serial port access, you'll need to activate it in
> /etc/inittab. There are lots of guidelines on how to do it, but the key is
> to associate a getty with a specific serial port, and to make sure the
> serial port is working (which may require setserial commands in init
> scripts, or BIOS resettings.)

As I said earlier I have never configured a BIOS for serial.  And you
shouldn't need to put any setserial commands into the init scripts.
getty configures the serial line and you can override it's defaults in
/etc/inittab.

> >7). Now shutdown and move the disk.  If it boots and you can log on great!
> >   If you can't go back to step 3 and try and fix the problem.
> >
> >8). Now install the software you want for the kiosk server.  If you have
> >   another machine on the network and can SSH into the kiosk server and
> >   play.
> 
> By the way, if what you have comfortably available nearby is a Windows box,
> the latest version of Putty is great. It has built-in serial port access to
> replace that ghods-awful built-in Hyperterm, and even directly supports
> SOCKS proxy access for those of us inside restrictive firewalls.

I didn't know PuTTY had serial support.  But then I've never needed it to.
I use minicom on a laptop most of the time for my terminal access.

> 9). Take a look at the content of /proc/cpuinfo.  This will report what
> >   the kernel knows of the CPU it is running on.  There maybe a better
> >   kernel for you.
> 
> Note for others of us: if you have a single CPU kernel, it won't detect
> multiple CPU's or hyperthreaded CPU's hardware this way. You need an SMP
> kernel to detect SMP: I've never actually tried to detect i686 architecture
> from an i386 or i486 kernel, and would be pleased to know that this works.

It does.  As I've never used an SMP system I didn't know about the it
not detecting multiple CPUs.  I've used an i486 kernel and it reported
happily that it was an AMD K7 CPU.

> I tend to work in RedHat/CentOS, but your advice is overall pretty sound.

And as both Gavin and I both use Debian and Gavin got me on of those very
same kiosk servers more sound than you know.  :-)

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.lug.org.uk/pipermail/sussex/attachments/20070218/da703bad/attachment.pgp