Michael's musings

Wed, 24 May 2006

git rebase

I just moved some patches to the Linux kernel from a 2.6.15 base to a 2.6.16.18 base.

This is how I did it:

- I started by going to my copy of the Linus Torvalds tree, and updating it.

% cd /mara1/git/torvalds
% cg-branch-ls
origin  http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
% cg-update

- I then cloned the tree.

% cd /mara1/git
% cg-clone torvalds stable2.6.16.y

- I then added the 2.6.16 branches:

% cd stable2.6.16.y
% cg-branch-add stable2.6.16.y http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
% cg-update stable2.6.16.y

- I then added the stable 2.6.16 tree to my working tree. I prefer to have

seperate trees like this so that I can poke around. I could added the stable branch to my torvalds tree, btw.

% cd /mara1/git/klips-ocf
% cg-branch-add stable  /mara1/git/stable2.6.16.y
% cg-fetch stable

- Then I ran git rebase.

% cg-tag ocf_v2.6.15
% git rebase stable ocf
% cg-branch-chg origin git+ssh://git.openswan.org/public/scm/klips.git#ocf_v2.6.16

I made sure to leave a tag, because "git rebase" changes the branch, and you might not be able to get it back.

How to unscrew your LVM

I had a system with a single 40Gb PATA drive in it. It had two 160GB SATA drives in it too, but the SATA controller on the motherboard was not supported yet by Fedora Core 5. (It's a VIA controller. VIA has drivers, but they aren't stable yet)

I got a 2-port Adaptec SATA controller, hooked it up while moving the machine to a 3U case, and booted. Great, everything works.

I then added the two new volumes to my "VolGroup00", and took the system down to the colo. Oh. shit. It won't boot.

Why? because the initrd for the system didn't have the Adaptec controller, so the system couldn't see the extra physical volumes, so it couldn't construct the logical volume group, so it couldn't find the "root" disk.

DAMN.

I booted a Fedora Core 5 rescue CD. (I am, btw, looking for a 30-50Mb image that I can stick on /boot, and invoke from grub, which would be a serial-console happy rescue image. It should have sshd, and be able to dhcp an address ideally.... I was going to take apart some CD-based .iso, but I haven't done hat yet)

I then fixed this by running mkinitrd properly, and the system found the right disks, and booted.

I thought: I don't want all my disks in the same volume group if a screw up will prevent the system from booting.

I came across the command "pvremove", which I proceeded to run on /dev/sda1 and /dev/sdb1. OOPS. System won't boot again, because I actually destroyed the physical volumes (from LVM's point of view), not removed them.

Another run through with the rescue CD. Need to figure out what to do. The command "lvm" is nice, because as a wrapper around all the commands, it also tells you quickly what are actual commands and not.

The solution:

lvm> vgreduce VolGroup00 --removemissing
  Couldn't find device with uuid 'nwprFB-HWF3-GRL7-ow4P-JUXO-Zp2J-ckZ8fe'.
  Couldn't find all physical volumes for volume group VolGroup00.
  Couldn't find device with uuid 'nwprFB-HWF3-GRL7-ow4P-JUXO-Zp2J-ckZ8fe'.
  Couldn't find all physical volumes for volume group VolGroup00.
  Couldn't find device with uuid 'nwprFB-HWF3-GRL7-ow4P-JUXO-Zp2J-ckZ8fe'.
  Couldn't find device with uuid 'tLpEoy-X3jh-7QgU-oWTY-dmrh-4dKx-jCOLVm'.
  Wrote out consistent volume group VolGroup00

Now, I have:

trout-[~] root 1 #lvs
  LV         VG           Attr   LSize  Origin Snap%  Move Log Copy%
  FlorinRoot GuestGroup00 -wi-a-  5.00G
  LogVol00   VolGroup00   -wi-ao 35.19G
  LogVol01   VolGroup00   -wi-ao  1.94G
trout-[~] root 2 #pvs
  PV         VG           Fmt  Attr PSize   PFree
  /dev/hdb2  VolGroup00   lvm2 a-    37.16G  32.00M
  /dev/sda1  GuestGroup00 lvm2 a-   149.05G 144.05G
  /dev/sdb1  GuestGroup00 lvm2 a-   149.05G 149.05G
trout-[~] root 3 #vgs
  VG           #PV #LV #SN Attr   VSize   VFree
  GuestGroup00   2   1   0 wz--n- 298.09G 293.09G
  VolGroup00     1   2   0 wz--n-  37.16G  32.00M

Why you should use SIP

http://www.theregister.co.uk/2006/05/24/skype_vuln/

describes a vulnerability in Skype's clients. Okay, no big deal, bugs happen in programs. Just switch to another program for awhile until it gets fixed.

What? you mean, the program and the protocol are one? You can't switch without switching networks? Isn't that bad?

Yes, it is.

The reason why we should strive to use standards in our network protocols is so that one can have a competitive marketplace where one can use the best software that there is.

And one should be able to trivially switch from one to another: we do this all the time everywhere. Let's take an example from motoring: we get upset if the vendors of gasoline (petrol) do not compete! We expect all of the gasoline to be essentially interchangeable. Honestly, anything else is communism.

Liam is 1

One year ago, my son Liam Ronald Morris Richardson was born.

http://www.sandelman.ca/lrmr/

What an amazing year it is has been.