pk stuff

Adding existing logical volumes to the list of virtual disks is non-obvious.
First add the VG to Proxmox using the “Storage|Add” UI. Once done, adding existing LV to Proxmox must be done via LVM command line tools.
A logical volume needs to have the correct naming, and (surprise!) an LVM tag set. For the correct tag (and LV name) format, use the UI to create a sample volume (VM|Hardware|Add|Hard Disk).
Note: LV names must fit a certain pattern. However, names like this seem to work: vm-110-timemachine.
The example below shows a pre-existing LV (vg1/vm-110-disk-2) without the “pve-vm-110” tag Proxmox requires.
Subsequent steps add the tag, after which the volume appears in Proxmox.

# lvs -o vg_name,lv_name,lv_tags
VG     LV              LV Tags
pve    data
pve    root
pve    swap
vg0    vm-110-disk-1   pve-vm-110
vg0    vm-110-disk-2   pve-vm-110
vg1    vm-110-disk-1   pve-vm-110
vg1    vm-110-disk-2


To see LV tags:

# lvs @pve-vm-110
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
vm-110-disk-1 vg0 -wi-ao--- 500.00g
vm-110-disk-2 vg0 -wi-ao--- 750.00g
vm-110-disk-1 vg1 -wi-ao--- 750.00g


To add missing tags:

# lvchange --addtag pve-vm-110 /dev/vg1/vm-110-disk-2


Refresh the Proxmox Storage UI to see the new LV.

Or perhaps it should be: how to retrieve an lvm partition from an xvda partition within an lvm partition.

Quite some time ago, I built a CentOS Xen DomU using lvm within an xvda partition. And the whole VM was hosted in yet another lvm partition. While lvm is easy to manage and physical backup and restore is straightforward, accessing the contents of the embedded partition without the VM running is tricky. Luckily, device mapping in Linux is very powerful and can be used recursively (not quite like Haskell or OCaml, but impressive none the less).

This recipe can be applied multiple times to dig deeper into your embedded file systems.

Add the device mappings (assuming the device created is /dev/xvda ):

kpartx -a /dev/VolGroupXX/LogVolxx

Kpartx is amazing as it will scan all your lvm volumes and create device mapper entries, which are required for the lvm tools to do their thing.

Scan for physical volumes:

pvscan

The above should tell you the physical volumes with LVM partitions (the PV column) along with the volume groups on it (the VG column). Activate the volume group:

vgchange -ay {VG name from previous step}

If you have additional embedded LVM, run vgscan to discover these, and vgchange -ay as required. You may need to repeat the kpartx and pvscan too.

When you eventually get to the volume required, mount it with :

mount /dev/{VG name}/{LV name} /mnt/xxx ;

The folks at Citrix have more detail here, especially if you’re running Xen.

The SystemRescueCd has all sorts of useful tools to restore ailing Linux systems.
Check it out at: https://www.sysresccd.org

I recently replaced the RAID 1 drives in my CentOS 5 box and had to reinstall the grub MBR. As the drives are a couple of TB each, I thought I’d try GPT instead of the old MBR partitioning, since soon all drives will exceed MBR’s 2TB limit. Luckily GPT is baked into RH/CentOS kernels (unlike many others).
Restoring the MBR was trickier than I expected and I made a couple of mistakes along the way – wish I had found the following description sooner:
https://idolinux.blogspot.com/2009/07/reinstall-grub-bootloader-on-md0.html

In a nutshell run grub interactively and do the following:

# grub
grub> root (hd0,0)        
root (hd0,0)
 Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  16 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.
grub> quit
# reboot

From Phil Sung:

Another Ubuntu release, another set of X.org shakeups.

Some things in X changed in Lucid (xorg 1:7.5+5 and higher), breaking existing Thinkpad TrackPoint scrolling configurations that modify files in /etc/hal/fdi/policy (like those you may have seen in this previous post). You can use gpointing-device-settings to apply the same policy, but I found that even that stops working after a suspend/resume cycle.

Samson Yeung pointed out to me the following fix which can be applied on Ubuntu Lucid/10.04:

Create a new file /usr/lib/X11/xorg.conf.d/20-thinkpad.conf with the following contents:

Section “InputClass”
Identifier “Trackpoint Wheel Emulation”
MatchProduct “TrackPoint”
MatchDevicePath “/dev/input/event*”
Driver “evdev”
Option “EmulateWheel” “true”
Option “EmulateWheelButton” “2”
Option “Emulate3Buttons” “false”
Option “XAxisMapping” “6 7”
Option “YAxisMapping” “4 5”
EndSection
Then restart X.

