Correct my assumptions  -- please.

The BIOS [memory] [can in modern PC's] detect the set of
potentially bootable devices [like `fdisk -l`] and allow the
user to select one as 'the boot device'.

Then <the instruction pointer is directed to> the beginning of
THIS boot device [in old systems it was fixed at hda].

The executable code [before the up-to-four partition
entries] in the MBR [1st 512B sector] of the boot-device does:
<find the FIRST bootable partition and 'continue' from there>,
which is the 'boot-partition' of the boot-device.

SO does that mean that if your 'factory setup PC' has
root = hda3  and you use `cfdisk` to set hda2 as bootable,
then with hda2 a non-bootable eg. pure data, you've LOST
booting ability? !!
--------------
OK I already see, confusion: can the boot-partition differ
from the root [the partition which holds /] ?
Of course; else there'd be no need to specify both.
But what happens if /etc/ [for lilo] or /boot [for grub]
and on different partitons than "/", which apparently
is allowed?  Is it allowed?
-----------

So the sequence is:
-> boot-device eg. sdb -> boot-partition eg. sdb2
-> but the 1st sector of sdb2 has limited size, and the next
stage must be able to be directed to load and run arbitrarily
large code; eg. since the args in lilo/grub are any size.
Of these args, 'boot' and 'root' can be compactly decoded into
the MBR/s, as implied above; but eg. the kernel-path-ID
will have to be indirectly read from a compactly addressed
location in the MBR/s.

So 'boot' and 'root' are 'compiled' into the 1st sector of the
appropriate partitions. But eg. the kernel path-name is
interpreted. In grub, the user can edit the TEXT, which grub
will interpret.

So with lilo: can the user edit the kernel path-name in
/etc/lilo.conf and NOT 'run lilo' if 'boot' & 'root' are not
to be changed?
--------------
The code that's fetched from the:
-> boot-device:sdb -> boot-partition:sdb2 -> next-stage,
is the first of the chain which is not constrained by part of
a 512byte-sector, and the first one able to have the freedom
to read where the lilo/grub <config files> are.

I'd like to find some script, which traces through [simulates
the asm-code] to move this process into the light out of
dark-art; ..
It could suitable/safetly be used to examine a USBstik?

== TIA.

I will do my best.

fdisk -l lists all your partitions, your BIOS will boot from a disk, not a
partition.

Yes, I suppose that is kind of how it is working.

The MBR contains both executable code and the partition table.

That is the way a Microsoft MBR works, it continues from the active
primary partition. Other bootloaders like lilo and grub might not care
about partitions.

I am not very familiar with grub, but lilo will not care about which
primary partition is marked as active (bootable). Lilo will be pointed to
the kernel and it might give the root partition as an argument to the
kernel.

I have some vauge memory of some computer which refused to boot unless
some primary partition were set as active even though I was using lilo.
But I don't remember for sure if lilo then was booting Windows or if it
was some bios limitation.

Yes, it is possible to create a directory /boot and that directory might
have its own partition. Once this could be necessary to make sure that the
kernel was placed at the beginning of the disk.

I can't talk for grub, but lilo allows you to have /boot on a separate
partition. In fact, lilo allows you to have your kernel in any directory
of your choise. Just make sure that your lilo.conf has that directory,
something like this:

image = /my/odd/place/for/a/kernel/vmlinuz

Nor does lilo care about if /etc is on a partition of its own. However you
might be able to boot your kernel with /etc on its own partition, but init
will not be able to mount partitions if it can't read /etc/fstab and run
scripts in /etc/rc.d. During the boot process init will start by reading
/etc/inittab.

It is possible to place lilo into a partition instead of MBR. With such a
configuration it is also possible to use a Microsoft MBR to boot Linux.

If you make any changes to lilo.conf you will have to run lilo. You will
also have to run lilo if you repalce your kernel even if the new kernel
has the same name and path as before.

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

On 04/13/2012 09:04 PM, Henrik Carlqvist wrote:

[...]

The reason being that lilo boot time doesn't give a hoot about
partitions and filesystems because every disk read has been translated
by lilo install time to sector ranges using ioctl FIBMAP. That's the
major difference to grub which includes file system drivers at boot time.

Yes, I seem to remember something like that. That was an overly
restrictive BIOS doing some MBR validation checking than has to be done
by the boot-code on the MBR not by the BIOS.

Regards,

Kees.

--
Kees Theunissen.

The code in the MBR does whatever it pleases.  This enables MBR-resident malware.

In general the code in the MBR finds and loads and transfers control
to more (and longer) code.  The location of the additional code varies.
It can be a hard-coded list of absolute sector extents (starting sector #,
length) on the same drive [might be sectors 2 through 63 immediately
following the MBR], an implicit extent (such as the first two sectors
of an ext2 filesystem, which are reserved for a boot block) on some
partition that is marked with a 'boot' flag in the partition info, etc.
With careful coding, (512 - 4*16 - 2)+1024 bytes of MBR+bootblock
is enough to implement lookup by pathname on ext2, combined with loading
a kernel and initrd (initial ramdisk).  See:
   http://bitwagon.com/ftp/e2boot4c.tgz
   http://bitwagon.com/ftp/mbr03.tgz

[snip]

Use dd to get the block(s).  Copy+Paste them into a binary Elf32 ET_REL file.
[Pre-pend an Elf32_Ehdr onto the blocks.]  Examine using gdb and "set arch i8086".

--

OK thanks, I had a look at those.
But I don't, at this time, want to by-pass lilo/grub.
Even they & linux use the existing M$loth INT [19 ? is it?].

OK thanks, I had a look at those.
But I don't, at this time, want to by-pass lilo/grub.
Even they & linux use the existing M$loth INT [19 ? is it?].
-----------------
I dissasembled the bytes decades ago.
Now I want to use clear-logic to evolve a debugging strategy
to show which 'stages' have succeeded.
A current fad of mine is opposing: klikA, klikB, klikC; explanations.
And even more so: random 'tips'.
We need an explanation: 1 -> 2 ->3.......N, for tasks which are
essentially 'serial'; which many tasks in life are.
This notion relates also to *nix-piping and to 'concatenative
programming', where, if it's OK at stage 7, you don't NEED to
be concerned/confused by the previous 6 stages.

I want a THEORETICAL essential understanding, [like a maths
theorem] and not a vague set of memories of how is actually
is/was.   So eg., IF the BIOS allows selection between:
1. <a name representing sda>
2. <a name representing sdb>
3. <a name representing sdc>
 THEN that stage can only take you to the MBR [1st sector]
 of either of these 3 listed/selectable devices.
This selection of the MBR of 1 of N devices is before the
running and unkown to lilo/grub.

But lilo/grub must have 'marked' the specific MBR, to say
"this is where" you go next. And IIRC, with the old/classical
method, that could only be <which one of 4 partitions>.
Perhaps that's why I had to use a fd0 to boot ETHO at hdx40.
But we know that's WRONG!

I still didn't get an answer to by claim that since conventionaly
the first code in the MBR, looks for the first active partition;
IF `cfdisk` say, had set hda2 to active, while running hda3:
the previously first active partition; THEN on the next boot
hda3 would effectively be hidden/masked by hda2 been found
as active BEFORE hda3. And normal booting would have been
destroyed. Is this correct or not?

That's what a mean by [an attempt at] a logical/theoretical
claim vs. vague memories of how-it-actually-is/was.

On Sun, 15 Apr 2012 14:04:10 +0000 (UTC)

'Active'? A (one) partition can be marked as 'bootable', but as far as I
am aware, it is only Windows which bothers about that. I'm not even sure
the Vista/Win7 bootloader does, I've done little multi-boot work since
XP arrived. That still wanted the first partition it could see (i.e.
having an MS partition type) to be marked bootable, or else the toys
went out of the pram. I think what you describe was indeed how
multi-booting worked when IBM set the four-partition limit (who needs
more than four operating systems?), but that was a long time ago, when
you got 2.5MB on a 12-inch disc platter.

Use the source, Luke. The lilo source is still available, along with
that of grub2 and possibly the first grub. Don't ask the monkey when
the organ-grinder is standing there.

--
Joe

Some BIOSes will insist that at least one partition be marked bootable
before booting from a disk.  This is daft, of course.

--
http://www.greenend.org.uk/rjk/