I'm currently running a Slack10-current (updated every week or so) setup
with kernel.org kernels (either mainline or -ac trees) on my main
home/desktop system. I have 2-3 disks set up via LVM providing a number of
filesystems. I've been mulling over the best method to reconfig my system to
be capable of booting either 2.4 or 2.6 kernels interchangably but still
pick up the LVM volumes. This is complicated by the fact 2.4 is using a
compiled-in lvm module and 2.6 will be using LVM2 tools w/dmapper. I'm
wondering if anyone out there has travelled this road and what tips/advice
you can offer.

Currently my best thoughts are..

- uninstall slack lvm* tools.
- compile my own lvm1 & lvm2 tools
- place them in their own paths (/sbin/lvm1 & /sbin/lvm2)
- pick the proper path at boottime based on kernel version (2.4* or 2.6*)
- (?) alter any /etc/rc.d/* scripts to accomodate this stuff

rolling dm into 2.4* is an option; i could then simply use lvm2
exclusively.. but not a good one imho as dm for 2.4 is really not supported
these days and its not in mainline (though I already do roll in my own alsa
& nvidia modules so i guess another one wouldn't really hurt).

Also, has anyone messed with the lvm2* packages in testing? I've not tried
them yet as I don't know how they will coexist/break existing 2.4 lvm.

last, my OS is NOT (currently) lvm'd: my OS is on a monolithic /.. but i
would like to address that later on as well: cut down the large fsck time,
etc...

any info or ideas, i'd appreciate it. thx.

-r

No Body <no@body.com> wrote:
> I'm currently running a Slack10-current (updated every week or so) setup
> with kernel.org kernels (either mainline or -ac trees) on my main
> home/desktop system. I have 2-3 disks set up via LVM providing a number of
> filesystems. I've been mulling over the best method to reconfig my system
> to be capable of booting either 2.4 or 2.6 kernels interchangably but still
> pick up the LVM volumes. This is complicated by the fact 2.4 is using a
> compiled-in lvm module and 2.6 will be using LVM2 tools w/dmapper. I'm
> wondering if anyone out there has travelled this road and what tips/advice
> you can offer.

I have done that.
Essentially, I got all my wisdom from the LVM HOWTO
http://www.tldp.org/HOWTO/LVM-HOWTO.html

Here is a short compilation of what I did (using Slackware 9.0):

- I compiled the LVM2 tools and, when installing them, did NOT install the
symlinks (e.g. vgscan -> lvm). So now I have both LVM1 and LVM2 tools on
my machine. To access LVM1, I type 'vgscan'; for LVM2, I type
'lvm vgscan'. Another option would have been to install LVM2 in another
directory.

- One problem was that the device nodes are quite different between
LVM1 and LVM2. There is the vgmknodes command to create the correct
entries in /dev. I use the trick from the LVM HOWTO to tell which
version of LVM is in the kernel during the boot process.
Here is a snippet of /etc/rc.S on my system, from the initial comment
you should be able to locate the code in /etc/rc.S that my fix replaces.

# Initialize the Logical Volume Manager.
# This won't start unless /etc/lvmtab is found,
# which is created by /sbin/vgscan.
# Therefore, to use LVM you must run /sbin/vgscan yourself the first time.
if [ -r /etc/lvmtab -o -d /etc/lvm ]; then
# Mount /proc early (it's needed for vgscan):
/sbin/mount -a -t proc
# hack to be able to work with LVM1 and LVM2
if grep device-mapper /proc/devices >/dev/null
then
if [ ! -e /dev/.devfsd ]
then
# only needed if no devfs: create device nodes (LVM2)
/sbin/dmsetup mknodes
# recreate correct device nodes (LVM2)
/sbin/lvm vgmknodes
fi
# Scan for new volume groups (LVM2)
/sbin/lvm vgscan
if [ $? = 0 ]; then
# Make volume groups available to the kernel (LVM2)
/sbin/lvm vgchange -ay
fi
else
# Scan for new volume groups (LVM1)
/sbin/vgscan
# recreate correct device nodes (LVM1)
/sbin/vgmknodes
if [ $? = 0 ]; then
# Make volume groups available to the kernel (LVM1)
/sbin/vgchange -ay
fi
fi
fi

- I had the additional problem that my / is on LVM (something that I
do not recommend - from the problems I had upgrading).
The device major and minor for my root file system are different in LVM1
and LVM2, but I want LILO to be able to boot both.
So instead of specifying a /dev path in lilo.conf, I added device major
and minor:

image = /boot/vmlinuz-2.6.11
root = 0xfe00
label = console
initrd = /boot/initrd-lvm2.gz
ramdisk = 1024
read-only

image = /boot/vmlinuz-2.4.22
root = 0x3a00
label = failsafe
initrd = /boot/initrd-lvm1.gz
ramdisk = 1024
read-only

- Since it does not affect you, I won't even start with the initrd
problems ;^)

Yours,
Laurenz Albe

On Mon, 14 Mar 2005 12:03:46 +0000 (UTC), Laurenz Albe <albe@culturallNOSPAM.com> wrote:

.. . .
Thanks for example.

>- Since it does not affect you, I won't even start with the initrd
> problems ;^)

A query: pros & cons for LVM from your perspective? I think some
distros throw it at the user, but I tend to fight it, thus dismiss
distro, here I am using slackware

Dual booting 2.4 / 2.6 -- this one I've put off for long time, soon
I go here too. You think it worth adjusting startup scripts or having
two separate OS partitions?

If you were to start over, had lots of space, which way would you go?

And, do I really need use initrd for 2.6? Methinks I miss something.

Thanks,
Grant.

Grant Coady <grant_nospam@dodo.com.au> wrote:
> A query: pros & cons for LVM from your perspective? I think some
> distros throw it at the user, but I tend to fight it, thus dismiss
> distro, here I am using slackware

I come from AIX, which is LVM only, so I have a natural propensity for it.
LVM on Linux is not as universally supported (by that I mean: not every
precompiled kernel and boot disk will have it).

Maybe there will be no more change in LVM as radical as the step from V1
to V2, but you never know, and upgrading the root logical volume from V1
to V2 was definitely unpleasant (which is why I recommend NOT to have
/ on LVM).

Still, LVM is wonderful: on the one hand it will allow you to create large
file systems spread over multiple disks, on the other hand, it allows
you to create (and resize when necessary!) several small file systems on
one disk (you don't want a program scribbling in /tmp to fill up your
root partition).

With LVM you do not have to mess around with the partitions on your hard
disk, which (from what I read in various posts) can be a pain in the butt
and should never be done without a full backup at hand.

> If you were to start over, had lots of space, which way would you go?

I would create 3 partitions on the OS disk, one for swap, one
for an ext3 file system that contains / and /boot, and the rest of the
disk as one LVM partition.
I would see to it that / is big enough so that I'll never need to
resize it.
I would create a volume group (rootvg) out of the LVM partition and
create logical volumes for /tmp, /var, and /usr.

Any other disks in the machine would contain only one LVM partition.
I would arrange them into volume groups as needed (datavg, homevg, ...)

Whether I put /home in the rootvg or somewhere else will probably
depend on how the machine is going to be used.
If it is a database server, /home would go in rootvg since there will
be no users doing actual work on the machine, and any existing users
will be administrative.
If there are lots of users doing, say, development on the machine,
I'd be tempted to put /home on another disk with lots of space.

> Dual booting 2.4 / 2.6 -- this one I've put off for long time, soon
> I go here too. You think it worth adjusting startup scripts or having
> two separate OS partitions?

If you have enough space, a cool setup might be:
One partition for / with 2.4 kernel, one for / with 2.6 kernel, and
both systems share all other file systems. All these would be on the
'OS disk'. That way you can avoid workarounds with startup scripts and
system utilities (like installing different versions of modutils or LVM
in the same file system) and still can keep most of the OS in one place
(/usr) which makes upgrades simpler.
Nothing comes for free, however: all changes and updates to - say -
startup scripts will have to be done twice.

If you change a 2.4 system into a 2.4/2.6 dual boot system (I say 'change'
here as I consider the word 'upgrade' inappropriate), you will probably
be constrained by the way your existing system is set up, and keeping
both kernels in one root file system might be the best way for you.
It is not so difficult if you are careful and read all the READMEs.

> And, do I really need use initrd for 2.6? Methinks I miss something.

Not unless you have the root file system on LVM like I do.
Then you need to perform a 'vgscan' and 'vgchange -ay rootvg' BEFORE
you can even access / (which contains these utilities), and you must
have an initrd which can perform these initial tasks.

Yours,
Laurenz Albe

Hi Laurenz,

On Tue, 15 Mar 2005 10:05:25 +0000 (UTC), Laurenz Albe <albe@culturallNOSPAM.com> wrote:
>Grant Coady <grant_nospam@dodo.com.au> wrote:
>> A query: pros & cons for LVM from your perspective?
.. . .
Thank you for your answer, it explains why I not see LVM == useful,
I don't mind playing with partitions -- but my attitude doesn't
scale up to larger systems where LVM becomes a useful + flexible
tool for drive space resource management.
.. . .
>If you have enough space, a cool setup might be:
>One partition for / with 2.4 kernel, one for / with 2.6 kernel, and
>both systems share all other file systems.

This is sort of what I'm thinking of doing.

>> And, do I really need use initrd for 2.6? Methinks I miss something.
>
>Not unless you have the root file system on LVM like I do.
>Then you need to perform a 'vgscan' and 'vgchange -ay rootvg' BEFORE
>you can even access / (which contains these utilities), and you must
>have an initrd which can perform these initial tasks.

Thanks, seems to confirm what I'm slowly picking up. Still avoiding
LVM, but it makes more sense to me now. My first DOS was cp/m 2.2

Cheers,
Grant.

"Laurenz Albe" <albe@culturallNOSPAM.com> wrote in message
news:d13uj2$ee2$1@paperboy.Austria.EU.net...
> - Since it does not affect you, I won't even start with the initrd
> problems ;^)

heh, understand that. initrd seems such the pain to deal with. the one time
i tried a lvm'ed OS volume, I still kept / as its own ~192M ext3 partition.
I think I even mirrored it by hand via rsync or something (hadn't played
with software raid yet).

on further reflection, though, I've been thinking of simply saying 'screw
it' to the 2.4 kernels and just going full-bore with the 2.6 kernels,
devmapper compiled in (not modular) and installing the lvm2 tools from
testing. not much real reason to hold back, save for the use of nvidia
binary drivers (which I can avoid breakage by holding back from the
bleeding-edge kernels when a kernel change busts something).

also, thx for the background/perspective. AIX & HPUX are also my day job and
the volume-management paradigm is a wonderful thing (even if ibm has to have
all their damn commands totally different from anybody [veritas] else..

thx again for the thought food,

-r (rmdev -dl fcs0 -R)