Re: [linux-lvm] booting w/o initrd

Re: [linux-lvm] booting w/o initrd

[Andreas Dilger]

Ulf writes:
> Imagine a LV lying in some VG of your PV.
> This LV has to be allocated in a continuous range of PEs, especially it
> must not cross the border between two disks.  With these requirements
> fullfilled, the LV could be described completely by the number of
> the its beginning sector on the disk and its length in sectors.

This is what IBM also needs for its "boot LV".  It is required that the
BLV is contiguous on one disk.  Normally, it only needs to be 1 PP in size,
but it can sometimes grow to 2 PPs in size.  I think Linux should have
enough space in 4/8 MB for a boot partition considering Tom's root/boot
disk has a whole system on 1.8MB floppy...

> But what if ... you want to resize the root?

> Even when booting via initrd, you cannot resize the root while it is
> mounted.

Actually, it IS possible to resize mounted ext2 filesystems with my
online resize tools (LVM is required, of course).  Have a look at:
http://www-mddsp.enel.ucalgary.ca/People/adilger/online-ext2/

for more information.

Good luck on your project.  I think this is a much better solution than
using initrd, since it is more like a normal system.

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] booting w/o initrd

[Ulf Bartelt]

Hi!

Andreas Dilger wrote:
> This is what IBM also needs for its "boot LV".  It is required that the
> BLV is contiguous on one disk.  Normally, it only needs to be 1 PP in size,
> but it can sometimes grow to 2 PPs in size.  I think Linux should have
> enough space in 4/8 MB for a boot partition considering Tom's root/boot
> disk has a whole system on 1.8MB floppy...

Right! A 4M partition for /boot should be enough to hold enough kernels
even for those who love experimenting with serveral versions...

...and if not, just give /boot 8M...

> > But what if ... you want to resize the root?
> 
> > Even when booting via initrd, you cannot resize the root while it is
> > mounted.
> 
> Actually, it IS possible to resize mounted ext2 filesystems with my
> online resize tools (LVM is required, of course).  Have a look at:
> http://www-mddsp.enel.ucalgary.ca/People/adilger/online-ext2/
> for more information.

Ok - I knew that page but I donnow how stable this is, so I didn't
include it in my argumentation.

> Good luck on your project.  I think this is a much better solution than
> using initrd, since it is more like a normal system.

It is tested for some weeks on two systems @myhome and Peter has two
systems up this way since last weekend (Peter: correct me if I'm wrong
with that date...).

I think the idea has proven to be handable and reliable now I'd like to
find an easy way to install such a system.

And even if it is not needed today, somewhen LVM might be changed in a
way that stopping it cleanly on shutdown will become a must. So I feel
better having an init.d script starting and stopping LVM and I have no
idea on doing this with an initrd based system...

...and if all else fails, I can access /boot and / with standard rescue
disks...

Bye for now!

	Ulf.

Re: [linux-lvm] booting w/o initrd

[Michael Ju. Tokarev]

Ulf Bartelt wrote:
> 
[]
> And even if it is not needed today, somewhen LVM might be changed in a
> way that stopping it cleanly on shutdown will become a must.
[]
What is about power failure for example?  Or kernel panic?  Or hardware error?
Does it mean that there will be no ability to bring lvm up again in such a
cases!?  But clean filesystem umount is a must, but there is a fsck here
that is started (automatically) if that "must" didn't satisfied....

Re: [linux-lvm] booting w/o initrd

[Ulf Bartelt]

"Michael Ju. Tokarev" wrote:
> []
> > And even if it is not needed today, somewhen LVM might be changed in a
> > way that stopping it cleanly on shutdown will become a must.
> []
> What is about power failure for example?  Or kernel panic?  Or hardware error?
> Does it mean that there will be no ability to bring lvm up again in such a
> cases!?  But clean filesystem umount is a must, but there is a fsck here
> that is started (automatically) if that "must" didn't satisfied....

For now, cleanly deactivating LVM before shutdown is not neccessary.
Otherwise bringing up LVM from an initial ram disk and switching the
root would bring the systems in trouble as there are no actions like
switching back to a ram disk on shutdown, unmount the "real" root, stop
LVM and stop the system...

Filesystems must be unmounted before shutdown. But if something crashes,
a fsck inspects the filesystem on the next system startup. I expect LVM
to behave similar if bringing LVM down before shutdown will be required.

Re: [linux-lvm] booting w/o initrd

[Ulf Bartelt]

Luca Berra wrote:
> 
> there are some good ideas here, i will only point the problems.
> On Wed, Dec 22, 1999 at 02:25:37PM +0100, Ulf Bartelt wrote:
> <snip>
> 
> > And when bringing the system down, LVM can be stopped cleanly because the
> > root filesystem is only addressed via the partition alias.
> 
> add mirrored LV to the equation and you'll obtain a mess.

The idea works for now. When I get in touch with mirrored LVs, I sure
have to rethink a lot. 

> what's the problem with initrd, just look at it as a very big
> __initfunc(), just easier to debug.

I dont see the clean __exitfunc().

Maybe I don't "see the forest because of too many trees" (we'd say in
german...)...

Bye!
	Ulf.

Re: [linux-lvm] booting w/o initrd

[Luca Berra]

there are some good ideas here, i will only point the problems.
On Wed, Dec 22, 1999 at 02:25:37PM +0100, Ulf Bartelt wrote:
<snip>

> And when bringing the system down, LVM can be stopped cleanly because the 
> root filesystem is only addressed via the partition alias.

add mirrored LV to the equation and you'll obtain a mess.

