Tag Archives: RHEL

How to check the source code in RHEL ?

If you guys like to dig more about the RHEL issue then Redhat is now providing the wonderful utility to see the code.

Below link, one Destination for most of the answers šŸ™‚

https://access.redhat.com/labs/

Search for “RED HAT CODE BROWSER” and click on “Go to App”

Or

Use the below link directly.

https://access.redhat.com/labs/psb/

Select the kernel version then fs (if you want to check the code for any filesystem). All the filesystems are present inside the fs. In below link I am at CIFS readdir code.

https://access.redhat.com/labs/psb/versions/kernel-3.10.0-229.4.2.el7/fs/cifs/readdir.c

It will show you all the struct and functions on left hand side.

Advertisements

How to Fix issue with File system Superblock in Red Hat Linux

Sometimes the file system superblock is getting corrupted. In worst case scenario we are also not able to run the file system check. By default file system check will be performed the on the superblock located at 0.
But nothing to worry as we know the superblock is having multiple copies saved at different locations in a file system. We can use those copies to to run the e2fsck on file system or to mount the file system.

Now the question arises

  • How would we come to know about the location of copies of superblock?
  • How can we run the file system check using another copy of superblock?
  • How can we mount the file system using another copy of superblock?

In this article I am going to address all these questions.

I have one file system of 19G on which I am going to perform all the actions.

Question 1 : How would we come to know about the location of copies of superblock?

Answer 1 : dumpe2fs and mke2fs commands can be used to know about superblock.

dumpe2fs : This command can be used on mounted file system as well means the file systems which are working absolutely fine.

After running this command you will get to know each and every term associated with file system from that platheora of information you can capture only superblock information.

[root@node1 ~]# dumpe2fs /dev/mapper/VolGroup01-VolLV01 | grep -i superblock
dumpe2fs 1.41.12 (17-May-2010)
Primary superblock at 0, Group descriptors at 1-2
Backup superblock at 32768, Group descriptors at 32769-32770
Backup superblock at 98304, Group descriptors at 98305-98306
Backup superblock at 163840, Group descriptors at 163841-163842
Backup superblock at 229376, Group descriptors at 229377-229378
Backup superblock at 294912, Group descriptors at 294913-294914
Backup superblock at 819200, Group descriptors at 819201-819202
Backup superblock at 884736, Group descriptors at 884737-884738
Backup superblock at 1605632, Group descriptors at 1605633-1605634
Backup superblock at 2654208, Group descriptors at 2654209-2654210
Backup superblock at 4096000, Group descriptors at 4096001-4096002

mke2fs : This command should be run on unmounted file system. NOTE : Don’t run this command without -n option.

[root@node1 ~]# mke2fs -n /dev/mapper/VolGroup01-VolLV01
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1245184 inodes, 4980736 blocks
249036 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
152 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000

SoĀ first most important question is answered.

Question 2 : How can we run the file system check using another copy of superblock?

Answer 2 : As we were not able to run the file system check on superblock at 0 location. Hence we proceed with file system check on superblock at 32768(Value taken from Step1 output).

Able to run the file system check on copy of superblock.

[root@node1 ~]# e2fsck -b 32768 /dev/mapper/VolGroup01-VolLV01
e2fsck 1.41.12 (17-May-2010)
One or more block group descriptor checksums are invalid. Fix<y>? yes

Group descriptor 0 checksum is invalid. FIXED.
Group descriptor 1 checksum is invalid. FIXED.
Group descriptor 2 checksum is invalid. FIXED.
Group descriptor 3 checksum is invalid. FIXED.
Group descriptor 4 checksum is invalid. FIXED.

Question 3 : How can we mount the file system using another copy of superblock?

Answer 3 : As we are not able to mount the file system using default superblock which starts at 0. We will try to mount the file system copy of superblock.

[root@node1 ~]# mount -o sb=98304 /dev/mapper/VolGroup01-VolLV01 /var/crash1

Tip : One useful command to determine when the file system is created and last mount time”

[root@node1 ~]# dumpe2fs -h /dev/mapper/vg_node1-lv_root | grep -E “Filesystem created|Last mount time”
dumpe2fs 1.41.12 (17-May-2010)
Filesystem created: Fri May 9 15:05:30 2014
Last mount time: Thu Jun 26 22:37:06 2014

 

