[linux-lvm] SuSE/LVM boot problem

[linux-lvm] SuSE/LVM boot problem

[Marco Shaw]

I lost my floppy with lilo on it.  Now I have to reconstruct it.  I've
tried booting in rescue mode, but even the rescue SuSE CD doesn't appear to
have LVM support.

What can I do at this point?

Thanks,
Marco

Re: [linux-lvm] SuSE/LVM boot problem

[Michael Marxmeier]

> 
> I lost my floppy with lilo on it.  Now I have to reconstruct it.  I've
> tried booting in rescue mode, but even the rescue SuSE CD doesn't appear to
> have LVM support.
> 
> What can I do at this point?

Use the installation disk - it has LVM support while the Rescue disk has not.
You can boot from the 2nd CD-ROM into the old Yast, do a "expert install"
and switch to a shell.


Hope this helps
Michael

--
Michael Marxmeier           Marxmeier Software AG
E-Mail: mike@msede.com      Besenbruchstrasse 9
Phone : +49 202 2431440     42285 Wuppertal, Germany
Fax   : +49 202 2431420     http://www.msede.com/

Re: [linux-lvm] SuSE/LVM boot problem

[dgould]

On Tue, May 02, 2000 at 11:51:31AM +0000, Michael Marxmeier wrote:
> > 
> > I lost my floppy with lilo on it.  Now I have to reconstruct it.  I've
> > tried booting in rescue mode, but even the rescue SuSE CD doesn't appear to
> > have LVM support.
> > 
> > What can I do at this point?
> 
> Use the installation disk - it has LVM support while the Rescue disk has not.
> You can boot from the 2nd CD-ROM into the old Yast, do a "expert install"
> and switch to a shell.
> 

Be careful. I have found that the install disks are very happy to create
systems that cannot be booted because lilo does not know about lvm.

On this topic, what is needed to make lvm work for both / and /boot with
full lilo support? I think it somewhat limits the utility of lvm not to
be able to make a fully lvm system, and might be tempted to do some of
the heavy lifting if it is not too gruesome.

-dg

-- 
David Gould                                   dgould@suse.com
If simplicity worked, the world would be overrun with insects.

Re: [linux-lvm] SuSE/LVM boot problem

[Jan Niehusmann]

> On this topic, what is needed to make lvm work for both / and /boot with
> full lilo support? I think it somewhat limits the utility of lvm not to
> be able to make a fully lvm system, and might be tempted to do some of
> the heavy lifting if it is not too gruesome.

As lilo doesn't parse filesystems, it has to know the sector numbers of
the disk blocks that contain the kernel (and the second stage boot loader).

I can imagine two ways to make lilo work with lvm:

1) at install time (when you run /sbin/lilo), lilo maps the logical (lvm)
locations to physical locations and writes these to the boot block. The boot
code doesn't need to be changed.

2) lilo writes logical locations to the boot block (trivial). The boot
code needs to understand lvm. 

Option 2 is probably very difficult to do, as it requires to implement 
lvm handling in 16 bit code. Only read-only access is needed, but still,
it's probably a major project.

Option 1 is way easier to implement, but has one big disadvantage: Whenever
you move physical extents, you have to re-run lilo.


Both ways, you may end up with the kernel (or parts of it) moved to
a drive that's not accessible by lilo.  (while the 1024-cylinder-limit
is gone, there are still drives that are accessible by linux but not by
the bios, for example scsi drives on a controller without bios)

So, while I think it's fairly easy to make booting from lvm possible, there
are problems, and I don't know a solution for some of them.


Jan

Re: [linux-lvm] SuSE/LVM boot problem

[Heinz Mauelshagen]

Jan Niehusmann wrote:

> > On this topic, what is needed to make lvm work for both / and /boot with
> > full lilo support? I think it somewhat limits the utility of lvm not to
> > be able to make a fully lvm system, and might be tempted to do some of
> > the heavy lifting if it is not too gruesome.
>
> As lilo doesn't parse filesystems, it has to know the sector numbers of
> the disk blocks that contain the kernel (and the second stage boot loader).
>
> I can imagine two ways to make lilo work with lvm:

