New Linux Kernel: Couldn’t find PV pv n. Check your device.map

When upgrading to a new kernel on Debian this error can present itself if you have previously added an extra drive to your LVM pool without having updated the /boot/grub/device.map.

The simplest way to get round this is to backup your current device.map file, delete the original and then run..

$# sudo update-grub

followed by trying to run the kernel install again.

If this hasn’t solved your issue you may have to add the new drive to the device.map file manualy

$# cat /boot/grub/device.map

(hd0) /dev/disk/by-id/ata-VBOX_HARDDISK_VBfdab3e2d-25850c00

(as you can see in this example only one drive is listed.)

$# sudo nano /boot/grub/device.map

<I would add the following line at the end of the file>

(hd1) /dev/device

(device can be eiher the standard /dev/sdxn or could be by id as per the first entry of the device.map file)

[ If this post helped you, please rate or leave a comment. ]

Enabling file ACL’s in Debian 6 (Access control lists)

I’ve been brushing up on my knowledge of Linux ACL’s this morning and thought I’d share some of the highlights with you.

Those of you with a Unix or Windows Server background will be well versed with the idea of access control lists on-top of basic file permissions but it seems to be something, which even today is less extensively used in the Linux world.

In a nutshell, for those unfamiliar with access control lists, they give you a finer granularity of control over  file or directory permissions than can be achieved with the standard Unix file permissions.

Take the following example for instance;

You have a number of users in you finance department who are all part of the ‘finance’ group, you also have a subset of these users who are involved with a special project and so are also members of the group ‘specialproject’. Out of those members of the ‘specialproject’ group, only John and Bob should have write access to the special project document but the others in the group should still be able to read the file.

With normal Unix permissions you could set the file to be owned by John and in the special project group with ‘rw’ permissions for the owner and just ‘r’ permissions for the group and your problem is solved for John and the special project group but not for Bob.

Now John and Bob could be added to yet another group and ‘rw’ permission  given to the file for that group but now as the file is owned by this new group instead of ‘specialgroup’ the rest of your special projects group have lost access.

This can be solved fairly trivially though by adding an ACL entry specifying Bob to have ‘rw’ access to the file which will over-ride the standard linux group permissions.

So, the standard Unix permissions would give John ‘rw’ access, the members of the ‘specialprojecct’ group ‘r’ access and then the ACL would specifically give Bob his ‘rw’ access to the file

(output of how the permissions would appear)

#$ ls -al

-rw-r—–+ 1 john specialproject 37 Feb 10 04:42 special_project_file

(notice the ‘+’ after the permissions, this specifies that an acl has been applied to this file)

(to check the acl entry you can do the following)

#$ getfacl /opt/t1/admin/finance_team/special_project_file
getfacl: Removing leading ‘/’ from absolute path names
# file: opt/t1/admin/finance_team/special_project_file
# owner: john
# group: specialproject
user::rw-
user:bob:rw-
group::r–
other::—

Despite ACL support being compiled in to both my custom kernel and the standard Debian version it was not enable at the filesystem level by default.

To do this you can enabled it until reboot/remount of your filesystem by running the following command.

#$ sudo mount -o remount,acl /

(replacing / with the filesystem which you wish to enable ACL’s for)

To enable this permanently you will need to edit you ‘/etc/fstab’ and add ‘acl’ to the list of options for each partitions it’s required on. In my case that meant changing the option ‘defaults’ to ‘acl,defaults’ for my ‘/’, ‘/home’, ‘/tmp’ directories, etc.

Now that your filesystem has ACL enabled you’ll need to grab the user-land tools to read and modify your ACL permissions.

#$ sudo apt-get install acl

This installs the following tools, ‘/bin/getfacl’, ‘/bin/setfacl’ and ‘/bin/chacl’ which can be used to manipulate and read back ACL settings. Information on using each of these can be looked up in ‘man’.

(a few examples of using these commands)

#$ setfacl -m user:john:rwx ./myfile (gives user john rwx access to myfile)

#$ setfacl -m group:admin:rw ./myfile (give the group admin rw access to myfile)

#$ getfacl ./myfile (display ACL entries for myfile)

 

(the following example creates a folder that will automatically propagates its acl permissions to all file contained within)

#$ mkdir shared_area

#$ setfacl -d -m u:john:7 shared_area

#$ setfacl -d -m u:bob:7 shared_area

#$ touch ./shared_area/testfile

#$ ls -al ./shared_area

drwxr-xr-x+ 2 john john 4096 Feb 10 14:08 .
drwxrwx— 6 john staff 4096 Feb 10 14:06 ..
-rw-rw-r–+ 1 john john 0 Feb 10 14:08 testfile

(and now to prove that the acl has been inherited to the new file we’ve just created)

#$ getfacl ./shared_area/testfile

# file: shared_area/testfile
# owner: john
# group: john
user::rw-
user:john:rwx #effective:rw-
user:bob:rwx #effective:rw-
group::r-x #effective:r–
mask::rw-
other::r–