Comparison or Analogy in pkg (Solaris 11) and yum (RHEL) commands.

Purpose Ā RHEL Solaris 11.1 Remarks
Check available Repostiories on server. yum repolist all pkg publisher
Check whether update of packages are available yum check-update pkg update -nv
To install the package on server yum install <pkg-name> pkg install <pkg-name>
To list the available and installed packages yum list pkg list
To get the information related to package yum info ftp pkg info <pkg-name>
To search the package yum search <pkg-name> pkg search <lot of options> https://ervikrant06.wordpress.com/2014/06/17/solaris-11-pkg-repository-commands-cheat-sheet-part-3/
Remove the package from server. yum remove <pkg-name> pkg uninstall <pkg-name>
Check the history yum history pkg history
Repository Information yum repoinfo pkgrepo info -s <URI>
Checking dependencies yum deplist <pkg-name> pkg contents or pkg search https://ervikrant06.wordpress.com/2014/06/17/solaris-11-pkg-repository-commands-cheat-sheet-part-3/
To downgrade the version of package yum downgrade pkg mediator <options> If multiple version of packages are installed in solaris 11
Which file belongs to package yum provides <filename> pkg contents <options> https://ervikrant06.wordpress.com/2014/06/17/solaris-11-pkg-repository-commands-cheat-sheet-part-3/

How to Configure Network Teaming in RHEL 7 ?

Network Teaming in RHEL 7 is not replacement of bonds. But it’s alternate option depending upon the requirement. In this post I am going to show you how to create teamĀ using two ethernet interfaces. I am creating it using static network configuration files.

Step 1 : I have create configuration file for team. Below is the content of that file.

[root@node1 ~]# more /etc/sysconfig/network-scripts/ifcfg-team0
DEVICE=team0
DEVICETYPE=Team
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.120.11
NETMASK=255.255.255.0
TEAM_CONFIG='{“runner”: {“name”: “activebackup”}, “link_watch”: {“name”:”ethtool”}}’

Step 2 : After that I have configured the files for two interfaces which are going to part of team configuration.I have given one priority of 100 and 99 to another interface.

[root@node1 ~]# more /etc/sysconfig/network-scripts/ifcfg-ens38
DEVICE=ens38
HWADDR=00:0c:29:9e:4c:f7
DEVICETYPE=TeamPort
ONBOOT=yes
TEAM_MASTER=team0
TEAM_PORT_CONFIG='{“prio”: 100}’

[root@node1 ~]# more /etc/sysconfig/network-scripts/ifcfg-ens39
DEVICE=ens39
HWADDR=00:0c:29:9e:4c:01
DEVICETYPE=TeamPort
ONBOOT=yes
TEAM_MASTER=team0
TEAM_PORT_CONFIG='{“prio”: 99}’

Step 3 : After configuing configuration files. We can restart the network service.

[root@node1 ~]# systemctl restart network

Step 4 : In the output of ifconfig you can see the team0 will come up. Now to check the whether our configuration is as expected. We can issue the below commands.

a) How to check which NICs are part of team ?

[root@node1 network-scripts]# teamnl team0 ports
5: ens39: up 1000Mbit FD
4: ens38: up 1000Mbit FD

b) How to check which NIC is currently working actively in team ?

[root@node1 network-scripts]# teamdctl team0 state
setup:
runner: activebackup
ports:
ens38
link watches:
link summary: up
instance[link_watch_0]:
name: ethtool
link: up
ens39
link watches:
link summary: up
instance[link_watch_0]:
name: ethtool
link: up
runner:
active port: ens38

From above output we clearly see that ens38 is our active NIC.

c) How to check the fail over in team?

[root@node1 network-scripts]# ip link set ens38 down

[root@node1 network-scripts]# teamdctl team0 state view
setup:
runner: activebackup
ports:
ens38
link watches:
link summary: down
instance[link_watch_0]:
name: ethtool
link: down
ens39
link watches:
link summary: up
instance[link_watch_0]:
name: ethtool
link: up
runner:
active port: ens39

We can see that active port has changed to another NIC ens39 when we manually bring down the ens38. That means our team0 is working as expected. Very soon I will come up with Bridge configuration as well.