[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Considerations for lilo removal



On Mon, Jun 16, 2008 at 10:53:22AM +0200, Goswin von Brederlow wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > On Mon, Jun 16, 2008 at 02:27:11AM -0500, William Pitcock wrote:
> >> Hi,
> >> 
> >> On Mon, 2008-06-16 at 07:20 +0000, Sune Vuorela wrote:
> >> > On 2008-06-16, William Pitcock <nenolod@sacredspiral.co.uk> wrote:
> >> > > That doesn't strike me as a valid configuration. Infact, it shouldn't
> >> > > work with lilo because lilo wants /boot to be on a real device. The fact
> >> > > that it does should be considered a bug, not a feature.
> >> > 
> >> > lilo-22.8$ head debian/patches/01_devmapper.dpatch
> >> > #! /bin/sh -e
> >> > ##
> >> > ## All lines beginning with `## DP:' are a description of the patch.
> >> > ## DP: Patch to make lilo understand device-mapper block devices.
> >> > ## DP: Bug#229932
> >> > 
> >> 
> >> That patch only makes lilo map LVMs to an appropriate physical device.
> >> It does not guarantee that you will be able to boot off of an LV on a
> >> physical volume. As such, the behaviour is still undefined.
> >> 
> >> Consider a situation where /boot spans multiple PVs, and you will see
> >> lilo fail to boot the system correctly.
> >> 
> >> If /boot happens to be on a single PV, then it will work, but it is
> >> still not guaranteed.
> >
> > Il will only work if all extents containing initramfs and kernel are
> > contiguous and ordered on the physical volume.
> >
> > Mike
> 
> Why? Lilo looks up the block addresses of the file on the disk. Having
> the LV fragmented into several segments is no different from having
> the file fragmented in the filesystem.

AFAIK, lilo only stores the start of initrd and kernel images in CHS
form.

Mike


Reply to: