[Sussex] GRUB mystery

[Nico Kadel-Garcia]

On 2/18/07, Steve Dobson <steve at dobson.org> wrote:
>
> Gavin
>
>
> 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.


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.)

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.

3). Let the disk reboot where it is.  In days of old Debian use to install
>    a safe, run anywhere kernel and you picked a better one for your
>    system later.  Now they detect the CPU type during installation and
>    only install the best kernel for that CPU.  You're moving the disk
>    to new hardware, so it is best to have a common CPU kernel that
>    will boot on any x86 hardware.
>
>      # apt-get install linux-image-2.6-486


They don't have a 386 kernel? Not shocking, but perhaps a shade surprising.


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.


> 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.


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 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.)


> 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.

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.

Anyway, have fun and I hope this helps.  If not bring the kiosk system with
> you on Thursday.  I will be bring my system for my talk on "The Joy of X"
> and I happen to have a Debian mirror on it so I may be able to get it
> working.
>
> Steve D.


I tend to work in RedHat/CentOS, but your advice is overall pretty sound.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.lug.org.uk/pipermail/sussex/attachments/20070218/d1348cb1/attachment.htm