Luca Berra wrote: > lilo does not read a partition. all that lilo needs is to > be able to create a mapping from a file to the physical sectors > on the drive, and guess the BIOS id of that drive. ... and use BIOS (?) to load in the sectors containing the kernel, initrd, etc... before passing off execution to it? Anyway, now I believe I understand what you were trying to get at earlier: > confusion between a boot loader (which is the only limitation > we have in loading a kernel/initrd/initramfs) and what the kernel > can do. In order for things to work if /boot resides in a non-physical (e.g. RAID1, RAID0, lvm, etc...), LILO itself has to know how to read the contents of /boot off of that type of partition. Having lvm/md autodetect on the kernel will NOT help LILO (it will, however, eliminate the need for an initrd). > I insist initrd is not an hassle, it is good programming > practice. This means code separation between kernel-space > and user space, and the linux kernel is moving _that_ way. Yes, I do find myself agreeing with your general sentiments. The primary concern, to do away with the need to have a separate /boot partition, is not helped at all if the kernel can autodetect lvm partitions. Dispensing with the need for an initrd is but a secondary concern, and fact is, I would also say that it brings a lot of flexiblity to the table. So no, having lvm autodetect in the kernel is not what I'm looking for. What we're looking for is good lvm support in LILO. -- reply-to: a n d y @ n e o t i t a n s . c o m _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