>
> 1) at install time (when you run /sbin/lilo), lilo maps the logical (lvm)
> locations to physical locations and writes these to the boot block. The boot
> code doesn't need to be changed.
>
> 2) lilo writes logical locations to the boot block (trivial). The boot
> code needs to understand lvm.
>
> Option 2 is probably very difficult to do, as it requires to implement
> lvm handling in 16 bit code. Only read-only access is needed, but still,
> it's probably a major project.
>
> Option 1 is way easier to implement, but has one big disadvantage: Whenever
> you move physical extents, you have to re-run lilo.
>
> Both ways, you may end up with the kernel (or parts of it) moved to
> a drive that's not accessible by lilo.  (while the 1024-cylinder-limit
> is gone, there are still drives that are accessible by linux but not by
> the bios, for example scsi drives on a controller without bios)
>
> So, while I think it's fairly easy to make booting from lvm possible, there
> are problems, and I don't know a solution for some of them.

Actually some of them are not solvable at all :-{(
LVM actually could try to deal with BIOS constraints but
this would be a real mess regarding multiple platforms.

IMHO it's not worth to put root on a logical volume because of the
above mentioned problems and because of the fact, that a root filesystem
of 300MB is only a fraction of a typical disks size of today and that it is big
enough
and therefore never has to be resized.

BTW: all of the commercial solutions i'm aware of just 'fake' root in a logical

             volume to eanble mirroring. This can be done in Linux with MD
anyway.

Heinz

Re: [linux-lvm] SuSE/LVM boot problem

[Ulf Bartelt]

Jan Niehusmann wrote:
> I can imagine two ways to make lilo work with lvm:
> 
> 1) at install time (when you run /sbin/lilo), lilo maps the logical (lvm)
> locations to physical locations and writes these to the boot block. The boot
> code doesn't need to be changed.
>
> 2) lilo writes logical locations to the boot block (trivial). The boot
> code needs to understand lvm.

While waiting for either 1 or 2 you could use 3:

3) Make /boot and / contiguous and remember not to move them until lvm
has a non-moveable flag. Calculate the physical start and the length in
sectors of /boot and /, fake them into your partition table and use
these "partition aliases" to boot and use these filesystems...
...and don�t forget to give lilo an append="..." line defining the real
geometry of your drive as linux�s geometry guessing will give strange
results with such aliases not starting on cylinder boundaries...
This hack works fine for me since end of november 1999.
Better explanations are at http://www.freenet.de/y.e.t.i./

Re: [linux-lvm] SuSE/LVM boot problem

[Andi Kleen]

On Tue, May 02, 2000 at 11:22:21PM +0200, Jan Niehusmann wrote:
> > On this topic, what is needed to make lvm work for both / and /boot with
> > full lilo support? I think it somewhat limits the utility of lvm not to
> > be able to make a fully lvm system, and might be tempted to do some of
> > the heavy lifting if it is not too gruesome.
> 
> As lilo doesn't parse filesystems, it has to know the sector numbers of
> the disk blocks that contain the kernel (and the second stage boot loader).
> 
> I can imagine two ways to make lilo work with lvm:
> 
> 1) at install time (when you run /sbin/lilo), lilo maps the logical (lvm)
> locations to physical locations and writes these to the boot block. The boot
> code doesn't need to be changed.

That's not very hard to do. You just need a FIPHYSBMAP ioctl. 

> 
> 2) lilo writes logical locations to the boot block (trivial). The boot
> code needs to understand lvm. 
> 
> Option 2 is probably very difficult to do, as it requires to implement 
> lvm handling in 16 bit code. Only read-only access is needed, but still,
> it's probably a major project.
> 
> Option 1 is way easier to implement, but has one big disadvantage: Whenever
> you move physical extents, you have to re-run lilo.
> 
> 
> Both ways, you may end up with the kernel (or parts of it) moved to
> a drive that's not accessible by lilo.  (while the 1024-cylinder-limit
> is gone, there are still drives that are accessible by linux but not by
> the bios, for example scsi drives on a controller without bios)

I would just add a ``bootable''/``non bootable'' attribute to a PV and a LV. 
When lilo runs it sets a ``bootable'' attribute on the LV, and when you try
to move a bootable LV onto a non bootable PV it complains. Not 100% bulletproof,
because it requires some user action to tag the PVs correctly, but better
than nothing.


-Andi

Re: [linux-lvm] SuSE/LVM boot problem

[Marco Shaw]

On Tue, 2 May 2000 dgould@suse.com wrote:

Well I just have the eval version so no 2nd CD.  I tried creating a lilo
disk with another system, but I guess lilo needs the same
boot.b/system.map files to create a lilo disk?

So now I'm left with creating lilo on a disk somehow with another
system...  How could I create it?  Otherwise, I could always install a
copy of SuSE 6.3 in a VMWare VM and create a disk there...

Marco


> On Tue, May 02, 2000 at 11:51:31AM +0000, Michael Marxmeier wrote:
> > > 
> > > I lost my floppy with lilo on it.  Now I have to reconstruct it.  I've
> > > tried booting in rescue mode, but even the rescue SuSE CD doesn't appear to
> > > have LVM support.
> > > 
> > > What can I do at this point?
> > 
> > Use the installation disk - it has LVM support while the Rescue disk has not.
> > You can boot from the 2nd CD-ROM into the old Yast, do a "expert install"
> > and switch to a shell.
> > 
> 
> Be careful. I have found that the install disks are very happy to create
> systems that cannot be booted because lilo does not know about lvm.
> 
> On this topic, what is needed to make lvm work for both / and /boot with
> full lilo support? I think it somewhat limits the utility of lvm not to
> be able to make a fully lvm system, and might be tempted to do some of
> the heavy lifting if it is not too gruesome.
> 
> -dg
> 
> 

Re: [linux-lvm] SuSE/LVM boot problem

[Michael Marxmeier]

Forwarded message from Andreas Dilger <adilger@turbolabs.com>

-------- Original Message --------
From: Andreas Dilger <adilger@turbolabs.com>
Message-Id: <200005030309.e4339BK11871@webber.adilger.net>
Subject: Re: [linux-lvm] SuSE/LVM boot problem
In-Reply-To: <20000502232221.A20803@gondor.com> "from Jan Niehusmann
at May 2,
 2000 11:22:21 pm"
To: Jan Niehusmann <list039@gondor.com>
Date: Tue, 2 May 2000 21:09:10 -0600 (MDT)

Jan writes:
> > On this topic, what is needed to make lvm work for both / and /boot with
> > full lilo support? I think it somewhat limits the utility of lvm not to
> > be able to make a fully lvm system, and might be tempted to do some of
> > the heavy lifting if it is not too gruesome.
> 
> I can imagine two ways to make lilo work with lvm:
> 
> 1) at install time (when you run /sbin/lilo), lilo maps the logical (lvm)
> locations to physical locations and writes these to the boot block. The boot
> code doesn't need to be changed.
> 
> Option 1 is way easier to implement, but has one big disadvantage: Whenever
> you move physical extents, you have to re-run lilo.
> 
> Both ways, you may end up with the kernel (or parts of it) moved to
> a drive that's not accessible by lilo.  (while the 1024-cylinder-limit
> is gone, there are still drives that are accessible by linux but not by
> the bios, for example scsi drives on a controller without bios)

I don't think that these limitations are very serious.  You can always
put some restrictions on how /boot is created under LVM (e.g. must be
contiguous or on a BIOS visible disk).  I assume it is possible with
lvcreate to force creation of an LV on a specific PV, at least.  With
the newer LILO, there is no longer the 1024 cylinder limit either, so
as long as the kernel is on a single disk, LILO can boot it.

It might be nice to allow LILO to boot from a mirrored /boot LV, by
having it internally think there are two kernels involved, or by
having it write slightly different boot sectors to the mirror drives
used (i.e. if we are using /dev/hda1 and /dev/hdb1 to mirror /boot,
LILO could go through /etc/lilo.conf once with root=/dev/hda and once
with root=/dev/hdb).  However, this is not a requirement at all - get
LILO to work with /boot in an LV, and you've won 90% of the battle.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of
antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               --
Dogbert

Re: [linux-lvm] SuSE/LVM boot problem

[dgould]

On Wed, May 03, 2000 at 09:38:25AM +0200, Michael Marxmeier wrote:
> Forwarded message from Andreas Dilger <adilger@turbolabs.com>
> 
> -------- Original Message --------
> From: Andreas Dilger <adilger@turbolabs.com>
> Subject: Re: [linux-lvm] SuSE/LVM boot problem
> To: Jan Niehusmann <list039@gondor.com>
> Date: Tue, 2 May 2000 21:09:10 -0600 (MDT)
> 
> Jan writes:
> > > On this topic, what is needed to make lvm work for both / and /boot with
> > > full lilo support? I think it somewhat limits the utility of lvm not to
> > > be able to make a fully lvm system, and might be tempted to do some of
> > > the heavy lifting if it is not too gruesome.
> > 
> > I can imagine two ways to make lilo work with lvm:
> > 
> > 1) at install time (when you run /sbin/lilo), lilo maps the logical (lvm)
> > locations to physical locations and writes these to the boot block. The boot
> > code doesn't need to be changed.
> > 
> > Option 1 is way easier to implement, but has one big disadvantage: Whenever
> > you move physical extents, you have to re-run lilo.

Yes. Would it be reasonable to have LVM tools check for this and warn
the user?

> > Both ways, you may end up with the kernel (or parts of it) moved to
> > a drive that's not accessible by lilo.  (while the 1024-cylinder-limit
> > is gone, there are still drives that are accessible by linux but not by
> > the bios, for example scsi drives on a controller without bios)
> 
> I don't think that these limitations are very serious.  You can always
> put some restrictions on how /boot is created under LVM (e.g. must be
> contiguous or on a BIOS visible disk).  I assume it is possible with
> lvcreate to force creation of an LV on a specific PV, at least.  With
> the newer LILO, there is no longer the 1024 cylinder limit either, so
> as long as the kernel is on a single disk, LILO can boot it.
> 
> It might be nice to allow LILO to boot from a mirrored /boot LV, by
> having it internally think there are two kernels involved, or by
> having it write slightly different boot sectors to the mirror drives
> used (i.e. if we are using /dev/hda1 and /dev/hdb1 to mirror /boot,
> LILO could go through /etc/lilo.conf once with root=/dev/hda and once
> with root=/dev/hdb).  However, this is not a requirement at all - get
> LILO to work with /boot in an LV, and you've won 90% of the battle.
> 
> Cheers, Andreas

Yes, this is what I was hoping for. I bring this up because I just
installed SuSE 6.4 _three_ times. Yast is happy to let you create /boot
on a LV. But Lilo isn't. Yast will also cheerfully create / on an LV.
But Lilo is still unsatisfied. So I gave up and made a partition table
and hard partitions etc. But, except for the lilo and boot/mounting
issue, I have no need of DOS partitions or partition table at all. It
would be quite nice to just let LVM manage _all_ the disks.

If I have understood this, we need the following to make this
work (some of this may already exist):

 - lvm needs to provide an way for other programs to translate logical
   blocks to physical

 - lvm needs to have a way of tracking/enforcing/satisfying the constraint
   that specified lvs need to be in the bios bootable physical area

 - lilo needs to understand about lvm and use the lvm provided ways to
   get physical mappings.

 - the kernel needs to be able to reconstruct enough of the lvm
   descriptors to mount / at boot time.

Anything I am missing?

Any of this already done/planned?

Any other thoughts?

-dg
 
-- 
David Gould                                   dgould@suse.com
If simplicity worked, the world would be overrun with insects.

Re: [linux-lvm] SuSE/LVM boot problem

[Andi Kleen]

On Wed, May 03, 2000 at 09:53:26AM -0700, dgould@suse.com wrote:
> If I have understood this, we need the following to make this
> work (some of this may already exist):
> 
>  - lvm needs to provide an way for other programs to translate logical
>    blocks to physical

A physical equivalent to FIBMAP. Not too hard to implement I think.  

> 
>  - lvm needs to have a way of tracking/enforcing/satisfying the constraint
>    that specified lvs need to be in the bios bootable physical area

That's pretty much impossible. How would e.g. LVM find out that the scsi
controller of disk X does not have a boot rom? You have to trust the user there.

> 
>  - lilo needs to understand about lvm and use the lvm provided ways to
>    get physical mappings.

That's complicated. Someone did a similar hack for RAID0, but LVM is more
complicated than MD RAID0. Better just supply the real block numbers to lilo
and rerun it as needed (LVM could warn about it) 

> 
>  - the kernel needs to be able to reconstruct enough of the lvm
>    descriptors to mount / at boot time.

That's handled in the initrd (lilo loads kernel + initrd, initrd contains
LVM tools) 


-Andi

Re: [linux-lvm] SuSE/LVM boot problem

[Christoph Hellwig]

Andi Kleen schrieb:
> > 
> >  - lilo needs to understand about lvm and use the lvm provided ways to
> >    get physical mappings.
>
> That's complicated. Someone did a similar hack for RAID0, but LVM is more
> complicated than MD RAID0. Better just supply the real block numbers to lilo
> and rerun it as needed (LVM could warn about it) 

Don't use lilo, use grub. I'm trying to implement lvm support in grub. The idea 
is that grub should read the first lvm on each pv. This first lv must be only on 
this pv. (and have a special name, eg lv_root, so grub can find it)

> > 
> >  - the kernel needs to be able to reconstruct enough of the lvm
> >    descriptors to mount / at boot time.

The kernel should know about all lvm descriptor and the /etc/lvm* should only be 
used for pvcreate an similar programs. 

	Christoph

Re: [linux-lvm] SuSE/LVM boot problem

[Andi Kleen]

On Wed, May 31, 2000 at 06:13:08PM +0200, Christoph Hellwig wrote:
> Andi Kleen schrieb:
> > > 
> > >  - lilo needs to understand about lvm and use the lvm provided ways to
> > >    get physical mappings.
> >
> > That's complicated. Someone did a similar hack for RAID0, but LVM is more
> > complicated than MD RAID0. Better just supply the real block numbers to lilo
> > and rerun it as needed (LVM could warn about it) 
> 
> Don't use lilo, use grub. I'm trying to implement lvm support in grub. The idea 
> is that grub should read the first lvm on each pv. This first lv must be only on 
> this pv. (and have a special name, eg lv_root, so grub can find it)

Limiting to the ``first LV'' sounds ugly. When you read the first, is it
that hard to read the second (and allow arbitary names)  ?

> 
> > > 
> > >  - the kernel needs to be able to reconstruct enough of the lvm
> > >    descriptors to mount / at boot time.
> 
> The kernel should know about all lvm descriptor and the /etc/lvm* should only be 
> used for pvcreate an similar programs. 

And who maintains that ? Using linuxrc and the normal LVM tools makes much
more sense IMHO. Just say no to kernel bloat.


-Andi

Re: [linux-lvm] SuSE/LVM boot problem

[Michael Marxmeier]

Andi Kleen wrote:
> 
> On Wed, May 31, 2000 at 06:13:08PM +0200, Christoph Hellwig wrote:
> > Andi Kleen schrieb:
> > > >
> > > >  - lilo needs to understand about lvm and use the lvm provided ways to
> > > >    get physical mappings.
> > >
> > > That's complicated. Someone did a similar hack for RAID0, but LVM is more
> > > complicated than MD RAID0. Better just supply the real block numbers to lilo
> > > and rerun it as needed (LVM could warn about it)
> >
> > Don't use lilo, use grub. I'm trying to implement lvm support in grub. The idea
> > is that grub should read the first lvm on each pv. This first lv must be only on
> > this pv. (and have a special name, eg lv_root, so grub can find it)
> 
> Limiting to the ``first LV'' sounds ugly. When you read the first, is it
> that hard to read the second (and allow arbitary names)  ?

You need to distinguish 'bootable' LV from others. This could either
be 
by LV name or a 'bootable' flag.  However if we need a flag anyway and 
could accept the restriction to have to root fs contigous on a single
PV
and non striped we could simply save the starting block and size as
well.
This is not that different from a partition.

For example HP-UX has a simple hack in the boot area which holds
the start and size of the /stand fs such that the boot loader
and the kernel could simply handle this as a partition equivalent
during boot.

It should be possible to detect this 'bootable' flag and the
start/size
in the LVM init code without causing much kernel bloat and create the 
equivalent of a partition using a fixed major/minor. vgscan could then 
in user space create the device files accordingly such that the 
major/minor of the LV holding the root fs is mapped accordingly.

AFAIR someone already did something similar by hacking the partition
table  and creating an overlapping partition which just happened to
map to the root LV.


Michael

-- 
Michael Marxmeier           Marxmeier Software AG
E-Mail: mike@msede.com      Besenbruchstrasse 9
Phone : +49 202 2431440     42285 Wuppertal, Germany
Fax   : +49 202 2431420     http://www.msede.com/

Re: [linux-lvm] SuSE/LVM boot problem

[Ulf Bartelt]

Michael Marxmeier wrote:
> AFAIR someone already did something similar by hacking the partition
> table  and creating an overlapping partition which just happened to
> map to the root LV.

someone == me.

It�d work if the root were the only partition but I preferred to do this
hack on /boot and /.


What do I gain?

I just refer /boot and / by the "partition aliases" in fstab and
lilo.conf and my system boots strictly conventional.

And when turning off lvm functionality becomes a must, the init.d-script
can safely switch lvm off and I�m still able to access /boot and /.

When the system crashes by eventually using wrong lvm tools, I still can
get up the essential file systems and insert the right lvm tools from
e.g. a floppy (I needed this once since 11-1999).


What do I loose?

/ and /boot appear as conventional partitions in all locations e.g. df
output. I cannot switch from partition alias to lvm addressing after the
system comes up. While not modifying the boot setup, /boot could be
mounted using the lv device, but I see no reason why this would make
sense...

Both partitions are flagged to be contiguous and <strong>I</strong> have
to remember, not to move them arround. I�d like to have a nonmoveable
flag in lvm instead...

If I�d resize or move /boot or /, I�d have to recalculate the faked
partition entries.

I have to tell the geometry of the boot drive to the kernel on booting
("append=" in lilo.conf is enough) cause the kernel guesses arround and
shows strange geometries if I do not...

As long as lvm is not launched and brought down by some kernel code like
the raid stuff, I thing this way is my favourite one...


Bye!
	Ulf.

Re: [linux-lvm] SuSE/LVM boot problem

[David Gould]

On Wed, May 31, 2000 at 11:01:28AM +0200, Andi Kleen wrote:
> On Wed, May 03, 2000 at 09:53:26AM -0700, dgould@suse.com wrote:
> > If I have understood this, we need the following to make this
> > work (some of this may already exist):
> > 
> >  - lvm needs to provide an way for other programs to translate logical
> >    blocks to physical
> 
> A physical equivalent to FIBMAP. Not too hard to implement I think.  

Yes. That is what I meant. 
 
> >  - lvm needs to have a way of tracking/enforcing/satisfying the constraint
> >    that specified lvs need to be in the bios bootable physical area
> 
> That's pretty much impossible. How would e.g. LVM find out that the scsi
> controller of disk X does not have a boot rom? You have to trust the user there.

Fine. Trusting the user is ok, but I like the marked bootable idea to
protect against arbitrary reconfigs.

> >  - lilo needs to understand about lvm and use the lvm provided ways to
> >    get physical mappings.
> 
> That's complicated. Someone did a similar hack for RAID0, but LVM is more
> complicated than MD RAID0. Better just supply the real block numbers to lilo
> and rerun it as needed (LVM could warn about it) 

I meant only that lilo needs to call the lvm flavored FIBMAP, to get the
block numbers. That is, lilo will need a small patch.

> >  - the kernel needs to be able to reconstruct enough of the lvm
> >    descriptors to mount / at boot time.
> 
> That's handled in the initrd (lilo loads kernel + initrd, initrd contains
> LVM tools) 

Ok.

-dg

-- 
David Gould                                                 dg@suse.com
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
C++ : an octopus made by nailing extra legs onto a dog

Re: [linux-lvm] SuSE/LVM boot problem

[Andreas Dilger]

David Gould writes:
> > Option 1 is way easier to implement, but has one big disadvantage: Whenever
> > you move physical extents, you have to re-run lilo.

> Yes. Would it be reasonable to have LVM tools check for this and warn
> the user?

You need to re-run LILO even if you move the kernel on a regular filesystem,
so I don't think it's that important if LVM doesn't warn you about this.
How often do you move LVs around anyways?  If you keep them in your /boot
LV and it's only a couple of PPs in size, it shouldn't be an issue.  Under
AIX, you are forced to have your boot LV contiguous (which I think LILO
doesn't need, as long as it is a single disk), and you are still required
to run "bosboot" if you move or mirror your BLV.

> If I have understood this, we need the following to make this
> work (some of this may already exist):
> 
>  - lvm needs to have a way of tracking/enforcing/satisfying the constraint
>    that specified lvs need to be in the bios bootable physical area

I think this can mostly be left up to the sysadmin for now.  I think if
LILO can handle LVs at all, it already complains if your kernel isn't
in a BIOS bootable area.

>  - lilo needs to understand about lvm and use the lvm provided ways to
>    get physical mappings.

How does LILO do this now?  It currently gets a filename for the kernel,
and that's it.  It must do some sort of internal calculation or IOCTL to
get the physical block numbers on the disk.  Is the problem that it does
its calculations w.r.t. the start of the partition?

>  - the kernel needs to be able to reconstruct enough of the lvm
>    descriptors to mount / at boot time.

You could always require that the / partition be contiguous, so it can
initially be mounted as ext2 directly.  If you want to resize your root
filesystem, you have to migrate the blocks after it to another location,
or move the whole LV to a contiguous region large enough for the new
size and re-run LILO.  I think it is already possible to specify an offset
into a block device for the / filesystem (think bootfloppy), so the kernel
could mount /dev/hda1 + X blocks read-only at boot, and when it goes to
mount read/write it remounts /dev/rootvg/lv00 as read-write.

I think I need to dig a bit more into the LILO code to see what's really
happening there.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] SuSE/LVM boot problem

[Eric M. Hopper]

[-- Attachment #1: Type: text/plain, Size: 3346 bytes --]

On Wed, May 03, 2000 at 12:09:03PM -0600, Andreas Dilger wrote:
> 
>> Yes. Would it be reasonable to have LVM tools check for this and warn
>> the user?

	One idea for making this happens is to have a way of locking
logical extents to physical extents so that you have to use a special
command to unlock them.  This kind of thing is already done in different
parts of LVM to make sure you don't delete logical volumes that are in
use, or remove physical volumes that still have extents allocated to
them.

	One this exists, altering lilo to detect LVM, and automatically
lock the necessary logical->physical extent mappings isn't too hard.

> You need to re-run LILO even if you move the kernel on a regular
> filesystem, so I don't think it's that important if LVM doesn't warn
> you about this.  How often do you move LVs around anyways?  If you
> keep them in your /boot LV and it's only a couple of PPs in size, it
> shouldn't be an issue.  Under AIX, you are forced to have your boot LV
> contiguous (which I think LILO doesn't need, as long as it is a single
> disk), and you are still required to run "bosboot" if you move or
> mirror your BLV.

	Well, the problem is that moving a few physical extents does not
obviously suggest re-running lilo.  Many physical extents are fine to
move, and trying to keep track of which physical extents lilo cares
about, and which one's it doesn't isn't a task I think a sysadmin should
have to deal with.

	The locking mechanism makes a sysadmin aware of when they're
moving something that lilo (or some other program that maintained
information about where stuff physically was) cared about, and re-run
the necssary utilities so than can regather the information they need.

> How does LILO do this now?  It currently gets a filename for the
> kernel, and that's it.  It must do some sort of internal calculation
> or IOCTL to get the physical block numbers on the disk.  Is the
> problem that it does its calculations w.r.t. the start of the
> partition?

	That's an interesting question, and I'm curious about it.  I
believe this also has implications for reiserfs /boot partitions.

>>  - the kernel needs to be able to reconstruct enough of the lvm
>>    descriptors to mount / at boot time.

	I don't believe this is a problem.  There is already something
called lvm_initrd that creates a ramdisk to load the lvm modules and
build the lvm devices so root can be mounted from an lvm device.  It
could be improved, but I have a suspicion this isn't a big problem.

	While I expected that /boot would have to be ext2fs, and
allocated a very generous 50M to it, I purposely compiled lvm into the
kernel in the hopes of one day having an lvm / parition.  Of course,
resizing an lvm / partition is a dicey affair.  :-)

> I think I need to dig a bit more into the LILO code to see what's
> really happening there.

	I think so too.  Sadly, though I have time to post here, I don't
have time to dig into lilo.

Have fun (if at all possible),
-- 
Its name is Public Opinion.  It is held in reverence. It settles everything.
Some think it is the voice of God.  Loyalty to petrified opinion never yet
broke a chain or freed a human soul.     ---Mark Twain
-- Eric Hopper (hopper@omnifarious.mn.org  http://omnifarious.mn.org/~hopper) --

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] SuSE/LVM boot problem

[Andreas Dilger]

Eric M. Hopper writes:
> 	One idea for making this happens is to have a way of locking
> logical extents to physical extents so that you have to use a special
> command to unlock them.  This kind of thing is already done in different
> parts of LVM to make sure you don't delete logical volumes that are in
> use, or remove physical volumes that still have extents allocated to
> them.

> 	One this exists, altering lilo to detect LVM, and automatically
> lock the necessary logical->physical extent mappings isn't too hard.

> 	Well, the problem is that moving a few physical extents does not
> obviously suggest re-running lilo.  Many physical extents are fine to
> move, and trying to keep track of which physical extents lilo cares
> about, and which one's it doesn't isn't a task I think a sysadmin should
> have to deal with.

I agree.  If it is possible/easy to already do this, I would say do it.
I'm also saying that if it isn't possible (or if it is, but it's a lot
of work), then it isn't really a show stopper.  People don't often move
their kernels around, and if they do, there is no indication that LILO
should be run either.  The /boot filesystem (or / if no /boot) is special
in other ways as well, and I don't think many sysadmins will have a problem
with remembering not to move it.

> 	While I expected that /boot would have to be ext2fs, and
> allocated a very generous 50M to it, I purposely compiled lvm into the
> kernel in the hopes of one day having an lvm / parition.  Of course,
> resizing an lvm / partition is a dicey affair.  :-)

Why do you say that?  You can resize it while it is mounted:
http://ext2resize.sourceforge.net/

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] SuSE/LVM boot problem

[dgould]