> But what if ...
> ---------------
> 
> ... you want to resize the root?
> 
> It is not much more complicated to do this compared to booting via initrd.
> Even when booting via initrd, you cannot resize the root while it is
> mounted. So this way is not responsible for the main problem in resizing 
> the root.
it is, you are adding one more constraint, that the root must
be contiguous. enjoy pvmoving things around (if you have 2 disks)
btw you can resize a mounted filesystem, and i hope this wil become
standard practice.

what's the problem with initrd, just look at it as a very big
__initfunc(), just easier to debug.

L.

-- 
Luca Berra -- bluca@comedia.it
    Communication Media & Services S.r.l.

[linux-lvm] booting w/o initrd

[Ulf Bartelt]

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

Hi!

We're searching ppl with some time to try this out...

;-)

Bye!
	Ulf.

[-- Attachment #2: partition-alias.txt-19991222 --]
[-- Type: text/plain, Size: 5705 bytes --]

==============================================================================
The Idea (and Definition) of a Partition Alias for a LV
------------------------------------------------------------------------------

Required reading:
LVM-HOWTO
http://www.freenet.de/y.e.t.i./LVM-experimente.txt (sorry, only in german
                                                    at the moment)
sfdisk(8)

Partitions and Logical Volumes
------------------------------

Partitions of disks are normally contiguuous blocks of disk space, starting at
a specific cylinder and ending at another one. 
They allow for addressing raw data blocks by translation through filesystem
facilities. However, this doesn't have to be so with LVM. Since this logical
layer between the raw disk and the filesystem allows for online allocation 
of more disk space it is quite normal that Logical Volumes as counterpart to 
traditional partitions are spread non-contiguuous over the disk(s). This 
poses no threat on an LVM system - it is just normal.

Booting with partitions vs. LVM
-------------------------------

Booting on a PC is a relatively simple thing: the partition only has to be 
flagged bootable and - it has to be contiguuous. 
This is required by all conventional PC Hardware and OSes. Therefore 
different approaches have been done to overcome this limitation, some of them are 
also used to boot the system with LVM activated. This includes initrd with its 
two-phase boot concept as well. But there is another, simpler and easier 
technique to make a system boot with initial LVM support.

Prerequisites
-------------

Imagine a LV lying in some VG of your PV.
This LV has to be allocated in a continuous range of PEs, especially it 
must not cross the border between two disks.  With these requirements 
fullfilled, the LV could be described completely by the number of the its beginning 
sector on the disk and its length in sectors. This information can be obtained by 
looking up the start of the LV relative to the partition which is the PV 
containing this LV and the offset of this partition on your harddisk:

iason:~# pvdisplay -v /dev/sda3
--- Physical Volume ---
PV Name		 	 		 /dev/sda3
VG Name		 	 		 vg00
PV Size		 	 		 9996.22 MB / NOT usable 223 KB [LVM: 121 KB]
PV#		 	 		 1
PV Status				 available
Allocatable		 		 yes
Cur LV		 	 		 7
PE Size	 (KByte)	 		 4096
Total PE		 		 2498
Free PE	 		 		 1043
Allocated PE		 		 1455

		 --- Distribution of physical volume ---
		 LV Name		LE of LV		 PE for LV
		 /dev/vg00/root		2		 		 2

		 --- Physical extents ---
		 PE		 LV		LE	 Disk sector
       		 00000		 /dev/vg00/root 00000	 446
		 00001		 /dev/vg00/root	00001	 8638
iason:~#

Adding the values for the start Disk sector of the LV to the start value 
of the partition in which the LVM lives gives the absolute position of the boot 
sector of the LVM-ized system.
Now imagine entering start (on the disk) and length of this LV in the
partition table of this disk (maybe using sfdisk) as another (normally in 
a LVM system unused) partition.

What would you get?

You could access this LV via an ordinary partition device like /dev/hda1.


Partition Alias and Booting a Linux Installation
------------------------------------------------

Prerequisites:

* you partitioned (nearly) your whole harddisk as one partition with the 
  right ID (0xFE) to be recognized by LVM.

* you created two LVs /dev/vg00/boot and /dev/vg00/root fullfilling the
  requirements mentioned above and a lot of other LVs to contain the other
  filesystems of your linux installation.

* you created partition aliases for /dev/vg00/boot and /dev/vg00/root and
  use only the partition aliases in /etc/lilo.conf and /etc/fstab.

* you put some script to start and stop LVM in some /etc/init.d-script.

So you would be able to boot your root in a conventional way, activate LVM
and mount the other LVs.

And when bringing the system down, LVM can be stopped cleanly because the 
root filesystem is only addressed via the partition alias.


But what if ...
---------------

... you want to resize the root?

It is not much more complicated to do this compared to booting via initrd.
Even when booting via initrd, you cannot resize the root while it is
mounted. So this way is not responsible for the main problem in resizing 
the
root.

Using initrd, you would bring up a initrd with all tools to resize the root
or create another secondary root with all these tools.

Using a partition alias you can do this the same way. The only thing you 
have to remember is to recalculate the values for the partition alias and put 
those in your partition-table again. And even this can be done by a script.

So this is not really a drawback.


Installing...
-------------

Installing a LVM-only system is the main problem even when using an initrd.

If you managed to get a system up with all filesystems in LVs and
temporarily boot using a syslinux-disk with an initrd, creating the
partition aliases is no hard task and the next reboot could succeed without
bootfloppy.

==============================================================================

Ok -- you mean what I know... ;-)

There's a lot to do in getting such a system up and running but it was
sucessfully done with two systems @home as well as with a notebook and another
desktop system. With the notebook system it was also possible to use an LVMized
Linux system in a multiboot- configuration with Windows NT4.0 and Windows 95. 

Comments?

==============================================================================
1999-12-22

Ulf Bartelt, ulf@twc.de
Peter Wuestefeld, pw@resnova.de
==============================================================================