lilo loading other os (Slackware 13.37 amd64)

[er1ch]

Hello.

Honestly I spent hours and hours reading, googleing and experimenting to
figure this out - and couldn't.

I installed another linux system (debian mint) on my /dev/sda3, just to
experiment with it. Now I wanted to start that from my normal lilo.
Here is my lilo.conf, the comments stripped off:

-----------------------------------------------\

append=" vt.default_utf8=0"
boot = /dev/sda
lba32
prompt
timeout = 1200
change-rules
reset
vga = normal
default = "Slack_8"
# stanza 1
image = /boot/vmlinuz
root = /dev/sda7
label = Slack_7
read-only
# stanza 1
image = /boot/vmlinuz
root = /dev/sda8
label = Slack_8
read-only
# stanza 3
image = /boot/vmlinuz-2.6.32-5-amd64
initrd = /boot/initrd.img-2.6.32-5-amd64
root = /dev/sda3
label = Linux_Mint
read-only

-----------------------------------------------/


Now when I run "/sbin/lilo -v -t", both of my slackwares are recognized
(I have a working system and a testing one)
but not the debian in stanza 3 and I get:

--------------\
Boot image: /dev/sda3/boot/vmlinuz-2.6.32-5-amd64
Fatal: open /dev/sda3/boot/vmlinuz-2.6.32-5-amd64: Not a directory
--------------/

I tried to copy the debian kernel and the initrd to a subdir,
/boot/debian_mint, this is an advice I found googleing:

-----------------------------------------------\

# stanza 4
image = /boot/debian_mint/vmlinuz-2.6.32-5-amd64
root = /dev/sda3
initrd = /boot/debian_mint/initrd.img-2.6.32-5-amd64
label = Linux_Mint
append = "pfix=ram"
read-only

-----------------------------------------------/

Now lilo finds the kernel and starts the debian os -
but deb is not started correctly, the modules are not found. Tried to
change the sequence of the lines etc. - it does
not work.

I must be missing something obvious. Now, I don't want to run debian
because I do not get accustomed to the package management - this is more
a general problem. What can I do?

TIA,

Erich

[Eef Hartman]

er1ch <erichh...@gmx.de> wrote:
> # stanza 3
> image = /boot/vmlinuz-2.6.32-5-amd64
> initrd = /boot/initrd.img-2.6.32-5-amd64

These filenames will have to be the names the SLACKWARE system sees
for the Mint boot files (you may have to mount /dev/sda3 first, then
add ITS mount directory in front of /boot).
Because _slackware_ is doing the lookup for them, so it has to be
pathnames valid TO slackware, not Mint.
The bootloader doesn't care for the filenames, but installing lilo
is done in the _running_ linux.

The other solution is creating a separate /boot PARTITION and put
both the slackware and mint kernel files in it. But mint probably
hasn't got lilo anyway (grub is more likely) so the slackware
system still has to do the work.
--
******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-27 82525 **
******************************************************************

[dillinger]

On 01/24/2012 05:16 PM, Eef Hartman wrote:
> er1ch<erichh...@gmx.de> wrote:
>> # stanza 3
>> image = /boot/vmlinuz-2.6.32-5-amd64
>> initrd = /boot/initrd.img-2.6.32-5-amd64
>
> These filenames will have to be the names the SLACKWARE system sees
> for the Mint boot files (you may have to mount /dev/sda3 first, then
> add ITS mount directory in front of /boot).
> Because _slackware_ is doing the lookup for them, so it has to be
> pathnames valid TO slackware, not Mint.
> The bootloader doesn't care for the filenames, but installing lilo
> is done in the _running_ linux.
>
> The other solution is creating a separate /boot PARTITION and put
> both the slackware and mint kernel files in it. But mint probably
> hasn't got lilo anyway (grub is more likely) so the slackware
> system still has to do the work.

It's probably easier to use 'other':

# stanza 3
other = /dev/sda3
label = Linux_Mint

And tell Mints installer to install Grub or Lilo on /dev/sda3.

[o...@grrr.id.au]

Yes, this is the simplest and thus the correct method.

You could use a global boot directory but that can get messy,
I use chain booting for other OS and it works no matter if the
other OS is a Linux distro, different slackware version, or
windows.

Slackware lilo gets control on boot from the MBR, then starts
the nominated OS, which will, if not slackware, in turn boot
fresh from the other OS's partition.

Grant.

[Thomas Overgaard]

er1ch wrote:

> # stanza 3
> image = /boot/vmlinuz-2.6.32-5-amd64
> initrd = /boot/initrd.img-2.6.32-5-amd64
> root = /dev/sda3
> label = Linux_Mint
> read-only
>
> -----------------------------------------------/
>
>
> Now when I run "/sbin/lilo -v -t", both of my slackwares are
> recognized (I have a working system and a testing one)
> but not the debian in stanza 3 and I get:
>
> --------------\
> Boot image: /dev/sda3/boot/vmlinuz-2.6.32-5-amd64
> Fatal: open /dev/sda3/boot/vmlinuz-2.6.32-5-amd64: Not a directory
> --------------/

