Re: /usr/lib vs /usr/libexec
On Wednesday 11 May 2005 00:55, GOMBAS Gabor <email@example.com> wrote:
> On Tue, May 10, 2005 at 11:16:54AM +0200, Bernd Eckenfels wrote:
> > the bootloader does not need to access the root filesystem. It only loads
> > the kernel and the initrd from /boot.
> (I assume that /boot is on /. If not, the following still applies to
Of course /boot only really needs to be about 20M in size. It can be
read-only mounted most of the time (or even entirely umounted), so it's in an
entirely different category to the rest of the system.
> Well, grub _does_ access the filesystem directly so it needs explicit
> support for every filesystem you want to boot from.
On the system I use to write this email (Fedora):
So I guess that GRUB supports XFS and ReiserFS.
Incidentally if you have a separate partition for /boot (as some people
recommend doing for reliability issues) then XFS and ReiserFS are bad options
due to the journals which have overly large minimum sizes. Ext2/3 really is
the best option for a /boot file system. It's only when /boot is on the root
file system that some other file system may be desired.
> I think reiserfs is
> OK nowadays (I do not use it so I'm not sure). xfs + lilo (from the
> XFS FAQ):
> No, for root partition installations because the XFS superblock
> is written at block zero, where LILO would be installed. This is
> to maintain compatibility with the IRIX on-disk format, and will
> not be changed.
The simple solution to this is that you don't install LILO on the first block
of the partition but instead you install it as the boot block of the hard
disk (IE use /dev/hda instead of /dev/hda1 or whatever).
If you wanted to use LILO with XFS and LVM then I guess that you would have to
put the LILO boot block on /dev/hda anyway.
The only reason for installing the LILO boot block onto /dev/hda1 instead
of /dev/hda is for a software RAID-1 installation where you want to have the
Debian-MBR on /dev/hda and /dev/hdc while /dev/hda1 and /dev/hdc1 have the
LILO boot blocks. Apart from that I recommend putting the LILO boot loader
in the partition table.
> lvm, raid0, raid5: the boot loader must understand the lvm/raid
> descriptors to be able to determine where to load the kernel/initrd from
> (and in case of raid5, it has to be able to reconstruct the data using
> the parity disk if one of the non-parity chunks is inaccessible). AFAIK
> neither lilo nor Grub supports these.
Here is the relevant section of the lilo changelog regarding LVM:
lilo (1:22.6.1-4) unstable; urgency=high
- Rewrote. Now it adds LVM partitions as a secure partition type to
LILO in, while leaving the warning for really dangerous partition types.
It also removes the prompt when the user wants to install LILO on a
- Never set to 'false' lilo/runme template. (Closes: #284929)
-- Andr<C3><A9>s Rold<C3><A1>n <firstname.lastname@example.org> Thu, 9 Dec 2004
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page