Kernel/dmesg email addr & Converting to LVM 2

[Cyber Source]

We've been using LVM2 for all our FC3 stuff and I really like it, the 
flexibility and the drive access speeds are fantastic. I have also seen 
a few things that might be of note. If you even e2fsck a logical volume 
that is a swap partition in LVM, it will reset the swap declaration, you 
need to mkswap again to the partition after e2fsck. I have never went 
from LVM1 to LVM2 but it would probably be a smooth transition if you 
could create the LVM2's and then tar your data in. Why are you sticking 
with 2.4 kernels? Going forward with LVM2 and staying behind with 2.4 
might have some unforseen problems, I myself have never compiled a 
kernel without forgetting a thing or two. As far as your vgimport 
problem, since you relabeled /dev/hdg (0x84), did you pvcreate /dev/hdg 
BEFORE you then tried to vgimport /dev/hdg and /dev/hdf ?
I suspect relabeling /dev/hdg removed the pv declaration.

Mark T. Valites wrote:

>I've been hacking away at my TODO list for my do-it-all box at home.
>Three of the items on my list were to compile the latest 2.4 kernel, fix a
>lilo 'Duplicate Volume ID' problem, and convert to Logical Volume Manager
>2 from LVM 1. Little did I know they'd all be related...
>
>Since I have to compile a new kernel for the second two problems, I'd
>like to set the address that is first displayed in the very first line you
>see when linux loads or when you run dmesg:
>
>myth:/usr/src/linux-2.4.28# dmesg | head -1
>Linux version 2.4.26-myth (root at myth) (gcc version 3.3.3 (Debian 20040422)) #1 Sat Jun 5 15:01:29 EDT 2004
>
>I thought I remembered the stock RedHat kernels used to have the guy's
>name from RedHat who compiled them in the first line. I'd like to put in a
>different email address in the line then root@<unqualified_hostname>. I
>grepped the kernel source to see if I could find how to set this, but I
>had no luck. I'd guess the unqualified hostname comes from $HOSTNAME,
>which is easy enough to change temporarily if need be, but I'm not sure
>how exactly it determines I'm compiling the kernel as root or how to fake
>that. I'm using kpkg on Debian, but that shouldn't matter.
>
>If you haven't done LVM before, you probabaly don't want to read on...
>
>Ever since I christened the box a while back, I'd been getting an error
>right before lilo loaded telling me 'Duplicate Volume IDs detected'. After
>digging around a little, I found that newer versions of lilo allowed you
>to display the volume IDs for your drives:
>
>myth:/usr/src/linux-2.4.28# lilo -T vol-ID
>
>  BIOS     Volume ID
>
>  0x80     3DB012B3
>  0x81     2EB7C8E7
>  0x82     00000006
>  0x83     00000002
>  0x84     00000002 *
>
>The manpage for lilo says you can reset volume IDs with:
>
>lilo -z -M /dev/<device_name>
>
>I ran this on the drive 0x84 mapped to above and it did in fact change
>what was displayed for the volume ID. Only problem was that the logical
>volume (LVM1) I had spanning the last two disks above no longer wanted to
>work - pvscan and vgscan would see both PVs, but vgimport would complain
>and fail:
>
>myth:~# vgimport music_vg /dev/hdg /dev/hdf
>vgimport -- ERROR "pv_check_consistency(): allocatable PE" checking physical volume consistency of "/dev/hdg"
>vgimport -- ERROR: only 1 physical volumes of 2 given for volume group "music_vg"
>
>Luckily, I was intelligent and had a copy of my MBR and parition table
>(I'd dd-ed it out and lilo keeps a backup copy) Putting the old
>MBR/partition table back in worked fine, but gave me back the
>'Duplicate Volume ID' problem.
>
>After a little bit of digging, I found the volume ID is stored in the MBR,
>as four bytes, whose last byte was located at offset 000001B0. Using a
>binary editor on a copy of my MBR, I was (successfully) able to manually
>change the volume ID, re-run lilo, and reboot. Upon reboot, I was back to
>the same situation: no 'Duplicate Volume ID' error, but a broken LVM
>volume.
>
>Turns out that when you have a physical volume (PV) in LVM version 1 that
>spans an entire disk instead of single partition which spans the whole
>disk (/dev/hdg, as opposed to /dev/hdg1 in my case), LVM uses sector 0 of
>the drive for itself, and doesn't allow you to use it for other things -
>namely volume IDs. LVM version 2 starts storing its information in sector
>1.
>
>If you're still with me, I'll be compiling 2.4.28 tomorrow with devmapper
>support patched in. I'd like to put my email address in the first line
>that shows up when I boot. After I have devmapper support, I'll be
>converting my LVM version 1 setup to LVM version 2 - has anybody done this
>before? It doesn't look all that bad, but it doesn't look all that fun
>either... And if anyone has done it, have you been in the same boat as I
>with a PV across two whole disks which gave you what looked like duplicte
>volume IDs & did the problem go away after converting to LVM version 2?
>
>-Mark
>
>  
>