You must mount your Mint partition first. You can create a mount point
like /mnt/mint or just use /mnt/floppy. If the latter then your Mint
section in lilo.conf should look like this:
# stanza 3
image = /mnt/floppy/boot/vmlinuz-2.6.32-5-amd64
initrd = /mnt/floppy/boot/initrd.img-2.6.32-5-amd64

root = /dev/sda3
label = Linux_Mint
read-only
--

Thomas O.

This area is designed to become quite warm during normal operation.

[er1ch]

Am Wed, 25 Jan 2012 13:53:24 +1100 schrieb omg:

> On Tue, 24 Jan 2012 17:52:05 +0100, dillinger <dill...@invalid.not>
> wrote:

(...)

>>> doing the lookup for them, so it has to be pathnames valid TO
>>> slackware, not Mint. The bootloader doesn't care for the filenames,
>>> but installing lilo is done in the _running_ linux.

(...)

>>It's probably easier to use 'other':
>>
>># stanza 3
>>other = /dev/sda3
>>label = Linux_Mint
>>
>>And tell Mints installer to install Grub or Lilo on /dev/sda3.
>
> Yes, this is the simplest and thus the correct method.
>

(...)

Thanks a lot to all of you. Thus I could tell lilo to use the grub of
another distribution. This is very straightforward. Now I get the idea.
I'll try that this weekend. Fine!


Erich

[er1ch]

Am Wed, 25 Jan 2012 20:48:32 +0100 schrieb Thomas Overgaard:

> er1ch wrote:

(...)

> You must mount your Mint partition first. You can create a mount point
> like /mnt/mint or just use /mnt/floppy. If the latter then your Mint
> section in lilo.conf should look like this: # stanza 3
> image = /mnt/floppy/boot/vmlinuz-2.6.32-5-amd64 initrd =
> /mnt/floppy/boot/initrd.img-2.6.32-5-amd64 root = /dev/sda3
> label = Linux_Mint
> read-only

Excuse me: How can I mount, i.e. where do I put the command to mount
/dev/sda3 in the boot process? It should be before lilo starts?

Erich

ps. Thank you for looking into this. I'm interested in that solution, but
I will not have time to answer before weekend.

[Helmut Hullen]

Hallo, er1ch,

Du meintest am 26.01.12:

[...]

>> You must mount your Mint partition first. You can create a mount
>> point like /mnt/mint or just use /mnt/floppy. If the latter then
>> your Mint section in lilo.conf should look like this:
>> # stanza 3
>> image = /mnt/floppy/boot/vmlinuz-2.6.32-5-amd64
>> initrd = /mnt/floppy/boot/initrd.img-2.6.32-5-amd64
>> root = /dev/sda3
>> label = Linux_Mint
>> read-only

> Excuse me: How can I mount, i.e. where do I put the command to mount
> /dev/sda3 in the boot process? It should be before lilo starts?

For testing I run a system with 2 intern hdds and (about) 6 extern SCSI
disks.

/dev/sda is the booting and repairing and examninating system for all
others.

I use to create a special directory in the "/boot" directory of sda1,
p.e.

/boot/fedora9

with the (minimal) contents
vmlinuz-...
initrd-...

which I copy from the foreign partition (p.e. /dev/sdh)

And then I add (p.e.) a paragraph into "/etc/lilo.conf" on /dev/sda1:

# SCSI ID 5
root = /dev/sdh1
image = /boot/fedora9/vmlinuz-...
initrd = /boot/fedora9/initrd-...
label = fedora9

----------------------------------

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Henrik Carlqvist]

er1ch <erichh...@gmx.de> wrote:

> Am Wed, 25 Jan 2012 20:48:32 +0100 schrieb Thomas Overgaard:
>> You must mount your Mint partition first. You can create a mount point
>> like /mnt/mint or just use /mnt/floppy. If the latter then your Mint
>> section in lilo.conf should look like this:
>> # stanza 3
>> image = /mnt/floppy/boot/vmlinuz-2.6.32-5-amd64
>> initrd = /mnt/floppy/boot/initrd.img-2.6.32-5-amd64
>> root = /dev/sda3
>> label = Linux_Mint
>> read-only
>
> Excuse me: How can I mount, i.e. where do I put the command to mount
> /dev/sda3 in the boot process? It should be before lilo starts?

