Archive for the ‘Linux/Linux kernel’ Category

Mount LVM based volumes from a loopback device (disk image)

December 15, 2010 Leave a comment

Recently I needed to extract some files from the root partition in a full disk backup image taken with dd. I didn’t notice when I took the disk image, but the disk only contained two primary partitions: /boot and an LVM physical volume containing the rest of the partitions as LVM logical volumes. I don’t work with LVM much manually, so I had to look up the commands to get it to find physical volumes and activate volume groups. Here’s the full process of mounting LVM logical volumes from a full disk image:

There are two ways to get to the LVM partition on this disk, and I’ll cover both: 1) the manual offset finding way and 2) the easy way.
First, the easy way: make sure the loopback module is inserted with the max_part parameter, which causes the automatic creation of loopback subdevices for individual partitions. An easy way to make sure is to remove it and re-insert with the right parameter: modprobe -r loop && modprobe loop max_part=63
Next, mount the whole disk image loopback: losetup /dev/loop0 sda.img. Now you should see /dev/loop0p1,/dev/loop0p2, etc. for all of the individual partitions. Now you’re already done — you can go directly to the next section to deal with LVM directly.
If you can’t do the easy method, mount the whole disk image loopback to look at the partition offsets: losetup /dev/loop0 sda.img
Now that /dev/loop0 looks just like the block device image, so check out the partition table sector offsets with fdisk: fdisk -u -l /dev/loop0. I use sector offsets (-u flag) rather than cylinders because they are easier to work with and some partitions may not fall on cylinder boundaries. My image shows something like this:
Disk /dev/loop0: 250 GB, 250056737280 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488392065 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/loop0p1 * 63 401624 200781 83 Linux
/dev/loop0p2 401625 488392064 243987187 8e Linux LVM
Now, remove the whole disk image from /dev/loop0: losetup -d /dev/loop0 and set /dev/loop0 to just the LVM partition by adding the partition offset. Here, the second partition starts at sector 401625, and each sector is 512 bytes, so the offset is 205632000. Run losetup /dev/loop0 sda.img -o205632000
Now whichever method you used, you have a loopback device with the LVM physical volume partition: /dev/loop0p? (2 in my case) if you used the easy way, or /dev/loop0 if you used the manual offset method. Get LVM to recognize the physical volume and activate the volume groups:

Tell LVM to scan for new physical volumes: lvm pvscan
Activate the volume groups: lvm vgchange -ay (it will print something like 2 logical volume(s) in volume group “VolGroup00” now active).
Now you can finally mount the LVM logical volumes. Run lvm lvs to list the logical volumes. Each should appear in /dev/mapper, typically with the device name (volume group name)-(logical volume name), like VolGroup00-LogVol00.
When you are done, unmount all logical volumes and deactivate the volume groups with lvm vgchange -an. Now you can reclaim the loopback device by using losetup -d /dev/loop0.

Copied from :

Categories: Linux/Linux kernel

How to find out which package a file belongs to

August 6, 2010 Leave a comment

If you want to figure out which package a file belongs to you can use rpm to find out (On a system that uses rpm). Which package does /bin/bash belong to?

[root@host ~]# rpm -qf /bin/bash

So /bin/bash belongs to bash-3.0-19.3

The -q option lets rpm know that you want to do a query of the database. The f lets you query the package containing the file you specify.

Here’s another query:

[root@host ~]# rpm -qf /usr/bin/xargs
[root@host ~]#

yum lets you get info on the findutils package:

[root@host ~]# yum info findutils
Setting up repositories
update 100% |=========================| 951 B 00:00
rpmforge 100% |=========================| 1.1 kB 00:00
base 100% |=========================| 1.1 kB 00:00
addons 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
Installed Packages
Name : findutils
Arch : i386
Epoch : 1
Version: 4.1.20
Release: 7.el4.1
Size : 231 k
Repo : installed
Summary: The GNU versions of find utilities (find and xargs).

The findutils package contains programs which will help you locate
files on your system. The find utility searches through a hierarchy
of directories looking for files which match a certain set of criteria
(such as a filename pattern). The xargs utility builds and executes
command lines from standard input arguments (usually lists of file
names generated by the find command).

You should install findutils because it includes tools that are very
useful for finding things on your system.

So, if you are using a system that uses RPM/YUM, you can easily find out the packages that files on your filesystem belong to

Categories: Linux/Linux kernel

Linux Git repo

July 19, 2010 Leave a comment

#git clone git:// linux-2.6

Git repository quick howto:

Categories: Linux/Linux kernel

Find the offsets of data structures easily

July 19, 2010 Leave a comment

From Kaz Kylheku’s post in LKML:

Categories: Linux/Linux kernel

signal handlers are executed in the context of their own private stack frame

July 19, 2010 Leave a comment

See arch specific setup_frame() function in the kernel. For mips, it installs the signal trampoline, the user context (the registers) and the siginfo (when appropriate). The trampoline is just a syscall trap to the kernel to call sigreturn(). The address of the trampoline is set in the RA register, the arguments (signr, siginfo and the signal context) in registers 4, 5 and 6 respectively, pc points to the sighandler, reg# 29 (stack ptr) points to the allocated stack frame and off you go! On completion of the handler, the user land code returns to the address pointed to by RA register which has the trampoline. This it traps to the kernel in sysexit() syscall and this syscall then restores the user context through the saved register set, saved earlier in reg# 6.

Categories: Linux/Linux kernel

malloc() does not necessarily unmap free’d pages

July 19, 2010 Leave a comment

Glibc’s malloc uses a combination of brk() and mmap() (where available) system calls depending upon the size of the chunk being allocated and some other factors like holes in the address space. a brk() only increases the data segment of a process in turn increasing the address space of that process. When you free() it, libc only marks this chunk as un-available but it still remains mapped. If malloc() uses mmap(), a free would so a munmap() and then later on accessing a freed memory will result in a seg-fault.

There’s a comment in glibc’s mmap.c that says:

Define HAVE_MMAP as true to optionally make malloc() use mmap() to
allocate very large blocks.  These will be returned to the
operating system immediately after a free(). Also, if mmap
is available, it is used as a backup strategy in cases where
MORECORE fails to provide space from system.

This malloc is best tuned to work with mmap for large requests.
If you do not have mmap, operations involving very large chunks (1MB
or so) may be slower than you'd like.

The default mmap() threshold is 128*1024 bytes (or 128 KB). This value can be changed using mallopt() glibc call:

Enhanced by Zemanta