Date: Mon, 12 Nov 2001 22:10:15 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-mobile@FreeBSD.ORG Subject: Re: Two FreeBSDs on same disk, booting secondary slice? Message-ID: <20011112221015.G39804@shell.gsinet.sittig.org> In-Reply-To: <XFMail.011112080833.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Mon, Nov 12, 2001 at 08:08:33AM -0800 References: <3BEF1290.2663.3F79F2@localhost> <XFMail.011112080833.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 12, 2001 at 08:08 -0800, John Baldwin wrote:
>
> boot0 can boot Linux, but it is the 'same by default' problem that is
> killing you here. If you used that feature with boot0, this would
> break as well. The problem is that when boot1 is loaded, it has no
> idea where it was loaded from, so it has to have a way of finding the
> slice it came from. As I explained earlier, we use the active slice
> over other slices to help in the case of multiple FreeBSD slices.
Interesting to know (better: to learn). I take it I never
noticed any problem since I boot my machine by means of booteasy?
My conclusion is that booteasy moves the "active" flag to the
selected partition and offers the active one as the default to
boot? Not that I think this would be wrong. It's just good to
know. And I'm sure it is by design. And yes, I'm aware of the
fact that any boot loader has some limitations mostly because of
size constraints (512 - 2 - 64 bytes isn't too much room for
code).
> However, LILO and boot0 both use the active slice as their default
> slice, so for the default slice to always be the same, it has to not
> change the active slice in teh MBR when it boots.
No! LILO is a completely different beast. You _somehow_ get to
LILO -- either because
- it lives in the MBR or
- the MBR is the default one and LILO lives in the boot sector of
the active partition (usually: one of the Linux partitions, /
or /boot) or
- because you copy over the above boot sector to your DOS drive
and tell the NT loader about the new boot option
to cut it short: You activate LILO's boot code in *any* way, no
matter how long the chain is to get there.
Once you're there, LILO can
- load any of the configured kernels into memory and jump into
them (that's why you have to collect the mapping, LILO itself
doesn't know about file systems but BIOS geometry only)
- jump into any boot sector like floppies, CDROMs, drives with
removable media, or neighbourhood partitions
That's the upside(id?) and the downside of running LILO: it
doesn't need to know anything about the filesystem(s) the images
live in. But you have to "compile" configuration changes into
the map file.
In any case there's a fix(!) default. There's *no* MBR / PTable
munging! After "installation" or "update" by means of running
lilo(8) all the LILO boot code has is a pointer to a map file and
the map file holds options plus a list of BIOS accessible blocks
for any kernel image available as an option. LILO is just one
step in a chain leading forward only. No traces are left in the
system documenting or storing which option was selected (short of
passing them as variables to the Linux kernel and thus Linux'
boot scripts).
BTW: There's one interesting feature: A one time target (see
"lilo -R") which is to be booted by default the next time around
while keeping the usual default boot option. This one is _very_
handy when updating kernels or temporarily switching over to a
second system (maintenance, rescue, remote administration, or the
like).
I'm not positive about LILO's capability to mark the selected
boot target as the "active" partition. Since I know that LILO
can swap BIOS drives and does the silly Windows partition hiding
game I could imagine there's some way to flag partitions as
active. It might not be default behaviour, but could be
available upon request. But since I shutdown my last Linux
machine some months ago, I cannot look it up ATM. :)
> If you know Forth, you can write a Forth function [ ... ]
That's another option, of course. :)
> The other question is why you are
> putting 4.3 and 4.4 on separate slices. Why not just go with 4.4?
> That's about like trying to run Windows 95 and Windows 98 on the
> system in two different partitions.
I can imagine that running -STABLE and -CURRENT in a dual boot
configuration is the more common situation. But since everybody
is told to check wether things run well before upgrading
production environments, I do see the point in running a proven
-RELEASE or -STABLE and a test environment with another -STABLE
system in parallel ... Just a thought. Mostly since I'm in
the very same situation ATM, having a configured 4.3 system I
made myself comfortable at (in?) while having a 4.4 system
alongside I'm tinkering around with without being (too) sorry in
case things go wrong and get screwed up ...
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011112221015.G39804>