The partitions should be mounted when you run /sbin/lilo, not during the
boot process when lilo loads the kernel. The easiest way to automatically
mount partitions at the boot of a system is to edit /etc/fstab.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc123(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[Thomas Overgaard]

er1ch wrote:

> Excuse me: How can I mount, i.e. where do I put the command to mount
> /dev/sda3 in the boot process? It should be before lilo starts?

Just to confuse people there's two things called lilo; there's the boot
loader LILO and a program /sbin/lilo.

The program reads /etc/lilo.conf and tries to build and write the boot
loader based on the information here. The program must have access to
the partition with the kernel because it must detect the blocks at the
disk where the kernel is stored. This information is then written into
the boot loader.

The boot loader doesn't care about partitions, file-systems or file-
names. It reads the kernel directly from the blocks of the disk and then
it mounts the partition with the root partition. Then the boot loaders
job is done and Linux takes over.

[Aragorn]

On Friday 27 January 2012 21:59, Thomas Overgaard conveyed the following
to alt.os.linux.slackware...

> er1ch wrote:
>
>> Excuse me: How can I mount, i.e. where do I put the command to mount
>> /dev/sda3 in the boot process? It should be before lilo starts?
>
> Just to confuse people there's two things called lilo; there's the
> boot loader LILO and a program /sbin/lilo.
>
> The program reads /etc/lilo.conf and tries to build and write the boot
> loader based on the information here. The program must have access to
> the partition with the kernel because it must detect the blocks at the
> disk where the kernel is stored.

As well as to the blocks where the initrd is stored, and where the
secondary LILO stage is stored. ;-)

> This information is then written into the boot loader.

More precisely, into the code in the primary stage of the bootloader.
;-)

> The boot loader doesn't care about partitions, file-systems or file-
> names. It reads the kernel directly from the blocks of the disk and
> then it mounts the partition with the root partition. Then the boot
> loaders job is done and Linux takes over.

Slight correction here. The bootloader does /not/ mount the partition
with the root filesystem. That's the kernel's job. The bootloader's
job is only to offer the user a choice of loading a kernel (or a
particular partition's boot sector) into memory, and doing just that,
and then all passing control of the machine (and the boot parameters
listed in the boot configuration for said kernel) onto the bootstrap
code of the kernel, or the code in the loaded partition (or floppy) boot
sector.

On x86 with a legacy BIOS, the Linux kernel binary contains a small
amount of real mode code, which is needed to safely store the boot
parameters in memory, prepare the boot processor for protected mode - by
setting up pagetables et al - and then switch it into protected mode,
relocate the boot parameters to a write-protected area of memory, and
decompress the actual runtime kernel. The mounting of the root
filesystem is done only by the runtime kernel, long after the switch to
protected mode, and after the root filesystem has been checked first.

At least, that's as far as LILO goes. GRUB is an entirely different
thing, which has a filesystem driver for the filesystem that the kernel
image and the secondary GRUB stage are on. This filesystem driver is
located in an intermediary GRUb stage, called stage 1.5. And once that
stage has been loaded, GRUB will indeed mount the partition that the
kernel image and the secondary GRUB stage are on, but if that is a
separate "/boot" filesystem, then GRUB will still not mount the actual
root filesystem. Even with GRUB, this is the job of the kernel. ;-)

--
= Aragorn =
(registered GNU/Linux user #223157)

[Thomas Overgaard]

Argon wrote:

> The boot loader does not mount the partition with the root file
> system.

I wanted to keep it very basic. But you're right, the boot loader
doesn't mount the root partition but it specify which partition the
kernel must mount as root.

[er1ch]

Am Tue, 24 Jan 2012 15:56:39 +0000 schrieb er1ch:

> Hello.
>
(...)

> I installed another linux system (debian mint) on my /dev/sda3, just to
> experiment with it. Now I wanted to start that from my normal lilo.
> Here is my lilo.conf, the comments stripped off:
>
> -----------------------------------------------\

(...)
> -----------------------------------------------/
>
(...)

>
> Now lilo finds the kernel and starts the debian os - but deb is not
> started correctly, the modules are not found. Tried to change the
> sequence of the lines etc. - it does not work.
>
> I must be missing something obvious. Now, I don't want to run debian
> because I do not get accustomed to the package management - this is more
> a general problem. What can I do?

(...answers...)

Thank you all very much! I'll give a summary first, and then some
comments.

Please correct my when I'm writing nonsense here:

There are at least 3 methods for starting Other-OS from First-OS
with lilo.

------------------------------------------------------------------

1.) When installing Other-OS on /dev/XY, let it install its boot
manager, but not to the MBR, but to /dev/XY. Re-Start First-OS
and reinstall lilo with the following extra stanza in lilo.conf:

# Linux bootable partition config begins
other = /dev/XY
label = Other-OS
# Linux bootable partition config ends

Lilo in this case gives control to the boot manager on /dev/XY.

(This should work whenever there is a valid boot manager on /dev/XY.
I didn't realize that I had to install the bootmanager to the device.)

2.) After installing Other-OS to /dev/XY, restart First-OS and mount
Other-OS to /(mountpoint)/. Add this stanza to lilo.conf:

# Linux bootable partition config begins
image = /(mountpoint)/boot/(name-of-kernel)
# initrd, if needed
initrd = /(mountpoint)/boot/(name-of-initrd)
root = /dev/XY
label = Other-OS
read-only
# Linux bootable partition config ends

(What I didn't realize before was that this really is all that's
needed. When lilo finds the kernel (and initrd, if needed) at the
time it is installed, it will find it next time the computer boots.)

