splitting a volume group

I just split a logical volume into two volumes.

I did this by using pvmove to move data around inside the volume group after adding more disks.
This left me with just 1 logical volume on a set of five physical volumes that I wanted to spit off from the others.

Note: I set physical volumes to non allocatable when using pvmove so that it moved them to the right place.

So, before I split, pvs looked something like this

PV         VG     Fmt  Attr PSize   PFree
/dev/md1   system lvm2 a-    44.92G   8.32G
/dev/md2   data   lvm2 --    93.75G  93.75G
/dev/md3   data   lvm2 --    93.75G  93.75G
/dev/md4   data   lvm2 --    93.75G  93.75G
/dev/md5   data   lvm2 --    93.75G  11.73G
/dev/md6   data   lvm2 a-    92.62G      0
/dev/md7   data   lvm2 a-   306.41G 212.67G
/dev/md8   data   lvm2 a-   306.41G 212.67G
/dev/md9   data   lvm2 a-   318.68G 213.21G

Then, I ran
vgchange -a n data
vgsplit -v data other /dev/md2 /dev/md3 /dev/md4 /dev/md5 /dev/md6
vgchange -a y data
vgchange -a y other

pvs then looked like

  PV         VG     Fmt  Attr PSize   PFree
  /dev/md1   system lvm2 a-    44.92G   8.32G
  /dev/md2   other  lvm2 --    93.75G  93.75G
  /dev/md3   other  lvm2 --    93.75G  93.75G
  /dev/md4   other  lvm2 --    93.75G  93.75G
  /dev/md5   other  lvm2 --    93.75G  11.73G
  /dev/md6   other  lvm2 a-    92.62G      0
  /dev/md7   data   lvm2 a-   306.41G 212.67G
  /dev/md8   data   lvm2 a-   306.41G 212.67G
  /dev/md9   data   lvm2 a-   318.68G 213.21G

How to break things in interesting ways

Well, over the last 15 hours or so, I’ve broken stuff twice, inside of a VM thankfully.

I’ve been trying to do some testing to ensure that the pvmove command is going to work ok on my main system, so thought I would test this first within a vm. First test went just fine. Thought I’d test another pvmove as well, so did, and while I was doing that, decided to put a little disk load on the system by copying the /lib/modules/kernel files. All was going sweet.. So I decided to remove that files again, however, being inside a vm, it has the occasional issue with keyboard repeat, or something, anyway, long story short, ran rm -rf / mytestkernel modules. See the mistake! an extra space. It killed the system pretty quick.. oh, and pvmove fails if you trash /dev and /proc while it’s running… not really surprising!

So, lucky it was a VM.. unlucky, I didn’t have a snapshot. So, in the morning rebuilt a new vm, ready to try the test again.. Now, on my new vm, updated it, and created an LVM with a raid1 disk. Then added a raid0 device and rebooted. Ouch… did not reboot. I got an interesting message tho: “lvm locking type 1 failed”. After much playing, booted from a rescue cd and tried to mount up the filesystems.

Anyone booting from a rescue cd should know the drill: bring up the raid, using mdadm –assemble –scan if needed, modprobe dm-mod dm-mirror dm-zero, vgs, vgchange -a . mount /dev/system/root /mnt/root

chroot /mnt/root

now, an interesting problem I had, but found the solution to is: how to run mkinitrd from inside a chroot. Every time I’ve tried it, I would mount /prod, run it. it would use 100% cpu and go very slow. I found out why. you need to mount /sys within the chroot also. this can be done using mount -t sysfs /sys /sys

then mkinitrd will run. however, I am getting ahead of myself. The problem, I discovered was that the raid0 module was not in my initrd, so when I booted, my raid0 device would not come up, which resulted in lvm not having all it’s physical volumes, so it would not start, so it could not operate properly.

The solution I used before finding this out was to just remove my raid one device which did not have any extents allocated to it from the volume group.. When I did this, the system booted fine.

So, end story was to run mkinitrd on the system after starting a raid0 device. This works because mkinitrd looks at the modules loaded in the running kernel and included them if it finds they are needed.

oh. and have now made a snapshot, so can go break some more stuff!

Well, I still have an eblogger account. Funny.

two good cross platform apps

Peazip — much better than winzip, and cross platform.. LGPL

Keepass -> also pretty damn good.

How to upgrade mandriva dist with urpmi

Re: [Cooker] Upgrade Notes (e.g. urpmi upgrades...)
From: Colin Guthrie
To: cooker@mandrivalinux.org
Date: Today 11:15:02 am

Angelo Naselli wrote:
> Alle 12:58, giovedì 12 aprile 2007, Rafal Prasal ha scritto:
>> try to make 2006.0 -> 2007.0 and then 2007.0 -> 2007.1 :>
>>
>> There are many things that were changed since 2006.0 arrived.
>
> Yes but 2006->2007.1 should be supported anyway, so if there are problems....

Indeed. I'll bite the bullet and go for the 2 step jump!

> Ah well Col you can be the first one ;) The machines are yours :p

Done three 2007.0 -> 2007.1's so far.

It all went smoothly. I followed my usual procedure which is roughly:

   1. Find any .rpmnew files and resolve them prior to upgrade.
   2. Copy /etc/ to a safe location for sanity (probably never used)
   3. rpm -qa --nosignature | sort >
/home/rpms/upgrades/rpmlist.2007.0.$(hostname -s).txt
   4. urpmi.removemedia -a
   5. urpmi.addmedia Main-32
/home/rpms/Mandrake/2007.1/i586/media/main/release
   6. urpmi.addmedia --update MainUpdates-32
/home/rpms/Mandrake/2007.1/i586/media/main/updates
   7. urpmi.addmedia Contrib-32
ftp://anorien.csc.warwick.ac.uk/Mandriva/official/2007.1/i586/media/contrib/release
   8. urpmi.addmedia --update ContribUpdates-32
ftp://anorien.csc.warwick.ac.uk/Mandriva/official/2007.1/i586/media/contrib/updates
   9. urpmi --auto --no-verify-rpm urpmi 2>&1 | tee -a
/home/rpms/upgrades/urpmi.2007.0.$(hostname -s).log
          * This appears to remove your /etc/localtime (leaves an
.rpmsave meaning the machine is now in UTC mode)
  10. urpmi --auto --no-verify-rpm --auto-select 2>&1 | tee -a
/home/rpms/upgrades/urpmi.2007.0.$(hostname -s).log
  11. Do the kernel
  12. Switch to grub
  13. Reboot
  14. rpm -qa --nosignature | sort >
/home/rpms/upgrades/rpmlist.2007.1.$(hostname -s).txt
  15. Compare the packages and remove orphaned libs still installed.

There are quite a few 2007.0 packages that are still part of 2007.1. The
last step would be made a lot simpler if all packages were rebuilt with
the relevent dist suffix for each release - despite the PITA that is to
do in terms of all the bump+submits required.

During step 9 on my first u/g my /etc/localtime was removed, I replaced
it with a symlink but when timezone updated it moaned that I'd created a
symlink.... with the second u/g it was replaced automatically, so the
answer is - don't touch it ;)

Other than that everything went pretty smoothly.

Col.

-- 

+--------------------------+
|      Colin Guthrie       |
+--------------------------+
| cguthrie(at)mandriva.org |
|  http://colin.guthr.ie/  |
+--------------------------+