Re: Considerations for lilo removal
Mike Hommey <mh@glandium.org> writes:
> 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
That would require them to be continious and they often aren't.
Afaik lilo stores an array of extents (location, size). The number of
extens is limited but certainly > 1.
MfG
Goswin
Reply to: