SuSE/LVM boot problem
Forwarded message from Andreas Dilger <[email protected]>
-------- Original Message --------
From: Andreas Dilger <[email protected]>
Message-Id: <[email protected]>
Subject: Re: [linux-lvm] SuSE/LVM boot problem
In-Reply-To: <[email protected]> "from Jan Niehusmann at May 2,
2000 11:22:21 pm"
To: Jan Niehusmann <[email protected]>
Date: Tue, 2 May 2000 21:09:10 -0600 (MDT)
Quoted 11 lines · Jan
Quoted 4 lines
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.
Quoted 7 lines
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
Signature · 5 lines
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/ --
DogbertQuoted 22 lines · Michael Marxmeier
Forwarded message from Andreas Dilger <[email protected]>
-------- Original Message --------
From: Andreas Dilger <[email protected]>
Subject: Re: [linux-lvm] SuSE/LVM boot problem
To: Jan Niehusmann <[email protected]>
Date: Tue, 2 May 2000 21:09:10 -0600 (MDT)Quoted 13 lines · Jan
Quoted 4 lines
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?
Quoted 20 lines
Quoted 4 lines
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/hda1and/dev/hdb1to mirror /boot, LILO could go through/etc/lilo.confonce 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.
Quoted 1 line
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
Signature · 2 lines
David Gould [email protected] If simplicity worked, the world would be overrun with insects.
Quoted 5 lines · On Wed, May 03, 2000 at 09:53:26AM -0700, [email protected] 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.
Quoted 3 lines
- 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.
Quoted 3 lines
- 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)
Quoted 3 lines
- 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
Quoted 7 lines · Andi Kleen
Quoted 3 lines
- 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)
Quoted 3 lines
Quoted 3 lines
- 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
Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · Andi Kleen
Quoted 3 lines
- lilo needs to understand about lvm and use the lvm provided ways to get physical mappings.
Quoted 7 lines
Quoted 3 lines
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) ?
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
- 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
Quoted 11 lines · Andi Kleen
Quoted 9 lines · Christoph Hellwig
Quoted 7 lines · Andi Kleen
Quoted 3 lines
- 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)
Quoted 6 lines
Quoted 3 lines
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
Signature · 4 lines
Michael Marxmeier Marxmeier Software AG E-Mail: [email protected] Besenbruchstrasse 9 Phone : +49 202 2431440 42285 Wuppertal, Germany Fax : +49 202 2431420 http://www.msede.com/
Quoted 3 lines · Michael Marxmeier
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.
Quoted 8 lines · Andi Kleen
Quoted 5 lines · On Wed, May 03, 2000 at 09:53:26AM -0700, [email protected] 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.
Quoted 5 lines
Quoted 2 lines
- 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.
Quoted 6 lines
Quoted 2 lines
- 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.
Quoted 5 lines
Quoted 2 lines
- 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
Signature · 3 lines
David Gould [email protected] SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380 C++ : an octopus made by nailing extra legs onto a dog