3.) After installing Other-OS to /dev/XY, restart First-OS, create
a subdirectory unter /boot, and copy kernel and initrd (if needed)
from Other-OS into /boot/(subdir). Add to lilo.conf:

# Linux bootable partition config begins
image = /boot/(subdir)/(copy-of-kernel of Other-OS)
# initrd, if needed
initrd = /boot/(subdir)/(copy-of-initrd of Other-OS)
root = /dev/XY
label = Other-OS
read-only
# Linux bootable partition config ends

---

(Always test before installing lilo and say '/sbin/lilo -v -t' first ;)

------------------------------------------------------------------

I hope I put this right. Excuse me for the verbosity, this is what I
need to find my way.

Now, I always have 2 running slackware systems here, one as a
productive system which *must* remain stable at all costs, and a
second one for testing, making packages &c. When I start Slack-2
from Slack-1 with lilo, all of the 3 methods work flawlessly.

This was not the case with Debian Mint. I deleted Mint and
installed CentOS in the meantime, and method 1 works. Methods 2 and
3 start the CentOS kernel, but they stop when the mouse is loaded.
They just hang up. When I experimented with Debian Mint before,
some of the modules were not loaded and I could not log into X.

OK as for me, I can live with the result, because I have method 1 which
works. On the other hand it seems that the hangup with "Other-OS" is
not a lilo problem, but a problem of my installation of CentOS (or
Debian Mint), so probably I should investigate more in those OSes than
in different lilo configuration. If I think that it is worth while.

Thanks to all a lot. If you see me posting _very_ rarely to this
group, it is because normally my slackware box just works or I can
figure out a solution myself. Just in the last weeks I have some
problems.

Cheers, Erich

ps.

Sometimes I like to try other oses just to see how they work,
but frankly I always had more trouble installing Ubuntu than Slackware.
Note that I'm not complaining. But last time I installed Ubuntu, my wlan
went down and I had to reinstall the passwords. Don't ask me how this
could happen, I don't know and perhaps it was no Ubuntu problem. And
when I installed Debian Mint, it took me one hour to work around
dependency problems. Aptitude told me that before updating the
installation I had to fix package problems first. It didn't tell me
which packages I had to fix. Again, I'm not complaining. It's just
that all my experiments lead to the conclusion that Slackware is the
simpler and safer choice - for me, of course.

[Helmut Hullen]

Hallo, er1ch,

Du meintest am 29.01.12:

> Sometimes I like to try other oses just to see how they work,
> but frankly I always had more trouble installing Ubuntu than
> Slackware.

Me too ...
And it got worse with the Ubuntu-versions from 2011.
Working with Ubuntu is more and more like working with Microsoft - the
distribution allows no individual way.

[Martin]

er1ch wrote:

>
> (...answers...)
>
> Thank you all very much! I'll give a summary first, and then some
> comments.
>
> Please correct my when I'm writing nonsense here:
>
> There are at least 3 methods for starting Other-OS from First-OS
> with lilo.

good sumary. What you also need to take into accout is that the first method
is more universal than the other two. For instance, if /dev/XY is not known
at the time of calling /sbin/lilo the latter will throw an error.

<xsl:deviation>This check can be hard at the time of changing drivers in
First-OS, like from /dev/hda to /dev/sda. Luckily there is a workaround by
calling up a prompt at boot time and overriding the root
device.</xsl:deviation>

Martin

[Helmut Hullen]

Hallo, dillinger,

Du meintest am 24.01.12:

> It's probably easier to use 'other':

> # stanza 3
> other = /dev/sda3
> label = Linux_Mint

> And tell Mints installer to install Grub or Lilo on /dev/sda3.

Yes - it works!
Finally I had success installing Ubuntu-alternate. Ubuntu-desktop
doesn't offer putting Grub2 in another place than the MBR of the first
recognized disk, Ubuntu-alternate does (but has another well known bug
while installing ...).

[er1ch]

Am Sun, 29 Jan 2012 11:33:47 +0100 schrieb Martin:

> er1ch wrote:
>> (...answers...)

>> There are at least 3 methods for starting Other-OS from First-OS with
>> lilo.
>
> good sumary. What you also need to take into accout is that the first
> method is more universal than the other two. For instance, if /dev/XY is
> not known at the time of calling /sbin/lilo the latter will throw an
> error.
>
> <xsl:deviation>This check can be hard at the time of changing drivers in
> First-OS, like from /dev/hda to /dev/sda. Luckily there is a workaround
> by calling up a prompt at boot time and overriding the root
> device.</xsl:deviation>
>
> Martin

There is something more I should add.

The first method (adding a stanza with "other = /dev/XY") is more
universal than mounting or copying kernel and initrd of Other-OS because
both of methods 2 & 3 may generate the warning that I got which I
forgot to mention. (BTW I deleted debian mint and installed CentOS,
because I want to keep my /dev/sda3 for experiments on other OSes.)
Here it is:

--------------------------------------------------------------\

