Re: GRUB OR LILO?
On Mon, 04 Jul 2011 15:50:10 -0400 (EDT), Nico Kadel-Garcia wrote:
> On Mon, Jul 4, 2011 at 3:18 PM, Stephen Powell <zlinuxman@wowway.com> wrote:
>> ...
>> both versions of Grub use unallocated sectors to store extra
>> code when they are installed in the master boot record. This can
>> lead to conflicts with other programs trying to do the same thing
>> or backup / restore issues. So there is a down side to this feature.
>
> If you've got other tools writing to the MBR for boot loading, you've
> got other issues. Typically, that's used with "chain loading". Your
> default OS is responsible for the MBR updates, and your alternative
> OS's used to rely on their own boot loaders (such as a grub or LILO
> boot loader on a particular partition or non-standard boot drive, such
> as detached storage.)
I'm not talking about multiple programs using the MBR. I'm talking
about multiple programs trying to store data in unallocated sectors.
More importantly, I'm talking about whether or not disk backup
programs backup the unallocated sectors and whether or not the
restore software can or does restore those unallocated sectors.
I know what chain loading is, and it has nothing to do with
unallocated sectors. The boot sector of a primary partition is
allocated, in the sense that it is the first sector of the partition.
But, say, LBA 1 (cylinder 0, head 0, sector 2) is usually an
unallocated sector. It is usually not part of any partition,
nor is it the master boot record. But both versions of Grub
want to write data to it.
>>
>> ...
>> With an appropriate
>> combination of symbolic links to block special files and direct
>> UUID or LABEL specifications, LILO can be made independent of driver
>> type (i.e. traditional IDE vs. libata SCSI emulation) and discover
>> order (i.e. /dev/sda vs. /dev/sdb).
>
> Changing the kernel, or attaching bootable media, can change the
> naming of block devices *unpredictably*. The use of uuid specific
> device names is relatively new. I went through the pain when ID drives
> suddenly switched from being named "/dev/hda", /dev/hdb", etc. to
> suddenly being "/dev/sda", "/dev/sdb", etc. (Don't get me started on
> Promise's RAID controllers.) And /dev/sd* device ordering is
> sensitive to kernel storage controller modules being statically
> loaded, dynamically loaded, and in different booting order in the
> BIOS.
True. But LILO can handle that when properly configured.
>
> All the pre-planned symlink setups in the world will break when
> /dev is now rebuilt by udev,
It doesn't matter. The symlinks I'm talking about are created by
udev. And LILO takes advantage of them.
>
> This way lies madness, and grub allows you to see and gracefully
> manipulate that madness much more effectively and safely than LILO.
I disagree. Did you actually read the web page I mentioned earlier?
(http://users.wowway.com/~zlinuxman/lilo.htm) If not, I suggest that
you do so. When configured as shown in that page, LILO can handle
all that stuff with no problems.
>>
>> ..
>> LILO doesn't either. Not anymore. As long as the BIOS supports
>> EDD packet addressing, the old 8.4G limit is long gone.
>
> Yup. Been there, done that, had to deal with old server class hardware
> less than 2 years ago. While this is commonly available in even
> vaguely modern motherboards, it is a serious crap shoot to rely on it
> for ancient server systems, or without doing BIOS updates. Ever tried
> to do BIOS updates on systems without Windows on them?
The LILO diagnostic diskette (referenced on the above-mentioned web
page) will tell you for sure if the system supports EDD packet addressing.
I have a very old laptop, an IBM ThinkPad 600, circa 1998, which is now
13 years old at the time of this writing, and its BIOS supports EDD
packet addressing. Not that it would need to, since the entire hard
disk is only 4G in size, and is therefore fully addressable by the
legacy BIOS Int 13h, Function 02h. Nevertheless, it does support EDD
packet addressing, which can address up to 2T (two terabytes).
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: