Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
lilo/grub: hidden as a black art.
29 views
Skip to first unread message
no.to...@gmail.com
Apr 13, 2012, 10:30:21 AM4/13/12
to
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.
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.
Henrik Carlqvist
Apr 13, 2012, 3:04:55 PM4/13/12
to
I will do my best.
> 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'.
fdisk -l lists all your partitions, your BIOS will boot from a disk, not a
partition.
> Then <the instruction pointer is directed to> the beginning of THIS boot
> device [in old systems it was fixed at hda].
Yes, I suppose that is kind of how it is working.
> The executable code [before the up-to-four partition entries] in the MBR
> [1st 512B sector] of the boot-device
The MBR contains both executable code and the partition table.
> does: <find the FIRST bootable partition and 'continue' from there>,
> which is the 'boot-partition' of the boot-device.
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.
> 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? !!
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.
> OK I already see, confusion: can the boot-partition differ from the root [the
> partition which holds /] ?
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.
> 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?
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.
> So the sequence is:
> -> boot-device eg. sdb -> boot-partition eg. sdb2
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.
> 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?
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
> 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'.
partition.
> 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.
primary partition. Other bootloaders like lilo and grub might not care
about partitions.
> 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? !!
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.
> OK I already see, confusion: can the boot-partition differ from the root [the
> partition which holds /] ?
have its own partition. Once this could be necessary to make sure that the
kernel was placed at the beginning of the disk.
> 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?
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.
> So the sequence is:
> -> boot-device eg. sdb -> boot-partition eg. sdb2
configuration it is also possible to use a Microsoft MBR to boot Linux.
> 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?
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
Martin
Apr 13, 2012, 5:08:12 PM4/13/12
to
On 04/13/2012 09:04 PM, Henrik Carlqvist wrote:
> 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.
[...]
> 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.
> Nor does lilo care about if /etc is on a partition of its own.
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.
Kees Theunissen
Apr 13, 2012, 5:31:40 PM4/13/12
to
Henrik Carlqvist wrote:
>
> 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, I seem to remember something like that. That was an overly
>
> 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.
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.
John Reiser
Apr 14, 2012, 11:12:32 AM4/14/12
to
> The executable code [before the up-to-four partition
> entries] in the MBR [1st 512B sector] of the boot-device does:
The code in the MBR does whatever it pleases. This enables MBR-resident malware.
> entries] in the MBR [1st 512B sector] of the boot-device does:
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]
> 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?
Use dd to get the block(s). Copy+Paste them into a binary Elf32 ET_REL file.
> the asm-code] to move this process into the light out of
> dark-art; ..
> It could suitable/safetly be used to examine a USBstik?
[Pre-pend an Elf32_Ehdr onto the blocks.] Examine using gdb and "set arch i8086".
--
no.to...@gmail.com
Apr 15, 2012, 10:04:10 AM4/15/12
to
In article <TbmdnS_lXoI...@giganews.com>, John Reiser <jrei...@comcast.net> wrote:
> > The executable code [before the up-to-four partition
> > entries] in the MBR [1st 512B sector] of the boot-device does:
>
> 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
>
OK thanks, I had a look at those.
> > The executable code [before the up-to-four partition
> > entries] in the MBR [1st 512B sector] of the boot-device does:
>
> 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
>
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?].
> [snip]
> > 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?
>
> 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".
> --
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.
Joe
Apr 15, 2012, 5:37:30 PM4/15/12
to
On Sun, 15 Apr 2012 14:04:10 +0000 (UTC)
no.to...@gmail.com wrote:
>
> 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.
>
>
>
'Active'? A (one) partition can be marked as 'bootable', but as far as I
no.to...@gmail.com wrote:
>
> 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.
>
>
>
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
Richard Kettlewell
Apr 16, 2012, 4:11:48 AM4/16/12
to
Joe <j...@jretrading.com> writes:
> no.to...@gmail.com wrote:
>> 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.
>
> 'Active'? A (one) partition can be marked as 'bootable', but as far as I
> am aware, it is only Windows which bothers about that.
Some BIOSes will insist that at least one partition be marked bootable
> no.to...@gmail.com wrote:
>> 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.
>
> 'Active'? A (one) partition can be marked as 'bootable', but as far as I
> am aware, it is only Windows which bothers about that.
before booting from a disk. This is daft, of course.
--
http://www.greenend.org.uk/rjk/
0 new messages