The configuration above works for both Thinkpad laptops with TrackPoints and the Thinkpad TrackPoint keyboard.

Somehow my ThinkPad (T60p) desktop never seems big enough so whenever possible I like to plug in a second monitor. Until recently, Ubuntu required all sorts of messing around in xorg.conf, but fortunately the situation is somewhat improved with Hardy. To be fair, much of this configuration mess is probably due to ATI’s less than stellar Linux support, which is slowly improving.

First, always backup your existing /etc/X11/xorg.conf !!!  Virtually every screen config tool I’ve used under Linux has ultimately toasted my xorg.conf file.

I found “amdcccle” produced the best results, with Compiz still operational.

Others may prefer “aticonfig –initial=dual-head“, which also worked but left my Compiz out of action.

Both are far from perfect and this is one area where Ubuntu (and other distros) still lag far behind Windows and OSX.

This is too good to risk losing so I’m reproducing the recipe here.
For my needs, I was able to skip a few steps by using root and by using screen session ids.
Here is the original article (with a couple of minor changes):

Assume user jsmith wants to share his terminal session with remote user bjones for training or troubleshooting purposes, but does not want to use VNC or other full-blown GUI remote control access.

Requirements:
– GNU Screen
– Local account on host computer for remote user (i.e. bjones requires local account)

1. Install screen

sudo apt-get install screen

2. Set the screen binary (/usr/bin/screen) setuid root. By default, screen is installed with the setuid bit turned off, as this is a potential security hole.

sudo chmod +s /usr/bin/screen
sudo chmod 755 /var/run/screen

3. The host starts screen in a local xterm, using the command screen -S SessionName. The -S switch gives the session a name, which makes multiple screen sessions easier to manage.

screen -S screen-test

4. The remote user (bjones) uses SSH to connect to the host computer (jsmith).

ssh [email protected]

5. The host (jsmith) then has to allow multiuser access in the screen session via the command CTRL-A :multiuser on (all ‘screen’ commands start with the screen escape sequence, CTRL-A).

CTRL-A
:multiuser on

6. Next, the host (jsmith) must grant permission to the remote user (bjones) to access the screen session using the commadn CTRL-A :acladd user_name where user_name is the remote user’s login ID.

CTRL-A
:acladd bjones

7. The remote user can now connect to the hosts ‘screen’ session. The syntax to connect to another user’s screen session is screen -x host_username/sessionname.

screen -x jsmith/screen-test

Every once in a while archives contain DOS formatted text files – they contain carriage returns in addition to Unix-style linefeeds. Depending on the project, these may cause all sorts of subtle problems.

The following command recursively strips carriage returns from all files in this and lower folders.

find . -type f -exec dos2unix '{}' ;

From Cliff Pearson’s excellent system administration blog:

<<begin quote>>

From time to time, people want me to create LINUX init scripts for them. I usually just take an existing one for another service and change it up to work for my new application, but most of them have become so long these days that I end up having to hack out a ton of code just to reduce them down to the very basic script I need. I decided to create this very simple template so I wouldn’t have to keep trimming down the more complex scripts that one tends to find in /etc/init.d these days.

This script is chkconfig compatible, so call it the name of your new service and put it in /etc/init.d

The chkconfig: 235 section indicates the the default runlevels. For instance, if we called this script /etc/init.d/new-service and ran chkconfig new-service on, it would be active in runlevels 2,3 and 5.

The 98 and 55 numbers indicate the order of startup and kill. This means that using this tag, the startup symbolic link would be named S98new-service and the symbolic link to kill the process would be named K55new-service.

#### SNIP ####

#! /bin/sh
# Basic support for IRIX style chkconfig
###
# chkconfig: 235 98 55
# description: Manages the services you are controlling with the chkconfig command
###

case "$1" in
  start)
        echo -n "Starting new-service"
        #To run it as root:
        /path/to/command/to/start/new-service
        #Or to run it as some other user:
        /bin/su - username -c /path/to/command/to/start/new-service
        echo "."
        ;;
  stop)
        echo -n "Stopping new-service"
        #To run it as root:
        /path/to/command/to/stop/new-service
        #Or to run it as some other user:
        /bin/su - username -c /path/to/command/to/stop/new-service
        echo "."
        ;;

  *)
        echo "Usage: /sbin/service new-service {start|stop}"
        exit 1
esac

exit 0

#### /SNIP ####

Obviously change all instances of “new-service” to the name of your actual service… Enjoy!

<< end quote >>