Linux login issue - Can not login: Resource temporarily not available

Sometime we get following error while user login:

$su - username
Coud not login: Resource temporarily not available

Most of the times this is because of processes or number of files available to user is already used. So, could not arrange more files/processes to login, in this case we required to increase the limits for user in /etc/security/limits.conf (PAM module)

username        soft    nproc           3000
username        hard    nproc          4096
username        soft     nofile           6000
username        hard    nofile          8192


Set these values as per requirement else setting up these values higher may result in server inaccessible in case that particular uses all file descriptors, process and higher memory of server.

Linux Resize LUN Without Reboot

Try running following commands

Check OS using what devices for attached LUNs:

multipath -l

mpath5 (360060.......................) dm-15

[size=100G][features=1 queue_if_no_path][hwhandler=1 emc][rw]

\_ round-robin 0 [prio=0][active]

 \_ 1:0:0:14 sdb 66:192 [active][undef]

 \_ 0:0:0:14 sdc  8:224  [active][undef]

\_ round-robin 0 [prio=0][enabled]

 \_ 0:0:1:14 sdd 66:112 [active][undef]

 \_ 1:0:1:14 sde 67:176 [active][undef]

Rescan all paths:

echo 1 > /sys/block/sdb/device/rescan

echo 1 > /sys/block/sdc/device/rescan

echo 1 > /sys/block/sdd/device/rescan

echo 1 > /sys/block/sde/device/rescan

Then run:

       
partprobe

multipathd -k

resize map mpath5

If LVM is used, also required following:

#pvscan

Check Disk Changes detected under LVM:

#pvs

#vgscan

  Check VG Size is Increased:

#vgs

Now Extend the LV: 

#lvextend -L +G

Finally Extend the File System

#resize2fs

Thats it!!! 

Redhat Linux : Rollback RPMs

RPM Rollback for Redhat 5.x versions

1) Create a file /etc/rpm/macros and put following

cat >> /etc/rpm/macros
%_repackage_all_erasures 1

2) Add following at the end of /etc/yum.conf

echo "tsflags=repackage" >> /etc/yum.conf

After above entries, we can rollback rpms installed using yum

3) Now update system with single rpm or complete using

yum update

4) Lets say we had update rpms 1 hour, 2 month and 1 day ago and wants to remove all those then use following commands:

rpm --rollback "1 day ago"
rpm --rollback "1hour ago"
rpm --rollback "2 month ago"


Will be posting for Redhat 6.x version soon.......

Redhat Device Mapper Multipathing

                                           REDHAT DEVICE MAPPER MULTIPATH



                                  

1) DM Software Installation


yum install device-mapper-multipath


2) Initialize /etc/multipath.conf file


mpathconf --enable


3) Start multipath service

service multipathd start


4) If you do not want to use user friendly name


mpathconf --enable --user_friendly_names n


5) Ignoring Local Disks when generating Multipath devices


multipath -v2 (shows local disk, /dev/sda, in the multipath map)