On Wed, May 03, 2000 at 05:50:57PM -0600, Andreas Dilger wrote:
> Eric M. Hopper writes:
> > 	One this exists, altering lilo to detect LVM, and automatically
> > lock the necessary logical->physical extent mappings isn't too hard.
> 
> > 	Well, the problem is that moving a few physical extents does not
> > obviously suggest re-running lilo.  Many physical extents are fine to
> > move, and trying to keep track of which physical extents lilo cares
> > about, and which one's it doesn't isn't a task I think a sysadmin should
> > have to deal with.
> 
> I agree.  If it is possible/easy to already do this, I would say do it.
> I'm also saying that if it isn't possible (or if it is, but it's a lot
> of work), then it isn't really a show stopper.  People don't often move
> their kernels around, and if they do, there is no indication that LILO
> should be run either.  The /boot filesystem (or / if no /boot) is special
> in other ways as well, and I don't think many sysadmins will have a problem
> with remembering not to move it.

I agree with the statment "I don't think many sysadmins will have a
problem", however this does not address the typical desktop or home user.

They basically do not have a sysadmin, so mechanisms that rely on a savy
sysadmin avoiding disaster (ie, won't boot) are not suitable for a large
population of potential users. These are the same people who don't know
how to use fdisk safely, and who have no idea of how to lay out
filesystems. That is, the people who could really appreciate being able
to turn over all the storage to lvm so they can just add a disk and
extend their filesystems onto it when they need more space without
worrying about the details.

> Why do you say that?  You can resize it while it is mounted:
> http://ext2resize.sourceforge.net/

Cool.

-dg
 
-- 
David Gould                                   dgould@suse.com
If simplicity worked, the world would be overrun with insects.

Re: [linux-lvm] SuSE/LVM boot problem

[Michael Loftis]

On Wed, 3 May 2000 dgould@suse.com wrote:

> I agree with the statment "I don't think many sysadmins will have a
> problem", however this does not address the typical desktop or home user.
> 
> They basically do not have a sysadmin, so mechanisms that rely on a savy
> sysadmin avoiding disaster (ie, won't boot) are not suitable for a large
> population of potential users. These are the same people who don't know
> how to use fdisk safely, and who have no idea of how to lay out
> filesystems. That is, the people who could really appreciate being able
> to turn over all the storage to lvm so they can just add a disk and
> extend their filesystems onto it when they need more space without
> worrying about the details.

Which is something that eats me.  Why?  Because there is no reason for
people who have no idea what they are doing, or have no WANT to know what
they are doing, to be mucking around in Unix.  If we keep adding
"features" to make it "easier to use" eventually we'll have bloat and be
just like Windows.  It makes the software over-complicated and isn't
necessary.

Just my $.0001 worth

> 
> > Why do you say that?  You can resize it while it is mounted:
> > http://ext2resize.sourceforge.net/
> 
> Cool.
> 
> -dg
>  
> -- 
> David Gould                                   dgould@suse.com
> If simplicity worked, the world would be overrun with insects.
> 
> 

Re: [linux-lvm] SuSE/LVM boot problem

[Eric M. Hopper]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Wed, May 03, 2000 at 05:50:57PM -0600, Andreas Dilger wrote:
> 
> Why do you say that?  You can resize it while it is mounted:
> http://ext2resize.sourceforge.net/

	Thanks for pointing this out to me.  I had been illegally using
Partition Magic's utility.  :-)  Although, I may very well buy a copy of
that program because it's so useful.

Have fun (if at all possible),
-- 
Its name is Public Opinion.  It is held in reverence. It settles everything.
Some think it is the voice of God.  Loyalty to petrified opinion never yet
broke a chain or freed a human soul.     ---Mark Twain
-- Eric Hopper (hopper@omnifarious.mn.org  http://omnifarious.mn.org/~hopper) --

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: [linux-lvm] SuSE/LVM boot problem

[Shaw, Marco]

You've all seen this?

http://lwn.net/980514/a/resizefs.html

Marco

> -----Original Message-----
> From:	Eric M. Hopper [SMTP:hopper@omnifarious.mn.org]
> Sent:	May 3, 2000 11:38 PM
> To:	Linux LVM mailing list
> Subject:	Re: [linux-lvm] SuSE/LVM boot problem
> 
> On Wed, May 03, 2000 at 05:50:57PM -0600, Andreas Dilger wrote:
> > 
> > Why do you say that?  You can resize it while it is mounted:
> > http://ext2resize.sourceforge.net/
> 
> 	Thanks for pointing this out to me.  I had been illegally using
> Partition Magic's utility.  :-)  Although, I may very well buy a copy of
> that program because it's so useful.
> 
> Have fun (if at all possible),
> -- 
> Its name is Public Opinion.  It is held in reverence. It settles
> everything.
> Some think it is the voice of God.  Loyalty to petrified opinion never yet
> broke a chain or freed a human soul.     ---Mark Twain
> -- Eric Hopper (hopper@omnifarious.mn.org
> http://omnifarious.mn.org/~hopper) --