Boot image: /other/3/boot/vmlinuz-2.6.32-220.el6.x86_64
Mapping RAM disk /other/3/boot/initrd-2.6.32-220.el6.x86_64kdump.img
Warning: The initial RAM disk is too big to fit between the kernel and
the 15M-16M memory hole. It will be loaded in the highest memory as
though the configuration file specified "large-memory" and it will
be assumed that the BIOS supports memory moves above 16M.
Added CentOs-mount ?

--------------------------------------------------------------/

Obviously my "highest memory" wasn't "high" enough for that
CentOS intitrd on /dev/sda3, and this was the reason for the hangup.
Anyway it is good to know all of the 3 methods.

I often read the advice that one should give an extra partition to
the /boot directory, and I think that this is good advice. I ported
that to my own thinking. Created a partition of 5GB with a minimal
slackware install just capable of running lilo, and I never touch that
exept I install another OS.

I have been asking myself why Slackware itself sticks to lilo while
most of the other distributions and a lot of slackware people are
using grub. I tried to configure grub2. With the new things I learned
now I'm happy with lilo.

Cheers, Erich

[Helmut Hullen]

Hallo, er1ch,

Du meintest am 30.01.12:

> The first method (adding a stanza with "other = /dev/XY") is more
> universal than mounting or copying kernel and initrd of Other-OS
> because both of methods 2 & 3 may generate the warning that I got
> which I forgot to mention. (BTW I deleted debian mint and installed
> CentOS, because I want to keep my /dev/sda3 for experiments on other
> OSes.) Here it is:

> --------------------------------------------------------------\

> Boot image: /other/3/boot/vmlinuz-2.6.32-220.el6.x86_64
> Mapping RAM disk /other/3/boot/initrd-2.6.32-220.el6.x86_64kdump.img
> Warning: The initial RAM disk is too big to fit between the kernel
> and the 15M-16M memory hole. It will be loaded in the highest
> memory as though the configuration file specified "large-memory"
> and it will be assumed that the BIOS supports memory moves above
> 16M. Added CentOs-mount ?

No problem. I have seen this warning with many (self made) slackware
kernels - they all worked without any problem.

[er1ch]

Am Mon, 30 Jan 2012 20:02:00 +0100 schrieb Helmut Hullen:

> Hallo, er1ch,
>
> Du meintest am 30.01.12:
>
>> The first method (adding a stanza with "other = /dev/XY") is more
>> universal than mounting or copying kernel and initrd of Other-OS
>> because both of methods 2 & 3 may generate the warning that I got which
>> I forgot to mention. (BTW I deleted debian mint and installed CentOS,

[...]

>
> No problem. I have seen this warning with many (self made) slackware
> kernels - they all worked without any problem.

hmnmnmnm, yes, but perhaps this is a slackware thing.
Look at this:

# Linux bootable partition config begins

image = /boot/vmlinuz
root = /dev/root
label = slackware-on-dev-7

read-only
# Linux bootable partition config ends

# Linux bootable partition config begins

image = /boot/vmlinuz
root = /dev/sda8

label = slackware-on-dev-8

read-only
# Linux bootable partition config ends

Even now slackware on /dev/sda8 is booted and runs smoothly. It's
the other Os'es that make difficulties, or it is this notebook here.
It is a very cheap one, very new, but a "beginner's model" as they
say (samsung RV511), for I don't need much resources for my doings.
(Here is the next problem which I probably will mail to the list.
The notebook is very cheap, but new, slackware doesn't recognize the
touchpad.) (yet.)

I guess that yours has more memory. In my case the CentOS only runs
when booted with the 'other =' - method. Which doesn't matter because
I can get along with that method.

Cheers, Erich

>
> Viele Gruesse
> Helmut
>
> "Ubuntu" - an African word, meaning "Slackware is too hard for me".

ps.

In my case this should run:
"Slackware" - an American word, meaning "Ubuntu is too hard for me" ;-D

As I said, I always had difficulties installing ubuntu. I am a
subscriber to slackware for more than a decade now because for me
it is the distribution I have the least problems with. That means a
lot, because I belong to the guys that when they have no problems, they
create them. :-)

[Helmut Hullen]

Hallo, er1ch,

Du meintest am 30.01.12:

>>> The first method (adding a stanza with "other = /dev/XY") is more
>>> universal than mounting or copying kernel and initrd of Other-OS
>>> because both of methods 2 & 3 may generate the warning that I got
>>> which I forgot to mention. (BTW I deleted debian mint and
>>> installed CentOS,

> [...]

>> No problem. I have seen this warning with many (self made) slackware
>> kernels - they all worked without any problem.

> hmnmnmnm, yes, but perhaps this is a slackware thing.

No - I've seen/produced this message with some slackware kernels (not
all), and (just now) with an Ubuntu kernel too.

[Martin]

er1ch wrote:

> I have been asking myself why Slackware itself sticks to lilo while
> most of the other distributions and a lot of slackware people are
> using grub.

I personally dislike the idea of having (lots of) file system drivers in a
boot loader, but maybe that's just me.

Afer so many years I pretty much understand how lilo works, maybe that's
another reason why I like it. ;)

