[Sussex] wysiwyg html editor

[Nico Kadel-Garcia]

Paul Tansom wrote:
> ** Nico Kadel-Garcia <nkadel at gmail.com> [2007-05-04 18:25]:
>   
>> Paul Tansom wrote:
>>     
>>> ** Steve 'Dobbo' Dobson <steve at dobson.org> [2007-05-04 15:50]:
>>>       
> <<snip>>
>   
>> I've some experience with grub and LILO. What's the problem?
>>     
>
> The requirement is quite simple, but read as I might I cannot get my
> head around grub, and not having a spare machine to experiment on it
> isn't too easy to learn by trial and error!
>
> I have a RAID 1 mirror and unfortunately a drive died (que Queen music,
> dun, dun, dun, another Maxtor bites the dust). I've rebuilt and am
> running again, but having swapped the drive with a larger one I now want
> to swap the remaining one of the pair. Unfortunately this one has the
> boot information on and whereas with lilo I could simply boot of a boot
> CD and write it to the other drive, the Grub documentation I've read is
> about as clear as the muck a real grub would crawl around in. In fact
> most of the GNU tools I've read up on have had dire documentation -
> fetchmail is another example.
>   
Yeah, it's a long-standing problem for many tools. I highly recommend 
the light reading of http://www.catb.org/~esr/writings/cups-horror.html, 
partly because he quoted me, but partly because he describes and 
analyzes this sort of problem and why it happens.
> In the longer term I'd like to have them both bootable so there is a hot
> fallback onto the other one, although this has the added complication
> that they are both on a PCI ATA card, so that may be scuppered as I
> don't think I can persuade it to fallback onto the other drive, but at
> least I can swap the caddies or reconfigure the cards BIOS to boot from
> the second drive.
>   
OK. While we all use boot loaders, I'll try to walk through it for you 
and iinterested parties.

All machine BIOS's need to know enough about a system to find the kernel 
and configuration of drivers needed to actually run the hardware at boot 
time. There are all sorts of weird games played to get this information, 
rooted in history and design limitations and a lot of sausage making. 
(The squeamish should not look inside the wrappers.)

The BIOS looks in certain places in certain orders in order to find the 
first indication of where the kernel is hidden on the disk: this 
indication is called the Master Boot Record, or MBR. It's traditionally 
placed at the very beginning of the first hard drive detected by the 
BIOS, but people can play lots of games and put it *LOTS* of places: 
they can load it over a network, put it on a floppy or a floppy-image 
stashed on a CD drive (which is how CD's boot), on a floppy image on a 
USB drive (which use the same trick as CD's) or even load it over a 
network (via PXE).

The Linux boot process applies additional leverage that is just plain 
odd, to get around old hardware limitations. Separate /boot partitions 
that live on a simple file system that the BIOS itself can read to find 
the kernel (vmlinuz) in an oddly compressed format, and the modules 
necessary to load drivers for the other partitons with the rest of the 
operating system in a weird compressed format (initrd) in order make the 
whole mess small enough to fit on a floppy are just parts of the fun and 
games.

Now, LILO stores all its information in that little MBR. But MBR's are 
*tiny*, and this seriously limits what LILO can do, and to add new 
options to a LILO configuration you have to run the "lilo" command and 
overwrite your old MBR. The MBR is only a few hundred bytes.

Grub applies some leverage. It stores only enough hooks in the boot 
loader to get grub itself loaded up. This gives you huge capability to 
set and edit and unset options at boot time itself, and lets you edit 
grub configurations without having to reset your boot loader. But it 
also exposes a lot of the complexity to allow reconfiguration and 
manipulation of it, and this can get *very* confusing.

So, what you need to do to get grub, or LILO onto both hard drives, is 
to be extremely consistent about your setups, and to always mirror your 
boot loaders as well as your operating system. ATA drives make this 
somewhat easier to manage, since they don't relabel your drives from 
/dev/sdb to /dev/sda if the old /dev/sda drive is absent, but some BIOS 
configurations *do* swap /dev/hda and /dev/hdb if you boot from the 
second drive. That's a nasty problem!

So what I would do in your situation is take a rescue or installation 
CD, put your drives in the way you want, and take advantage of the 
available network connections to send us a copy of your 
/boot/grub/grub.conf or your /etc/lilo.conf, and run "/sbin/fdisk -l" 
to  look around for what your system sees. Then power off, swap the 
drives or remove the drives, and look around with the rescue CD again, 
to see if any renumbering happened. Then

>
> Probably not, and I'm not exactly as old as that implies, but in IT
> terms it seems a lifetime ago - though not as far back as my collection
> of Acorn, Commodore, Sinclair, Amstrad, etc. machines :)
>   
Ohh, goodness. I was playing with electronics, not systems in those 
days, but yeah.

> ...or if you're referring to OS/2, that was my OS of choice on the PC
> before Linux and I supported it for some time. In fact if it wasn't for
> OS/2 I may well have never taken the step into professional IT work, and
> certainly would never have purchased a PC. OS/2 made the system bearable
> after being used to an Amiga. I could then have Windows available for
> when I needed to use it without having a wasted piece of hardware -
> after all it was of no use whatsoever for serious use, it was merely a
> pretty toy that didn't really do anything (or at least that's how I saw
> it at the time!)
BSD (actual BSD!) was my early professional Kool-Aid. I remember getting 
yelled at for emailing myself the source code for Emacs over our modem 
link....