Hi!
I intend installing Slackware-13.0 using LVM partitioning scheme. My root partition is going to be on LVM too. I have 2 preliminary questions.

1. I have a single hard drive sda. It is usually recommended to create a single partition encompassing the whole hard drive, i.e. sda1, and then use it a physical volume for the LVM volume group. However in the LVM howto it is written that there should be no problem using the whole hard drive directly as a physical volume in lvm, i.e. instead of running
running:
My question is, will this be possible, bearing in mind that the root logical volume will also be LVM?

2. Everywhere it is said that to have /boot (or /) on LVM, one has to use initrd. If I create a custom kernel will LVM and device mapper support built-in, will I still need to create and use initrd?

I could find the answers to these questions through trial and error, but I would be glad if someone could shed some light on these issues so that I save some time of unpleasant experiences

Thanks in advance.

Martin

If I remember correctly, this is not possible...
I use LVM as well on my machine, and the LVM partitions can only be mounted later on in the boot process (in /etc/rc.d/rc.S).

So you will need to have / mounted before you can mount the LVM volumes.

But, maybe there is a way... won't be simple though.

For creating LVM volumes, I just followed instructions from the README_LVM.TXT written by Alien Bob (a.k.a. Eric Hameleers) and had no problem.

Is there something missing in this document?

No, that document is excellent. And it even explains how to create your root partition on a logical volume.

So I stand corrected, as it seems possible after all since Slackware 12.0
Guess I need to read the newer documents to update my knowledge

AIUI, /boot cannot be on an LVM volume because grub doesn't have LVM capability but needs to read from /boot.

/ can be an LVM volume (my ubuntu 8.04 system has it) but I see little advantage in it.

Not that I don't believe you, but does it really work with the kernel and initrd.gz inside the LVM itself? I wonder if LILO has LVM features build inside, else it couldn't work I guess.
EDIT: Using GRUB myself I'm just curious ...

I'm not an expert, but after creating the initrd.gz image and editing the /etc/lilo.conf file, you need to run lilo. At that point, lilo copies the necessary code/program in the MBR (Master Boot Record) of your machine to enable boot. The LVM stuff is stored in the initrd.gz image.

Thanks! I guess I have to look at LILO again.

Guys, thank you for the discussion.
Nobody however ventured to answer any of the 2 questions in my first post

Question 1: No, it's better to create PV using the partition /dev/sda1

Question 2: Yes you still need to create the initrd.gz image which will contain the code to enable LVM at boot time (that's the "-L" option in the mkinitrd command). Options you mentioned in the kernel allow the running kernel to manage LVM after the boot.

I hope it clears things out

1. Yes, it is possible to run your root filesystem on a logical volume, if you do not boot from the same device that your root logical volume is located on. The reason is that lilo or grub cannot read logical volumes (which ties into the answer for your question #2). Given hardware support, you could boot another hard disk or USB HD/CD/flash drive or even PXE boot.

2. Yes, (AFAIK) you still need an initrd to have a root filesystem on a logical volume, because the logical volumes need a userspace component (in this case, /sbin/lvm.static) to make the logical volumes available to the kernel (vgscan --mknodes && vgchange -a y). Also, you can pass either the symlinked or real names of the root device to the kernel at boot.
Either:

or:

will work, because mkinitrd preserves links on necessary directories as it makes an initrd.

Ok, thank you that made things much clearer.

I thought of initiating a new thread, but in view of the rather general title of this one, I think I can post my new questions here.

1. With LVM, what happens if a badblock occurs in the hard drive? With the usual partitioning with fdisk, if a badblock occurs on the drive, one can fsck and repair the file system on the partition affected. Does the same refer to an LVM partition? To be more specific, my whole disk /dev/sda will be made into a single partition /dev/sda1. It will be the only physical volume within my volume group HDvg, in which I will create several logical volumes: root, usr, home, swap and so on. If a badblock occurs , say in /dev/HDvg/usr, will I be able to correct its filesystem and restore the contents from my backup?

2. I use the jfs filesystem, as a discussion in this forum lead me to the conviction that it is the best filesystem for my needs. If at some point in time I decide to shrink the /dev/HDvg/usr logical volume with, say 5 GB to transfer them to /dev/HDvg/home, will I be able to do that, having in mind that the jfs filesystem cannot be shrunk? This is the only clue as to what might be done that I found in the internet, but I do need some guru to shed some more light:
http://unix.derkeiler.com/Newsgroups...5-06/0761.html
If that should somehow be possible, what a procedure would you recommend? Maybe I should delete /dev/HDvg/usr, expand /dev/HDvg/home with 5 GB, and then create a 5 GB smaller/dev/HDvg/usr, format it with jfs and restore its contents from my backup? Or maybe I should switch to jfs2 and use chfs to shrink it?

Any suggestions will be appreciated.

Martin

What follows is a demonstration of what happens when you create a logical volume from a block device with bad blocks:

Sorry for the mess of commands, but the first command creates a file of zeroes and has a for loop that makes a selection of 3 pseudo-random blocks that fail badblocks' test pattern of zeroes. Then, it assigns the first unallocated loopback block device out of the file of zeroes and some ones, and shows you what it assigned, then checks for the badblocks that were just created.
The second command makes a physical volume, a volume group, and a logical volume for the newly-mapped loopback device.
I ran the third command mostly to show the offset the the test device. I don't know exactly what's going on here, but I've tested it a bit before this, and badblocks' output on the mapped device is incremented by half of the device's offset (384/2 for 192 here).

Gegechris99 was right in saying that creating a partition is a good idea for your lvm data. Boot loaders, live CD's, other OS's are all more likely to mistake your LVM data for unallocated space and lose it for you.

So, to answer your first question, the bad blocks are also present in the logical volumes you create out of underlying device(s). I don't think JFS, XFS, or reiserfs do anything but fail with bad blocks present, at least not without kludges. The ext[234] filesystems are capable of not using bad blocks on the underlying device. You would need to use a file system that avoids bad blocks to do a fsck and then restore from backup to not lose data.
I know of no way of using lvm2 to avoid bad blocks on a device. As I read here, especially appendix A, I found that the mapped blocks need to be contiguous when using the linear mapping targets, and the other targets were irrelevant. Someone could possibly do things such as distribute encrypted data within a block device, like an encrypted device-within-a-device with device mapper if contiguous blocks for each device node weren't required and could be chained in sequence to define a volume.
The advice I've read about drives with bad blocks is that you should not trust a drive with bad blocks present. They're likely to lose your data for you. Despite that, what I would do, if I found bad blocks (back up your data!) and wanted to use lvm2, would be to go ahead and move the affected data elsewhere and partition around the bad blocks, leaving the bad block(s) unallocated. LVM has no trouble making logical volumes span multiple devices .

As for your second question, I haven't decided for myself what is best. What you suggested -- juggling data across devices -- would work fine, if you watch disk usage closely. But, it sure would be a nice feature for a filesystem to do online shrinking. I'm an XFS user, mostly because it's what I know best, not necessarily because it's the best filesystem for all uses. XFS does not do online shrinking, but I have not yet had the need to scavenge space from mostly static data devices to allocate to growing data.

To install Slackware 13 in a LVM I followed instructions from the README_LVM.TXT written by Eric Hameleers and tried to install lilo in my root partition (in the LVM):
I thought it had worked, but at reboot I got the infamous message:
Does that mean that I should have installed lilo either in the MBR (which I do not want to do) or at least outside the LVM ?

Sorry to hijack this thread but this is also a LVM question, isn't it ?