Martin

[Aragorn]

On Wednesday 01 February 2012 21:24, Martin conveyed the following to
alt.os.linux.slackware...

> er1ch wrote:
>
>> I have been asking myself why Slackware itself sticks to lilo while
>> most of the other distributions and a lot of slackware people are
>> using grub.
>
> I personally dislike the idea of having (lots of) file system drivers
> in a boot loader, but maybe that's just me.

Actually, the GRUB bootloader as it is installed will only contain a
real mode filesystem driver for the filesystem that "/boot" is on -
whether it's a separate partition or just a directory on the root
filesystem. The other filesystem drivers are provided for in the
package, but only one will be chosen. After all, it has to fit into the
GRUB 1.5 stage, which sits right at the end of the GRUB 1 stage in the
master boot record.

> Afer so many years I pretty much understand how lilo works, maybe
> that's another reason why I like it. ;)

There are certain scenarios where LILO is inadequate - e.g. when booting
the Xen hypervisor. However, I too much preferred the simplicity and
robustness of LILO over GRUB, and GRUB2 is a nightmare that I would
prefer to avoid for as long as I can.

[Sylvain Robitaille]

On Wed, 01 Feb 2012 21:33:43 +0100, Aragorn wrote:

> There are certain scenarios where LILO is inadequate - e.g. when

> booting the Xen hypervisor. ...

Any chance you'd be willing to elaborate on that, or point to
documentation where a curious mind could find out more detail?

--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

[Aragorn]

On Thursday 02 February 2012 00:16, Sylvain Robitaille conveyed the
following to alt.os.linux.slackware...

> On Wed, 01 Feb 2012 21:33:43 +0100, Aragorn wrote:
>
>> There are certain scenarios where LILO is inadequate - e.g. when
>> booting the Xen hypervisor. ...
>
> Any chance you'd be willing to elaborate on that, or point to
> documentation where a curious mind could find out more detail?

But of course. ;-) First I'll try putting it in my words, and then I'll
see whether I can dig up the documentation on the Xen website and
provide you with a link. ;-)

So the thing is this... Contrary to the virtualization solutions
commonly used by desktop GNU/Linux users - i.e. VirtualBox, VMWare
Workstation (or VMWare Player), or the Linux Kernel Virtual Machine -
Xen is a bare metal hypervisor.

So when the machine cold-boots, it does not load a Linux kernel, but
instead it loads the Xen hypervisor, which is also a compressed binary,
similar to the Linux kernel. The hypervisor will then in turn boot a
special Linux kernel - compiled with paravirtualization support - as the
"dom0" system, i.e. the "privileged domain". This is a GNU/Linux system
which has access to all the hardware and is comparable to a "host
operating system" in the commonly used other virtualization solutions,
but it isn't a host, in that it too runs on top of the hypervisor as a
virtual machine. It just happens to be a privileged virtual machine,
with direct access to the underlying hardware - but this is not what
makes it privileged - and direct access to the other, unprivileged
virtual machines, called "domU".

So far the theory. Now, in order to get Xen to boot and launch the dom0
Linux kernel, it needs to load this Linux kernel as a module. The
stanza in the bootloader would then have to look something like the
simplified example below - and assuming that the "/" below is the root
directory of a separate "/boot" partition, because GRUB's paths are
relative to the partition it itself has its stage 2 file on.

title "Xen virtualization platform"
kernel /xen.gz
module /vmlinuz
initrd /initrd.img

However, GRUB supports this "module" command, but LILO does not. A
workaround exists, but it is tricky and I don't know whether it still
works with Xen 4.x. This workaround is to decompress both xen.gz and
the vmlinuz binary, and to "weld them together" in a special way - by
way of some special tool - and then gzip them again.

More information about this can be found at...

http://tinyurl.com/6rlp9b9

(Preview: http://preview.tinyurl.com/6rlp9b9)

There used to be an easier link to this but xen.org has "recently" -
well, about a year and a half ago - redesigned its website and I
couldn't directly get to the documentation which elaborated on this
anymore, so the above is from the Xen developer mailinglist.

[Sylvain Robitaille]

On Thu, 02 Feb 2012 01:42:36 +0100, Aragorn wrote:

>> Any chance you'd be willing to elaborate ...
>
> But of course. ;-) ...

Thanks, I think your explanation covers it quite well.

> ... Xen is a bare metal hypervisor.
>
> ... The hypervisor will ... boot a special Linux kernel ... as the
> "dom0" system, i.e. the "privileged domain". ...

Yes, ok ...

> ... in order to get Xen to boot and launch the dom0
> Linux kernel, it needs to load this Linux kernel as a module. ...

Oh, yes ... I do recall that.

> However, GRUB supports this "module" command, but LILO does not. ...

Right. It seems to me it *should* still be possible to use Lilo (and
insert the dom0 kernel module by other means), though I've not
experimented with it at all. Thanks for the explanation. I *had* some
time ago read about it and understood it, but had completely forgotten
the dom0 kernel as a module to the hypervisor business.

