Hello Ron,
[IMHO] in an less confusing and slightly pedantic world, a piece of code
living inside the MBR that can load a partition boot record would be
called a Boot Manager (whether it could load boot sectors from multiple
partitions or not), and the code in the PBR would be called the [OS]
Boot Loader. The BL would hide all OS specifics from the BM, and both
would be handled separately, i.e. would be installed by separate
programs. OpenBSD does this, using fdisk(8) for the MBR code vs.
installboot(8) for the PBR code.
If you're used to boot loaders like Lilo or GRUB, the OpenBSD
terminology can be quite confusing at first:
MBR "MBR bootcode"
PBR "first-stage bootstrap"
/boot "second-stage bootstrap"
"First stage" and "second stage" have different meanings here than with
the average boot loader such as GRUB or Lilo: the FSB can never be
installed in the MBR, because the PBR and MBR code are two different
things. All the MBR code can do, is to load a[n OpenBSD] PBR, and all
that the PBR code does is load "/boot". With most other boot loaders,
the two functionalities are merged into a single piece of code, which
can be installed either in the MBR or the PBR (with Lilo at least, I'm
not familiar enough with GRUB to be certain about that one). By the way,
OpenBSD's second stage boot loader is mildly fs-aware as well, because
it needs to access /etc/boot.conf.
Anyway, from the BM/BL point of view, GRUB displays the correct
behaviour, and what Lilo does is no less than horrible. At least not
when it is used the way that almost everyone does. But Lilo's maker
wrote a much more modular and very flexible program than the majority of
existing documentation suggests. Here's a Lilo setup that adheres to the
"BM/BL standard", and can be useful if you have more than one Linux
installation on a single disk.
Per-partition lilo.conf:
-------------------------------------------------------------------
boot=/dev/ROOTDEVICE
install=text
map=/boot/map
default=LABEL
image=/vmlinuz
label=LABEL
read-only
root=/dev/ROOTDEVICE
initrd=/initrd.img
-------------------------------------------------------------------
Usage:
- copy the thing to /etc/lilo.conf
- subsitute the keywords with their real values
- run 'lilo'
Global lilo.conf.mbr (example):
-------------------------------------------------------------------
boot=/dev/sda
map=/boot/map
install=menu
prompt
timeout=80
ignore-table
password=""
default=kubu
# Recovery section
#image=/mnt/MOUNTPOINT/vmlinuz
# label=LABEL
# read-only
# root=/dev/ROOTDEVICE
# initrd=/mnt/MOUNTPOINT/initrd.img
other=/dev/sda6
label=kubu
other=/dev/sda7
label=ubu
other=/dev/sda2
label=rescue
other=/dev/sda12
label=puppy
other=/dev/sda4
label=obsd
-------------------------------------------------------------------
Here, "kubu", "ubu", "rescue" and "puppy" are all Linuxes, booted from
"other" sections. This will cause the Lilo MBR code to load PBRs i.o.
kernel images.
The "recovery section" can be used temporarily to make an installation
bootable whose PBR is corrupted or (at install time) not recognized.
If you store lilo.conf.mbr on a shared partition that is/can be mounted
from all Linux installations, you can run lilo with this config from
each Linux installation with no fuss.
Usage:
- optional: store lilo.conf.mbr on a shared partition
- Run 'lilo -p -C /path/to/lilo.conf.mbr' (the '-p' is for the password)
Note that both 'lilo' commands above can be executed from the same
partition without interfering with each other (and also note the speed
with which the MBR code is written..).
Advantages:
- multibooting is set up in a more modular way, and modular == good
after all.
- having bootable code inside each PBR adds an extra recovery option
(it's never a bad idea to install Lilo - or GRUB, possibly - inside
the PBR as well as in the MBR).
- the MBR boot code that is actually executed is small, simple, and
therefore more reliable.
- because all OS-specific data is hidden behind the PBRs, the Lilo MBR
code can be replaced with some other boot manager without problems,
which again makes recovery a lot less trouble.
- a practical advantage: the annoying phase of being warned about files
not found, and subsequently having to mount all Linux partitions and
run lilo again (pffff...), is no longer there.
And there probably are a few more.. All in all, this setup will make
Lilo run like a very well-behaved Boot Manager / Boot Loader combo.
Almost "Grand and Unified";).
Bill
On Fri, 2007-04-27 at 15:23 -0400, Ron Watkins wrote:
> To fix this specific issue, the first thing I'd try would be another
> netboot, and then running the appropriate fscks for the filesystem(s) on
> the CF partition(s). That might be enough to get things straightened
> out and booting.
>
> More generally, are you using one of the extended filesystems as your
> boot partition? I generally find it's best to have /, /boot and /usr as
> ext3.... on a small CF like that, you'd likely want just one partition,
> which means ext3. You're probably not going to be doing much in the
> filesystem anyway (to avoid wear on the CF), so sticking with a simple,
> compatible format is usually the best idea. Reiser/XFS/JFS are great,
> but I prefer using them in non-system-critical partitions like /var,
> /tmp and /home.
>
> As far as why GRUB is throwing this error, complaining about the
> filesystem.... it's a design decision. It installs its bootsector only
> once, at installation time, and never touches it again. That boot stub
> uses the filesystem structures to find the next stage and the
> configuration file. This lets you boot arbitrary kernels from arbitrary
> partitions at the command line, which has saved my butt more than once.
> But it can obviously be confused by a bad filesystem, a problem LILO
> doesn't have
>
> LILO hardcodes the file locations on disk, so it doesn't care about the
> filesystem, but you can end up unbootable if you forget to rerun it. It
> will let you change boot arguments, but can't change the actual kernel
> that gets loaded; if a given kernel hasn't been hardcoded into the boot
> sector, you just flat can't run it. GRUB doesn't have that problem; it
> can load anything you like from any media that's visible from the BIOS.
>
> Further, I've seen many more bugs in LILO; there was a period about
> three years ago where I was very fearful of updating, as new versions
> broke constantly. Recovering from a bad LILO install is painful. GRUB
> is generally much easier to fix, and this is the first time I've seen it
> outright break.
>
> Overall, if you want to boot from something other than ext3, then LILO's
> hardcoded sectors will probably be easier to work with. With ext3, I
> think GRUB is a bit better.
>
> Bill Maas wrote:
> > Hello Andy,
> >
> > quick search on well-known search engine reveals a.o.:
> >
> > https://bugs.launchpad.net/grub/+bug/64928
> >
> > Admitted, I shun those monstrous GNU "manuals" as well, but typing "grub
> > error 16" in a search engine input box can't be that hard;).
> >
> > What a boot loader has to do with fs health remains a mystery to me, I
> > used to think that that was an OS boot issue. But grub seems to need
> > data from the fs. Maybe revert to good old reliable Lilo, or the new
> > EXTLINUX.
> >
> > Bill
> >
> >
> > On Thu, 2007-04-26 at 12:50 -0400, Andy Michaels wrote:
> >
> >> I finally got Debian to netboot and install to a 1GB flash card on a
> >> Net4801. After Debian installs, the reboot fails with this:
> >>
> >> GRUB loading stage 1.5
> >>
> >> GRUB loading please wait
> >> ERROR 16
> >>
> >> I installed GRUB to the MBR of the CF card. Should I not? I also created
> >> 2 partitions / is ext2 and /var is ext2 noexec noatime
> >>
> >> eventually, I'll mount / with noatime
> >>
> >> Anyone know how to get past this ERROR 16?
> >>
> >> Thanks!
> >>
> >> -Andy
> >> _______________________________________________
> >> Soekris-tech mailing list
> >> [email protected]
> >> http://lists.soekris.com/mailman/listinfo/soekris-tech
> >>
> >>
>
> _______________________________________________
> Soekris-tech mailing list
> [email protected]
> http://lists.soekris.com/mailman/listinfo/soekris-tech
>
--
"Fix bugs first, add features later"
_______________________________________________
Soekris-tech mailing list
[email protected]
http://lists.soekris.com/mailman/listinfo/soekris-tech