create: SIBM-ESXSST336732LC____F3ET0EP0Q000072428BX1 undef WINSYS,SF2372 size=33 GB features="0" hwhandler="0" wp=undef `-+- policy='round-robin 0' prio=1 status=undef
- 0:0:0:0 sda 8:0 [---------



device-mapper ioctl cmd 9 failed: Invalid argument device-mapper ioctl cmd 14 failed: No such device or address

create: 3600a0b80001327d80000006d43621677 undef WINSYS,SF2372 size=12G features='0' hwhandler='0' wp=undef `-+- policy='round-robin 0' prio=1 status=undef
- 2:0:0:0 sdb 8:16 undef ready running `- 3:0:0:0 sdf 8:80 undef ready running



create: 3600a0b80001327510000009a436215ec undef WINSYS,SF2372 size=12G features='0' hwhandler='0' wp=undef `-+- policy='round-robin 0' prio=1 status=undef
- 2:0:0:1 sdc 8:32 undef ready running `- 3:0:0:1 sdg 8:96 undef ready running



In order to prevent the device mapper from mapping /dev/sda in its multipath maps, edit blacklist section in /etc/multipath.conf

blacklist {

wwid SIBM-ESXSST336732LC____F3ET0EP0Q000072428BX1

}


6) After updating file reload the changes


service multipathd reload


7) Run following command to remove multipath device

multipath -f SIBM-ESXSST336732LC____F3ET0EP0Q000072428BX1


8) Now check if device removed from multipath


multipath

create: 3600a0b80001327d80000006d43621677 undef WINSYS,SF2372 size=12G features='0' hwhandler='0' wp=undef `-+- policy='round-robin 0' prio=1 status=undef
- 2:0:0:0 sdb 8:16 undef ready running `- 3:0:0:0 sdf 8:80 undef ready running


create: 3600a0b80001327510000009a436215ec undef WINSYS,SF2372 size=12G features='0' hwhandler='0' wp=undef `-+- policy='round-robin 0' prio=1 status=undef
- 2:0:0:1 sdc 8:32 undef ready running `- 3:0:0:1 sdg 8:96 undef ready running


...

....

...


9) Add storage that is not supported by default as a know multipath device lets say "Vendor is HP, Product Open-V"

To add information about the HP Open-V series the entry looks like this, where %n is the device name. Add following in /etc/multipath.conf file

devices {

device {

vendor "HP"

product "OPEN-V."

getuid_callout "/lib/udev/scsi_id --whitelisted --device=/dev/%n"

}

}


To be continued..............

GRUB Image Files

GRUB consists of several images: a variety of bootstrap images for starting GRUB in various ways, a kernel image, and a set of modules which are combined with the kernel image to form a core image. Here is a short overview of them:

boot.img

On PC BIOS systems, this image is the first part of GRUB to start. It is written to a master boot record (MBR) or to the boot sector of a partition. Because a PC boot sector is 512 bytes, the size of this image is exactly 512 bytes.

The sole function of boot.img is to read the first sector of the core image from a local disk and jump to it. Because of the size restriction, boot.img cannot understand any file system structure, so grub-setuphardcodes the location of the first sector of the core image into boot.img when installing GRUB. 

diskboot.img

This image is used as the first sector of the core image when booting from a hard disk. It reads the rest of the core image into memory and starts the kernel. Since file system handling is not yet available, it encodes the location of the core image using a block list format. 

cdboot.img

This image is used as the first sector of the core image when booting from a CD-ROM drive. It performs a similar function to diskboot.img. 

pxeboot.img

This image is used as the start of the core image when booting from the network using PXE. See Network. 

lnxboot.img

This image may be placed at the start of the core image in order to make GRUB look enough like a Linux kernel that it can be booted by LILO using an ‘image=’ section. 

kernel.img

This image contains GRUB's basic run-time facilities: frameworks for device and file handling, environment variables, the rescue mode command-line parser, and so on. It is rarely used directly, but is built into all core images. 

core.img

This is the core image of GRUB. It is built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program. Usually, it contains enough modules to access /boot/grub, and loads everything else (including menu handling, the ability to load target operating systems, and so on) from the file system at run-time. The modular design allows the core image to be kept small, since the areas of disk where it must be installed are often as small as 32KB.

Initrd.img

initrd (initial ramdisk) is a scheme for loading a temporary file system into memory in the boot process of the Linux kernel. initrd and initramfs refer to slightly different methods of achieving this. Both are commonly used to make preparations before the real root file system can be mounted.

How to password protect GRUB?

There are only 3 steps to password protect users to edit grub properties while system booting:

1) Run following command to generate MD5 encrypted password:


root@localhost# grub-md5-crypt
Password:
Retype password:
$1$yAr5c0$ZYlcLULaS2rwOvry1B4gX/


2) Copy MD5 encrypted password of above command

3) Paste copied MD5 encrypted password in menu.list/grub.conf file :

default = 0
timeout=5
password --md5 $1$yAr5c0$ZYlcLULaS2rwOvry1B4gX/

Thats it!!!

Now whenever user's try to run GRUB commands or try to change booting parameters at the time of BOOT, above entered text password will be required!!

Linux : How To Recover From Bad SuperBlock Corrupted Ext3 File System??

I was getting following error:

/dev/cciss/c0d0p1: Input/output error

mount: /dev/cciss/c0d0p1: can't read superblock

In case you are also facing the same error with superblocks, you can follow below given steps to recover superblock:

#### dumpe2fs  /dev/cciss/c0d0p1|grep -i superblock

dumpe2fs 1.39 (29-May-2006)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super
  Primary superblock at 1, Group descriptors at 2-2
  Backup superblock at 8193, Group descriptors at 8194-8194
  Backup superblock at 24577, Group descriptors at 24578-24578
  Backup superblock at 40961, Group descriptors at 40962-40962
  Backup superblock at 57345, Group descriptors at 57346-57346
  Backup superblock at 73729, Group descriptors at 73730-73730


Above command output showing back'd up superblock. Now we need to restore from these superblocks

#### fsck -b 8193 /dev/cciss/c0d0p1

If still showing any error continue to restore with next Backup superblock i.e;  24577, 40961 etc....

After successful completion of above command i.e; output will be like this

Free blocks count wrong for group #362 (32254, counted=32248).
Fix? yes
Free blocks count wrong for group #368 (32254, counted=27774).
Fix? yes
..........

/dev/cciss/c0d0p1: ***** FILE SYSTEM WAS MODIFIED *****

 /dev/cciss/c0d0p1: 59586/30539776 files (0.6% non-contiguous), 3604682/61059048 blocks

Now mount your file system

##### mount  /dev/cciss/c0d0p1 /mnt

Thats it!!!