> http://tinyurl.com/6rlp9b9

It's a rather old discussion admittedly, but thanks for that. It seems
the Xen developpers were pretty satisfied with using Grub.

In an effort to give back, the multiboot specification (which is what
makes this all happen) is documented at
http://www.gnu.org/software/grub/manual/multiboot/

A utility has since been created that packages the hypervisor, dom0
kernel, and associated initrd into a single image that Lilo can boot, at
least on a 32-bit system, available at
http://www.tjd.phlegethon.org/software/mbootpack-0.6a.tar.gz

It's not perfect, but it does satisfy my curiosity that it is indeed
possible, if ultimately not easier than just using Grub in those cases.

[Aragorn]

On Thursday 02 February 2012 07:14, Sylvain Robitaille conveyed the
following to alt.os.linux.slackware...

> On Thu, 02 Feb 2012 01:42:36 +0100, Aragorn wrote:
>
>> http://tinyurl.com/6rlp9b9
>
> It's a rather old discussion admittedly, but thanks for that. It
> seems the Xen developpers were pretty satisfied with using Grub.
>

> [...]

> A utility has since been created that packages the hypervisor, dom0
> kernel, and associated initrd into a single image that Lilo can boot,
> at least on a 32-bit system, available at
> http://www.tjd.phlegethon.org/software/mbootpack-0.6a.tar.gz
>
> It's not perfect, but it does satisfy my curiosity that it is indeed
> possible, if ultimately not easier than just using Grub in those
> cases.

Yes, as I have mentioned. But all things considered, I think simply
installing GRUB would be a lot easier. As long as it's grub-legacy,
because I hate grub2. ;-)

[Kees Theunissen]

Aragorn wrote:
>
> There are certain scenarios where LILO is inadequate - e.g. when booting
> the Xen hypervisor. However, I too much preferred the simplicity and
> robustness of LILO over GRUB, and GRUB2 is a nightmare that I would
> prefer to avoid for as long as I can.

There are other scenarios where LILO is better.
I have a system with a software raid1 (mirror) root filesystem and I
want the boot loader installed in the MBR's of both disks. This way
I'm still able to boot if either disk fails.

This can be done with LILO with this global section:
# Start LILO global section
lba32
append="root=/dev/md1 vt.default_utf8=0 acpi=off"
boot = /dev/md1
raid-extra-boot = mbr-only

With Grub you need -as far as I know- to install the bootloader
twice, separately in the MBR of each disk.


Regards,

Kees.

--
Kees Theunissen.

[Aragorn]

On Thursday 02 February 2012 10:56, Kees Theunissen conveyed the
following to alt.os.linux.slackware...

I'm not sure how to set up GRUB with Linux software RAID - I have more
experience with (and preference for) hardware RAID anyway - but you are
correct; GRUB - or at least, grub-legacy - has a serious problem with
booting off of a RAID or logical volume. I believe grub2 is capable of
booting off of a logical volume - and logically, that would also signify
that it understands software RAID - but as said earlier, grub2 is a
nightmare. grub2 is a solution to a problem that didn't exist.

So yes, I fully concur that LILO does also have its advantages, and
quite frankly, I've always liked its simplicity.

[er1ch]

Am Wed, 01 Feb 2012 21:33:43 +0100 schrieb Aragorn:

> On Wednesday 01 February 2012 21:24, Martin conveyed the following to
> alt.os.linux.slackware...
>

[...]

> the Xen hypervisor. However, I too much preferred the simplicity and
> robustness of LILO over GRUB, and GRUB2 is a nightmare that I would
> prefer to avoid for as long as I can.

``nightmare´´ was *exactly* the word that popped into my mind when I
tried to learn GRUB2.

erich

[Chick Tower]

On 2012-02-02, Aragorn <str...@telenet.be.invalid> wrote:
> Yes, as I have mentioned. But all things considered, I think simply
> installing GRUB would be a lot easier. As long as it's grub-legacy,
> because I hate grub2. ;-)

Yeah, I've been wrestling a little with GRUB2 on a laptop. It seems to
be tricky, if not impossible, to put boot options in the order you
want if you have more than two distros installed. There is no
equivalent to menu.lst that you can edit to your satisfaction, or at
least it warns you not to do so. You have to modify configuration files
and generate a new grub.cfg.

Of course, this is a CrunchBang (based upon Debian) installation, so
perhaps it's just wrapped up in the typical Debian confuscated way of
doing things.
--
Chick Tower

For e-mail: aols2 DOT sent DOT towerboy AT xoxy DOT net

[Aragorn]

On Friday 03 February 2012 21:59, Chick Tower conveyed the following to
alt.os.linux.slackware...

No, this is the default modus operandi for modifying the grub2
configuration across all distribution. It really _is_ that bad. :p

[Kees Theunissen]

Last time I looked at it (on a debian squeeze, must have been around the
time it was released) GRUB2 would detect _and_include_in_the_boot_menu_
every partition on your system that seemed to be bootable. You had to
modify the scripts to exclude some partition(s). I understood that
"upstream" was working on this to make this configurable, so this might
be different now.

