Does Lilo support multiboot? I have installed CentOS 5.4 with a xen kernel. The grub.conf file that the installer generated looks like:
title CentOS (2.6.18-164.el5xen)
module /vmlinuz-2.6.18-164.el5xen ro root=LABEL=/c5 irqpoll
And I am unsure what I should put in /etc/lilo.conf (I want to use Lilo and not grub, if that is at all possible).
Re: USB keyboard and LILO
> LILO contains NO device drivers. All
> I/O is performed by the BIOS. This
> includes disk I/O and keyboard I/O.
> Unless your BIOS provides support on int
> 16h for the USB keyboard, you will not
> be able to use it with LILO.
My BIOS does support USB and the keyboard works (i.e. the Delete key gets me into the BIOS and I can make changes in the BIOS) until I get to LILO where the arrow keys can't select any menu options and the Enter key does not work. LILO auto boots to the linux partition where the keyboard works fine again beginning with the linux bootup process. I hope that there is a fix for this issue. Mandriva 2008.
how to install LILO boot loader into a disk image
It is possible to create a disk image using a file, partition it, create file systems, install a Linux distro, and install the boot loader of choice. This file can then be copied to actual disk, used as a virtual disk with an emulator (such as bochs), etc.
Below is a short example of how to install LILO into such virtual disk, one that I actually made and using currently.
Assuming you have created already the disk image file, have partitioned it, and attached it to loopback device(s) appropriately, this is the relevant part of lilo.conf:
# You have attached your disk image to the loop0
# The disk geometry is that how you've defined it
# when creating your disk image (fdisk .... )
# Within my disk image, i have 3 partitions.
# Note the start offsets (fdisk -lu on image)
# The partitions are attached to other loops,
# if you need to use them.
# Some standard lilo things ...
# MBR to install LILO to: loop0 is the entire disk
# image, so we install into MBR of that image;
boot = /dev/loop0
# the boot partition I have mounted for working at
map = /void/wrk/lo_2/boot/.map
install = /void/wrk/lo_2/boot/boot-menu.b
delay = 50
vga = normal
# I have vmlinuz on the boot partition,
# which is mounted at lo_2/boot
========end lilo.conf ==============
I have to note that inside my initrd image, my linuxrc
sets up appropriate root device, then does pivot.
(actual root device can be say /dev/sda, or /dev/hda).
In shells like nash, you can run mkrootdev, which can
create needed device node passed as root=/dev/XXX
So then you only have to run lilo -v3 -C mylilo.conf -t,
and if all is oK, remove the '-t' :)
In case you wanted to see the mounts :
#loop0 is the entire disk, partitions are mounted
/dev/loop/2 on /void/wrk/lo_2 type squashfs (rw)
/dev/loop/1 on /void/wrk/lo_2/boot type ext2 (rw)
/dev/loop/3 on /void/wrk/lo_2/mnt type ext2 (rw)
This was my first adventure of this sort, so I can't guarantee
that installing LILO this way is best and most efficient.
If you know of a better / alternative / another useful way of installing LILO into a file, or how to improve the above way,
please post a comment.
Re: Preparing a hd[x] drive for another machine
If you wish to prepare a disk image and then copy it to a hard drive, I suggest you follow the example in the script "mkrescue --iso --size HD". Normally the "--iso" option creates a bootable floppy image; however, with the 2.6 kernels >1.4Mb this is no longer possible. So the extra size (Hard Disk), allows for very large kernels. Although this script ultimately creates an ISO image, the hard disk image is created along the way.
The 'mkrescue' script is a part of the LILO source and binary distributions.
Re: Preparing a hd[x] drive for another machine
You wrote that it is possible to contact you directly for more involved case.
I was wondering about the 'other' ways to create a bootable
disk for another machine, and what is / not possible with lilo here.
I was interested if its possible to install lilo without having actual hard drive , only the disk image (which I then would copy to the disk ).
I have made a disk image, with partitions, file systems, and a linux distro installed. I was trying to install lilo into it, but with no luck. I was trying to install lilo through the use of loopback
devices, but that seems did not work (installed, but does not boot). Its most likely wrong what I was trying to do.
I would really appreciate help on this.
> Make sure you are using LILO 22.5.9 or
> newer, and that you are using 'lba32'
> disk addressing. A sector-by-sector
> copy of a bootable drive (same size)
> will be bootable:
> >dd if=/dev/hda of=/dev/hdb
> Then move hdb to hda on the second
> machine. This, of course, assumes a
> compatible BIOS.
> If /dev/hda1 is the bootable partition
> on the first machine, and /dev/hdb1 is
> to be the bootable partition on the
> second machine (/dev/hda1 after moving
> the disk), then a simple install of LILO
> on the second disk (mounted as /mnt/b),
> would go as follows (identical
> /etc/lilo.conf files on both disks):
> > lilo -r /mnt/b -b /dev/hdb
> At this point, dismount, power down, and
> move the hdb disk to hda on the second
> machine. Presumably even the
> "root=/dev/hda1" specification for hdb
> will now become valid.
> There are other ways to create a
> bootable disk for a second machine, but
> they quickly increase in complexity from
> this point. I suggest you contact me
> directly if your situation is
> significantly more involved.
Re: Deadlocked Installations
I don't know if this will solve the problem of booting FreeBSD, but I would chain boot this installation on /dev/hdc4 with: 'other = /dev/hdc4'. Then install the FreeBSD boot loader on /dev/hdc4. The LILO installation can chain to it through the 'other' descriptor.
Re: Deadlocked Installations
To address just one issue, the skipping of the installation on /dev/hdc17. The 'optional' keyword is used, meaning if LILO cannot find the specified kernel, the entire descriptor will be skipped. Omit 'optional', and the installation will probably fail with a 'file not found' complaint.
'linear' is used in the global section. This limits you to booting from the first 1024 cylinders of your hard disk. Is this really what you want?
Many installation instructions advise the installer to produce a boot disk. But not all Linux and BSD distros allow that. Using floppies is not as common practice than that once used to be. In the case of new installations however it can save a lot of headaches. What even further complicates the situation is that the believed rescue options fail to deliver.
I do not like to destroy what works, rather prefer to extend its scope. But this cautious approach led to a situation that I have completed the first phase of two installations neither of which can be restarted now.
One of them is openSUSE 10.2. Based on some loosely-worded advises on installing multiple Linux distros on one drive, and using lilo to boot them just has not worked out. The used lilo.cnf is listed below. Executing /sbin/lilo resulted in skiping the last entry, i.e., the newly installed system.
(Please note that on the first IDE controller /dev/hda is the CDROM, and /dev/hdb is the DVD unit; /dev/hdc, the first hard drive is master on the secondary IDE controller.)
### LILO configuration file
### Global Section START
### Global Section END
### Windows_and_DOS START
### Windows_and_DOS END
### SuSE_old kernel-2433 START
### SuSE_old kernel-2433 END
### SuSE_old_orig START
### SuSE_old_orig END
### openSUSE-10.2 Linux START
### openSuSE-10.2 Linux END
The second system is FreeBSD located in the forth primary partition. Supposedly it should be booted though the fixit.flp floppy using the correct
n1 and n2 in the n1:ad(n2,a)/kernel command.
But, no matter what I use, it replies with "invalid label". Also lilo should be able to handle it, but I have not been able to find any specific example for it.
If anyone having closer familiarity with the subject has any specific advice to resolve either case, or could point to an article on lilo that deals with cases involving two Linux systems located in two different directories, and/or has a specific description of booting a FreeBSD system I would greatly appreciate it.
Re: Hiding logical partitions
> Hi all,
> I am running Win98 Win2k and linux on
> one HD.
> I would like to share user data between
> Linux and
> Win2k which are located on logical FAT
> partitions on
> an extended (Windows generated)
> Win98 should run as an isolated system
> with no
> connections to the outer world, so I
> wanted LILO to
> hide my user data partitions.
> Unfortunately I couldn't
> find any way to do this, as it seems
> that LILO only
> supports primary partition hiding.
> As an alternative I tried to hide my
> whole extended
> partition by simply changing the ID of
> the extended
> partitions to something else (in my case
> FAT32 as there is no hidden extended
> partition) so the logical drives became
> hidden too.
> This is not a nice solution but it would
> have worked
> out for my special case.
%So here, in short, my issues :
%1.) Why isn't it possible to change IDs of
%logical partitions by the change rules (or is it possible
%and I am wrong ) ?
%2.) Why isn't it possible to add change rules for the
%linux sections in lilo.conf ?
%3.) Is there a way to automatically set back the
%partition IDs when LILO is started (I thought this
%would be the case, but it seemingly wasn't)
%4.) Is there a solution or a workaround for my
> particular problem
> Thanks in advance
You probably don't need this by now, but i suppose it may be useful to someone else.
I recently encountered a very similar problem, and after some experimenting eventually came up with this.
1. When booting into win98 you set the extended partition's type to 0x85 (Linux extended). Windows doesn't have a clue what type 0x85 is so it'll leave it alone.
2. When booting to winxp you set the type to 0x0f (windows extended). xp will now see it and be happy about it.
3. when booting linux you needn't do anything, as it doesn't care if the type is 0x85 or 0x0f. it will see it either way.
but i still agree with your points, especially 1 and 2. it would be nice to have those.
hope this helps someone
Re: Long install times with Reiser filesystem
The change has occurred in the Reiser filesystem code, not in LILO. The fix will have to come from the Reiser development team. The more people they hear from, the quicker this problem will be addressed.
An open, cross-platform journaling program.
A scientific plotting package.