I hate this approach where you have to specify the exclusions instead
of the things to be done.

[Aragorn]

On Friday 03 February 2012 23:58, Kees Theunissen conveyed the following

to alt.os.linux.slackware...

> Aragorn wrote:
>
>> On Friday 03 February 2012 21:59, Chick Tower conveyed the following
>> to alt.os.linux.slackware...
>>

>>> It seems to be tricky, if not impossible, to put boot options in the
>>> order you want if you have more than two distros installed. There
>>> is no equivalent to menu.lst that you can edit to your satisfaction,
>>> or at least it warns you not to do so. You have to modify
>>> configuration files and generate a new grub.cfg.
>>>
>>> Of course, this is a CrunchBang (based upon Debian) installation, so
>>> perhaps it's just wrapped up in the typical Debian confuscated way
>>> of doing things.
>>
>> No, this is the default modus operandi for modifying the grub2
>> configuration across all distribution. It really _is_ that bad. :p
>
> Last time I looked at it (on a debian squeeze, must have been around
> the time it was released) GRUB2 would detect
> _and_include_in_the_boot_menu_ every partition on your system that
> seemed to be bootable. You had to modify the scripts to exclude some
> partition(s). I understood that "upstream" was working on this to make
> this configurable, so this might be different now.
>
> I hate this approach where you have to specify the exclusions instead
> of the things to be done.

Yes, but this, _and_ the fact that more and more GUI filemanagers for
GNU/Linux - such as KDE's Dolphin, et al - are now offering the
nonsensical volume-oriented approach to storage (as the default) in
favor of the logical and ever-transpararent UNIX file hierarchy view are
both concessions to and/or influences from Microsoft Windows usage.

Volume-oriented organization of storage made perfect sense back in the
days of personal computers and so-called home computers which didn't
have support for fixed disks - neither in software nor in hardware - and
used flat filesystems on floppy disks only, so the volume-oriented
approach offered the possibility of easily copying over a file from one
floppy disk to another one. Given that IBM's OS/2 was intended to be
the successor to DOS - which was a Microsoft product, albeit that it was
based upon CP/M - OS/2 retained this volume-oriented approach to
storage. Microsoft Windows was initially still based on DOS, but given
that Windows NT was based upon the design of OS/2, both designs
converged and still retained that volume-oriented approach to storage.

In UNIX, it makes no sense to have a filemanager offer you a choice to
directly look at whatever different filesystems you have, because at the
lowest level, each of those filesystems has its own root directory, but
given that this root directory is normally mounted to a directory
elsewhere in the logical file hierarchy with the "real" root directory
at the top, it only makes things more confusing. Yet, many of the newer
GNU/Linux developers all started off on Windows - because they're young
enough to have started their computing experiences in a time when
"Windows just came with the computer".

This has extended to the bootloader philosophy. Rather than sticking to
the multiboot specification that GRUB was initially intended to offer -
whereas LILO was explicitly developed for booting only a Linux kernel
and offering support for booting DOS - e.g. for flashing a BIOS et al,
which also came in handy for booting Windows, even though that was never
the intent - the GRUB developers have decided to look at all partitions
for something bootable, even logical partitions in an extended partition
container. This is done via the "osprober" script - it might be spelled
differently - which is executed together with a bunch of other scripts
under "/etc/grub.d" when you execute the "update-grub" script (or
whatever it's called).

Furthermore, the GRUB developers themselves have already stated -
whether this was tongue-in-cheek or serious is hard to tell - that they
consider GRUB to be the most important part of the system; more
important than the kernel or the C library or whatever. And in addition
to that, there was a lot of in-fighting among the GRUB developers on the
further evolution of GRUB as a bootloader, and, undoubtedly, coupled
with some ego manifestation.

The result is an incredibly atrocious way of configuring GRUB - whereas
GRUB's forte over LILO initially was that you could update it by simply
editing "/boot/grub/menu.lst" without having to run a binary tool
afterwards to save the changes to the MBR. But considering that "OS
prober", the Windows users are happy. After all, the distributions such
people tend to pick all boot into a GUI by default and cover up the
whole boot process - from the kernel's printk all the way through the
runlevel initialization - behind pretty splash screens à la Microsoft
and Apple. And they then have GUI tools for configuring GRUB and
running the scripts in the background.

The more developers are going to give in to Windows'isms and cater to
the Windows userbase, the more the quality, logical organization and
configurability of the GNU/Linux system is going to suffer. And in the
end, Microsoft will not only have corrupted its own operating system
designs, but all others as well. They can be proud of themselves over
how they've single-handedly managed to lower quality standards and user
expectations. But then again, that's about the only thing they /can/ be
proud of, and a sane mind wouldn't be proud of such feats.

But then again, let's not ever suspect Microsoft of possessing any
sanity. They're the root of all evil in IT, and I mean that, and to a
far more far-reaching extent than most people would ever suspect.

Time to get off my beercase again. ;-)